| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
qfkw0998
8年前发布

携程ELK日志分析平台深耕之路

来自: http://techshow.ctrip.com/archives/1042.html

源起

日志,看似简单简单的文本,在网站运维人员眼里却似一座蕴含丰富的宝藏。通常以下运维任务都或多或少需要运维人员和日志打交道:

• 系统健康状况监控

• 查找故障根源

• 系统瓶颈诊断和调优

• 追踪安全相关问题

技能熟练的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并持续的优化生产集群:

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

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

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

成果与未来展望

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

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

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

</div>

 本文由用户 qfkw0998 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1456887784031.html
Logstash 日志分析 日志处理