贝聊ELK实战

大家好，我是贝聊的运维工程师马铁军，我们贝聊刚上了ELK系统，这里针对之前的实战过程作一个归纳总结，跟各位分享一下:

一、部署ELK的背景

之前公司没有一套统一的日志收集方案

1. 大部分开发人员都有相应服务器的登陆权限，增加管理成本

2. 开发人员查询日志的时如果命令使用不当有可能造成内存耗尽、误删除等问题，给服务器带来不少安全隐患

3. 现有的日志统计，调整相当不便，实效性差

4. 重要业务都有冗余机器，日志分布在几台机器上，查找不便

如果有日志收集方案:

1. 开发人员不需要服务器权限也能快捷的查找问题

2. 可以根据业务需要从各个维度分析日志并展现

3. 日志集中实时收集，查询问题不影响服务器正常运行

二、技术选型

通常一套日志管理体系需要如下几个阶段的工作：

1.日志的采集

2.日志的汇总与过滤

3.日志的存储

4.日志的分析与查询

ELK技术栈(即Logstash + ElasticSearch + Kibana)属于业界已经应用比较广泛且成熟的开源方案，这套一站式解决方案基本上可以满足大部分企业对日志管理体系的需求。我们即选择ELK作为日志收集方案，其架构如下：

这种架构有如下优点：

1、 使用filebeat收集日志，减少应用服务器的压力

2、中间层使用kafka做消息队列。防止数据丢失同时也能起到削峰填谷的作用

3、Logstash根据需求过滤处理数据

4、ES两个数据节点一个主节点缓解压力

5、ElastAlert插件定时去查询ES里面的数据，根据用户配置实时告警

6、方便扩容

三、遇到的问题及解决方案：

1、日志中的时间为系统时间不为日志输出的时间。这是由于logstash在写入ES的时候默认会生成写入时间点的时间戳@timestamp，kibana默认以@timestamp为时间过滤字段导致的

2、由于时区导致日志8小时的时差。引起这个问题主要是由于ELK各组件对时间的处理是基于“数据的存储和显示相分离”的设计原则，只要把表示绝对时间的时间戳存储数据库，在显示的时候根据用户设置的时区格式化为正确的时间。所以在logstash写入ES时存储为UTC时间，由于中国是东八区，所以会比日志时间晚8个小时，而kibana是从ES读出UTC时间后，通过浏览器获取当时时区，在UTC时间的基础上加上浏览器时区偏移值，再展现出来。当logstash没有正确设置时区时即会导致这个问题

如上两个问题以通过在logstash filter阶段使用date插件处理

date {

match => ["timestamp", "dd/MMM/yyyy:HH:mm:ss"]

target => "@timestamp"

timezone => "+08:00"

}

3、_dateparsefailure失败。这是由于时间匹配失败，仔细检查date插件的math看是否与日志时间格式对上

4、Grokparsefailure失败。这是由于日志消息正则匹配失败可通过如下网站调试：grokdebug.herokuapp.com/

5、logstash重启消费kafka。Logstash默认会把所有的配置文件整合为同一个配置文件，由于我们java日志分为dubbo服务和web服务，在filebeat收集的时候我把它们放在一个kafka topic中，导致在logstash这边配置了两个文件同时消费同一个topic，引发这个问题

6、索引默认以logstash开头。ES使用默认索引模板都是以logstash开头。如果需自定义则需要通过ES接口配置新的索引模板

7、ES数据查询缓慢，刚开始时2个数据节点又为主节点，导致CPU负载过高。后面把主节点分离出来。同时使用，数据保存15天，热索引7天。加快查询速度。同时修改默认的分片数和副本数

8、Logstash负载过高，logstash最耗负载的就是grok，所以把nginx日志改为json格式，其次一些固定格式的日志使用dissect插件进行切割，这是5.x版本中新插件，能很大程度上降低logstash负载

四、部署之后成效

1、系统故障报警更及时，以前在系统出现故障时需要等到URL监控、或者数据库监控报警才能发现问题，这两个监控粒度较大，往往发现故障时已经很严重了。部署ElastAlert监控之后能实时监控nginx日志的状态码，当某个错误状态码在1分钟内达到500个就告警。及时有效的告警服务给故障排查留出了宝贵的时间，以便在最短的时间内解决问题，把影响降到最小。

2、可以实时快速的查询每个接口的响应时间。优化响应慢的接口，提高系统服务质量

3、故障排查更迅速，当碰到有异常流量时及时过滤出异常IP\UserAgent，添加防火墙，减少系统安全事故

4、回收开发人员服务器上的权限，减少误操作的可能

5、每周生成质量报表，统计每个项目每周的ERROR、WARN日志

6、每个项目按需求建好visualize实现日志可视化，分析各项目运行状态更方便快捷

五、总结

1、在部署过程中或多或少会碰到各种故障，排查故障时需仔细观察日志，找到引发故障的关键字，再根据关键字做有针对性的排查。其次要仔细观察配置文件了解各配置的原理，上下文关系。

2、实施项目前要充分调研项目的可行性

3、在部署完毕之后可以根据实际情况进行调优，使系统处于最佳的运行状态