特定插件故障排除

Kafka 会话超时问题 (输入)编辑

症状

吞吐量问题和重复事件处理 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

背景

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

当 Logstash 从 Kafka Broker 请求比在超时时间内可以处理的更多事件时，它会触发分区重新分配。分区重新分配需要时间，并且会导致事件重复处理和严重的吞吐量问题。

可能的解决方案

详细信息

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 output logging status 429。

使用模式注册表时 Kafka 输入插件崩溃编辑

默认情况下，kafka 输入插件会在处理事件之前在插件注册期间检查连接并验证模式注册表。在某些情况下，此过程在尝试验证经过身份验证的模式注册表时可能会失败，导致插件崩溃。

该插件提供了一个 schema_registry_validation 设置来更改默认行为。此设置允许插件在注册期间跳过验证，这允许插件继续并处理事件。有关插件和其他配置选项的更多信息，请参阅 kafka 输入插件文档。

大量偏移量提交 (输入)编辑

症状

Logstash 的 Kafka 输入导致对偏移量主题的提交数量远超预期。通常，投诉还提到了重复的偏移量提交，其中相同的偏移量被重复提交。

解决方案

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

对于旧版本的 Kafka 或如果上述方法不能完全解决问题：问题也可能是由于 poll_timeout_ms 的值设置得太低，而与 Kafka Broker 接收事件本身的速率相比（或者如果 Broker 在接收事件突发之间周期性地处于空闲状态）。增加 poll_timeout_ms 的设置值会按比例减少这种情况下偏移量提交的数量。例如，将其提高 10 倍会导致偏移量提交减少 10 倍。

Kafka 输入中的编解码器错误（仅限于插件版本 6.3.4 之前）编辑

症状

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'"]}

背景

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

解决方案

为 Kerberos SASL 设置调试编辑

您可以设置您的机器来帮助您排除 Kafka 客户端中的身份验证错误。

事件中心插件无法连接到存储 Blob（输入）编辑

症状

Azure 事件中心无法连接到 Blob 存储

[2024-01-01T13:13:13,123][ERROR][com.microsoft.azure.eventprocessorhost.AzureStorageCheckpointLeaseManager][azure_eventhub_pipeline][eh_input_plugin] host logstash-a0a00a00-0aa0-0000-aaaa-0a00a0a0aaaa: Failure while creating lease store
com.microsoft.azure.storage.StorageException: The client could not finish the operation within specified maximum execution timeout.

插件无法完成注册阶段，因为它无法连接到在插件 storage_connection 设置中配置的 Azure Blob 存储。

背景

Azure 事件中心插件只能在配置了 Blob 存储连接设置的情况下与其他消费者共享消费者组的偏移量位置。EventHub 使用 AMQP 协议传输数据，但 Blob 存储使用一个利用 JDK 的 http 客户端 HttpURLConnection 的库。要排除 HTTP 连接问题（可能与代理设置有关），必须提高此 JDK 部分的日志记录级别。问题是 JDK 使用 Java Util Logging 来满足其内部日志记录需求，而这无法使用 Logstash 附带的标准 log4j2.properties 进行配置。

可能的解决方案

详细信息

在 Logstash 上启用 JDK 日志记录的步骤

JUL 定义

创建一个可以用来定义日志记录级别、处理程序和记录器的文件。例如，<LS_HOME>/conf/jul.properties。

handlers= java.util.logging.ConsoleHandler,java.util.logging.FileHandler
.level= ALL
java.util.logging.FileHandler.pattern = <USER's LOGS FOLDER>/logs/jul_http%u.log 
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.level=ALL
java.util.logging.FileHandler.maxLocks = 100
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter

java.util.logging.ConsoleHandler.level = INFO # or put FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

# defines the logger we are interested in
sun.net.www.protocol.http.HttpURLConnection.level = ALL  

JVM 属性

要告知 JUL 框架所选的定义文件，必须评估一个属性 (java.util.logging.config.file)，这就是 Logstash 的 config/jvm.properties 派上用场的地方。编辑该文件，添加指向创建 JUL 定义文件的路径的属性

-Djava.util.logging.config.file=<LS_HOME>/conf/jul.properties

日志可能包含敏感信息，例如凭据，并且可能很冗长，但应该提供有关与 Azure Blob 存储的 HTTP 级别连接问题的线索。

其他问题编辑

即将推出，您可以提供帮助！如果您有要添加的内容，请

还可以查看 Logstash 讨论论坛。