聊聊监控

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

指标

《踩坑记：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. 若是点的数量大于一、且切割次数小于阈值，则重复上述过程

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

具体实践中：

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

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

- 小结 -

照例小结一下：

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

限于各类缘由，有些细节未能在文中展开（好比咱们基于 OpenTSDB 实现的时序数据服务在架构上作了不少改造，以及生产中的具体案例）；并且除了时序数据以外，咱们还有不少其余监控报警的方案，感兴趣的同窗不如投个简历，到厂里来慢慢看：

↓↓↓ 长期招聘 ↓↓↓

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

欢迎关注

参考资料：

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