良好的监控测量是系统的关键 － 排查ELK系统瓶颈

前言

随着分布式以及微服务架构的兴起，整个系统的架构复杂度大幅上升。为了保证系统的稳定运行以及排查出现的问题，一个精确完善的监控测量系统越来越重要。

最近在拜读《高性能MySQL》，读完了第三章“服务器性能剖析”。书中反复强调了精确测量在问题排查、分析系统中的重要性，联想到工作上的一些经历，不能同意更多了。没有精确的测量，排查分析问题就像盲人摸象，只能看到系统的某一个片面。通过这个片面来分析，往往会得出错误的结论。

另外比较重要的一点是排查分析问题一定要有逻辑性，至上而下还是至下而上都是可以的，但是不能东打一枪西打一枪。一定要明确知道我目前收集的数据是为了验证什么猜想的。

下面我以工作中的实际例子讲一下上述结论的重要性。

问题

ELK（ElasticSearch + Logstash + Kibana) 是非常常见的日志处理分析技术栈，在我们日常业务中发挥了巨大的作用。但是17年下半年我们遇到了问题，因为业务飞速发展，接入的日志量大量增加，ELK系统出现了比较严重的日志延迟的情况，日志一般要等待几个小时才能在ELK里面查询到。如果生产环境出现问题，我们是需要查询实时日志来排查问题，ELK如此巨大的延迟我们是不能接受的。

当时因为之前负责ELK的同事离开了，我就自告奋勇地来解决这个问题。

排查整个链路

先讲一下我们ELK具体的架构。

Filebeats =>  Kafka  =>  Logstash1 => Kafka => Logstash2 => ElasticSearch

业务机上的Filebeats收集日志，传给Kafka的队列。第一组Logstash作为消费者订阅Kafka的topic，清洗日志的脏数据，同时给日志打上一些标签，再传给Kafka。第二组Logstash负责将清洗