黄俊毅-海量日志搜索分析技术及行业应用案例-日志易.pdf

海量日志搜索分析技术及行业应用案例
日志易黄俊毅
IT运维分析
ª 从 IT Operation Management (ITOM) 到 IT Operation Analytics (ITOA)
ª 大数据技术应用于IT运维,通过数据分析提升IT运维
ª Gartner估计,到2017年15%的大企业会积极使用ITOA;而在2014年这一数字只有5%
ITOA 4种数据占比
100% 93%
86%
80% 72%
60%
47%
40%
20%
0%
machine data(日志) wire data(网络抓包) agent data(插入代码) probe data(模拟检测)
ITOA 四种数据来源的比较
机器数据(日志) 通信数据(网络抓代理数据(嵌入代探针数据(模拟用
日志无所不在包) 码) 户请求)
但不同应用输出的日网络流量信息全面代码级精细监控端到端监控
志内容的完整性、可但一些事件未必触发但侵入性,会带来安但不是真实用户度量
用性不同网络流量全、稳定、性能问题(Real User
Measurement)
日志,我们重要的数据资产
clientIP timestamp method uri
- - [15/Apr/2015:00:27:19 +0800] “POST /report HTTP/”
200 21 “https:///search/”“Mozilla/ (Windows NT ; WOW64;
rv:) Gecko/20100101 Firefox/”“”
status length reference
span
过去
存储日志性能方面
l 无法适应每天TB级海量日志
l 数据库的schema无法适应千变万化的日志
格式
l 无法提供海量日志全文检索和字段统计功能
运维方面
l 需要登陆每一台服务器,使用脚本命
安全方面
令或程序查看,操作繁琐,容易出错
l ***后往往会删除/修改
l 数据是孤立分散的,无法进行关联,
日志,抹除入侵痕迹,导致无
无法提取出其中的共性
法通过日志分析攻击行为
l 只能做简单搜索和统计,无法满足分
l 海量的ids/waf报警,根本无
析要求
法辨别是否是误报
l 没有实时监控和报警,如程序出错日
志
近年
l 批处理,不够及时
l 查询慢
Hadoop l 数据离线挖掘,无法做 OLAP
(On Line Analytic Processing)
Storm 都只是一个开发框架,不是拿
/Spark 来即用的产品
NoSQL 不支持全文检索
现在
非结构化大
Fast big data
能处理所有机器数据,能适每天处理 TB 级的日志量,
应各种日志格式,而无需对数十TB的日志只需几秒就实时大数据
原有日志进行改造能搜索出结果无缝横向扩展
丰富对外接口
01 02 03 04 05
快灵活
日志从产生到搜 Google for IT,
索分析出结果只可搜索、分析任
有几秒的延时何日志
日志管理系统演进
04
03
NG 日志
02 l 机器学****br/> 实时搜索分
01 析 l 人工智能
Hadoop/
l 实时
Nosql
数据库 l 灵活
l 需要开发成本
l 固定的schema无 l 全文检索
l 批处理,实时性差
法适任意日志格式
l 不支持全文检索
l 无法处理大数据量
日志管理核心技术
Schema on Write
l 索引时(入库前)抽取字段,对日志做结构化
l 检索速度快
l 但不够灵活,必须预先知道日志格式
Schema on Read
l 检索时(入库后)抽取字段,对日志结构化
l 灵活,检索时根据需要抽取字段
l 但检索速度受影响
日志管理核心技术
搜索处理语言(Search Processing
Language, SPL)
l SPL命令用管道符(“|”)串接成脚本程序
l 在搜索框里写 SPL 脚本,完成复杂的查询分析
用一条SPL语法解决复杂的聚合逻辑,以缴费业务关联分析为例:
:“/charge/?BMEBusiness=&_cnt