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