nsqio/nsq

nsqd: record delivery to FIN metrics

Open

#347 创建于 2014年5月19日

在 GitHub 查看
 (1 评论) (0 反应) (0 负责人)Go (25,788 star) (2,898 fork)batch import
featurehelp wanted

描述

We currently have end-to-end (from PUB to FIN) metrics in NSQ. We need another distinct set of "e2e" metrics that measure delivery (the point in time nsqd wrote the message to the wire) to FIN.

This way you could separate the overall end-to-end processing health from the current health of the consumption side.

Obviously, when the queue is 30mm behind the existing E2E metrics are gonna go through the roof (and from a business perspective it's a good metric to know).

But, for debugging, you want to be able to understand how fast your workers are currently able to process messages. This would help identify when it's a consumer/downstream problem vs. something else. i.e. If it normally takes 2seconds to process messages but now it's taking 10seconds, that would help explain why you have a backlog.

cc @elubow

贡献者指南

技术栈
go
领域
backendobservability
议题类型
feature
难度面向新贡献者的预计实现难度，1 表示很小改动，5 表示专家级工作。
3
预计时间有经验贡献者完成调查、实现、测试并准备 pull request 的粗略时间范围。
1-2 days
活动状态议题当前的可参与程度：新鲜、活跃、陈旧、阻塞或等待维护者输入。
stale
清晰度议题是否清楚说明期望改动、验收标准和下一步。
clear
前置要求
Go programmingNSQ messaging conceptsMetrics instrumentation
新手友好度1-100 的估计分数，表示该议题对首次贡献者的友好程度。
45
研究方向
Examine the existing end to end metric implementation in the nsqd package, likely in code related to message handling and stats. Identify where the PUB time is captured and where FIN is acknowledged. Add a new metric that records the timestamp when the message is written to the wire (delivery) and compute the difference when FIN is received. Reference the conversation in the issue, including the comment by @elubow, to ensure the solution matches the intended behavior. Consider using the same instrumentation library already in use.