原文：https://www.cnblogs.com/liang1101/p/8509978.html

具体问题如下图所示：

将 INFO 信息打印大致如下所示：

[2018-03-05T16:26:08,711][INFO ][logstash.setting.writabledirectory] Creating directory {:setting=>"path.queue", :path=>"/usr/share/logstash/data/queue"} <br>[2018-03-05T16:26:08,727][INFO ][logstash.agent ] No persistent UUID file found. Generating new UUID {:uuid=>"f4d5f9a9-42ca-4765-b3fb-0f4566f440df", :path=>"/usr/share/logstash/data/uuid"}
[2018-03-05T16:26:09,175][INFO ][logstash.outputs.elasticsearch] Elasticsearch pool URLs updated {:changes=>{:removed=>[], :added=>[http://logstash_system:xxxxxx@localhost:9200/_xpack/monitoring/?system_id=logstash&system_api_version=2&interval=1s]}} <br>[2018-03-05T16:26:09,176][INFO ][logstash.outputs.elasticsearch] Running health check to see if an Elasticsearch connection is working {:healthcheck_url=>http://logstash_system:xxxxxx@localhost:9200/, :path=>"/"} <br>[2018-03-05T16:26:09,262][WARN ][logstash.outputs.elasticsearch] Attempted to resurrect connection to dead ES instance, but got an error. {:url=>#<URI::HTTP:0x59e42e4f URL:http://logstash_system:xxxxxx@localhost:9200/_xpack/monitoring/?system_id=logstash&system_api_version=2&interval=1s>, :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch Unreachable: [http://logstash_system:xxxxxx@localhost:9200/][Manticore::SocketException] Connection refused (Connection refused)"}

首先，从日志上看到发现可能是 es 被写死了，即无法再写入更多的数据，既然这样，那么很自然的就会想到限流 logstash 数据的写入，配置logstash-5.4.1/config/logstash.yml修改：

降低 pipeline 中的 workers 的量，由原来的 32 -> 16， batch size 修改 1000 -> 500， delay 修改 200 -> 1000， output.workers: 16 -> 8

修改完毕之后重启 logstash 发现过一段时间还会有相应的日志出现，找了半天终于 google 中找到有一个老外说的可能是 xpack 做的 helth check 影响的，我一看日志果然有对应每隔 1s 会对 es 做一次 helth check，于是就在 logstash.yml 中增加一行：

xpack.monitoring.enabled: false

即去除 xpack 的监控，再重新启动 logstash 后观察了一段时间果然不会再有任何的 WARN 和 ERROR 日志，问题得以解决。

总结

我猜测，这确实是 xpack 的问题，因为它每1s 去 ping es 状态，当集群繁忙时很容易导致 time out，此时 logstash 认为 es 不可达，就会一直轮询等待。去除掉 xpack 的helth check 等监控，由 logstash 自己写入时判断即可。

【2018-03-06 18:08:56 记录】

昨天修改完，今天查看发现仍然有上面提到的异常日志，于是继续查看。对应的logstash 以及 ElasticSearch 服务器对应的负载、cpu 都不是太高，初步怀疑可能是 io 的问题，即很频繁的进行 io 交互。

通过查看日志发现在很多的时间内，反复提示 ‘send a bulk request to elasticsearch’ 的错误，代表logstash在不断的，快速的给ES发送 bulk reuqest。我们查看logstash的配置发现，默认的配置是：

# How many events to retrieve from inputs
pipeline.batch.size: 125
# milliseconds
pipeline.batch.delay: 5

而我当前配置是：

pipeline:workers: 32batch:size: 200delay: 100output:workers: 8unsafe_shutdown: falsequeue:type: persistedpage_capacity: 250mbmax_events: 10000max_bytes: 1gbcheckpoint:acks: 10000writes: 10000interval: 1000

这里的单位是milliseconds，即每个 logstash 的 instance，每 100 毫秒会发送 200 条 request 到ES集群，这个会导致ES集群的网络io过载。

那么，是不是说我们需要把每个 batch 之间的间隔增大，把每次batch的size调大？比如batch.size = 500, batch.delay = 500，就能防止出现以上的问题？

经过测试这样是可行的。

由于下面配置的 max_bytes 以及 max_events 的限制，修改后的配置如下（仅供参考）：

pipeline:workers: 16batch:size: 500delay: 200output:workers: 12unsafe_shutdown: falsequeue:type: persistedpage_capacity: 250mbmax_events: 10000max_bytes: 1gbcheckpoint:acks: 10000writes: 10000interval: 1000

这样配置的目的有那么几个：

尽量一次读出最大可能条数据，这样可以最大程度的降低与 ES 之间的 IO 交互。
间隔时间不能太久，刚开始配置 1000，发现还是出现又降低到 500，错误变少了，分析发现应该是间隔时间长了，logstash 堵在队列中的数据就会增多，这样导致读取的频次永远不会降低，尤其是过了一段时间发现部分日质数量比较大的收集延迟变大。故综合考虑将延迟时间修改为 200。
由于 CPU 核数比较高达到40多个，故将 output.workers 线程数增加，提升处理能力，减少数据拥堵，降低延迟度。

最后总结一句：以上报错信息其实并不影响整体日志收集，这个错误只是 logstash 自己认为可能不可达，是由于其中的组件导致的，查了下 github 上的说法，后续最新版本可能会解决这个误报问题，但是不是说我们就不管不顾了，而是要想办法将这个错误频次降低，尽最大可能使其运行良好。

【2018-05-06 10:18:56 记录】

在这期间将 ELK 收集日志丢失日志问题解决。最主要还是配置不合理导致的。问题原因是因为配置的 filebeat 中不可达等待最长时间为：3min，如果中途 logstash 拥堵比较严重，elasticsearch 负载又高，极大可能会造成 filebeat 休眠超过3min，看最新版本 filebeat 默认为 1天，其实配置是合理的，虽然有点大，但是总比丢数据要来的好。将其中的配置增大为 1h 后，再不会发生丢失日志的情况。

解决 ELK 收集日志延迟比较高的问题，尝试了很多优化发现无法从根本上解决，于是将最耗资源的 nginx_log 和 push_log 单独迁移到各自小的集群上，剩下所有的其他日志仍然保留在现有集群上，从此以后各种问题得以解决。归结起来就是一句话：有多大能力就干多大的事，不要超过其最大承受能力。

【LogStash】logstash marking url as dead 问题解决相关推荐

【FLink】Flink 消费 kafka 消费组死掉 Marking the coordinator dead for group 造成数据重复消费
文章目录 1.概述 2.源码分析 2.2 能不能设置多次提交呢? 2.3 监控日志 1.概述首先参考几个案例: [Flink]Flink Kafka 消费卡死消费组卡死 topic无写入实际有数 ...
【kafka】消费组死掉 kafka Marking the coordinator dead for group
文章目录 1.概述 2. 如果构造消费组死掉? 3. 诡异消费组死掉 4. 如果构造一个消费组死掉 5.消费组死掉导致重复消费 1.概述转载:java kafka consumer不消费,报错mar ...
Logstash [logstash.outputs.elasticsearch][main] retrying failed action with response code: 403
问题描述: 今天发现当天的索引在ES中并没有创建,logstash中不停的报错: [2021-05-24T05:47:51,904][INFO ][logstash.outputs.elasticse ...
LogStash~LogStash的output（输出）
1.标准输出 output {stdout {codec => rubydebug} } 2.ElasticSearch output {elasticsearch {hosts => [ ...
CC00290.CloudKubernetes——|KuberNetes运维.V12|——|EFLK架构.v07|验证日志输出采集是否正常|
一.验证日志输出采集是否正常 ### --- 进入Filebeat-pod查看是否正常启动 ~~~ 查看Filebeat容器[root@k8s-master01 filebeat]# kubectl ...
LogStash 原理和使用（十六）
这篇我们分析LogStash 原理和使用: LogStash 是一个类似实时流水线的开源数据传输引擎,它像一个两头连接不同数据源的数据传输管道,将数据实时地从一个数据源传输到另一个数据源中. 在数据 ...
8.11. Migrating MySQL Data into Elasticsearch using logstash
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-jdbc.html 8.11.1. 安装 logstash 安装 JDB ...
Spring Boot 整合 Elastricsearch + LogStash + Kibana
以下文章来源方志朋的博客,回复"666"获面试宝典为什么要用ELK ELK实际上是三个工具,Elastricsearch + LogStash + Kibana,通过ELK,用来 ...
Logstash（一）的入门与运行机制
Logstash介绍 Logstash是一个具有实时管道功能的开源数据收集引擎,Logstash可以动态地将来自不同数据源的数据统一起来,并将数据规范化为你选择的目的地,清理和大众化你的所有数据,用于 ...

【LogStash】logstash marking url as dead 问题解决

总结

【2018-03-06 18:08:56 记录】

【2018-05-06 10:18:56 记录】

【LogStash】logstash marking url as dead 问题解决相关推荐

最新文章

热门文章