谈到可观测性，我们可以用数据库的可观测性能力来做些什么呢？大家肯定可以立即想到可视化展现。确实是的，用漂亮的仪表盘把这些信息展现出来是绝大多数数据库运维工具的选择。不过我们正处于DBA无法跟踪与分析所有系统风险的时代，普通DBA需要在更短的时间内处理更多数据，完成更多工作,因此那些漂亮的仪表盘是展现给谁看的这个问题更像是一个灵魂的拷问。我们必须有能力更为快捷和有效的处理与分析这些数据，而不是把它们展现出来给专家来看，专家根本没时间看这些花花绿绿的仪表盘。
数据库可观察性与传统监控的真正区别在于开放了DBA实时了解系统内部情况的能力，或者你可以让AIOPS工具为你做这件事。 我们认为仪表化的展现数据库的可观测性并不是我们追逐数据库可观测性能力的最终目标，而仅仅是一个方法，而且在信息系统规模日益庞大的今天，这不是一个很好的方法。比较理想的方法是，系统能够自动处理这些数据，并且通过数据库提供的可观测性数据，自动发现数据库可能存在的风险。
似乎理想很丰满，现实能做到吗？我们先来看看可观测性分析常用的理解方式，谷歌的SRE文档中对此有十分详细的描述，因此我在这里就不做过多的阐述了。
可观测性最初指的是一种管理策略。它的目的是将最相关、最重要和最核心的问题提供给运维人员，并将关键信息与常规信息分离，使运维人员易于识别。可观察性是控制理论中的一个要素，针对IT系统而言，它认为 IT 系统的内部状态可以从它们的输入和输出之间的关系中推断出来，因此，它也经常被描述为自上而下的评估。可观察性的挑战不在于从观察中得出内部状态，而在于收集正确的观察。
对于数据库系统来说，我们可以从多个角度对数据库产生的数据进行观察，不过对我们帮助最大的不外乎四个方面：延时、负载、错误、资源使用率。
延时包含各种各样的延时，应用访问的延时，慢SQL，锁的平均等待时间，物理读的平均延时，网络PING延时等，在一个正常的系统中，这些延时应该在一个比较平稳和相对固定的区间内波动，这也是以前网管系统做基线预警得基础。
只不过不同硬件配置，不同业务负载模式，不同负载规模的系统这些延时差异很大，制定合理的基线预警模板工作量较大，所以近些年这些利用基线预警模板已经无法满足当前运维的需求了。虽然我们无法通过基线来直接进行观察，但是多个相关指标之间的延时波动还是有很强的参考性，配合以一些拟合与波动预测算法，从延时上我们还是能够获得很好的观测效果。
负载是一部分故障的根因，比如它可能导致延时增加，错误增加，资源使用率增加。同时负载也可能是一些其他因素的果，比如应用出现BUG，比如说SPINLOCK异常导致负载的不合理升高，亦或是某个磁盘故障引发某条SQL执行变慢，最终导致并发执行的SQL数量增加，引起负载增高。从这方面来看，这四个可观测的方面之间也存在十分复杂的关系。
错误是由于某些外在或者内在因素引起的，外在的错误是应用系统，中间件，存储等上下游要素之间存在的问题。内在的错误是由BUG或者某些系统的内在缺陷导致的。
实际上由于数据库管理系统是十分复杂的软件系统，因此某些缺陷是无法规避和无法以较低成本的方式解决的。这些错误大部分不会引发数据库宕机，仅仅会影响一部分业务或者某个功能的正确实现。如果数据库系统能够把内部错误的计数器作为一个指标输出出来，对于我们进行正确的观测也是十分有价值的。我们在针对某个国产数据库进行分析的时候，发现随着某些种类的并发负载增加，其runtime error也会增加，不过应用的整体功能并未异常，只是部分SQL的执行延时变得不稳定了。
数据库中存在某些错误并不可怕，如果我们知道了这些错误的根因与处置方案后，这些错误就可以比较好的在日常运维中应对了。这两天我们在做某国产分布式数据库的接口。这个产品是一个超级大乐高，是由相当多的开源组件糅合而形成的，文档写的也相当不好。不过有一份文档写的确实很好，那就是《应急处置手册》，里面罗列了五六十个常见应急处置场景，对每个场景的表现，验证方式，处置方式都做了详细的介绍。从文档的内容上看，这些内容应该是从大量的实践案例中总结出来的真实场景，对运维人员运维这套数据库系统来说，十分有价值。这份文档十分类似于我们的“故障模型”，我们利用这份文档也可以十分快捷的构建“运维经验”。
资源使用率是我们能够最方便观测到的系统状态，系统资源使用率的观察主要用途有几个方面，一方面是发现异常，一个数据库系统的资源使用率变化会有一定的规律，发生背离的情况往往预示着系统可能存在某些异常。白天业务高峰时CPU使用率从平均50%突变为平均超过90%，如果持续时间较长，那么一定是系统出现了什么异常，而如果今天突然变得低于20%了，是不是也是一种异常呢？
我想大概率是的。系统资源使用率观察的第二个用途就是容量管理。我们需要为系统的扩容与建设发展制定策略，因此我们会关注使用率的变化，以及使用率与业务增量之间的额关系，从而推断出硬件扩容的最佳时机。过早扩容意味着更高的成本，过晚扩容可能会导致SLA无法保证，因此选取最合适的扩容时机对于企业IT运营中获得较好的成本效益十分关键。
除此之外，观测可以采用直接观测，也可以采用间接观测。昨天一个客户问我，我们的D-SMART能不能对SQL的执行计划变化做实时跟踪，当某个SQL的执行计划走歪的时候能够立即发现。我回答说，一些大型系统，每秒执行的SQL数量是几万甚至几十万，要对每条SQL的执行计划进行实时追踪，成本太大。我们可以采用一些变通的方法来发现执行计划走歪的问题，而不必要去TRACE每条SQL的执行计划。如果一条SQL存在多种执行计划，而且走了一种比较差的执行计划，那么系统的逻辑读、物理读、活跃会化数、并发执行的SQL总数等都会发生变化，我们只要能够发现这些异常就可以通过根因定位找到某条SQL的执行计划变坏了。
