很多公司听说可观测性好，就要上马可观测性项目，自研/采购，各种投入，结果发现效果很差，业务不认可，最终一地鸡毛。其实凡事总有个过程和时机问题，在落地可观测性之前，我建议你先看看你们的监控做好了没有，监控的投入产出比高，也是可观测性的数据基础之一。
可观测性如果建设的好，对故障定位、梳理架构、知识沉淀等各方面都有作用。目前，大家建设可观测性，最核心的诉求就是解决故障定位的问题，但是兄弟们，定位故障之前，你得先发现故障啊，而且尽量是靠技术手段发现故障，而非靠客户投诉！而发现故障，就是靠监控了！
你可能会想，监控还不简单，Zabbix、Prometheus、Nightingale 很容易就搞定了。嗯，如果说仅仅只是把这些工具装上，那确实简单，但你要思考两个问题：
覆盖完备性：是否所有该采集的数据都采集了，该监控的都监控了，该配置的告警规则都无遗漏且合理？
能力完备性：数据采集、存储，告警规则管理，事件分发，收敛降噪，告警自愈，都有完备的能力吗？
不是说可观测性不能搞，而是先搞监控，ROI 更高，如果上面两个问题，你觉得都搞挺好了，那你再考虑可观测性为时不晚。
从监控目标类别划分，监控分为如下方向：
业务监控使用业务类指标，比如订单量，平时都是每分钟几百，这会掉底了，说明业务有问题。业务指标/业务监控是最为重要的，体现为：
公司高层关注：如果订单掉底，各类 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 都不一样。
网络链路通常使用 pingmesh、eBPF 等技术，采集各个单元之间的连通性和连通质量。基础网络如果有问题，上层应用都会有问题，所以要尤为重视。
如果你们的服务是互联网服务，那么外网出口监控、全国各地的拨测监控也是必不可少的。
端监控是指客户端监控，比如你们的 App、Web 端、H5、小程序，这是用户的访问入口。端监控通常是通过埋点、SDK 等技术采集用户的访问数据，比如页面加载时间、页面交互时间、页面错误率等等。
监控这个领域比较驳杂，涉及内容较多，也有很多相关的开源项目，下面我们看看，如何攒一个整体的方案。
监控数据通常是指指标数据，可以用 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 的数据做告警。
一般监控系统侧重在监控数据采集、存储、可视化分析、告警事件生成，对于告警事件后续的处理，比如收敛、降噪、按条件分发、排班、认领、升级、深度集成钉钉飞书企微等，做的功能比较薄，想想 Zabbix、Open-Falcon、Nightingale、Prometheus、ElastAlert、各类云监控，是不是这么个情况？所以 PagerDuty、Opsgenie这类产品应运而生。
其实要把监控做好，大概率你的指标数据也就顺便建设的完备了，甚至你的日志也都采集了，其实对于故障定位，也已经可以解决八九成的场景了（可观测性三大支柱，把任意一个支柱单独做到极致，都可以把定位这个事情解决个八九成）。后面如果想继续做可观测性，可以：
把缺失的各类数据补充完备
做好数据之间的串联
根据场景来排布这些数据，把数据真正变成可以洞察的信息
【DTCC2024最新大会议题】
👇👇👇
