如何监控测量你的代码

对于如何监控测量你的代码这个问题,有一个粗暴的答案就是对所有东西监控,每个库、每个子系统和服务都应该至少有几个监控指标,这样你可以了解你的代码是如何运行的。

监控应该是代码的一部分,如果在一个文件中有监控指标,在发生错误的时候就可以定位追踪,从报警到控制台到定位代码位置就变的非常容易。

三种类型的服务

为了进行监控,通常可以将服务分为三类:在线服务,离线服务和批处理作业。它们之间有重叠,但是每种服务都非常适合这些类别之一。

在线服务

在线服务系统有一个特点,用户或者其他系统对他发出请求以后,希望能够立即获得响应。比如,大多数数据库和 HTTP 请求都属于这一类。

在线服务系统的关键指标是执行的查询数、错误数、延迟时间、正在进行的请求的数量、请求失败的数量。

在线服务系统应该同时在客户端和服务器端进行监控,对于调试来说有一个非常有用的信息是双方看到的不同行为。如果一个服务有很多客户端,让这个服务单独跟踪他的客户端是不现实的,所以客户端必须依靠自己的统计数据。

在计算查询的开始时间或结束时间时要保持一致。当它们结束时,它将与错误和延迟统计数据一致,并且容易编写代码。

离线服务

离线处理服务是指没有人要求这个服务及时响应,这个服务可以分批处理已有的任务,也有可能是多阶段处理。

在每个阶段,跟踪进入的项目、有多少项目正在进行、最后一次处理某件事情的时间以及有多少项目已发出。如果是批处理,你还应该跟踪批的进出。

可以通过系统最后一次处理某件事情来判断他是否已经停止,但是这种判断方法存在一定的局限性,另一种更好的方式是通过系统发送心跳信息,并且在心跳信息中插入时间戳。这样可以在离线处理服务的每个阶段看到他最近的心跳时间戳,可以了解当前的处理进度。对于没有在处理任务的时间范围内,可以暂时关闭心跳,不让他显示出现。

批处理作业

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

批处理作业的关键指标是它最后一次成功的时间,跟踪作业的每个主要阶段所花费的时间、总体运行时和作业最后完成的时间(成功或失败)也很有用。这些都是数据指标,应该推送到 PushGateway。通常还有一些对跟踪有用的总体特定于工作的统计数据,例如处理的记录的总数。

对于需要运行几分钟以上的批处理作业,使用基于拉取数据的监控方式来获取它们的监控指标也是很有用的。这使得您可以在一段时间内跟踪与其他类型作业相同的指标,例如与其他系统通信时的资源使用和延迟。如果作业开始变慢,这可以帮助调试。

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

子系统

除了上边的三种主要服务类型之外,系统还应监控其子部分。

库文件

库应提供用户无需额外配置的工具。如果它是一个用于访问进程之外的某些资源(例如,网络、磁盘或IPC)的库,则在最低限度上跟踪总体查询计数、错误和延迟。

根据库的复杂程度,跟踪库本身的内部错误和延迟,以及你认为可能有用的任何常规统计数据。

一个库可能被应用程序的多个独立部分针对不同的资源使用,因此要注意在适当的地方使用标签来区分使用。例如,数据库连接池应该区分与之通信的数据库,而不需要区分DNS客户端库的用户。

日志

一般的规则是,对于每一行日志代码,还应该有一个递增的计数器。如果您发现了一个有趣的日志消息,您希望能够看到它发生的频率和发生的时间。

如果同一个函数中有多个密切相关的日志消息(例如,If 或 switch 语句的不同分支),有时为所有这些消息增加一个计数器是有意义的。

通常,导出应用程序作为一个整体记录的 info/error/warning 行总数也是很有用的,并检查作为发布过程的一部分的显著差异。

失败

对失败的处理应与日志记录类似。每当出现故障时,计数器就应该递增。与日志记录不同的是,根据代码的结构,错误也可能上升到一个更通用的错误计数器。

当报告失败时,您通常应该使用其他度量来表示总尝试次数。这使得故障率很容易计算。

线程池

对于任何类型的线程池,关键指标是排队请求的数量、正在使用的线程数量、线程总数、已处理的任务数量以及它们所花费的时间。跟踪在队列中等待的时间也很有用。

缓存

缓存的关键指标是总查询、命中、总延迟,然后是查询计数、错误和缓存所在的在线服务系统的延迟。

收集

在实现一个重要的自定义指标的 Exporter 时,建议导出一个 Gauge ,以秒为单位收集所需的时间,以及另一个指标所遇到的错误数量。

这是两种情况中的一种,可以将持续时间作为 Gauge 而不是 Summary 或 Histogram 导出,另一种情况是批处理作业持续时间。这是因为这两种方法都表示关于特定推送/刮擦的信息,而不是在一段时间内跟踪多个持续时间。

results matching ""

    No results matching ""