日志很重要，但是不能直接用；写正则很崩溃，但是含泪也得上；前仆后继的各种尝试，然并卵；神器面世，大兄弟我来拯救你啦，亲测有效；最后，这个神器是一个开箱即用的盒子。
日志范式化为什么这么难？
一、日志范式化
日志就像机器与人之间、机器与机器之间对话的语言，人可以通过阅读日志，在大部分时候是可以通过对类似自然语言的log的理解，获取到其中包含的有用信息。
而机器就很难使用同样的手段完成对日志的理解。通常都是通过范式化的方法，把日志中包含的关键信息提取出来，范式化以后再进行下一步处理，否则面对一堆杂乱无章的非范式化的日志，机器基本没有办法挖掘出其中的信息并加以利用，就是大家常说的GIGO：“garbage in，garbage out”。
二、日志范式化之痛
要实现日志的范式化，有2个前提条件，也是日志分析应用的2个门槛：
1.必须要了解日志的结构，即日志的schema，schema有2个主要作用：
·为数据定性，赋予意义，与业务场景对接，死数据变活数据：
比如有一列yyyy-mm-dd格式的数据，从格式看这是个日期，但是如果定性为用户最近一次登录日期，则可以结合其他数据进行用户分类，并使用不同策略进行运营。
·为数据定结构，提高使用者认识数据的效率，结构化的数据比非结构化数据更有利于理解：
为了了解日志结构及其内容含义，可以向开发团队或者系统厂商调研，索要文档。如果此路不通，只能通过人工看大量的日志样本，进行归纳猜测，耗时费力看运气，且结果的准确性并不能保证。例如：
12-01 20:56:10:988772| 866|datapool |5144608|从数据区中获取变量[acctseqno]错误！！！|
这条日志里，很难猜到“866”是什么意思，只有看过足够多的日志，才能归纳出866和后面的“从数据区中获取变量[acctseqno]错误！！！”是对应的，应该是错误号。目前在某些领域，特别是安全领域，提出统一日志格式（CEF），或者采用结构化数据（常用json）来输出日志。希望能够通过这些规范来降低日志解析的难度。从目前业界发展情况看，CEF已经形同虚设，而结构化日志输出也还处于起步阶段，绝大多数产品的日志还是非结构化的。
再举一个例子：
2014-12-01-00.16.18.847563|0|机构:10100,柜员:EBANK1|交易:852100|网银接口个人网银查询交易|交易成功|
这个日志已经足够结构化了（使用了竖线分割，并且内容是key-value结构），但是在其中的一个字段：“网银接口个人网银查询交易”，其实是可以分解为2个更精确的业务字段：网银接口+个人网银查询交易，分别是接口名和交易名，这目前只能通过人工看足够多的日志样本才能归纳出的结构。而这样的结构可能在一个系统里有成百上千个，人工工作量之大可想而知。
2.要把日志按照schema进行解析，提取字段。
目前schema解析最成熟的手段是正则表达式，最直接的实现方式是手工写，例如这样一条结构很简单的日志：
127.0.0.1 - - [10/Sep/2018:12:36:49 0800] GET /index.html HTTP/1.1 200 612 - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
对应的正则表达式是：
(\S )\s-\s(\S )\s\[([^]] )]\s (\S )\s(\S )\s(\S ) \s(\S )\s(\S )\s (\S ) \s ([^ ] ) .*
三、日志范式化传统解决办法
虽然正则表达式是目前主流的解析手段，但它的缺点还是显而易见的。看似天书的语法、性能差、可扩展性差、管理复杂，这些都是日志分析项目的梦魇，也让无数SOC、日志运维分析项目折戟在这个门槛外。
虽然splunk、sumologic等日志平台厂商也推出了schema on read或者schema on write等技术对正则表达式进行了封装，让它对用户透明，但这些都不是本质改变，没有根本解决难题。
华青融天神器面世轻松搞定日志范式化
一、EZLogic核心能力
华青融天创新推出一款与机器学习相结合的日志范式化工具——EZLogic就是解决日志范式化这个“老大难”的神器。
作为一款智能化产品，EZLogic通过机器学习模型，可识别海量、多样日志数据并进行智能解析，大量缩减人工成本，不再需要手工编写正则表达式，快速挖掘日志价值。填补了日志数据智能解析技术的国际空白，并取得国内发明专利授权。
二、EZLogic独特之处
数据共享，解析自治
“租户”是从SAAS借用的概念，不同租户对日志的解析是隔离的，互不影响。支持多租户是日志解析系统必备的功能，因为用户内部有不同的部门，根据他们各自的应用场景，对日志的解析需求有很大的差异，而且这个需求可能在不停的变化，很难靠一个集中管理的部门（例如数据中台部门）去快速应对这种多样化的需求。
对于大数据平台（数据中台）来说：日志数据实现了集中，解析难以集中。面对日志的各个应用部门变幻莫测的解析需求，如果由数据中台集中解析，数据中台团队将会疲于应付，如果由各应用团队自行解析，数据中台又价值何在？
再举一个例子，下面这条linux的系统日志：
37 sshd ( pam_unix ) [ 12799 ] : authentication failure ; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = 10.6.7.12 user = oracle
安全团队需要解析其中每个key-value字段，并且还要加上一个事件类型字段，来标记这是一个鉴权失败类事件，用于触发某条安全审计规则。而运维团队可能只需要解析“sshd”，而不需要日志内容的其他具体字段。
因此，各部门对日志解析的自治成为一个强烈的需求。相对一般SAAS服务的以数据自治为目的的多租户功能，多租户并不是简单的将原始日志按照应用场景进行复制和分发，否则日志的解析将重复工作量，租户变多以后会给系统带来额外的负载，影响系统的可扩展性。
我们将一类日志输入多个租户（场景）自定义范式化标准，从而实现1 TO N租户（场景）日志有效范式化内容输出，满足更多用户和运维场景需求。其架构如下，通过在消息系统层完成对数据的实时动态范式化能力。
三、EZLogic落地实践
某全国性的大型股份制商业银行采用了华青融天EZLogic产品，实现以日志、事件为驱动的安全运营平台框架建设。
目前已采集全行整个网络设备、安全设备、主机系统等与信息安全相关的日志信息，每天收集日志量达到200G-300G/日；将原本需要10位运维工程师处理缩减至5位即可完成，为运维工作减少一半以上工作量，并且还在逐步提升，极大的提高运维工程师的效率、节省了人力。
EZLogic是一个盒子
EZLogic作为一个开箱即用的盒子，真正做到了海量日志解析轻松搞定，成为IT运维神器，让运维人员和“正则表达式”说拜拜！
