日志很重要,但是不能直接用;写正则很崩溃,但是含泪也得上;前仆后继的各种尝试,然并卵;神器面世,大兄弟我来拯救你啦,亲测有效;最后,这个神器是一个开箱即用的盒子。
日志范式化为什么这么难?
一、日志范式化
日志就像机器与人之间、机器与机器之间对话的语言,人可以通过阅读日志,在大部分时候是可以通过对类似自然语言的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运维神器,让运维人员和“正则表达式”说拜拜!
本文来源：商讯
责任编辑：
陈体强_NB6485
