《海量日志搜索分析技术及应用案例》由会员分享，可在线阅读，更多相关《海量日志搜索分析技术及应用案例（24页珍藏版）》请在金锄头文库上搜索。
1、,海量日志搜索分析技术及应用案例,86%,93%,47%,72%,40% 20% 0%,60%,80%,100%,machine data（日志）,wire data（网络抓包）,agent data（插入代码）,probe data（模拟检测）, 从 IT Operation Management (ITOM) 到 IT Operation Analytics (ITOA) 大数据技术应用于IT运维，通过数据分析提升IT运维 Gartner估计，到2017年15%的大企业会积极使用ITOA；而在2014年这一数字只有5% ITOA 4种数据占比,IT运维分析,ITOA 四种数据来源的比较,机
2、器数据（日志） 日志无所不在 但不同应用输出的日 志内容的完整性、可 用性不同,通信数据（网络抓 包） 网络流量信息全面 但一些事件未必触发 网络流量,代理数据（嵌入代 码） 代码级精细监控 但侵入性，会带来安 全、稳定、性能问题,探针数据（模拟用 户请求） 端到端监控 但不是真实用户度量 （Real User Measurement）,日志，我们重要的数据资产,180.150.189.243 - - 15/Apr/2015:00:27:19 +0800 “POST /report HTTP/1.1” 200 21 “ “Mozilla/5.0 (Windows NT 6.1; WOW64;
3、rv:37.0) Gecko/20100101 Firefox/37.0” “10.10.33.174” 0.005,clientIP,timestamp,method,uri,status,length,reference,span,过去,安全方面 黑客入侵后往往会删除修改 日志，抹除入侵痕迹，导致无 法通过日志分析攻击行为 海量的idswaf报警，根本无 法辨别是否是误报,存储日志性能方面, 无法适应每天TB级海量日志 数据库的schema无法适应千变万化的日志 格式 无法提供海量日志全文检索和字段统计功能,运维方面 需要登陆每一台服务器，使用脚本命 令或程序查看，操作繁琐，容易出错 数据
4、是孤立分散的，无法进行关联， 无法提取出其中的共性 只能做简单搜索和统计，无法满足分 析要求 没有实时监控和报警，如程序出错日 志,近年,都只是一个开发框架，不是拿 来即用的产品,Storm /Spark,批处理，不够及时,查询慢 数据离线挖掘，无法做 OLAP (On Line Analytic Processing),Hadoop,不支持全文检索,NoSQL,现在,030405,非结构化 能处理所有机器数据，能适 应各种日志格式，而无需对 原有日志进行改造 0102,大 每天处理 TB 级的日志量， 数十TB的日志只需几秒就 能搜索出结果,Fast big data 实时大数据 无缝横向扩
5、展 丰富对外接口,快 日志从产生到搜 索分析出结果只 有几秒的延时,灵活 Google for IT， 可搜索、分析任 何日志,01,02,04 03,日志1.0 数据库 固定的schema无 法适任意日志格式 无法处理大数据量,日志2.0 Hadoop Nosql 需要开发成本 批处理，实时性差 不支持全文检索,日志3.0 实时搜索分 析 实时 灵活 全文检索,NG 日志 机器学习 人工智能,日志管理系统演进,日志管理核心技术,Schema on Write 索引时（入库前）抽取字段，对日志做结构化 检索速度快 但不够灵活，必须预先知道日志格式 Schema on Read 检索时（入库后）
6、抽取字段，对日志结构化 灵活，检索时根据需要抽取字段 但检索速度受影响,日志管理核心技术,搜索处理语言 （Search Processing Language, SPL） SPL命令用管道符（“|”）串接成脚本程序 在搜索框里写 SPL 脚本，完成复杂的查询分析 用 一 条 SPL 语 法 解 决 复 杂 的 聚 合 逻 辑 ， 以 缴 费 业 务 关 联 分 析 为 例 ： json.url:“/charge/business.action?BMEBusiness=charge.charge&_cntRecTimeFlag=true” | transaction apache.dimensi
7、ons.cookie_CURRENT_MENUID startswith=eval(json.action:“ 查 询 ”& timestamp30m) endswith=json.action:提交,1.先通过url 过滤出所有 缴费业务日 志,2.通过menuid进行分 组聚合,3.将“查询”动作作为 步骤起点,4.默认30分钟内营业员 处理完一笔完整业务,5.将“提交”动作作为 步骤结束,日志应用场景统一日志平台,备份中心2,日志集群1 主中心,日志集群3,备份中心2 日志集群2,多个IDC日志易集群之间用同一个帐号登录即可查询多个 IDC的数据,日志应用场景统一日志平台,只要在一个输入
8、框上输入需要查询的关键字，就能在几 秒钟查询出所有机器，所有类型日志与关键字匹配的日 志信息,日志应用场景业务运维分析,实时监控每一笔交易，对异常和错误实时告警 交易是否正常 交易耗时 交易的服务器资源消耗 接口、服务调用实时统计 交易量统计、分析,日志应用场景业务运维分析,快速统计任意时间段，0-50ms操作时长的业务数量（low），50-500ms的业务数 量（middle），以及500ms以上的业务数量（high）,日志应用场景业务运维分析,快速统计任意时间段，每台服务器各业务类型的业务数量占比,日志应用场景业务运维分析,快速统计各台服务器每天各时段操作时长趋势，可以看出服务器操作时长变
9、化趋势 非常相似，业务耗时长的操作集中在某1，2台机器,日志应用场景业务关联分析,不同的交易，应用系统之间的逻辑流程各不一样，而且出现错误日志的模块，很可能不是真正发生异常的 模块，但应用系统之间有明确的日志关键字进行关联，通过日志关联以及时间排序，能快速定位出每笔交 易的业务流程以及最早的故障源,日志应用场景业务关联分析,resFormat=HTML, funCode=BE311001,origAmt=12865,retCode=0000, retMsg= 查 询 成 功 ,comAmt=0,comAmtType=-99,reqDate=20160801, transferDate=2016
10、0801,reqTime=151958, orderId=17453288, accessType=U,0801-153205-064SER_29569_WPF153204e561dd3INFO Ser: 【P2P标的余额查询】业务网关返回的P2P标 的余额查询结果为： Swapresult=0,e=nullmsgNum=0, merId=7001079, rpid=WPF153204e561dd3, reqDate=20160801, transNum=0, balance=00000000000000, accDate=20160801, retCode=0000, Memo=null,
11、reqTime=153205, retMsg=null, funCode=0602, brc=01, bidId=7001079A0005990, avlBal=00000000000000,p2plateform日志,spay日志 2016-08-01 15:19:58.950INFO9800-20160801-17453288PayBusiServiceImpl|httpPostForm2Xml 返 回 结果：orderState=4, tradeNo=1608011519586161, trace=1608011519584381, orderDate=20160801, merId=9
12、800, transferSettleDate=20160801, purpose= 司 机 提 现 , rpid=WPF153204e561dd3,日志应用场景业务关联分析,输入rpid的值自动关联自动展现搜索结果,日志应用场景安全分析,某驾校在2014年4月某天被黑客入侵导致网站无法登录，用户提供5GB的web 日志文件，需要从日志文件中快速定位出攻击源ip 通过把服务器web日志导入到日志易系统，给日志打上标签“hacking”，标签和日志分组方便日志易系统 同时处理不同的案件的日志，每个案件都有自己的标签和分组，方便不同的办案人查看不同的日志。这批将 近5GB的日志总共有19,556,
13、430条 01,日志应用场景安全分析,在服务器存在web后门的情况下，该后门程序格式通常为php文件，并且一般后门通过POST方式进行请 求）。所以在搜索框搜索 “php AND apache.method:POST AND apache.status:200”，得到以下结果， 共3642条日志，可以清晰发现请求中存在异常文件 02,日志应用场景安全分析,进行可视化统计视图（统计请求路径），可以发现搜索结果中（即步骤二筛选出来的3642条日志）请求数 量最多的基本都是异常文件，可以统计这些异常文件的数量，快速确定了服务器内后门位置： 如/sites/default/files/upload/201404/ec70c4642fa08bff32922a3e0dd2a702.php 可以观察到该目录应为图片及其它文件上传目录，不应该存在可解析的php文件，所以判断为异常 03,日志应用场景安全分析,迅速统计出各异常路径的访问次数以及访问源ip 04,日志应用场景安全分析,通过日志查询，可以看到后门最初访问时间为2014年4月10日 9点10分，进一步缩小时间段，扩大搜索范围， 以便查找该黑客攻击行为，定位该黑客攻击IP为222.141.155.4 05,
