Prom、ES、Jaeger 都有了，然后呢？
秦晓辉约 7 分钟图片来自：https://flashcat.cloud/topic/observability/
我们创办“快猫星云”为客户提供监控、可观测性解决方案，创业三年就服务了数百家企业客户，总结客户遇到的普遍问题，主要是在两个方面：
既有的工具没有用透；
没有依据场景建设数据；
既有的工具没有用透
虽然很多工具看起来是有，但是很多公司并没有把工具用好、用透。可能仅仅是搭建起来了，然后根据网上的教程做了简单的配置，并没有和自己的业务深度整合。比如 Prometheus，作为一款优秀的开源监控工具，其适用的场景是非常多的，但是大部分公司仅仅是把 Prometheus 搭建起来，然后使用几个 Exporter 采集数据，导入 Grafana 仪表盘，看到仪表盘数据了，就觉得万事大吉了。但是：
每个指标是何含义？哪些指标比较重要哪些指标不重要？哪些指标甚至因为标签维度爆炸的问题不应该采集？
针对自己的业务，应该配置什么样的告警规则才算合理？
自己的业务程序是否都埋点了，RED 等黄金指标是否都采集了？别人质疑你的服务稳定性的时候，你是否能自证清白？
Exporter 可以采集通用监控数据，业务数据是否做了采集？比如用户注册量、订单量等，这些数据对于业务运营是非常重要的。
Google SRE 那本书里有介绍，所有的 Google 服务，不管是 C++ 的还是 Java 的，不管是 RPC 服务还是 HTTP 服务，都会提供一个 /varz 的 HTTP 接口，用于暴露服务自身的监控数据。仅就服务埋点这一项而言，估计很多公司都没有做到。
为什么没有用透？
管理层不重视，尤其是 CTO。管理层可能没有这个认知，或者认为这个是下面团队的基本功，不需要自己过问。但是下面团队水平参差不齐，最终的效果也是参差不齐。
没有投入专职的团队来推进这个事情。没有量化运营的手段，没有培训，没有 SDK 和平台，甚至没有宣贯，导致大家都不知道这个事情的重要性，就很难落地。
技术团队缺少领头人，互相看不上，互相不通气。各个业务自己造自己的轮子，语言五花八门，开发框架五花八门。此时要做一些横向的统一设计，就会非常麻烦。
怎么办？
从管理层开始，重视监控、可观测性，把这个事情当做公司的核心竞争力之一。你想想，在产品功能一样的情况下，你们的服务更快、更稳定，客户肯定就更愿意使用你们的服务嘛。
投入专职团队，推进这个事情。组成虚拟团队，把各个业务的技术负责人拉到一起，一起讨论监控、可观测性的事情。这个事情不是一个人能够完成的，需要大家一起来做。CTO 挂帅提供尚方宝剑，虚拟团队拉通各个业务，再由 SRE 做过程管理，就比较容易成功了。
引入外部专家或工具平台，利用新平台引入的契机，做一次全方面的梳理。外来的和尚好念经，外部专家一方面可以引入一些新的理念、经验，另一方面是外部专家是中立的，不会受到内部政治的影响，可以更客观的看待问题。
没有依据场景建设数据
大家都知道数据很重要，但是只有零零散散的数据也是远远不够的。我们建设数据的初衷，是希望从数据中提取信息，得到洞察。以可观测性数据举例，大概可以分成四个信息层级：
如果只是把数据采集存储起来，平铺在用户面前，相当于只提供了第一层信息，用户还需要自己去挖掘。但是让普通研发、运维人员通过裸写 Query Language 去挖掘数据，是非常困难的。所以，需要可观测性平台提供一些能力，引导用户去挖掘上层信息。大部分公司建设的零零散散的监控、可观测性系统，都是只提供了第一层或者第二层信息，没有提供更上层的信息，而越是上层的信息，对于业务的帮助越大。
如何建设上层信息？
依据信息层级这个图，我们可以从下往上建设，也可以从上往下建设。
“数据”到“特征”，可以从下往上建设，比如 MySQL 的监控数据，我们做了一张仪表盘，在仪表盘变量里可以筛选 MySQL 实例，选中某个实例即可查看对应实例的监控数据，这个仪表盘就是典型的“数据”维度的仪表盘。
至于“特征”层面的信息，我们也可以做一个仪表盘，这个仪表盘使用“蜂窝图”或“排行榜”或“表格”等图表类型，把所有 MySQL 塞到一张图里，然后在图表里体现出“最大值”、“最小值”等特征，比如慢查询做到一张图里，IO利用率做到一张图里，用户就可以一目了然得知哪个实例问题较大，更应该关注。
“特征”层面的仪表盘更像是一个 Overview，“数据”层面的仪表盘更像是一个 Detail，我们可以在 Overview 的仪表盘图表里配置跳转链接，跳转到 Detail 仪表盘，比如点击“排行榜”中的一个 MySQL 实例，可以跳转到这个实例对应的 Detail 的仪表盘，并且把实例标识作为参数带过去，这样串联起来就很方便查看了。
我手头恰好有一个串联的例子，不过是针对机器监控数据的，道理相通。左侧的是蜂窝图，可以一目了然识别出有问题的机器，点击对应的机器，即可跳转到机器的详情页（即右侧仪表盘）。
至于“观点”层面的信息，仅仅靠有限的指标数据就不够了，需要综合各类可观测性数据。比如线上订单量大跌，各个服务的负责人去排查自己的服务，他可能会希望得到如下零散的结论：
我的服务对外提供的接口是否正常。通过接口的 RED 指标可以得知。
我的服务最近是否有变更，毕竟变更导致线上故障的概率是很高的。通过版本发布记录或变更事件列表可以得知。
我的服务依赖的 MySQL 是否正常。通过 MySQL 的 SLI 数据可以得知。
我的服务是否产生异常报错。通过日志数据可以得知。
我的服务依赖的其他服务是否正常。通过链路追踪数据和 client 侧埋点数据可以得知。
这些零散观点，如何通过分析数据得到？这就需要可观测性系统提供一些能力，引导用户把这些数据建立、组织起来，方便用户分析。比如：
我们可以围绕服务建立相关的数据，把服务的 SLI 数据、变更数据、依赖的其他服务的 SLI 数据、日志数据、链路数据等，都组织起来，形成一个服务的可观测性数据集。如果数据底座建设的完备且规范，理论上各个服务的数据集都是可以复用的，只需要替换里边的具体实例标识即可。
有了服务数据，我们可以建设全局驾驶舱。可以依据业务、系统、子系统、服务这样的层级关系，把服务的健康度层次化组织起来，形成全局视角。一旦发生故障，可以从全局驾驶舱里快速定位到具体的服务。然后再根据服务的可观测性数据集做进一步定位。
本质上，其实就是从需求场景出发来组织数据，或者说，先考虑数据是怎么用的，再考虑数据怎么建。当然了，大部分公司都是先建了一部分数据，然后去用，发现用得不得劲，再回头去治理，这也是常见的做法，也 OK 的。至于如何治理，就可以遵照我上面提到的这些思路。
自动分析数据直接得到洞察？
我们做可观测性产品的终极目标，就是希望用户啥都不用干，平台就可以直接提供止损依据，即告诉用户是哪里的问题，甚至告诉用户应该如何去止损。但是理想很丰满现实很骨感，大部分公司的数据底座建设的不行，数据不完备不规范，数据分析能力不足，所以很难做到这一点。
总结
很多公司都建设了零零散散的监控、可观测性系统，但是遇到故障要定位了，仍然很费劲。本文总结了两个主要原因：一个是既有的工具没有用透；另一个是没有依据场景建设数据。对于这两个问题，我提出了一些解决方案，希望对大家有所帮助。尤其是第二点，站在场景的角度去建设数据，会有更宏观的全局视角，避免迷失在零散的数据中。