在 Java 或 Scala 中使用 CodaHale Metrics 为集群环境编写代码时，向 Graphite 报告时有哪些问题？
如果我的应用程序有多个实例正在运行并创建不同的指标，Graphite 可以应对 - 即报告是否累积？
例如，如果我有 AppInstance A 和 B。如果 B 有一个仪表报告 1.2，另一个报告 1.3 - Graphite 的结果是什么？会是平均值吗？或者将一个覆盖另一个。
计数器是累积的吗？
计时器是累积的吗？
或者我应该以某种方式给每个实例一些标签来区分不同的 JVM 实例？
【问题讨论】：
标签： java scala metrics graphite codahale-metrics
您可以在aggreagtion-rules.conf 中找到您的对于石墨在聚合期间收到多个点的情况的默认行为@。 我认为石墨默认是在聚合期间采取最后收到的点。
如果您可能对流程实例的度量细节感兴趣（并且您可能会在某个时候），您应该以某种方式标记实例并在度量路径中使用该标记。 Graphite 对于在请求时进行聚合非常有用，并且找到一种方法来聚合单个指标（总和、平均、最大值或更复杂），但您很难做到。
如果您有一个非常通用的环境，其中实例一直在变化（因此创建了许多临时指标），那么您可能不愿意通过发送方进程获得不同的指标。否则，只要使用 ip+pid 就可以了。
【讨论】：
我为我知道同时进入的每组指标添加了一个“计数”字段。然后我将包括计数在内的所有值汇总为“总和”。这让我可以找到一组中所有指标的平均值、总和和计数。 （是的，石墨的默认设置是在一段时间内采集最近的样本。您需要使用碳聚合器前端。）
将 IP 地址添加到指标名称后，您可以计算不同服务器的相对速度。如果它们都是相同的类型，并且有些是其他类型的 4 倍，那么您就有问题了。 （我见过这个）。如上所述，添加像 IP 这样的临时值会产生死指标问题。如果您关心历史记录，您可以为“旧”创建一个特殊 IP 并在那里收集失效指标，然后删除失效条目。事实上，任何时间段的机器数量都是一个非常有用的指标。
【讨论】：
我们发现处理此问题的最简单方法是使用每个实例的指标。通过这种方式，您可以看到每个实例如何独立运行。如果您想要集群的整体视图，还可以通过在指标名称中使用通配符来轻松查看一组指标的 sumSeries。
这种方法需要注意的是，您要跟踪石墨实例中的更多指标，因此如果您使用托管解决方案，这确实会花费更多。
【讨论】：