用于度量标准的StatsD/Graphite命名约定

Question

我正在开始检测Web应用程序,并使用StatsD收集尽可能多的相关指标.例如,以下是我目前使用的高级度量标准名称的几个示例:

http.responseTime
http.status.4xx
http.status.5xx
view.renderTime
oauth.begin.facebook
oauth.complete.facebook
oauth.time.facebook
users.active

......还有很多很多.我现在正在努力解决的问题是为各种指标建立一致的层次结构和命名约定,以便当前的指标有意义,并且有一些逻辑存储桶可以在其中添加未来的指标.

我的问题有两个:

1. 您收集哪些相关指标,您发现不可或缺？
2. 您使用什么命名结构对指标进行分类？

Answer 1

这是一个没有明确答案的问题,但这是我们在Datadog上做的事情(我们是一个托管的监控服务,因此我们倾向于对这些事情着迷).

1.哪些指标不可或缺？这取决于旁观者.但是在每个团队的高层,任何尽可能接近目标的指标(可能不是最容易收集的).

系统指标(例如系统负载,内存等)很容易收集,但很少可行,因为它们太难以将它们可靠地连接到可能的原因.

另一方面,完成产品之旅的数量对任何负责确保新用户在使用产品的第一分钟内感到满意的任何人都很重要.StatsD使这种东西很容易收集.

我们还发现,随着产品的发展,任何团队的核心关键指标都会发生变化,因此有一个持续的编辑过程.

这反过来意味着公司中的任何人都需要能够选择哪些指标对他们而言至关重要.没有权限要求,没有摩擦来获取数据.

2.命名结构最高级别的层次结构是产品线或流程.我们的Web前端在内部称为dogweb,因此该组件的所有指标都以前缀为前缀dogweb..下一层次的层次结构是子组件,例如dogweb.db.,dogweb.http.等等.层次结构的最后一级是被测量的事物(例如renderTime或responseTime).

石墨中未解决的问题是度量标准名称中的度量元数据的编码(并且使用*例如选择dogweb.http.browser.*.renderTime)它很聪明但可能妨碍.

我们最终在我们的数据模型中实现了显式元数据,但这不是statsd/graphite,所以我将详细说明.如果您想了解更多信息,请直接与我联系.