聊聊监控

最新推荐文章于 2021-10-21 16:11:41 发布

felix021

最新推荐文章于 2021-10-21 16:11:41 发布

阅读量341

点赞数

文章标签：大数据 java 分布式数据分析数据库

本文链接：https://blog.csdn.net/felix021/article/details/109269192

版权

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

指标

《踩坑记：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 通过定制化的数据结构，能够大幅提高对时序数据的采集、存储和查询效率。

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

时序数据库是为了帮助我们发现问题，但不应因此影响线上业务，因此 client 的实现往往会采用 udp 或者 sidecar 的方式实现，从而达到 nonblocking 的效果（当然其代价是可能会丢失一些数据）；
OpenTSDB 底层只存储了数据点的采样值，这适合用来存储 cpu 使用率、goroutine 进程数等数据（当前值和历史值无关），对于更复杂的需求，例如计数器、延迟(需要计算avg/p95/p99)等，需要在客户端或 sidecar 里实现一个累加器、计时器，并上报它们的采样值；
由于每一组 tag key/value 组合（例如前述 ip=10.0.0.1, datacenter=sh）都对应一个独立的 Time Series ，因此需要控制这些 tag 取值组合的总数；一个典型的 badcase 是使用 uid 作为 tag ，可能导致千万甚至更多的独立组合，从而对存储和查询造成过大的压力；
在性能要求特别苛刻的场景，例如超高并发、低延迟业务采集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) 异常点的特征与正常点差异很大。因而，如果在数据空间某个区域里点的分布很稀疏，我们就可以认为该区域中的点为异常点。

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