COVID-19暴露出分析技术中的致命软肋

• Prometheus Server：用于收集指标和存储时间序列数据，并提供一系列的查询和设置接口。
• Grafana：用于展示各类趋势图，通过 PromQL 从 Prometheus 服务端查询并构建图表。
• Alertmanager：用于处理告警事件，从 Prometheus 服务端接收到 alerts 后，会进行去重，分组，然后路由到对应的Receiver，发出报警。

这块具体的基本知识学习和搭建可详见我写的 Prometheus 系列，本文不再赘述。

监控指标

在平台搭建完毕后，常要做的第一步，那就是规划你整个系统的度量指标，结合 Google SRE 的 4 个黄金指标，可以初步划分出如下几种常用类型：

• 系统层面：Kubernetes Node、Container 等指标，这块大多 Cadvisor 已采集上报，也可以安装 kube-state-metrics 加强，这样子就能够对 Kubernetes 和应用程序的运行情况有一个较好的观察和告警。
• 系统层面：针对全链路上的所有基础组件(例如：MySQL、Redis 等)安装 exporter，进行采集，对相关基础组件进行监控和告警。
• 业务服务：RPC 方法等的 QPS 记录。可以保证对业务服务的流量情况把控，且后续可以做预测/预警的一系列动作，面对突发性流量的自动化扩缩容有一定的参考意义。
• 业务服务：RPC 方法等的错误情况。能够发现应用程序、业务的常见异常情况，但需要在状态/错误码规划合理的情况下，能够起到较大的作用，有一定困难，要在一开始就做对，否则后面很难扭转。
• 应用程序：各类远程调用(例如：RPC、SQL、HTTP、Redis)的调用开销记录。最万金油的度量指标之一，能够在很多方面提供精确的定位和分析，Web 应用程序标配。常见于使用 P99/95/90。
• 语言级别：内部分析记录，例如：Goroutines 数量、Panic 情况等，常常能发现一些意想不到的泄露情况和空指针调用。没有这类监控的话，很有可能一直都不会被发现。

指标落地

第一步完成了整个系统的度量指标规划后，第二步就是需要确确实实的把指标落地了。

无论是统一基础框架的打点，系统组件的 exporter，大多涉及了公司级的跨多部门协作，这时候需要更多的耐心和长期主义和不断地对方向纠错，才能尝到体系建设后的果实。

告警体系

在完成监控指标和体系的建设后，告警如何做，成为了一大难题，再好的监控体系，闭环做不好，就无法发挥出很大的作用。因此我们给告警定义一些准则：

告警不要太多，否则会导致“狼来了”。

告警出现时，应当要具体操作某些事情，是亟待解决的。

告警出现时，应当要进行某些智力分析，不应该是机械行为。

不需要人工响应/处理的告警规则，应当直接删除。

告警出现时，你下意识要再观察观察的告警，要直接进行调整。

告警应当足够的简单，直观，不需要猜。

简单来讲就是告警要少，事件需要解决，处理要人工介入。否则右拐自动化自愈恢复可能更香。

告警给谁?

另外一个难题就是：谁诱发处理的告警，要通知给谁?

这是一个很需要斟酌的问题，在告警的规范上，尽可能遵循最小原则，再逐级上报。也就是先告警给 on-call 人，若超出 X 分钟，再逐级上报到全业务组，再及其负责人，一级级跟踪，实现渐进式告警。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!