我正在开始检测 Web 应用程序的过程，并使用 StatsD 收集尽可能多的相关指标。例如，以下是我目前使用的一些高级指标名称的示例:
http.responseTime
http.status.4xx
http.status.5xx
view.renderTime
oauth.begin.facebook
oauth.complete.facebook
oauth.time.facebook
users.active
……还有很多很多。我现在正在努力解决的是为各种指标建立一致的层次结构和一组命名约定，以便当前的指标有意义并且有逻辑桶可以在其中添加 future 的指标。
我的问题有两个:
最佳答案
这是一个没有明确答案的问题，但这是我们在 Datadog 处的做法(我们是托管监控服务，因此我们倾向于关注这些事情)。
1.哪些指标是必不可少的？ 这取决于旁观者。但在高层次上，对于每个团队，任何尽可能接近他们目标的指标(这可能不是最容易收集的)。
系统指标(例如系统负载、内存等)很容易收集，但很少可操作，因为它们很难可靠地将它们与可能的原因联系起来。
另一方面，完成产品导览的次数对于任何负责确保新用户从使用产品的第一分钟起就感到满意的人都很重要。 StatsD 使收集这类东西变得非常容易。
我们还发现，随着产品的发展，任何团队的核心关键指标都会发生变化，因此有一个 连续编辑过程 。
这反过来意味着公司中的任何人都需要能够挑选对他们来说重要的指标。没有权限要求，没有摩擦来获取数据。
2. 命名结构 层次结构的最高级别是产品线或流程。我们的 Web 前端在内部称为 dogweb，因此来自该组件的所有指标都以 dogweb. 为前缀。下一级层次结构是子组件，例如dogweb.db. 、 dogweb.http. 等
层次结构的最后一层是被测量的事物(例如 renderTime 或 responseTime )。
Graphite 中 Unresolved 问题是度量名称中度量元数据的编码(以及使用 * 的选择，例如 dogweb.http.browser.*.renderTime )它很聪明，但会妨碍。
我们最终在我们的数据模型中实现了显式元数据，但这不在 statsd/graphite 中，因此我将省略详细信息。如果您想了解更多，请直接与我联系。
关于graphite - StatsD/Graphite 度量命名约定，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/18108047/