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

时间:2013-08-07 15:54:45

标签: graphite statsd

我正在开始检测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. 您使用什么命名结构对指标进行分类?

1 个答案:

答案 0 :(得分:13)

这是一个没有明确答案的问题,但我们是如何在Datadog处理的(我们是托管监控服务,因此我们倾向于对这些事情感到困惑)。

<强> 1。哪些指标是必不可少的?这取决于旁观者。但是在每个团队的高层,任何尽可能接近目标的指标(可能不是最容易收集的)。

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

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

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

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

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

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

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