2017年9月16日，由中国新一代IT产业推进联盟、江苏省企业信息化协会指导，CIO时代学院、苏州工业园区人工智能产业协会、江苏省企业信息化协会苏州代表处联合主办，CIO时代APP、苏州IT人俱乐部协办的“第四届互联网+高峰论坛暨大数据应用峰会CIO时代中国行苏州站”在苏州金陵观园国际酒店成功举行。日志易技术总监唐文俊在活动中发表了题为《智能运维与海量日志分析》的主题演讲。以下为演讲实录：

日志易技术总监  唐文俊

 

　　很荣幸能给大家带来智能运维与日志分析的分享。

 

 

　　2014年，日志易拿到了1400万的天使轮，A轮拿到了红杉资本的6000万投资，至今在日志分析领域，日志易已经成为部分细分领域的No.1，无论是市场占有率还是销售额。在日志细分领域的软件供应商中，我们的知名度、产品成熟度和客户案例也都是最丰富的。

 

 

　　今天在座的很多都是专家和公司领导，部门下会有运维工程师，他们每天会遇到越来越多的运维事件和故障，每天承载巨大的用户量，还需要服务业务系统和对抗数据量的增长，这些都是很严峻的。包括CNNIC的报告也曾指出，数据的增长非常恐怖，在运维人员支撑的数据体系下，每天需要不断处理事件。

 

　　开源社区提供了各式各样的工具和技术堆栈，或开源软件，通过安装它们解决运维问题，包括业务系统、网络、数据库等，逼迫运维人员研究发掘适合它的工具。传统ITIL方法论的相关内容需要运维人员快速转型迭代，成为一个DevOps，解决突发运维实践和新运维领域中的问题，这是现在运维人员面对的数据现状和挑战。这里基本涵盖了企业所用的技术堆栈和名字，所以可想而知运维人员的压力非常大。运维本身还面临着安全的问题，会面临危险漏洞和攻击等，有些严重的会从底层击穿OS漏洞，使运维和安全人员不能很快应对突发事件，因为没有办法防御。

 

　　在互联网行业，特别是BAT数据量级别的公司，运维人员每天运维的服务器台数是百万级别的。同样现在在云上的技术，每天在云端上服务的节点数量以及用微服务的架构去服务系统，更新快、迭代快且更加离散，数据不能集中。当运维人员服务的节点数超过本身能力承载的数字后，是很难应对的，运维质量势必下降。作为一线工程师每天面临查看设备和业务系统日志的困扰，否则便不能定位故障。

 

　　在应用发生崩溃或遇到瓶颈时，如何把故障问题快速解决，并且确定根源；在遭受安全攻击的时候及时发出警告，使管理员和工程师快速解决问题；每天制定具体细化的报表给BOSS时，是否需要把最终的情况汇总和统计，把结果通过可视化的方式提供出来，以上都是每天一线、二线工程师所要做的。

 

 

　　以上所遇到的问题逼迫我们IT运维不断进化，不只是体系、手法、工具和技术，还有整个理念的进化。从最早的传统ITOM管理的手段，它是做底层的监控和基本管理的，把数据和设备管理起来。慢慢进化到ITOA，它是这几年最热最火的概念，具备汇总、归并设备数据后对其进行分析的能力，否则数据在数据中心中没有被利用到，也是没有任何价值的。数据的分析是把进入到ITOM的数据利用起来，当然我们希望分析可以更智能化时，我们便有了AIOps。它可使一些软件落实到自动化形成体系。从ITIL到用互联网的方式，把数据用大数据技术利用起来，真正做到运维分析，再到智能运维，通过统计学的方式解决，使它自动化，使智能化的结果再到智能运维，通过统计学的方式解决，使它自动化，使智能化的结果实现预测和趋势分析，提供对未来趋势的研判，避免今后故障的出现，这是我们需要做到的。

 

 

　　用数据驱动运维，监控本身是模糊的估算，采样的点也是有限的，同时去除了没有用的数据，过量的数据会影响你的判断。通过监控建立了总体稳定的监控体系后，有全量的数据分析加入到分析体系中。要做ITOA，就要提供分析基础和数据源，巧妇难为无米之炊，因此应先把尽可能多的数据汇总。随着技术的进步和新技术的出现，利用新技术并结合公司的数据情况，不是一个概念或方法论就能用出效果的，需要数据的支撑。过去数据量很大，工具量不满足需求，现在是不存在这个问题的，包括Gartner对ITOA发展的展望是呈上升趋势，通过2015年趋势的判断，在2017、2018年仍然呈上升趋势，并未到达顶峰，所以空间是非常大的。

 

 

　　主流的用到ITOA分为四大类，86%的企业用到了日志，包括文本的数据，也有网络抓包，走流量数据的。还有一些探针的数据和插入代码的用法，这是渐渐被淘汰的手法，这两个方法有两个比较大的劣势，如果插入代码需要改变原有业务系统中间的代码，数据的完整度被破坏掉，有一定的侵入性，把统计探针的代码插入后若发生崩溃，是很难判断的。模拟检测并不代表真实的网络浏览情况，它并不是真实用户数据和真实的业务系统的情况，只能做到模拟、检测的程度。现在采用最多的是日志和网络抓包，它们的区别是企业本身有日志数据，当有业务系统或是有OS跑的时候，自动在后台生成程序的情况并将其打印，未产生网络流量，日志也会生成。例如，顾客进入到酒店，门口是流量的出口，房间中的情况就相当于最终的子系统，对应目录下面的日志。用日志一窥内部细节情况，全局总的出口便需要看流量，两者并不冲突，可以把各自的优势发挥后整合，把两个数据源合并利用，帮助企业做好ITOA。

 

　　如果企业并不想利用日志，就不要记录，这很浪费存储空间，确定好有用的数据存储下来。次数永远是最感兴趣的，频次永远藏着一些可怕的细节，防火墙上的用户访问量，异常次数频次的发生量，其中藏着的细节是可以帮助运维人员和业务人员业务分析的。在未浪费空间的前提下要尽量收集全日志，规避掉没有用的数据，是很重要的。

 

 

　　运维的数据绝大多数时候，都默认带有一个主键字段——时间戳，并且是TEXT格式，包括半结构和非结构化。处理半结构化的日志有一个痛点，所有的业务系统和设备的日志格式各异，需要自己解析、注入才能理解日志。如果换成其他不了解的系统日志，便不可以理解其中的含义，理解的过程是耗时的，会造结果的延时。如果遇到新的格式，需理解后获取知识后才能理解，这是在碰到非结构或不了解的日志时的困境。

 

　　运维数据和其它传统数据做结构化的数据对比，不变是时间戳，如果按照标准把日志打出来，并打印时间戳，便可以分辨某个时间节点发生哪些事情。度量的数据是timestamp+number，log永远是一个timestamp+text，时间戳后加一段文字，形成一个日志主题。很多经济学和统计学分析实际数据有一些方法论，在学术上，可以用到分析数据和趋势，做一些季节性分析的预判，统计学有成熟的方法，也可结合到技术领域，分析日志数据，挖掘其中的价值。

 

 

　　日志数据很好，分析才能得到其中的价值。大数据的技术在其中得到了运用，但是作为运维人员也遇到了一些困境和不适：

 

 

　　在运维方面，服务的节点数和业务系统很多，是否需要登录每一台去查看日志，如果有工具汇总，便可以很灵活的分属归类，否则很繁琐。数据孤立无法关联，无法判断不同的数据是否存在关联性。以银行为例，网银系统或底层的系统走过很多模块，模块间有前后关联性，无论是时序还是关联数据，这样才能分析事物。只能做简单搜索和统计，无法满足分析要求。没有实时监控和报警，如程序出错日志。

 

 

　　系统如果被黑客入侵，黑客第一时间会删除它的记录，把能够暴露他登录或者入侵的日志删除，如果没有把这个日志实时收集，晚一点便看不到他的痕迹。

 

 

　　企业是否有平台支撑每天到TB级日志的承载量，这是很有挑战的事情，用Hadoop平台把模式建立起来，快速利用数据，并且要做每一个字段的分析。

 

　　面对大数据的不适，企业会有不同的需求。随着日志容量和类型的增长，数据量越来越大，要去噪音，把这些数据进行深度分析，对运维人员是很有挑战的。数据的多样性，需要很快的把它检索出来，只有大数据是不行的，需要把速度也跟上。

 

 

　　日志易有自己的日志系统，把架构设置合理，数据提取层支撑到各个类型的数据源，不同的数据捕获的方式和数据源都支持，使数据采集不受限制。其次是底层支持各种基础架构，包括私有云、公有云，不同云的架构，基础设施层不可以成为平台的受限层，所以应该上下完全兼容。平台要完成自我监控，安全层完成安全加固，拥有完整性验证。存储层保证任何节点宕掉后不会损坏文件，应是一个可用的。数据处理应快速及时地把数据做完，数据进入到平台，把字段快速实现。然后到分析引擎，分析引擎层是已搜索引擎方式融入到平台中。其次是分析模块，集成了算法、统计学的函数，实现所要的分析需求，最后与用户层承上启下，把界面做的漂亮，有一个界面进行检索和统计，方便输出。

 

 

 

　　日志易集中管理并索引日志，快速定位问题，做到实时主动监控，数据可视化与业务洞察。集中索引并不应限制数据源，公司有各个层面的数据，包括中间件、底层、网络、存储、设备等，甚至是物联网的都可以汇总，把需要的类型快速解析，避免自己提字段。集中管理并索引，应快速完成规范的动作，从非结构化到结构化很重要，解析工作一站式完成。快速定位问题，能够承载TB级数据量，百万条的日志不积压，提取数据到索引引擎中，还支持横向增加节点，扩展性能。

 

 

　　使用强大的搜索处理语言SPL（Search Processing Language）分析数据，用这些分析语言的代码快速地输出结果，可节省学习成本。

 

　　对于SPL语言，这里举了一个例子，有大量的join、rename函数，其实是一个逻辑的点，看上去很长，但对于业务人员，可能只要5到10分就可以把逻辑拼凑好，通过管道或切割，把每层的逻辑范围缩小，加上组合计算，没有复杂的函数，用一些统计学的方法，并可选择不同展示的结果配合输出。从原始的数据到输出成型的可视化结果只要一行SPL命令，根据需要的输出方式组合数据。

 

 

　　刚刚与一些专家沟通，日志易在做监控的时候是主动式监控，更灵活，一切基于搜索。把它变成一个复杂的逻辑，不再是固定的阈值，输入到平台中去做搜索，满足复杂逻辑后输出监控的条件，再输出相应的告警，避免产生告警风暴，输出真正有用的告警，避免浪费时间。基于搜索很灵活，可以写复杂的逻辑，管理员有知识，结合起来可以把告警做得更精准。

 

 

　　对于业务洞察，首先做了搜索和告警，性能又很强，最后需要把可视化做漂亮。日志易的JS引擎可同步，将可视化的图库进行扩展，横向扩展图库选择适合展示样式，得到一个漂亮的展示结果。

 

 

　　日志易主要服务于金融、运营商领域，同时还有能源、互联网、基金和保险领域。日志产品适应的业务类型和客户类型很广泛，没有局限性，更没有行业特征，主要看企业是否有日志需求。现在日志易有SaaS版和企业部署版，推荐中小型企业体验SaaS版，如果您觉得适用，便可部署在您的企业内，若是考虑到企业数据的敏感性和日志数据的边界性，也可选择企业部署版，有对应服务器的版本供您选择。

 

　　谢谢大家！