聊聊监控

之前说要聊聊监控，这篇来填坑了。

指标

《踩坑记：Goroutine泄漏》开篇那张截图，展示了单个服务进程启动的 Goroutine 数量；除此之外，我们的服务进程在后台还采集了很多其他指标，例如：

（当前存活在堆上的对象所占空间）

这些数据是哪儿来的呢？runtime 包给我们提供了一些API，例如 runtime.NumGoroutine() 可以获得当前 Goroutine 数量，而 runtime.ReadMemStats() 则返回一个 MemStats 类型，给我们提供了内存相关的一系列监控指标。

以下摘取 MemStats 中的一些成员，略作解释：

• TotalAlloc

  • （累计）在堆上分配的对象所占内存；计入已回收对象。

• HeapAlloc

  • 当前存活对象所占内存；不计入已回收对象。

• StackInUse

  • 当前栈占用的内存（包括尚未分配的栈空间）；更准确地说是目前被栈占用的span（go runtime内存管理的一个结构）的内存合计（单位为字节）。

• PauseTotalNs

  • 进程启动以来累计的 GC STW 时间（单位为纳秒）

• NumGC

  • 进程启动以来累计的 GC cycle 数。

还有很多指标没有在这里列出，感兴趣的同学可以查看参考资料 runtime.MemStats [1]。

Go Runtime 的这些性能指标，反应了其运行状态，可以帮助我们排查性能问题：例如上篇《踩坑记：Goroutine泄漏》我们是通过 Goroutine 的上涨发现有泄漏；而在《踩坑记：go服务内存暴涨》，我们其实也可以借助 HeapAlloc 来实锤是否有内存泄漏（如果有内存泄漏的话，HeapAlloc也应该是不断增长，与进程的 RSS 保持同步）。

服务本身的性能指标也很重要，例如接口 QPS、延迟、cache命中率等也很重要。例如在我们的微服务框架中，就采集了每次请求的延迟、请求成功/失败等信息，基于这些信息配置的报警可以帮助我们快速发现下游服务的异常。

实际工作中，还需要关注业务指标 —— 例如点击率、转化率、交易量等等，需要结合自身业务的特定设计合理的指标体系。

采集

有指标还远远不够，还需要想办法采集下来，供后续查询和监控使用。

对于一般的业务数据，我们可能会考虑使用 MySQL 等 RDBMS 来存储，但是对于这类指标往往数据量非常庞大，因而在采集、存储、查询上都需要特殊考量。

例如一个占地5万平方米的数据中心，可能部署了10万台服务器。如果每秒采集一次 CPU 占用率，那就达到 10w QPS 了，更何况除了机器本身的指标，还有大量服务的性能指标、业务指标等。

好在这些指标有一个很重要的共同点：它们都是定时采样的，因此也被称“时序数据”（time series，时间序列）或“度量”（metric）。

以CPU占用率为例，我们可以取名为 "sys.cpu" ，它可能包含多个 tag，例如 ip、datacenter，那么一次典型的采集如下所示：

#   NAME    TIMESTAMP  VAL  TAG1        TAG2
put sys.cpu 1356998400 35   ip=10.0.0.1 datacenter=sh

在这里 sys.cpu {ip=10.0.0.1, datacenter=sh} 就是一个时间序列。

针对其时序特点，我们可以为其设计专用数据结构，并且通过降低采样频率（例如30s一个采样点）来降低负载。很多开源项目就是这么做的，例如 OpenTSDB, Prometheus, influxdb, StatsD 等，都实现了一个时序数据库（Time Series DB，TSDB）。

以 OpenTSDB 为例，它会将时序数据保存在 HBase 中，每一行保存某个时间序列一整个小时的数据，具体而言就是

• ROW KEY = <名称><时间><tag k1><v1><k2><v2>...

  • 时间会对齐到小时开始
  • 名称、k、v 会用另一个表映射到一个6字节整数，从而减少存储量、提高存储和查询效率

• COLUMN FAMILY

  • t = 连续存储该 ROW KEY 下每一个采样点的数据（时间偏移量+数据格式+数据）

从上述存储方式我们可以看到，相比于 RDBMS ，TSDB 通过定制化的数据结构，能够大幅提高对时序数据的采集、存储和查询效率。

在具体实现/使用中还有一些点值得关注：

1. 时序数据库是为了帮助我们发现问题，但不应因此影响线上业务，因此 client 的实现往往会采用 udp 或者 sidecar 的方式实现，从而达到 nonblocking 的效果（当然其代价是可能会丢失一些数据）；
2. OpenTSDB 底层只存储了数据点的采样值，这适合用来存储 cpu 使用率、goroutine 进程数等数据（当前值和历史值无关），对于更复杂的需求，例如计数器、延迟(需要计算avg/p95/p99)等，需要在客户端或 sidecar 里实现一个累加器、计时器，并上报它们的采样值；
3. 由于每一组 tag key/value 组合（例如前述 ip=10.0.0.1, datacenter=sh）都对应一个独立的 Time Series ，因此需要控制这些 tag 取值组合的总数；一个典型的 badcase 是使用 uid 作为 tag ，可能导致千万甚至更多的独立组合，从而对存储和查询造成过大的压力；
4. 在性能要求特别苛刻的场景，例如超高并发、低延迟业务采集QPS，可以考虑进一步采样，例如只随机抽取1%的请求累加计数器，每个请求+100，从而降低采样对性能的影响。

关于 OpenTSDB 的更多细节，感兴趣的同学可以参考其官网[2]，这里不过多展开。

监控

基于 TSDB 提供的 API ，我们就可以实现必要的监控和报警。

一个常用的工具是 Grafana [3]，支持各种 TSDB 作为数据源，并实现了一整套图表工具用于展示，方便创建各类看板，对于排查问题非常有帮助：

不仅如此，Grafana 从 4.0 版开始，还增加了一个 Alert 模块，可以很方便地配置报警规则，且支持邮件等常见报警方式（还可通过 API 扩展）；不过其规则的灵活度不够，不能承载很复杂的报警需求。

比如有这么一个 metric：svc.thoughput{success=1或0}，用于记录累计请求数，并且加上了 tag "success" 用来区分请求成功/失败。

一个常见的监控需求是，针对 QPS 的异常波动进行报警，但由于晚高峰和凌晨的 QPS 差别很大，不能只是设置一个简单的阈值；又或者，我们希望基于错误率进行报警，这就需要计算：

svc.thoughput{success=0} / svc.thoughput{}

这些需求对于 Grafana 来说就超纲了。

监控+

因此我们基于开源项目 Bosun[4] 进行二次开发，以支持复杂的报警需求。它是 Stack Exchange 开发的一个监控报警系统，其特点是实现了一套基于对 metrics 进行计算的表达式。

以前述 QPS 异常报警为例，虽然日内 QPS 会有显著的波动，但是通常日间的请求量却是相对稳定的：

如上图所示，凌晨、中午、晚上由于用户作息带来了明显的低谷和高峰，而代表 T 日和 T - 1 日数据的黄线和绿线则有相当程度的重合；因此我们可以设置这样的报警规则：如果日同比降幅超过 30% 则表示异常。

使用 bosun 表达式，实现这样的规则就很简单了：

# 当日过去 30 分钟 QPS
$today = avg(q("sum:rate:svc.thoughput{}", "31m", "1m"))
# 前日同一时间段 QPS
$yesterday = avg(q("sum:rate:svc.thoughput{}", "1471m", "1441m"))
warn = ($today / $yesterday) < 0.7

注：

• sum:rate:svc.thoughput{} 计算的是 svc.thoughput 的斜率，准确地说是对于两个相邻采样点，计算 (value2 - value1) / (ts2 - ts1) ，也就是 QPS；
• 使用过去 31m ~ 1m 的数据，是因为最近 1m 的数据还没有采集完。

bosun 表达式还提供了很多更复杂的玩法。例如，采集时添加一个 tag "api"，用于区分具体是哪个接口的请求，然后我们只要简单地将 svc.thoughput{} 改成 svc.thoughput{api=*} 就能同时监控所有接口的 QPS 了；又或者我们可以用 epoch() 获取当前时间戳，以针对夜间使用更宽松的阈值。

对 bosun 感兴趣的同学，可以看一下它的官网[4]。这里顺便吐槽一下，它的文档实在写得不咋地，尤其是表达式的那部分，很多方法只提供了描述、没有样例。

监控++

虽然 bosun 已经很强大，但是仍然不能满足所有场景。其根本缺陷在于，规则仍然需要我们从过去的经验中总结 —— 有多少人工，才有多少智能。

还是以 QPS 为例，虽然我们通过监控日同比变化率，绕过了日内的波动，但是却绕不过周内的波动 —— 周一早晨的请求量往往会低于周日同时间段。当然我们也可以在表达式里再加上相应的判断，但还有法定节假日的情况呢？表达式过于复杂，也会导致报警规则难以维护。

如果我们能够基于过去的数据，学习到异常点（离群点）的特征，那就能较好地解决这一类问题。

用于检测异常点的方法有很多，在具体实践中，我们采用了适用于孤立森林算法（Isolation Forest），它通常更适用于连续型、结构化数据（如时序数据）。

孤立森林算法有两个前提：1) 异常数据在总样本中的占比较小；2) 异常点的特征与正常点差异很大。因而，如果在数据空间某个区域里点的分布很稀疏，我们就可以认为该区域中的点为异常点。

基于这俩前提，算法提出了一个很有意思的训练思路。假设从数据点分布在一个二维平面上：

1. 用一个随机直线将平面分为两部分
2. 对每一部分统计点的数量
3. 如果点的数量大于1、且切割次数小于阈值，则重复上述过程

很直观地，数据点密集的区域，所需切割次数会显著高于稀疏区域；找到了稀疏区域，也就确定了离群点。

具体实践中：

• 数据点通常有多个特征（高维空间），因此需要用超平面来做划分；
• 计算所有数据的代价过高，通常是从数据集中抽取一定数量的点作为样本，训练得到一棵决策树；
• 为了降低单次采样/训练误差的影响，我们还需要训练多棵树（森林），综合每棵树的结果得到异常得分；
• 最后与人工设置的阈值对比，决定是否需要报警。

这个算法我自己没有实现过，这一节只能先装到这里了。感兴趣的同学可以阅读参考材料[5]，文中内容详实，还有一个对武林外传的人物性格进行训练、生成决策树的例子，很有意思。

- 小结 -

照例小结一下：

• 通过采集和利用各种性能和业务指标，可以帮助我们快速发现和解决问题；
• 时序数据库（如 OpenTSDB ）通过定制化的架构，能够提供高性能的指标采集、存储、查询能力；
• 通过 Grafana 和 Bosun 等开源项目，我们能够更直观地观察这些指标，以及进行针对性的监控和报警；
• 基于孤立森林等异常点检测算法，可以更智能地发现问题。

限于各种原因，有些细节未能在文中展开（比如我们基于 OpenTSDB 实现的时序数据服务在架构上做了很多改造，以及生产中的具体案例）；而且除了时序数据之外，我们还有很多其他监控报警的方案，感兴趣的同学不如投个简历，到厂里来慢慢看：

↓↓↓ 长期招聘 ↓↓↓

• 投放研发工程师 — 穿山甲 @上海
• 后端研发工程师 - 穿山甲 @北京
• 字节跳动所有职位

欢迎关注

参考资料：

1. runtime.MemStats
2. OpenTSDB
3. Grafana
4. Bosun
5. 异常检测算法 -- 孤立森林（Isolation Forest）剖析