此页面提供了一组针对你的代码进行仪表化的有见解的指南。
简短的答案是仪表化所有内容。每个库、子系统和服务都应该至少有一些指标，以便大致了解其性能。
仪表化应该是你代码不可或缺的一部分。在你使用指标类的同一个文件中实例化它们。这使得在追查错误时，可以轻松地从告警转到控制台再到代码。
出于监控目的，服务通常可以分为三种类型：在线服务、离线处理和批量作业。它们之间存在重叠，但每个服务都倾向于很好地适应这些类别之一。
在线服务系统是指人类或另一个系统期望立即响应的系统。例如，大多数数据库和 HTTP 请求都属于此类。
此类系统中的关键指标是执行的查询数量、错误和延迟。正在进行的请求数量也可能很有用。
有关计数失败查询的信息，请参见下面的 失败 部分。
在线服务系统应在客户端和服务器端都进行监控。如果双方看到不同的行为，这对调试非常有用。如果一个服务有很多客户端，则该服务无法单独跟踪它们，因此它们必须依赖自己的统计信息。
在开始时还是结束时计数查询要保持一致。建议在结束时计数，因为它将与错误和延迟统计信息保持一致，并且往往更容易编码。
对于离线处理，没有人主动等待响应，并且批量处理工作很常见。也可能存在多个处理阶段。
对于每个阶段，请跟踪传入的项目、正在进行的数量、上次处理的时间以及发送出的项目数量。如果进行批处理，还应跟踪传入和传出的批次。
了解系统上次处理某项内容的时间对于检测系统是否停滞不前非常有用，但它是非常本地化的信息。一种更好的方法是通过系统发送心跳：一些虚拟项目会一路传递，并包含插入时的时间戳。每个阶段都可以导出其看到的最新心跳时间戳，让你知道项目在系统中传播需要多长时间。对于没有不进行处理的安静时段的系统，可能不需要显式心跳。
离线处理和批量作业之间存在模糊的界限，因为离线处理可能会在批量作业中完成。批量作业的特点是不连续运行，这使得抓取它们变得困难。
批量作业的关键指标是上次成功的时间。跟踪作业的每个主要阶段所花费的时间、总运行时间和作业上次完成的时间（成功或失败）也很有用。这些都是仪表盘，应该推送到 PushGateway。通常还有一些有用的总体作业特定统计信息要跟踪，例如处理的记录总数。
对于运行时间超过几分钟的批量作业，使用基于拉取的监控来抓取它们也很有用。这使你可以像跟踪其他类型的作业一样，随着时间的推移跟踪相同的指标，例如资源使用情况以及与其他系统通信时的延迟。如果作业开始变慢，这可以帮助调试。
对于运行非常频繁（例如，每 15 分钟一次）的批量作业，你应该考虑将它们转换为守护程序并将它们作为离线处理作业处理。
除了三种主要类型的服务之外，系统还应监控子部分。
库应提供仪表化，而无需用户进行其他配置。
如果它是用于访问进程外部某些资源（例如，网络、磁盘或 IPC）的库，则至少跟踪整体查询计数、错误（如果可能发生错误）和延迟。
根据库的权重，跟踪库内部的内部错误和延迟，以及你认为可能有用的任何常规统计信息。
一个库可能会被应用程序的多个独立部分针对不同的资源使用，因此请注意使用标签在适当的地方区分用途。例如，数据库连接池应区分它正在与之通信的数据库，而无需区分 DNS 客户端库的用户。
作为一般规则，对于每一行日志记录代码，还应该有一个递增的计数器。如果你找到一条有趣的日志消息，你希望能够看到它发生的频率和持续时间。
如果在同一函数中有多个密切相关的日志消息（例如，if 或 switch 语句的不同分支），有时对它们全部递增一个计数器是有意义的。
导出应用程序作为一个整体记录的 info/error/warning 行的总数，并在你的发布过程中检查是否存在显着差异也通常很有用。
失败的处理方式应与日志记录类似。每次出现失败时，都应递增计数器。与日志记录不同，错误也可能会根据你的代码结构上报到更一般的错误计数器。
在报告失败时，你通常应该有一些其他指标来表示尝试的总次数。这使得失败率易于计算。
对于任何类型的线程池，关键指标是排队的请求数、正在使用的线程数、线程总数、处理的任务数以及它们花费的时间。跟踪事物在队列中等待的时间也很有用。
缓存的关键指标是总查询数、命中数、整体延迟，然后是缓存前面的任何在线服务系统的查询数、错误和延迟。
在实现非平凡的自定义指标采集器时，建议导出一个 gauge 指标，用于记录采集耗时（以秒为单位），另一个用于记录遇到的错误数量。
这是两种情况下可以导出持续时间作为 gauge 指标而不是 summary 或 histogram 指标的情况之一，另一种是批处理作业的持续时间。这是因为两者都表示关于特定推送/抓取的信息，而不是跟踪一段时间内的多个持续时间。
在进行监控时，有一些通用的事项需要注意，还有一些是 Prometheus 特有的。
很少有监控系统具有标签的概念以及利用它们的表达式语言，因此需要一些时间来适应。
当您有多个想要添加/平均/求和的指标时，它们通常应该是一个带有标签的指标，而不是多个指标。
例如，与其使用 http_responses_500_total 和 http_responses_403_total，不如创建一个名为 http_responses_total 的单个指标，并使用一个 code 标签来表示 HTTP 响应代码。然后，您可以在规则和图形中将整个指标作为一个整体进行处理。
作为经验法则，指标名称的任何部分都不应以程序方式生成（请改用标签）。唯一的例外是从另一个监控/检测系统代理指标时。
另请参阅命名部分。
每个标签集都是一个额外的时间序列，会产生 RAM、CPU、磁盘和网络成本。通常，开销可以忽略不计，但在具有大量指标和跨数百台服务器的数百个标签集的场景中，这种开销会迅速累积。
作为一般准则，尽量将指标的基数保持在 10 以下，对于超过该值的指标，应力求将它们限制在整个系统中的少数几个。绝大多数指标应该没有标签。
如果您的指标的基数超过 100 或有可能增长到那么大，请研究替代解决方案，例如减少维度数量或将分析从监控转移到通用处理系统。
为了让您更好地了解底层数字，让我们看一下 node_exporter。node_exporter 为每个已挂载的文件系统公开指标。每个节点都会有数十个时间序列，例如 node_filesystem_avail。如果您有 10,000 个节点，您最终将获得大约 100,000 个 node_filesystem_avail 的时间序列，这对于 Prometheus 来说是很好的处理能力。
如果您现在添加每个用户的配额，那么在 10,000 个节点上有 10,000 个用户，您将很快达到数千万。这对于当前 Prometheus 的实现来说太多了。即使数字较小，也会存在机会成本，因为您无法再在此机器上使用其他可能更有用的指标了。
如果您不确定，请从不使用标签开始，并随着具体用例的出现而逐渐添加更多标签。
了解为给定指标使用四种主要指标类型中的哪一种非常重要。
要在计数器和 gauge 指标之间进行选择，有一个简单的经验法则：如果该值可以下降，则它是 gauge 指标。
计数器只能上升（并且重置，例如当进程重新启动时）。它们对于累积事件数量或每个事件中某物的数量很有用。例如，HTTP 请求的总数，或 HTTP 请求中发送的总字节数。原始计数器很少有用。使用 rate() 函数来获取它们每秒增加的速率。
Gauge 指标可以设置、上升和下降。它们对于状态快照很有用，例如正在进行的请求、可用/总内存或温度。您永远不应该取 gauge 指标的 rate()。
Summary 和 histogram 是更复杂的指标类型，在它们自己的章节中讨论。
如果您想跟踪自某个事件发生以来经过的时间，请导出事件发生时的 Unix 时间戳 - 而不是自事件发生以来经过的时间。
导出时间戳后，您可以使用表达式 time() - my_timestamp_metric 来计算自事件以来经过的时间，从而无需更新逻辑并保护您免受更新逻辑卡住的影响。
一般来说，检测带来的额外资源成本远远小于其为运营和开发带来的好处。
对于性能关键的代码或在给定进程中每秒调用超过 10 万次的代码，您可能希望谨慎对待更新指标的数量。
根据争用情况，Java 计数器需要 12-17ns 来递增。其他语言将具有类似的性能。如果这段时间对于您的内部循环来说很重要，请限制您在内部循环中递增的指标数量，并尽可能避免标签（或缓存标签查找的结果，例如 Go 中 With() 或 Java 中 labels() 的返回值）。
还要注意涉及时间或持续时间的指标更新，因为获取时间可能涉及系统调用。与所有涉及性能关键代码的事项一样，基准测试是确定任何给定更改影响的最佳方法。
直到发生某些事情才存在的时间序列很难处理，因为通常的简单操作不再足以正确处理它们。为了避免这种情况，对于您知道可能提前存在的任何时间序列，请导出默认值（例如 0）。
大多数 Prometheus 客户端库（包括 Go、Java 和 Python）将自动为您导出没有标签的指标的 0。
本文档是开源的。请通过提交问题或拉取请求来帮助改进它。