mzh/blog

监控入门: 收集正确的数据

本文为Datadog《monitoring 101:collecting the right data》的中文翻译,有部分删减。原作者:Alexis Le-Quoc

本文是关于有效地监控系统的系列文章之一。敬请关注本系列的其它文章《有关的,才告警》和《调查性能问题》(译注:后续会翻译)。

监控的数据有多种形式—- 有些系统持续地输出数据而另一些是在罕见事件发生时产出数据。有些数据对于定位问题十分有用;而另一些则在调查问题时起主导地位。(译注:分别对应错误日志,性能日志)。本文涵盖了什么数据需要收集,以及如何对数据进行分类,读完后你就能:

  1. 对于潜在的问题接受有意义的,自动化的警告
  2. 进行快速调查并追查到性能问题的根源

不管你监控的数据形式如何,不变的主题是

收集的监控数据平时是没啥用,但是如果在你需要的时候你却没收集到,那监控数据就是宝贵且昂贵的,因此你需要尽可能地插手一切系统,收集你能收集到的一切的合理的数据。

监控(Metrics)

监控捕获的是系统在特定时间点上的有关数值—-举个例子,当前登入你web应用的用户总数。因此,监控常常设定在每秒、每分或其它常规间隔时间收集一次数据。

在我们的监控框架中有两个重要的分类:工况监控(work metrics)和资源监控(resource metrics)。每一个系统都是你软件的基础设施,对工况和资源监控都是合理的需求,请把他们都收集起来。

工况指标

工况通过有意义的输出数据,揭示了系统的顶层健康状况。当你给工况指标分类时,将它们分成4小类会相当有帮助:

下面是web服务器和数据存储应用中常见的工况指标例子。

Example work metrics: Web server (at time 2015-04-24 08:13:01 UTC)

SubtypeDescriptionValue
throughputrequests per second (每秒请求数)312
successpercentage of responses that are 2xx since last measurement(距上次测量时2xx返回值的百分比)99.1
errorpercentage of responses that are 5xx since last measurement0.1
performance90th percentile response time in seconds (90%的请求响应时间)0.4

Example work metrics: Data store (at time 2015-04-24 08:13:01 UTC)

SubtypeDescriptionValue
throughputqueries per second949
successpercentage of queries successfully executed since last measurement100
errorpercentage of queries yielding exceptions since last measurement0
errorpercentage of queries returning stale data since last measurement4.2
performance90th percentile query time in seconds0.02

资源指标

对于其它系统来说,大部分的组件都是你软件基础设施都是它们的资源。有些资源是底层的—- 例如,一台服务器的资源包括的物理组件有CPU,内存,磁盘和网络接口。但是高层组件,如数据库或地理位置服务,也可以看成是其它系统正常工作所需的资源。

资源监控对于调查问题常常是非常有价值的。对于每个资源项,你应该尽力地收集4个关键领域:

  1. 使用率(utilization) 是资源忙/闲时的百分比或者是资源总量的使用率。
  2. 饱和量(saturation) 已经请求的、但是尚未处理的工作,通常是队列。
  3. 错误(errors) 表示的是系统运转过程中也许无法侦测到的内部错误。
  4. 可用率(availability) 表示请求返回总数中正常的百分比。这个指标仅仅在资源可被定期地检查才可以用。

下面是一个对于常见资源类型的资源监控:

ResourceUtilizationSaturationErrorsAvailability
Disk IO% time that device was busywait queue length# device errors% time writable
Memory% of total memory capacity in useswap usageN/A (not usually observable)N/A
Microserviceaverage % time each request-servicing thread was busy#enqueued requests# internal errors such as caught exceptions% time service is reachable
Databaseaverage % time each connection was busy# enqueued queries#internal errors, e.g. replication errors% time database is reachable

其它指标

还有一些指标既不是资源也不是工况,但是对于诊断问题根源很有用。常见的例子有缓存的命中率和数据库的锁数量。有疑问时,收集它们。

事件

对于指标的监控或多或少都是持续地进行的。有些监控系统还可以捕获事件:分离的,无规律的,对于了解什么改变了你系统的行为提供了关键的上下文。一些例子:

一个事件常常携带了足以能解释自己的信息,不像其它数据指标,只能提供一个大概的环境。合理的事件包含了,发生了什么,在什么时候,附带信息。这里有些例子:

What happenedTimeAdditional information
Hotfix f464bfe released to production2015-05-15 04:13:25 UTCTime elapsed: 1.2 seconds
Pull request 1630 merged2015-05-19 14:22:20 UTCCommits: ea720d6
Nightly data rollup failed2015-05-27 00:03:18 UTCLink to logs of failed job

事件有时用来生成警告—-像上表中第三行,有人应该收到通知,关键的任务失败了。但更通常的情况下,事件用来调查跨系统的问题。总之,把事件当指标—- 它们有价值,能收集的尽量收集。

好的监控数据长啥样

得有四个特性:

为了告警和诊断的数据

下面有张关于不同等级警告的描述和它们的紧急程度。简单来说,低等级的告警时不需要通知任何人的,只需要记录在案以便不时之需。一个通知(notification)等级的警告算是中等级的,可以通过不打断人工作的方式通知,例如邮件或者聊天室。一个Page(译注:寻呼机)等级的告警是十分紧急的,需要立即有人工参与,不管维护的人是在睡觉还是享受个人时光。

DataAlertTrigger
Work metric: ThroughputPagevalue is much higher or lower than usual, or there is an anomalous rate of change
Work metric: SuccessPagethe percentage of work that is successfully processed drops below a threshold
Work metric: ErrorsPagethe error rate exceeds a threshold
Work metric: PerformancePagework takes too long to complete (e.g.,performance violates internal SLA)
Resource metric: UtilizationNotificationapproaching critical resource limit (e.g., free disk space drops below a threshold)
Resource metric: SaturationRecordnumber of waiting processes exceeds a threshold
Resource metric: ErrorsRecordnumber of errors during a fixed period exceeds a threshold
Resource metric: AvailabilityRecordthe resource is unavailable for a percentage of time that exceeds a threshold
Event: Work-relatedPagecritical work that should have been completed is reported as incomplete or failed

总结:全收了