logstash常见故障

Posted 2023-02-24

参考技术A 1.解决常见问题
我们正在添加更多故障排除提示，因此请稍后再回来查看。 如果您要添加一些内容，请：

在https://github.com/elastic/logstash/issues创建问题，或
在https://github.com/elastic/logstash创建带有您建议的更改的请求请求。
还可以访问Logstash discussion forum。

1.1.安装与设定
1.1.1.临时目录无法访问
JRuby运行时的某些版本和某些插件中的库（例如，TCP输入中的Netty网络库）将可执行文件复制到temp目录。 在/ tmp挂载noexec时，这种情况会导致后续失败。

Sample error

[2018-03-25T12:23:01,149][ERROR][org.logstash.Logstash ]
java.lang.IllegalStateException: org.jruby.exceptions.RaiseException:
(LoadError) Could not load FFI Provider: (NotImplementedError) FFI not
available: java.lang.UnsatisfiedLinkError: /tmp/jffi5534463206038012403.so:
/tmp/jffi5534463206038012403.so: failed to map segment from shared object:
Operation not permitted
可能的解决方案

更改设置以使用exec挂载/ tmp。
使用jvm.options文件中的-Djava.io.tmpdir设置指定备用目录。
1.2.Logstash启动
1.2.1.非法的反射访问错误
使用Java 11运行Logstash会产生类似于以下警告：

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.util.SecurityHelper (file:/Users/chrisuser/logstash-6.7.0/logstash-core/lib/jars/jruby-complete-9.2.6.0.jar) to field java.lang.reflect.Field.modifiers
WARNING: Please consider reporting this to the maintainers of org.jruby.util.SecurityHelper
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
这些错误似乎与JRuby的已知问题有关。

解决

尝试将这些值添加到jvm.options文件。

--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.security=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.security.cert=ALL-UNNAMED
--add-opens=java.base/java.util.zip=ALL-UNNAMED
--add-opens=java.base/java.lang.reflect=ALL-UNNAMED
--add-opens=java.base/java.util.regex=ALL-UNNAMED
--add-opens=java.base/java.net=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/javax.crypto=ALL-UNNAMED
--add-opens=java.management/sun.management=ALL-UNNAMED
笔记：

这些设置允许Logstash在Java 11中启动而不会发出警告，但它们阻止Logstash在Java 8上启动。
此解决方法已通过简单的管道进行了测试。 如果您有经验可以分享，请在issue中发表评论。
1.3.数据提取
1.3.1.错误响应代码429
429消息指示应用程序正在忙于处理其他请求。 例如，Elasticsearch发送429代码以通知Logstash（或其他索引器）由于接收队列已满，批量失败。 Logstash将重试发送文档。

可能采取的行动

检查Elasticsearch以查看是否需要注意。

https://www.elastic.co/guide/en/elasticsearch/reference/7.4/cluster-stats.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.4/es-monitoring.html
Sample error

[2018-08-21T20:05:36,111][INFO ][logstash.outputs.elasticsearch] retrying
failed action with response code: 429
("type"=>"es_rejected_execution_exception", "reason"=>"rejected execution of
org.elasticsearch.transport.TransportService$7@85be457 on
EsThreadPoolExecutor[bulk, queue capacity = 200,
org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@538c9d8a[Running,
pool size = 16, active threads = 16, queued tasks = 200, completed tasks =
685]]")
1.4.一般性能调优
有关常规性能调整的提示和准则，请参阅Performance Tuning。

1.5.常见的Kafka支持问题和解决方案
1.5.1.Kafka会话超时问题（输入端）
Symptoms

吞吐量问题和重复事件处理Logstash记录警告：

[2017-10-18T03:37:59,302][WARN][org.apache.kafka.clients.consumer.internals.ConsumerCoordinator]
Auto offset commit failed for group clap_tx1: Commit cannot be completed since
the group has already rebalanced and assigned the partitions to another member.
两次调用poll（）之间的时间长于配置的时间

session.timeout.ms，通常意味着轮询循环在处理消息上花费了太多时间。 您可以通过增加会话超时或通过使用max.poll.records减小poll（）中返回的批处理的最大大小来解决此问题。

[INFO][org.apache.kafka.clients.consumer.internals.ConsumerCoordinator] Revoking
previously assigned partitions [] for group log-ronline-node09
`[2018-01-29T14:54:06,485][INFO]`[org.apache.kafka.clients.consumer.internals.ConsumerCoordinator]
Setting newly assigned partitions [elk-pmbr-9] for group log-pmbr
Background

Kafka跟踪消费者群体（例如，多个Logstash实例）中的各个消费者，并尝试为每个消费者在他们正在使用的主题中提供一个或多个特定的数据分区。 为了实现这一点，Kafka跟踪使用者（Logstash Kafka输入线程）是否在其分配的分区上取得了进展，并重新分配了在指定时间范围内未取得进展的分区。

当Logstash向Kafka Broker请求的事件超出其在超时范围内无法处理的事件时，它将触发分区的重新分配。 分区的重新分配需要时间，并且可能导致事件的重复处理和严重的吞吐量问题。

Possible solutions

减少Logstash在一个请求中从Kafka Broker轮询的每个请求的记录数，
减少Kafka输入线程的数量，和/或
在Kafka Consumer配置中增加相关的超时。
Details

max_poll_records选项设置一个请求中要提取的记录数。 如果超过默认值500，请尝试减小它。
Consumer_threads选项设置输入线程的数量。 如果该值超过了logstash.yml文件中配置的管道工作程序的数量，则应该减少该值。 如果该值大于4，如果客户端有时间/资源，请尝试将其减小到4或更小。 尝试从1开始，然后从那里开始递增以找到最佳性能。
session_timeout_ms选项设置相关的超时。 将其设置为一个值，以确保max_poll_records中的事件数可以在该时限内安全地处理。
EXAMPLE
Pipeline throughput is `10k/s` and `max_poll_records` is set to 1k =>. The value
must be at least 100ms if `consumer_threads` is set to `1`. If it is set to a
higher value `n`, then the minimum session timeout increases proportionally to
`n * 100ms`.
实际上，该值必须设置为比理论值高得多，因为管道中输出和滤波器的行为遵循分布。 该值还应该大于您期望输出停止的最长时间。 默认设置为10s == 10000ms。 如果您遇到输出因负载或类似影响而可能停顿的周期性问题（例如Elasticsearch输出），则将该值显着提高到60s几乎没有什么不利之处。

从性能的角度来看，减小max_poll_records值优于增大超时值。 如果客户端的问题是由定期停止输出引起的，则增加超时是唯一的选择。 检查日志以获取停顿输出的证据，例如ES输出日志状态429。

1.5.2.大量的偏移提交（Kafka输入端）
Symptoms

Logstash的Kafka输入导致对偏移量主题的提交数量比预期的多得多。 通常，投诉还提到重复执行相同偏移量的冗余偏移量提交。

Solution

对于Kafka Broker版本0.10.2.1到1.0.x：问题是由Kafka中的错误引起的。 https://issues.apache.org/jira/browse/KAFKA-6362客户的最佳选择是将其Kafka Brokers升级到1.1版或更高版本。

对于较旧版本的Kafka或上述解决方案不能完全解决问题：可能是由于将poll_timeout_ms的值设置得相对于Kafka经纪人自己接收事件的速率而言太低（或者如果经纪人在两次接收之间周期性地闲置） 突发事件）。 在这种情况下，按比例增加为poll_timeout_ms设置的值会减少提交的偏移量。 例如，将其提高10倍将导致偏移提交减少10倍。

1.5.3.Kafka输入中的编解码器错误（仅在插件版本6.3.4之前）
Symptoms

Logstash Kafka输入会随机记录配置的编解码器中的错误和/或错误地读取事件（部分读取，多个事件之间的数据混合等）。

Log example: [2018-02-05T13:51:25,773][FATAL][logstash.runner ] An
unexpected error occurred! :error=>#<TypeError: can't convert nil into String>,
:backtrace=>["org/jruby/RubyArray.java:1892:in `join'",
"org/jruby/RubyArray.java:1898:in `join'",
"/usr/share/logstash/logstash-core/lib/logstash/util/buftok.rb:87:in `extract'",
"/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-codec-line-3.0.8/lib/logstash/codecs/line.rb:38:in
`decode'",
"/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-kafka-5.1.11/lib/logstash/inputs/kafka.rb:241:in
`thread_runner'",
"file:/usr/share/logstash/vendor/jruby/lib/jruby.jar!/jruby/java/java_ext/java.lang.rb:12:in
`each'",
"/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-kafka-5.1.11/lib/logstash/inputs/kafka.rb:240:in
`thread_runner'"]
Background

当在多个线程上运行（consumer_threads设置为> 1）时，Kafka Input插件处理编解码器实例的方式存在一个错误。 https://github.com/logstash-plugins/logstash-input-kafka/issues/210

Solution

将Kafka Input插件升级到6.3.4或更高版本。
如果（且仅）不可能升级，请将consumer_threads设置为1。
1.5.4.Other issues