1、IT运维分析与日志搜索分析引擎案例分析提纲 IT 运维分析（IT Operation Analytics）不同数据源及解决方案对比 日志处理技术的演进 日志搜索分析引擎详解 日志搜索分析引擎案例IT 运维分析 从 IT Operation Management(ITOM)到 IT OperationAnalytics(ITOA)大数据技术应用于IT运维，通过数据分析提升IT运维效率 可用性监控 应用性能监控 故障根源分析 安全审计 Gartner估计，到2017年15%的大企业会积极使用ITOA；而在2014年这一数字只有5%I TOA 的四种数据来源 机器数据（Machine Data）日志
2、 通信数据（Wire Data）网络抓包，流量分析 代理数据（Agent Data）在.NET/Java/Ruby/Python/PHP 字节码里插入代码，统计函数调用、堆栈使用 探针数据（Probe Data）布点拨测 在各地模拟ICMP ping、HTTP GET请求，对系统进行检测I TOA 四种数据来源使用占比100%90%80%70%60%50%40%30%20%10%0%93%86%72%47%machine data（日志）wire data（网络抓包）agent data（插入代码）probe data（模拟检测）I TOA 四种数据来源/解决方案比较 机器数据（日志）旁路 日
3、志无所不在 但不同应用输出的日志内容的完整性、可用性不同 通信数据（网络抓包）旁路 网络流量信息全面 但一些事件未必触发网络流量 代理数据（嵌入代码）侵入式 代码级精细监控 对C/C+无效 带来安全、稳定、性能问题 探针数据（布点拨测）旁路 端到端监控 只是模拟，不是真实用户度量（Real User Measurement，RUM）I TOA 解决方案厂商（1）机器数据（日志）Splunk ELK 日志易 通信数据（网络抓包）Netscout 科来 天旦 代理数据（嵌入代码）New Relic AppDynamics DynaTrace(Compuware)云智慧 OneAPMI TOA 解决
4、方案厂商（2）探针数据（布点拨测）Gomez(Compuware)Keynote听云（基调）博睿 大公司综合性产品IBMHPComputer AssociateBMCRiverbed日志：时间序列机器数据 带时间戳的机器数据 IT 系统信息 服务器 网络设备 操作系统 应用软件 用户信息 用户行为 业务信息 日志反映的是事实数据 深度解析LinkedIn大数据平台（http:/ Log:What every software engineer should know about real-time datas unifying abstraction”,Jay Kreps,LinkedIn e
5、ngineer一条 Apache Access 日志 180.150.189.243-15/Apr/2015:00:27:19+0800“POST/report HTTP/1.1”200 21“https:/ NT 6.1;WOW64;rv:37.0)Gecko/20100101 Firefox/37.0”“10.10.33.174”0.005 0.001 字段：-Client IP:180.150.189.243-Timestamp:15/Apr/2015:00:27:19+0800-Method:POST-URI:/report-Version:HTTP/1.1-Status:200-By
6、tes:21-Referrer:https:/ Agent:Mozilla/5.0(Windows NT 6.1;WOW64;rv:37.0)Gecko/20100101 Firefox/37.0-X-Forward:10.10.33.174-Request_time:0.005-Upstream_request_time:0.001日志的应用场景 运维监控 可用性监控 应用性能监控(APM)安全审计 安全信息事件管理(SIEM)合规审计 发现高级持续威胁(APT)用户及业务统计分析过去：没有集中管理日志日志没有集中处理登陆每一台服务器，使用脚本命令或程序查看（grep/awk/regexp）
7、日志被删除磁盘满了删日志黑客删除日志，抹除入侵痕迹 日志只做事后追查没有事中监控、分析过去：使用数据库存储日志 无法适应TB级海量日志 数据库的schema无法适应千变万化的日志格式 无法提供全文检索TimestampHostnameMessage15/Apr/2015:00:27:19 180.150.189.243+0800“POST/reportHTTP/1.1”20021“hps:/ Hadoop 批处理，不够及时 查询慢 数据离线挖掘，无法做 OLAP(On Line Analytic Processing)Storm 毫秒级延时 Spark Streaming 秒级延时 Hadoo
8、p/Storm/SparkStreaming都只是一个开发框架，不是拿来即用的产品 NoSQL Mongodb Redis Druid 不支持全文检索现在 对日志实时搜索、分析 日志实时搜索分析引擎 快 日志从产生到搜索分析出结果只有几秒的延时 大 每天处理 TB 级的日志量 灵活 Google for IT，可搜索、分析任何日志 Fast Big Data日志管理系统的进化日志1.0：日志2.0：日志3.0：实时搜索引擎数据库Hadoop 或 NoSQL 实时 灵活 固定的schema无法适应 需要开发成本任意日志格式 批处理，实时性差 全文检索 无法处理大数据量 不支持全文检索常用日志处理
9、解决方案ELK Elasticsearch/Logstash/Kibana 基础功能开源免费 告警、权限、管理模块收费 Splunk 日志易在线与离线日志处理结合 在线处理实时性好，但资源消耗大 离线处理资源消耗小，但实时性差 日志从消息系统出来，一路进在线系统，一路进离线系统 在线系统的索引文件备份到离线系统，检索时再从备份系统恢复如果对几年的日志做统计分析 把定时生成的统计分析数据写入新的索引文件 长期的统计分析基于二次生成的索引文件，而不是原始数据机器学习在日志分析的应用 异常自动检测 预测、容量规划Schema on Write vs.Schema on Read Schema on
10、Write 索引时（入库前）抽取字段，对日志做结构化 检索速度快 入库速度慢 占用硬盘空间大 但不够灵活，必须预先知道日志格式 Schema on Read 检索时（入库后）抽取字段，对日志结构化 检索速度慢 入库速度快 占用硬盘空间小 灵活，检索时根据需要抽取字段搜索处理语言 SPL(Search Processing Language)可编程的日志实时搜索分析平台灵活适应各种业务分析在搜索框里写 SPL 脚本，完成复杂的查询、分析”框计算“用管道符（“|”）串接前命令的输出作为后命令的输入 用双方括号(“”）执行子命令子命令的结果作为父命令的输入常见 SPL 命令命令描述evalbucke
11、tfieldsjoin对日志字段或统计结果进行计算表达式，并将表达式值放入新增字段中将连续的值分别放入按区间分割的桶中，用于计算趋势以及数组分组变化保留结果中的字段类似sql的连接，将主管道的结果和子管道的结果连接在一起limit返回前n个结果，常用于限制统计结果数量movingavgrollingstdrenamestats计算列值之间移动平均值计算列值之间的标准差重命名字段名提供各种统计函数，并可以选择按字段分组统计sortwheresave安装指定的字段对结果进行排序使用表达式对结果进行过滤将搜索结果保存为外部csv文件将结果分组形成交易日志组合对字段进行数量和百分比统计transaco
12、ntopSchema on Read 案例 从日志的原文中抽取 ip_addr 字段*|parse“(?d+.d+.d+.d+)”SPL 关联分析案例：transactionjson.url:“/charge/business.acon?BMEBusiness=charge.charge&_cntRecTimeFlag=true”|transaconapache.dimensions.cookie_CURRENT_MENUIDstartswith=eval(json.acon:“查询”&mestamp1000|statscount(logtype)aslen_1000byapache.geo.
13、ispSPL 类数据库分析案例join（5）场景：按照运营商isp，统计总数，status:400-499的数量及占比，status:500-599的数量及占比，请求长度大于1000的数量及占比，形成一张统计报表（5）joinlogtype:apache|statscount(logtype)ascount_allbyapache.geo.isp|sortbycount_all|limit5|jointype=leapache.geo.isplogtype:apacheANDapache.status:400TO499|statscount(logtype)ascount_400byapach
14、e.geo.isp|jointype=leapache.geo.isplogtype:apacheANDapache.status:500TO599|statscount(logtype)ascount_500byapache.geo.isp|jointype=leapache.geo.isplogtype:apacheANDapache.resp_len:1000|statscount(logtype)aslen_1000byapache.geo.ispSPL 类数据库分析案例join（6）场景：按照运营商isp，统计总数，status:400-499的数量及占比，status:500-59
15、9的数量及占比，请求长度大于1000的数量及占比，形成一张统计报表（6）统计占比，evallogtype:apache|statscount(logtype)ascount_allbyapache.geo.isp|sortbycount_all|limit5|jointype=leapache.geo.isplogtype:apacheANDapache.status:400TO499|statscount(logtype)ascount_400byapache.geo.isp|jointype=leapache.geo.isplogtype:apacheANDapache.status:50
16、0TO599|statscount(logtype)ascount_500byapache.geo.isp|jointype=leapache.geo.isplogtype:apacheANDapache.resp_len:1000|statscount(logtype)aslen_1000byapache.geo.isp|evalrate_400=if(empty(count_400),0,count_400/count_all)|evalrate_500=if(empty(count_500),0,count_500/count_all)|evalrate_len_1000=if(empty(len_1000),0,len_1000/count_all)三个解决方案的比较SchemaonWrite SchemaonReadSPLSplunk日志易ELK日志易-网络安全部门仪表盘日志易-应用监控仪表盘日志易-网络设备部门仪表盘
