168大数据

标题: 携程ELK日志分析平台深耕之路 [打印本页]

作者: 168主编 时间: 2016-12-7 10:53
标题: 携程ELK日志分析平台深耕之路

源起
日志，看似简单简单的文本，在网站运维人员眼里却似一座蕴含丰富的宝藏。通常以下运维任务都或多或少需要运维人员和日志打交道:
• 系统健康状况监控
• 查找故障根源
• 系统瓶颈诊断和调优
• 追踪安全相关问题

技能熟练的Linux SA们能够很快的组合诸如grep, awk这样的命令，奇幻般的从日志中挖掘出有用的信息；亦或是研发人员往往会基于MySQL,MongoDB,HBase开发自己的日志存储和分析工具。
然而互联网大规模、分布式的特性决定了日志的源头越来越分散，产生的速度越来越快，传统的手段和工具显得日益力不从心。市场对新工具的需求已然催生出Splunk这样近百亿美元市值的专业日志分析解决方案供应商。
从2013年携程网站运营中心成立伊始，集中化的运维日志分析平台就被提上议事日程。作为中国最大的OTA网站，携程基础设施每日产生的各类日志有好几十种，量级在数个TB级别，如果采用Splunk这样的商业软件，每年的授权费用就要近千万。昂贵的授权费用驱使我们深入研究这个领域，寻求商业软件以外的替代方案。

小试牛刀
一线运维部门对于日志分析工具有如下几个重要的期盼点:
1. 日志要支持多种数据源
2. 日志解析方式灵活但简单
3. 支持关键词搜索和浏览，能支持组合条件搜索
4. 能够按照时间窗对特定字段做数值统计，并且时间窗最好可以随意缩放，比如计算某个时间段的平均响应时间，或者出现某种错误类型最多的URL等等。
当时公司已有基于MySQL和HBase的日志分析工具，然而功能与用户期望相差甚远。我们对这些工具的感觉是：可以很好的存，却无法很好的用。具体说就是日志写到数据库问题不大，但一旦要用的时候，只能做类似tail的翻看，或者简单的过滤；一旦有复杂的查询和统计会非常非常慢，或者根本无法支持，用户体验比较差。
脑子里不停翻滚着用户需求，持续探寻了几天后，ELK进入了我们的视野。ELK是三个开源工具ElasticSearch，Logstash，Kibana组合而成的软件栈，其中的核心是开源的分布式搜索引擎Elasticsearch，辅以Logstash灵活多样的日志收集，过滤，传送功能以及Kibana炫酷的前端展示面板，组合成一套可以媲美商业应用的解决方案。
下面是个典型的ELK架构方案；

看起来很简单，logstash像一把瑞士军刀，可以通过plugin的方式从多种渠道输入日志、内部深加工（filter），再输出到多种类型的目的地，这里我们送到Elasticsearch做索引和存储。中间的Redis用作消息队列，使得架构的容错性更高，当ES故障或者下线维护的时候，日志可以缓存一段时间而不至于丢失。

我们团队经过短暂的测试环境POC以后，在线上部署了一个5台服务器规模的小集群。无线日志和云计算部门的VDI日志成了我们一批小白鼠，数据在Kibana里的可视化直观易读。

如下是一个Openstack日志的分析示例面板:

Elasticsearch是基于Lucene的，对于日志的所有字段都可以索引，并且其倒排索引的数据结构非常紧凑，搜索效率非常的高。Elasticsearch的Facet (aggregation)模块可以对数据做分布式的聚合计算，速度惊人的快。反映到前端Kibana上，用户可以随意组合条件过滤日志，随意伸统计时间窗，秒级获取聚合计算结果。再也不需要在Hadoop上长久的等待，也不用为更改Storm/Spark定好的计算维度而犯愁，非凡的用户体验一下抓住了用户的心，更多的日志接入需求随之而来。

持续学习、实践与优化

开源软件并非没有成本，如果无法理解其核心原理，无法将其驾驭往往会导致项目的失败。随着接入的日志量级增加，集群规模扩大，我们开始遇到各种诡异的稳定性和性能问题。一个系统再好，不稳定、慢，用户就会慢慢丧失信心和兴趣。这促使我们投入大量的精力，深入去研究ELK并持续的优化生产集群:

为提高系统稳定性和容量管理能力，我们加强了监控，在Ganglia上开发了ES监控插件:

为加强系统安全性，我们开发了开源的认证网关ESProxy(https://github.com/childe/esproxy)，使得Kibana可以接入公司的SSO(单点登录系统)，并在索引级别提供黑白名单的访问控制；
为提高CPU利用率，节省硬件资源，我们开发了开源工具Hangout(https://github.com/childe/hangout) 替代Logstash，吞吐量提升了5倍之多；
基于开源的Logstash Forwarder开发的Agent，解决了Windows平台原有Log Agent的资源消耗高、不稳定的问题；
为提高Kibana易用性，我们开发了导航Panel、数据同比排名Panel、时间偏移对比等等特性。
为应对更大规模的日志流，我们研究Kafka并替换了Redis，使得运输管道更易于水平扩展，稳定性和容错性更高。
为提升大范围数据聚合速度和防止内存溢出，我们很早发现了ES1.x版本对Doc Values特性的支持，率先采用后使得生产集群的聚合速度和稳定性大幅提高。
为提升数据数据写入实时性，我们对集群做了冷热数据分离和自动迁移，保障数据写入实时性不会受到大范围查询的影响。
为提高ES集群稳定性，我们还做了客户端节点和数据结点分离等架构上的优化。

以下架构是携程生产集群逐步演变成过程:

成果与未来展望

经过1年多的不懈努力，我们的ES集群扩展到40个数据结点，收集50多种类型的日志，日处理日志160亿条，大小近5TB。运行稳定，响应快速，监控完备。目前已经成为携程网站运维核心应用之一，用户涵盖运维，系统研发，信息安全，应用研发。

ElasticSearch成名于ELK，但绝非只擅长于做日志分析，作为分布式搜索引擎，很多公司将其用于全站搜索，相关性推荐等功能。ELK在携程的成功应用也吸引了部分业务研发部门的架构师对Elasticsearch这项技术的关注。部分应用的搜索功能正在引入ElasticSearch进行重构，以期提高搜索的准确性、速度和系统可靠性。

我们下一个基于Elasticsearch的应用将是正在研发中的新一代分布式监控平台HickWall。相较于主流监控平台采用的时间序列存储方案，例如RRDtool、MySQL、OpenTSDB、InfluxDB等，我们认为Elasticsearch可以提供更好的水平扩展性，更灵活快速的数值聚合计算功能。目前项目正在紧锣密鼓的开发过程中，有望在明年下半年在生产上部署，并助力携程网站流量10x的增长。

欢迎光临 168大数据 (http://www.bi168.cn/)