在这篇文章中我们介绍了如何利用Prometheus监控应用。在后续的工作中随着监控的深入，我们结合自己的经验和官方文档总结了一些Metrics的实践。希望这些实践能给大家提供参考。

确定监控对象

在具体设计Metrics之前，首先需要明确需要测量的对象。需要测量的对象应该依据具体的问题背景、需求和需监控的系统本身来确定。

从需求出发

Google针对大量分布式监控的经验总结出四个监控的黄金指标，这四个指标对于一般性的监控测量对象都具有较好的参考意义。这四个指标分别为：

以上四种指标，其实是为了满足四个监控需求：

反映用户体验，衡量系统核心性能。如：在线系统的时延，作业计算系统的作业完成时间等。
反映系统的吞吐量。如：请求数，发出和接收的网络包大小等。
帮助发现和定位故障和问题。如：错误计数、调用失败率等。
反映系统的饱和度和负载。如：系统占用的内存、作业队列的长度等。除了以上常规需求，还可根据具体的问题场景，为了排除和发现以前出现过或可能出现的问题，确定相应的测量对象。比如，系统需要经常调用的一个库的接口可能耗时较长，或偶有失败，可制定Metrics以测量这个接口的时延和失败数。

从需要监控的系统出发

为了满足相应的需求，不同系统需要观测的测量对象也是不同的。在官方文档的最佳实践中，将需要监控的应用分为了三类：

对于每一类应用其通常情况下测量的对象是不太一样的。其总结如下：

除了系统本身，有时还需监控子系统：

选择Vector

选用Vec的原则：

例子：

此外，官方文档中建议，对于一个资源对象的不同操作，如Read/Write、Send/Receive，应采用不同的Metric去记录，而不要放在一个Metric里。原因是监控时一般不会对这两者做聚合，而是分别去观测。

不过对于request的测量，通常是以Label做区分不同的action。

确定Label

常见Label的选择有：

确定Label的一个重要原则是：同一维度Label的数据是可平均和可加和的，也即单位要统一。如风扇的风速和电压就不能放在一个Label里。

此外，不建议下列做法：

my_metric{label=a} 1 my_metric{label=b} 6 my_metric{label=total} 7

即在Label中同时统计了分和总的数据，建议采用PromQL在服务器端聚合得到总和的结果。或者用另外的Metric去测量总的数据。

命名Metrics和Label

好的命名能够见名知义，因此命名也是良好设计的一环。

Metric的命名

Label的命名

依据选择的维度命名，如：

Buckets选择

适宜的buckets能使histogram的百分位数计算更加准确。

理想情况下，桶会使得数据分布呈阶梯状，即各桶区间内数据个数大致相同。

buckets 的设计可遵从如下经验：

需要知道数据的大致分布，若事先不知道可先用默认桶（{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10}）或2倍数桶（{1,2,4,8...}）观察数据分布再调整 buckets。
数据分布较密处桶间隔制定的较窄一些，分布稀疏处可制定的较宽一些。
对于多数时延数据，一般具有长尾的特性，较适宜用指数形式的桶（ExponentialBuckets）。
初始桶上界一般覆盖10%左右的数据，若不关注头部数据也可以让初始上界更大一些。
若为了更准确计算特定百分位数，如90%，可在90%的数据处加密分布桶，即减少桶的间隔。