如何配置 Telegraf 指标跟踪确保队列消费消息送达输出后才确认【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegraf如果你的 Telegraf 实例从 Kafka、MQTT、AMQP 这类消息队列消费数据默认的消费确认方式可能带来一个风险Telegraf 在从 broker 读到消息后就立刻告诉源端消息已消费而此时指标可能还没有真正写入输出端。一旦进程在写入前停止或系统崩溃这批数据就丢了。Telegraf 的Tracking Metrics跟踪指标机制就是为这个场景设计的它让输入插件在指标送达所有输出之后才向上游消息源发送确认ack从而保证未完全送达的消息在之后可以被重新读取。跟踪指标的工作方式根据 docs/METRICS.md 中 Tracking Metrics 一节的说明其工作机制是输入插件读取到一条消息后不会立即确认给消息源而是等待该指标被交给输出端handed to an output之后才通知源端消息已读如果在此期间 Telegraf 停止运行或所在系统崩溃那些尚未完全送达输出的消息不会被确认因此稍后可以被重新读取re-read适用范围限制该机制只作用于内部插件internal plugins。对于外部插件external plugins指标会无视实际输出状态被直接确认。支持该机制的输入插件例如kafka_consumer、mqtt_consumer其 README 中都通过 docs/includes/plugin_tracking_metrics.md 包含了对应的说明段落This plugin supports tracking metrics, which allows the plugin to be notified when metrics have been delivered to all outputs, enabling proper acknowledgment back to the source.见 kafka_consumer README 与 mqtt_consumer README。也就是说只要使用这些内建的队列消费插件跟踪行为就是内置能力无需额外开关你要做的是正确配置它的边界参数。配置 max_undelivered_messages当输入插件使用跟踪指标时插件配置中会出现一个额外选项max_undelivered_messages见 docs/METRICS.md 的 Undelivered Messages 小节该设置决定了在继续读取新消息之前允许有多少条指标处于已读但未确认状态。实际上这意味着 Telegraf 不一定在每个 collection interval 都从输入端读取新消息。以 Kafka 输入为例示例配置如下brokers、topics、consumer_group为插件的实际配置项max_undelivered_messages的 1000 为 sample.conf 中给出的值按你的 broker 与主题替换前三项[[inputs.kafka_consumer]] brokers [localhost:9092] topics [mytopic] consumer_group telegraf ## Max undelivered messages ## This plugin uses tracking metrics, which ensure messages are read to ## outputs before acknowledging them to the original broker to ensure data ## is not lost. This option sets the maximum messages to read from the ## broker that have not been written by an output. ## ## This value needs to be picked with awareness of the agents ## metric_batch_size value as well. Setting max undelivered messages too high ## can result in a constant stream of data batches to the output. While ## setting it too low may never flush the brokers messages. max_undelivered_messages 1000mqtt_consumer的 sample.conf 中同样提供该选项示例值也是 1000。文档对该取值给出了明确的警告调整时要结合 agent 的全局metric_batch_size设得太高Telegraf 可能持续向输出端推送批次绕过 flush interval设得太低可能永远无法刷新flushbroker 中的消息。如何确认行为符合预期文档描述的成功条件是行为层面的正常链路指标在被交给输出端之前消息不会被确认给 broker。你可以据此判断——如果输出端临时不可用上游队列中应仍存在未确认的积压而不是消息被确认后丢失崩溃恢复在 Telegraf 停止或系统崩溃后未完全送达输出的消息可以稍后被重新读取这正是启用该机制要达到的效果消费过慢的排查线索kafka_consumer README 中提示如果 debug 日志中打印了 sarama 关于 abandoning subscription to [topic] because consuming was taking too long 的消息说明单条消息处理耗时过长此时应增大max_processing_time的值。边界与限制跟踪确认只对内部插件生效外部插件的指标会无视输出状态直接确认docs/METRICS.md队列消费类插件属于 service input其 README 中均注明全局或插件级的interval设置可能不适用且 CLI 选项--test、--test-wait、--once可能不会为这类插件产生输出因此不要用这些测试参数去验证消费链路max_undelivered_messages的取值必须与metric_batch_size联动考虑不要单独拍定一个数值。完成上述配置后你的配置文件中应当至少包含一个支持 tracking metrics 的队列消费输入插件、其max_undelivered_messages设置以及对应的输出端插件。之后按上文的行为条件观察确认与积压情况即可判断该机制是否按预期工作。【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegraf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考