在这个工具上我们看到了太多的Oracle的工作细节，SpotLight可以说是我对Oracle数据库内部结构学习的第一个老师，很多DBA都对着SpotLight猜测Oracle的UNDO/REDO/DB CACHE/SHARED POOL等的工作机理。在二十年前，SpotLight可以算是Oracle数据库可观测性的巅峰之作。

随着对数据库内部原理的理解以及对系统优化的更为深刻的认知，我已经有十多年没有再用过SpotLight了，因为SpotLight的可视化界面离我对Oracle可观测性的要求相去甚远。数据库可观测性能力不再意味着把数据库内部的各个组件用一个十分容易看懂的方式图形化展示，而是需要了解数据库内部运作中存在什么特性，存在哪些风险，需要采取哪些前置性优化措施。

数据库可观测性能力的需求在不同类型的用户中也差异甚大。数据库可视性或者说可观测性并不是指那些花里胡哨的图形图表，而是指运维人员可以使用工具、脚本、接口获得的数据库的各种指标、日志、状态、统计值，并依靠这些基础数据进行自动化分析的能力。

昨天我们团队和一个用户做了一次交流，他和他的几个人的一个小组使用D-SMART的核心能力为600多套数据库做日常运维监控。我们问他最常用的功能是什么？是不是每天都看看日检报告，是否关注这些数据库的健康、性能、负载方面的模型。他的回答很简单：

这个回答有点出乎我们的意外，不过却让我感到很受鼓舞。对于这样的运维场景，运维人员已经没有时间整天去监控了，遇到运维经验报警使用自动诊断工具，TOPSQL工具去分析问题，定位问题。并通过十分详尽的采集指标去做一些判断和确定，验证自动分析的结果。这确实是我们在设计D-SMART的时候，希望此类用户最佳的使用方式。数据库的可观测性能力已经集成到了工具中了，不需要再通过视觉监控去浪费人力资源。

D-SMART会在本地构建起一个数据库的全面的资料库，而智能化分析工具会帮你做自动的分析。运维人员要做的事情就是相信这个工具，在这个工具发出告警的时候才去使用这个工具。同时记录下这个工具出现分析错误的情况，反馈给技术团队，让我们进一步优化算法。而日检功能他们只是在数据库刚刚接入监控的时候使用，从日检中，他们可以发现一些数据库安装部署时，或者系统刚刚上线时遇到的问题。经过一段时间后，日检中的一些普通问题他们已经不太关注了，一些重大隐患发生时，会通过运维经验告警通知他们，这一点对他们来说就足够了。

这种接近极限的极简模式的运维操作似乎不需要太复杂的界面，不过运维的场景是多样化的。前阵子我们遇到一个金融用户，我们的同事教他看运维经验告警，他说他的主要工作是监控银行核心系统的状态，一旦有风险立即分析处置，因此他不能等着运维经验告警才去做分析，因为他日常的工作就是随时准备应对核心系统的问题，一旦某些核心指标出现异常就马上要进行分析。

因此他们需要通过一个看板来进行运维。因为关注的系统有多个，关注的指标也很多，因此也不适合用SpotLight这种模式，需要一种十分直观的，能看到更多细节的看板来满足他的需求，因此一个表格状的看板是最合适的模式。这个看板上有他们所关心的所有指标，并且某个指标出现异常的时候，能够自动变红，同时点击这个指标，可以进入相应的分析模块。

从数据库运维工作的实践来看，我们不仅仅需要数据库系统能够提供很多可观测的数据，还需要有合适的工具来辅助这些数据的分析与解读。数据库内在的复杂的特性可以被一系列便捷使用的工具所封装，同时我们还需要能够十分方便的访问最原始的数据，以便于专家分析使用。因此从运维的角度来看数据库可观测性，实际上除了数据库产品提供的可观测能力之外，还需要我们拥有可以充分发挥数据库可观测能力的工具。

从这两个典型的需求，我们可以看到，在运维工作中，DBA所需要的数据库可观测性能力实际上实际上是很复杂的，在不同的场景中，我们可能需要不同的能力。虽然如此，我们也可以对这些场景构建一个超集，从而满足各种需求。实际上，Oracle的OEM是一个这方面的不错的样板。可能很少有ORACLE DBA常年使用OEM来监控系统（实际上OEM除了能够用于Oracle的运维外，还支持大量的第三方数据库，中间件等产品）。OEM将所有的运维对象的可观测性数据都离线采集到自己的资料库里，然后利用这些数据来进行展示和分析。

可能有些朋友会觉得采集运维对象的数据并不复杂，直接使用标准的SNMP MIB库不就行了吗？如果你没有深入的去研究数据库、中间件等运维对象，可能会觉得SNMP MIB库是很强大的，不过如果你真的认真去研究MIB库，你会发现大多数MIB库能够提供的能力都是基于网管时代的运维监控思想的，用于监控都十分勉强，要用于分析诊断，那是万万不能的了。受到MIB库影响的一些开源监控平台也存在类似的问题，如果你不去做深度的定制，直接使用的话，在运维可观测性能力建设方面依然是不够的。

全面的可观测性能力建设是需要投入的，因此在建设这方面能力的时候，需要根据自己的实际需要进行，逐步积累能力，而不要总想着一蹴而就。可观测性能力建设没有那么高不可及，那么高大上，只要你能够通过这个能力来完成你的运维目标就可以了。哪怕是当年的一条统计当前数据库等待事件排序的SQL，不也是很好的可观测性能力吗？只要这类的能力积累多了，你的运维能力不就越强了吗？如果从简单了说，运维角度的数据库可观测性就那么简单。