微服务日志监控与查询logstash + kafka + elasticsearch

使用 logstash + kafka + elasticsearch 实现日志监控

https://blog.csdn.net/github_39939645/article/details/78881047

在本文中，将介绍使用 logstash + kafka + elasticsearch 实现微服务日志监控与查询。

服务配置

添加 maven 依赖：

org.apache.kafka
kafka-clients
1.0.0

添加 log4j2 配置：

localhost:9092

系统配置
Zookeeper-3.4.10 官网
添加配置

在 conf 目录下创建配置文件 zoo.cfg , 并在其中添加以下内容：

tickTime=2000

dataDir=/var/lib/zookeeper

clientPort=2181

启动 ZooKeeper

windows:

bin/zkServer.bat start

Kafka_2.11-1.0.0 官网

修改日志存储位置

config/server.properties

log.dirs=D:/kafka-logs

启动 Kafka

windows:

bin/windows/kafka-server-start.bat config/server.properties

注：

如果在启动的时候出现以下错误：

错误: 找不到或无法加载主类

需要手动修改 bin/windows/kafka-run-class.bat ，找到以下的代码：

set COMMAND=%JAVA% %KAFKA_HEAP_OPTS% %KAFKA_JVM_PERFORMANCE_OPTS% %KAFKA_JMX_OPTS% %KAFKA_LOG4J_OPTS% -cp %CLASSPATH% %KAFKA_OPTS% %*

将其中的 %CLASSPATH% 添上双引号 => "%CLASSPATH%" 。

Elasticsearch-6.1.1 官网

安装 x-pack

bin/elasticsearch-plugin install x-pack

新增用户：

bin/users useradd mcloud-user

修改角色：

bin/users roles -a logstash_admin mcloud-log-user

注：

系统内置角色：

Known roles: [kibana_dashboard_only_user, watcher_admin, logstash_system, kibana_user, machine_learning_user, remote_monitoring_agent, machine_learning_admin, watcher_user, monitoring_user, reporting_user, kibana_system, logstash_admin, transport_client, superuser, ingest_admin]

启动服务

bin/elasticsearch.bat

Kibana-6.1.1 官网

安装 x-pack

bin/kibana-plugin.bat install x-pack

启动服务

bin/kibana.bat

Logstash-6.1.1 官网

创建配置文件文档

config/logstash.conf

input {

logstash-input-kafka {

topics => ["mcloud-log"]

}

}

output {

elasticsearch {

hosts => ["localhost:9200"]

user => "mcloud-user"

password => 123456

}

}

最终效果

相关服务启动完成后，登陆 kibana 管理界面，可以看到以下的效果：

KafKa+Logstash+Elasticsearch日志收集系统的吞吐量问题

https://blog.csdn.net/remoa_dengqinyi/article/details/77895931

公司的KafKa+Logstash+Elasticsearch日志收集系统的吞吐量存在问题，logstash的消费速度跟不上，造成数据堆积；

三者的版本分别是：0.8.2.1、1.5.3、1.4.0

数据从KafKa中消费，采用的是logstash-input-kafka插件，输出到Elasticsearch中采用的是logstash-output-Elasticsearch插件。

对于两个插件分别进行了一定的配置，参照了下面的博客：点击打开链接

但是问题并没有得到解决，消费的速度没有什么提升，或者说提升很小，还有数据堆积。考虑到使用的logstash版本以及插件的版本比较低，所以进行了版本升级：

在logstash的网站上下载了集成所有插件的2.3.4版本的logstash，配置的过程中遇到了以下问题：

Elasticsearch插件的配置：

1、新版本的插件没有host和port配置，改成了hosts：["127.0.0.1:9200"]

2、新版本的配置中没有protocol配置

在运行logstash的过程中，命令中有参数-l logs，用来配置log的目录logs，我没有手动创建这个目录，所以日志一直没有生成，开始一直没有找到日志文件，一旦有了日志，其中就提示了配置文件的问题，很容易就将新版本的logstash以及两个插件配置好了。

但是配置好之后，新版本的logstash的吞吐量有所上升，但是在数据量大、上升比较快的时候仍然会有数据堆积，所以问题还是没有解决。

下面的分析思路：

1、观察logstash的消费过程发现，kafka的中的数据均衡很差，少部分节点中的数据多，增长快，大部分节点中几乎没有数据，所以logstash的多线程到节点的分区中取数据，对于性能的提升不大。由于logstash对于数据的消费采用的是fetch的方式，个人感觉：每个线程会不断的去kafka中取数据，发现没有数据之后，在过一段时间之后又会去取，虽然这些分区中没有数据，但是仍然占用了一部分cpu去取数据，这反而会影响到有数据的线程。如果可以知道哪个节点上有数据，将cpu资源都给这几个节点，针对这几个节点进行数据抓取，效率会快很多。现在的情况是，每个分区都分配了一个cpu核心，其中2/3的核心是在不断去读却读不到数据，只有1/3的cpu在读取，这对于计算资源是很浪费的。

上面的想法是傻逼的。。。并不是每个分区分配一个线程，就是将一个核心绑定给了这个线程，线程申请的是cpu的计算资源，是从所有的核心中去申请，一个线程对应的分区中没有数据，那么这个线程就不占用cpu资源，或者说占用的很少，那么剩余的cpu资源就可以给别的线程用。注意：线程绑定的是cpu的计算资源，并不是一个线程绑定一个核心。所以说某些分区中数据少，kafka的负载均衡不好，并不会怎么影响logstash从中消费数据的速度。问题可能还是存在于logstash向ES中写数据的速度。

2、通过工具观察一下Elasticsearch的索引速度，如果很慢，很可能是logstash的output环节影响到了吞吐量。

针对Logstash吞吐量一次优化

Logstash性能优化：

场景：

  部署节点配置极其牛逼（三台 48核 256G内存 万兆网卡的机器），ES性能未达到瓶颈，而filebeat又有源源不断的日志在推送（日志堆积），此时却发现ES吞吐量怎么也上不去，基本卡在单logstash 7000/s 的吞吐。

  这时候我们基本确定瓶颈在logstash上。logstash部署在服务端，主要处理接收filebeat（部署在节点机）推送的日志，对其进行正则解析，并将结构化日志传送给ES存储。对于每一行日志进行正则解析，需要耗费极大的计算资源。而节点CPU负载恰巧又不高，这个时候我们就要想办法拓宽logstash的pipeline了，毕竟我们一天要收集18亿条日志。

ELFK部署架构图如下所示：

这里写图片描述

影响logstash性能因素如下：

logstash是一个pipeline，数据流从input进来，在filter进行正则解析，然后通过output传输给ES。

filebeat->logstash tcp连接

logstash->es tcp连接

logstash input

logstash filter

logstash output

filebeat-> logstash tcp连接 (目前非瓶颈)

TCP连接数：之前性能测试，3节点logstash可以承受1000节点filebeat的连接。

注：当时性能测试方案 1000节点filebeat推流极低，不确保线上日志大时,filebeat连接数增高成为瓶颈。

网络带宽：万兆网卡支持，无性能瓶颈

logstash-> es tcp连接 (目前非瓶颈)

TCP连接数：logstash后端仅与3个ES节点建立TCP连接，连接数无问题

网络带宽：万兆网卡支持，无性能瓶颈。

logstash input (目前非瓶颈)

接收filebeat推送日志，接收量由filter,output协同决定。

logstash filter & logstash output ( 瓶颈)

升级logstash版本 1.7 -> 2.2

2.2版本之后的logstash优化了input,filter,output的线程模型。

增大 filter和output worker 数量通过启动参数配置 -w 48 （等于cpu核数）

logstash正则解析极其消耗计算资源，而我们的业务要求大量的正则解析，因此filter是我们的瓶颈。官方建议线程数设置大于核数，因为存在I/O等待。考虑到我们当前节点同时部署了ES节点，ES对CPU要求性极高，因此设置为等于核数。

增大 woker 的 batch_size 150 -> 3000 通过启动参数配置 -b 3000

batch_size 参数决定 logstash 每次调用ES bulk index API时传输的数据量，考虑到我们节点机256G内存，应该增大内存消耗换取更好的性能。

增大logstash 堆内存 1G -> 16G

logstash是将输入存储在内存之中，worker数量 * batch_size = n * heap （n 代表正比例系数）

worker * batch_size / flush_size = ES bulk index api 调用次数

1

2

调优结果：

  三节点 logstash 吞吐量 7000 -> 10000 （未达到logstash吞吐瓶颈，目前集群推送日志量冗余） logstash不处理任何解析，采用stdout输出方式，最高吞吐 11w/s

  集群吞吐量 24000 -> 32000 （未饱和）

  stop两个logstash节点后，单节点logstash吞吐峰值15000 （集群目前应该有 2w+ 的日质量，单节点采集1w5，所以为单节点峰值）

集群调优前：

调优前

集群调优后：

这里写图片描述

最后观察，系统负载也一下上去了

这里写图片描述

最后，总结一下调优步骤：

worker * batch_size / flush_size = ES bulk index api 调用次数

根据CPU核数调整合适的worker数量，观察系统负载。

根据内存堆大小，调整batch_size,调试JVM，观察GC，线程是否稳定。

调整flush_size，这个值默认500，我在生产环境使用的1500，这个值需要你逐步增大，观察性能，增大到一定程度时，性能会下降，那么那个峰值就是适合你的环境的。