很多公司听说可观测性好，就要上马可观测性项目，自研、采购、组团队、拉专项，各种投入之后，结果发现效果很差，业务不认可，最终一地鸡毛。
我的判断很直接：在落地可观测性之前，先看看你们的监控是否已经做好。监控的投入产出比通常更高，而且监控也是可观测性的数据基础之一。
我们公司就是提供监控+可观测性的产品和解决方案，在这里讲让大家慎重落地可观测性，其实是对我们不利的，不过作为乙方，我们更希望真正解决甲方的问题，共同成事，而不是贩卖焦虑，让甲方投入大量资源，最终效果却很差。
核心要点
- 可观测性建设有价值，但它不能替代故障发现；故障发现首先依赖监控。
- 判断监控是否做好，可以看两个问题：覆盖是否完备，能力是否完备。
- 覆盖完备性包括业务、应用、组件、资源、网络和端监控，不只是机器指标。
- 能力完备性包括采集、存储、告警、事件分发、降噪、排班、认领、升级和自动化。
- 如果这两类基础没有做好，优先补监控体系通常比直接做大而全的可观测性项目更划算。
可观测性如果建设得好，对故障定位、梳理架构、知识沉淀等方面都有作用。目前大家建设可观测性，最核心的诉求是解决故障定位问题。
但是，定位故障之前，你得先发现故障，而且尽量靠技术手段发现故障，而不是靠客户投诉。发现故障，首先靠监控。
你可能会想，监控还不简单，Zabbix、Prometheus、Nightingale 很容易就搞定了。嗯，如果说仅仅只是把这些工具装上，那确实简单，但你要思考两个问题：
- 覆盖完备性：是否所有该采集的数据都采集了，该监控的都监控了，该配置的告警规则都无遗漏且合理？
- 能力完备性：数据采集、存储，告警规则管理，事件分发，收敛降噪，告警自愈，都有完备的能力吗？
不是说可观测性不能搞，而是先搞监控，ROI 更高，如果上面两个问题，你觉得都搞挺好了，那你再考虑可观测性为时不晚。
可以用下面这张表做初步判断：
| 判断维度 | 要回答的问题 | 不达标时的典型后果 |
|---|---|---|
| 覆盖完备性 | 业务、应用、组件、资源、网络、端侧是否都被监控 | 故障发生了，但没有任何技术信号先于用户投诉出现 |
| 能力完备性 | 采集、存储、告警、分发、降噪、协同、自愈是否形成闭环 | 有数据、有告警，但没人及时响应，或者响应过程低效 |
| 建设时机 | 监控基础是否足够支撑可观测性分析 | 上了链路、日志、AI 排障，仍然缺少关键数据和上下文 |
覆盖完备性
从监控目标类别划分，监控分为如下方向：
业务监控
业务监控使用业务类指标，比如订单量，平时都是每分钟几百，这会掉底了，说明业务有问题。业务指标/业务监控是最为重要的，体现为：
- 公司高层关注：如果订单掉底，各类 CXO 都会极为关注，相应的产研、运维，显然也要极为重视
- 可以兜底：客户到你们站点的中间环节可能出问题，比如网络、DNS、负载均衡等，这些方面出问题，你的后端模块都是不会告警的，但是订单量这类业务指标可以体现出异常
业务指标数据通常（这里说的通常）从关系库或分析库里读取，通常不会出现在 Zabbix 这类监控工具里，所以，如果你要构建完备的监控系统，要做业务监控，你的告警引擎需要具备读取 OLTP、OLAP 等库的数据并做告警判定的能力。
业务监控是监控体系里的兜底层。主机、容器、服务都可能看起来正常，但订单量、支付量、登录量、门店交易量这类业务指标掉底时，影响已经真实发生。
应用监控
主要是说你们自研/外采的业务系统，通常都是一些 Web 或 RPC 服务，当然，也可能是一些后台批量任务之类的。以 Web 或 RPC 服务举例，业内有一些方法论，典型的是 Google 四个黄金指标和 RED 方法论，即：
- Request：请求量
- Error：错误
- Duration：请求耗时
四个黄金指标比 RED 多了一个 S，即 Saturation，即饱和度，比如你的硬盘 IO 跑满了，新的请求就要在队列里排队，队列深度越大，即饱和度越高，说明越繁忙，需要扩容。
组件监控
这里说的是各类中间件、数据库、分布式存储、Kubernetes 之类的。应用程序通常是依赖这些组件的，这些组件的健康状态直接影响到应用程序的健康状态。所以显然，这些组件也都是要监控的。
这些组件要监控哪些指标才算完备？比较难以回答，可以参考 Google 的四个黄金指标，也可以参考 Datadog 这个文档：https://www.datadoghq.com/blog/monitoring-101-collecting-data/。
其实每个组件要想做好监控，是需要对组件的工作原理极为清楚的，以 MySQL 为例，你可能知道 show global status 可以看到各类系统指标，但是各个指标怎么着算是健康，怎么着算是不健康，这就需要你对 MySQL 的工作原理有深入了解。除了 global status，还有 global variables、InnoDB status、InnoDB metrics、performance schema 等等等等，路漫漫其修远兮。
资源监控
这里是指应用程序的 Runtime 环境，通常是物理机、虚拟机、容器。需要监控 CPU、内存、磁盘、网络等指标。当然，要想做的完备，还需要注意一些偏门指标，比如 ntp 的指标、conntrack 的指标、vmstat 的指标等等。
网络监控
网络监控主要是网络设备、网络链路、外网出口等。
看到网络设备我就头疼 😂，各种 OID 都不一样，之前我们服务 Zenlayer 的时候，感触颇深（Zenlayer 的网络设备种类比较多）。
网络链路通常使用 pingmesh、eBPF 等技术，采集各个单元之间的连通性和连通质量。基础网络如果有问题，上层应用都会有问题，所以要尤为重视。
如果你们的服务是互联网服务，那么外网出口监控、全国各地的拨测监控也是必不可少的。
端监控
端监控是指客户端监控，比如你们的 App、Web 端、H5、小程序，这是用户的访问入口。端监控通常是通过埋点、SDK 等技术采集用户的访问数据，比如页面加载时间、页面交互时间、页面错误率等等。
看吧，搭建了监控系统，只是第一步，连整体进程的 1% 可能都不到，客户在买我们的监控产品之前，我都会跟他讲，监控系统工具和完整的监控体系建设是两码事，只有工具是不够的，后面还有很多落地的工作、消化的过程、治理的工作、甚至运营的工作。
覆盖完备性可以总结为一句话：不要只问“有没有监控工具”，要问“从用户入口到业务结果，再到应用、组件、资源和网络，是否都有可用于发现问题的信号”。
能力完备性
监控这个领域比较驳杂，涉及内容较多，也有很多相关的开源项目，下面我们看看，如何攒一个整体的方案。
能力完备性关注的是另一件事：当信号已经被采集上来之后，系统能不能把它变成可靠的告警、响应和治理动作。
数据采集
监控数据通常是指指标数据，可以用 Telegraf、Categraf、Grafana-agent、Datadog-agent、各类 Exporter、Cprobe 等作为采集器。感兴趣的小伙伴可以挨个 Google 一下，这里不展开了。除了指标数据，日志数据也是很重要的监控数据源，业内采集日志的工具也很多，比如 Filebeat、Fluentbit、iLogtail、Loggie 等等。
当然，有些需要监控的数据可能已经存在于 MySQL、Oracle、ClickHouse、Postgres 等库里了，别的同事已经把数据写到这些库里了（典型的比如订单数据），告警引擎直接对接即可，不需要通过某个采集器来做数据采集。
数据存储
指标数据首推 VictoriaMetrics，用 Prometheus 也行，Prometheus 是单点的存储，需要注意一下。
日志存储首推 Elasticsearch，生态好，对于绝大部分中小企业都够用了，当然，你们的量如果特别巨大，需要大几十台 Data Node，也可以尝试 ClickHouse 降低存储成本。如果对日志检索能力没有很高诉求，对成本非常在意，也可以考虑 Loki、OpenObserve 等这类把日志存储到 S3 上的工具。
告警引擎
开源项目里，专门做告警引擎并且兼容各种数据源的，不太好找，Grafana 算一个，但我个人觉得不太好用，Grafana 还是看图能力更强大。夜莺监控也凑合，对兼容 Prometheus 的各类数据源支持的不错，其他数据源支持的有限。日志这块还有个 ElastAlert，专门对 Elasticsearch 的数据做告警的。另外 Clickvisual 主要是对 ClickHouse 的数据做告警。
我个人首推的，是 Flashduty 的告警引擎。Flashduty 是我们做一个 SaaS 产品，主要是做告警事件 OnCall，即告警事件收敛降噪、分发、排班、认领升级、协同等。虽然 Flashduty 是一个 OnCall 产品，却提供了免费的告警引擎，这个告警引擎可以对接 MySQL、Oracle、Postgres、Prometheus、VictoriaMetrics、Loki、ClickHouse 等各类数据源。
这么好？还能免费用？那你们图啥？
你看看，老想着我从你这得到啥，咱们先想如何共赢不好嘛 😄。坦白讲，免费提供告警引擎是为了给大家带来方便，也是为了给 Flashduty 引流的。最佳白嫖方案是：
注册个 Flashduty 的免费套餐（发送的短信、电话等数量有限制，毕竟短信、电话啥的运营商是要收费的，我们的斤两还没有能力做慈善），然后就可以白嫖告警引擎了。
如果你们的告警数量很多，有很多人要收电话、短信告警，可以使用 179 元/月·人 的专业套餐，那体验，就非常丝滑了。这就是所谓的引流手段了。量少可以白嫖，量大，让我们也赚点呗，共赢，共赢嘛。
OK，推荐的架构，最终就变成了：
数据采集、存储，还是复用你之前的逻辑，想用 Prometheus 就用 Prometheus，想用 VictoriaMetrics 就用 VictoriaMetrics，日志存在 Loki、Elasticsearch、ClickHouse 等，都行，业务数据用 MySQL 也行，用 Oracle 也行，Flashduty 的告警引擎都可以对接。
Flashduty 在云端，访问不了你的存储，所以单独搞了一个 monitedge 的模块，作为告警引擎下沉到你的环境里去部署，monitedge 的逻辑，就是从 SaaS 上同步告警规则，然后读取你的数据做告警判定，如果有异常，生成告警事件推给 SaaS 上的 Flashduty，非常丝滑。
事件分发
上面讲到的 Flashduty 就是做事件分发的，国外有 PagerDuty、Opsgenie，都是做 OnCall 事件分发的，Flashduty 就是对标他们并且适配国内用户习惯。
一般监控系统不是也能做事件分发么？你们开源的夜莺不就可以吗？干嘛还要用 OnCall 工具？
这是因为，一般监控系统侧重在监控数据采集、存储、可视化分析、告警事件生成，对于告警事件后续的处理，比如收敛、降噪、按条件分发、排班、认领、升级、深度集成钉钉飞书企微等，做的功能比较薄，想想 Zabbix、Open-Falcon、Nightingale、Prometheus、ElastAlert、各类云监控，是不是这么个情况？所以 PagerDuty、Opsgenie、Flashduty 这类产品应运而生。
因此，监控体系不是一个单点产品，而是一条链路：
| 环节 | 主要任务 | 关键问题 |
|---|---|---|
| 数据采集 | 指标、日志、业务数据进入系统 | 数据是否覆盖关键对象 |
| 数据存储 | 指标、日志、业务数据进入合适存储 | 查询、保留、成本是否可控 |
| 告警引擎 | 从数据中判断异常 | 是否支持多数据源、多规则形态和合理抑制 |
| 事件分发 | 把告警送到正确的人和流程 | 是否支持降噪、排班、升级、认领和协同 |
| 治理运营 | 持续改规则、补覆盖、降噪声 | 是否有复盘和持续改进机制 |
其实
其实要把监控做好，大概率你的指标数据也就顺便建设的完备了，甚至你的日志也都采集了，其实对于故障定位，也已经可以解决八九成的场景了（可观测性三大支柱，把任意一个支柱单独做到极致，都可以把定位这个事情解决个八九成）。后面如果想继续做可观测性，可以：
- 把缺失的各类数据补充完备
- 做好数据之间的串联
- 根据场景来排布这些数据，把数据真正变成可以洞察的信息
小结
如上，是我接触了 N 多客户之后的一个小感受：可观测性可以做，但不要跳过监控这层地基。
如果你的监控覆盖和响应能力还不完整，优先补业务监控、应用监控、组件监控、资源监控、网络监控、端监控，以及采集、存储、告警、事件分发这条链路。等这些基础足够扎实，再继续补链路追踪、日志关联、架构梳理、知识沉淀和 AI 排障，效果会更可控。
如果你对于监控、Flashduty、可观测性相关的产品感兴趣，欢迎约我们做产品技术交流：
