graphite - 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

...还有很多很多。我现在正在努力解决的是为各种指标建立一致的层次结构和一组命名约定，以便当前的指标有意义，并且存在可以添加 future 指标的逻辑桶。

我的问题有两个:

1. 您收集了哪些您认为必不可少的相关指标？
2. 您使用什么命名结构对指标进行分类？

Answer 1

这是一个没有明确答案的问题，但我们是这样做的:Datadog (我们是托管监控服务，因此我们倾向于沉迷于这些事情)。

<强>1。哪些指标是不可或缺的？ 这取决于观看者。但在较高层面上，对于每个团队来说，任何尽可能接近其目标的指标(这可能不是最容易收集的)。

系统指标(例如系统负载、内存等)收集起来很简单，但很少可操作，因为很难将它们可靠地连接到可能的原因。

另一方面，对于任何负责确保新用户从使用产品的第一分钟起就感到满意的人来说，完成的产品体验数量都很重要。 StatsD 使此类内容变得非常容易收集。

我们还发现，任何团队的核心关键指标都会随着产品的发展而变化，因此存在一个持续的编辑流程。

这反过来意味着公司中的任何人都需要能够选择对他们来说重要的指标。无需请求任何权限，无需遇到任何麻烦即可获取数据。

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

Graphite 中 Unresolved 问题是指标名称中指标元数据的编码(以及使用 * 进行选择，例如 dogweb.http.browser.*.renderTime)聪明但可能会妨碍。

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