前阵子的DTC2023上，我分享的内容是关于数据库可观测性的。会后有不少朋友都和我聊了关于数据库可观测性的问题，也有很多朋友对于这个新名词感到有点高大上，不过并不以为然。认为可观测性就是以前的数据库监控的炒冷饭。实际上从数据库监控到利用数据库的可观测性能力去做数据库运维，是在运维与监控领域的一个升级，而并不是用一句炒冷饭可以概括的。传统的数据库监控与现在大家说的数据库可观测性还真的不能等同来看。         上面是我总结的监控与可观测性的一些差异，这是我对这两个概念的理解，并不是这个问题的标准答案。我们传统的监控主要是对已知的场景进行指标采集，并设置仪表盘，依赖已知的知识去做监控，比如设定某些阈值，或者采用某些数据库日志的分析去发现数据库的异常。这种模式比较容易发现一些简单的，唯一性的问题，如果遇到复杂的场景，则很难被发现或者被定位。另外简单的监控日志告警或者基线阈值，很难发现系统中存在的真正的问题，经常因为阈值设置不够合理（甚至很难找到阈值的合理设置）或者对日志告警的理解不够深入而导致告警过多，淹没了真正的系统问题。而可观测性更注重与对系统进行深度的分析，因此可观测性能力既可以给提前假设的问题提供分析支撑，也可以用来分析未知的问题。因为能够进行足够深入的分析，因此可以对告警进行有效的收敛，从而预警与定位复杂场景下的复杂问题。可观测性能力可以用于建立操作任务与威胁用户体验的问题之间的关联，并能够正确应用可观察性可以提高IT系统的可用性和性能，从而改善用户体验，这是可观测性能力最重要的作用。可观测性能力还有助于在IT运维或者运营中降本增效，通过加快故障处置的速度和提前预警故障来降低系统故障带来的运营成本增加，通过减少不相关或冗余信息的数量并优先通知关键事件来实现的运维成本的降低，这种降本增效在需要大型运营团队的大型企业运营中最为明显。实际上目前很多企业都在使用的开源监控软件ZABBIX、普罗米修斯等，这些年都有了较大的发展。特别是普罗米修斯，这些年已经脱离了传统的监控系统，从而面向建设全面的可观测性能力。

• 支持多种类型的监控对象，如 Linux 系统、MySQL、Redis、Kubernetes、容器等，通过安装不同的 exporter 来适配不同的数据源；

• 支持自定义查询语言 PromQL，可以对收集的指标数据进行复杂的分析和聚合；

• 支持与 Grafana 集成，可以通过导入模板或自定义 Dashboard 来展示监控数据；

• 支持与 Alertmanager 集成，可以根据预定义的规则发送告警通知。

前些年，我们最为常用的就是与Grafana的集成，从而构建企业的监控仪表盘并通过Alertmanager对告警信息进行过滤和处理，从而解决告警风暴的问题。PromQL 是普罗米修斯的查询语言，可以用来选择和聚合时序数据，从而实现基础指标数据的深度加工。利用这些能力，普罗米修斯不仅仅可以作为普通监控工具来使用，而且可以注入运维团队的运维经验。这些技术能力的构建和我们开发D-SMART是有异曲同工的效果的。只是D-SMART从研发之初就把监控放在一个很小的位置，主要面向运维知识自动化能力的构建。可观测性能力建设比监控能力建设具有更大的挑战性，这一点可以从以下几个方面来分析：

• 意外数据不可见：未能正确构建关键数据集导致某些关键数据在重要事件发生时不可见，这可能会导致错过关键条件，无法正确预警或者无法正确定位故障根因；
• 关键数据缺失：在建设监控系统的时候并非所有重要信息都被收集，大多数是因为可观测性系统建设者缺乏相关经验或者建设之初仅仅从监控入手；
• 数据格式复杂性导致的数据割裂：当同一类型的数据以不同的格式来自不同的来源时，可能很难收集正确的信息并解释可用的信息；需要一种将信息结构化为标准形式的有组织的策略，以确保最佳的可观察性处理，并且能够把不同格式的原始数据解释为统一的可观测性模型体系。

数据库的可观测性能力可以应用于十分广泛的领域，帮助DBA清晰的了解数据库的运行状态，并且能够辅助完成大量的复杂工作。下图是我总结的一张数据库可观测性能力的图。

今天一早要出差，所以只能简单的聊聊，关于这个演讲的完整内容，等我出差回来，录一段视频分享给大家吧。