邦吉洛德斯全球首发有机OPO,引领有机婴配奶粉行业新突破 | 媒体人梁志镅:一个产品要形成广泛的认识需靠品牌广告引爆 | 广联达刘谦:“产业+数字” 融合发展将催生建筑产业新生态 | 异地评标新提升 项目远程跨市评 | 2021服贸会唯一亮相重卡 欧曼银河携福康A系列超级动力链向世界展示最“潮”技术 | 60%重点渠道铺货率提升!Trax为医药企业渠道检查注入新动力 | 呵护花开,给留守女孩上青春课 | 和“正则表达式”说拜拜!华青融天EZLogic日志精灵带你轻松搞定日志结构化,摆脱枯燥,拥抱幸福! | 让数据更有温度,华青融天可观察性平台助力客户 成功破解“黑客攻击” | 神经元比想象的更聪明 |
 
当前位置: 新闻>滚动>

华青融天EZLogic日志精灵带你轻松搞定日志结构化,摆脱枯燥,拥抱幸福!

发布时间:2021-09-07 10:01:47  |  来源:中国网科学  |  作者:张铭阳  |  责任编辑:科学频道

日志很重要,但是不能直接用;写正则很崩溃,但是含泪也得上;前仆后继的各种尝试,然并卵;神器面世,大兄弟我来拯救你啦,亲测有效;最后,这个神器是一个开箱即用的盒子。

日志范式化为什么这么难?

一、日志范式化  

日志就像机器与人之间、机器与机器之间对话的语言,人可以通过阅读日志,在大部分时候是可以通过对类似自然语言的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通过机器学习模型,可识别海量、多样日志数据并进行智能解析,大量缩减人工成本,不再需要手工编写正则表达式,快速挖掘日志价值。填补了日志数据智能解析技术的国际空白,并取得国内发明专利授权。

image.png

二、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租户(场景)日志有效范式化内容输出,满足更多用户和运维场景需求。其架构如下,通过在消息系统层完成对数据的实时动态范式化能力。

image.png

三、EZLogic落地实践  

某全国性的大型股份制商业银行采用了华青融天EZLogic产品,实现以日志、事件为驱动的安全运营平台框架建设。

目前已采集全行整个网络设备、安全设备、主机系统等与信息安全相关的日志信息,每天收集日志量达到200G-300G/日;将原本需要10位运维工程师处理缩减至5位即可完成,为运维工作减少一半以上工作量,并且还在逐步提升,极大的提高运维工程师的效率、节省了人力。

EZLogic是一个盒子

EZLogic作为一个开箱即用的盒子,真正做到了海量日志解析轻松搞定,成为IT运维神器,让运维人员和“正则表达式”说拜拜!