Prometheus添加监控

完整译文请访问：http://www.coderdocument.com/docs/prometheus/v2.14/best_practices/instrumentation.html。

如何添加监控

简而言之，就是为一切事物添加监控。每个库、子系统和服务都应该至少有一些指标，以便你了解它是如何执行的。

添加监控应该是代码中不可或缺的一部分。在使用它们的同一个文件中实例化指标类。这使得在跟踪错误时从告警到控制台再到编写代码变得很容易。

三种服务类型

出于监控目的，服务通常可以分为三种类型：在线服务、离线处理和批处理作业。它们之间有重叠，但每个服务都倾向于很好地符合其中一个类别。

在线服务系统

在线服务系统是指一个人或另一个系统期望即时响应的系统。例如，大多数数据库和HTTP请求都属于这一类。

在这样的系统中，关键指标是执行查询的数量、错误和延迟。正在处理的请求的数量也很有用。

要计算失败的查询，请参阅下面的失败部分。

在线服务系统应该同时在客户端和服务器端进行监控。如果双方看到不同的行为，这对于调试是非常有用的信息。如果一个服务有许多客户端，那么服务单独跟踪它们是不现实的，因此它们必须依赖自己的统计数据。

无论你在查询何时开始或何时结束时计数，都要保持一致。建议在查询结束时计数，因为它将与错误和延迟统计信息一致，并且更容易编码。

离线处理系统

对于离线处理，没有人在积极地等待响应，并且工作的批处理是常见的。也可能有多个处理阶段。

对于每个阶段，跟踪输入事项、有多少事项正在处理、最后一次处理的时间以及发送了多少事项。如果是批量处理，你还应该跟踪进出的批次。

知道系统处理某件事情的最后时间对于检测它是否停止是有用的，但是它是非常局部化的信息。更好的方法是通过系统发送一个心跳：一些一直传递的虚拟事项，包括插入时的时间戳。每个阶段都可以导出它看到的最新心跳时间戳，让你知道事项在系统中传播需要多长时间。

批处理作业

离线处理和批处理作业之间有一条模糊的界线，因为离线处理可以在批处理作业中完成。批处理作业的区别在于它们不是连续运行的，这使得抓取它们的指标非常困难。

批处理作业的关键指标是它最后一次成功的时间。跟踪作业的每个主要阶段花费的时间、总体运行时间和最后一次完成作业的时间（成功或失败）也很有用。这些都是Guage指标，应该被推送到一个推送网关。通常也有一些特定于作业的总体统计数据值得跟踪，比如处理的记录的总数。

对于运行时间超过几分钟的批处理作业，还可以使用基于拉取的监控来抓取它们的指标。这使你能够随着时间的推移跟踪与其他类型作业相同的指标，例如与其他系统通信时的资源使用和延迟。如果作业运行开始变慢，这可以帮助调试。

对于经常运行的批处理作业（例如，超过每15分钟一次），你应该考虑将它们转换为守护进程，并将它们作为离线处理作业进行处理。

完整译文请访问：http://www.coderdocument.com/docs/prometheus/v2.14/best_practices/instrumentation.html。