我们一起聊聊数据库的可观测性
本周五我会在信通院组织的一个线上沙龙里分享数据库可观测性的话题，这两天在准备PPT，今天我们就顺便聊聊这个话题吧。
实际上可观测性这个概念最初并不是数据库领域发明的，APM厂家最早提出了可观测性的概念。他们认为IT基础设施可以通过监控来解决问题，但是云原生应用系统太复杂了，仅仅通过监控是搞不定的，因此需要通过可观测性能力的建设来解决这方面的问题。
实际上可观测性最初指的是一种IT运维管理策略，目的是将最相关、最重要和最核心的问题提供给运维人员，并将关键信息与常规信息分离，从而达到更好的运维效果。
可观察性是控制理论中的一个要素，它认为 IT 系统的内部状态可以从它们的输入和输出之间的关系中推断出来。因此，它也经常被描述为自上而下的评估。可观察性的挑战不在于从观察中得出内部状态，而在于收集正确的观察。如何进行观察是可观测性发挥作用的关键，而正确的观察往往来自于对于内在原理的理解与存在于现实中的客观规律。
云原生应用来是更为复杂和无序的，而对于数据库来说，相对来说要简单一些。因为数据库系统是按照某种客观规律组织起来的，其内在规律可以被数字化。因此也有一些运维专家认为数据库不需要搞什么可观测性，做监控就好了。其实讨论到这里就已经出现了一个比较头疼的问题了。可观测性和监控到底是个什么关系呢？
一般来说，监控是对一个预知的场景进行数据采集，基线分析与预警，比较依赖于已知的知识，在已知的前提假设下发挥作用。这种方式比较容易发现一些已知的唯一性问题，但是无法进行根因溯源。比如监控很容易发现某个数据库宕掉了，但是比较难以发现数据库中存在的性能问题和一些局部的问题。因此基于监控的网管系统可以帮助运维人员发现系统出现的一些异常，但是不能帮我们精准定位。而告警风暴的出现又会淹没运维工作，给运维工作带来巨大的压力。因此现在很多企业也都希望通过一些AI算法来收敛告警，让监控告警更加精准。
而可观测性则提供了综合的，全面的数据，通过算法的支撑，可以用于复杂问题的分析。可观测性既可以提供带有前提假设性的问题分析，也可以用于未知的问题的分析，还可以通过算法收敛告警，将多类告警信息归类于某个问题，也可以利用丰富的数据做多维度的对比分析，从而确定问题的根源，因此可观测性可以用于十分复杂环境下的问题分析。
如果简单的比较可观测性与监控的含义，我们作为识货的人，肯定是会选择后者的。谁不希望自己的运维自动化系统有更强的能力呢。只不过建设可观测性能力也面临极大的挑战。实际上，如果我们抛开“可观测性”这个看上去十分高大上的词汇，来看看我们日常运维中所遇到的问题。
第一个问题是关键数据缺失的问题，这是我们经常会遇到的问题，分析某个已经发生的故障的根因的时候，由于某些数据没有采集，导致本次分析只能以推测作为终点，或者需要等故障再次发生时才能继续分析。因此要构建强大的可观测性能力，必须实现对关键数据采集的全覆盖，全覆盖这个事情好说不好做。
第二个问题是关键数据出现意外不可见情况，我们认为某个指标异常的时候，系统是异常的，但是系统异常的时候，这个关键数据往往是不可获得的，或者说获得这个数据是存在更大的风险的。这种情况在可观测性方面最常遇到的事情，系统不出问题的时候，可观测性分析都是正常的，但是系统一出问题，可观测性分析工具也出问题了。遇到这种情况，往往是因为可观测性分析工具的建设者经验不足，或者考虑不周。通过更为细致的指标设计，是完全可以规避这个问题的。
第三个问题是多种数据格式与数据来源的复杂性，这导致在一些复杂的场景下，很难正确的采集并正确的解析相关的数据。需要通过专业的模型建立起数据质量的标准，以及数据解读的标准。在D-SMART中，我们就是以运维知识图谱的方式进行知识梳理，并以此来解析这些数据。
对于数据库系统来说，我们其可观测性能力可以通过四个方面的数据来获得。
从日志告警、指标体系、全面跟踪、用户体验这四个方面，我们可以构建数据库系统的可观测性体系。前两个可能大家都比较熟悉，第三个跟踪在数据库里包含各种TRACE的能力，比如Oracle的oradebug，event事件跟踪、各种DUMP等。而用户体验有时候无法在数据库内部获得，需要从数据库之外的应用中去获取。
看上去很简单，不过在数据库中要获得这些能力也并不容易。现在的数据库系统都提供大量的指标，不过指标难以标记和排序，并且难以用于故障排除；而对日志进行排序和汇总，从而得出有意义的结论或与某个故障现象的关系可能具有挑战性；跟踪会产生大量不必要的数据，甚至会引发一些数据库的BUG，导致服务不可用；用户体验的获得也可能不够准确。这些问题都将导致可观测性能力大打折扣。
基于上述原因，我们的国产数据库在建设可观测性能力方面还比较滞后，一般是先搞定了数据库的基本功能，然后才考虑添加可观测性的接口。不幸的是，可观测性能力的基础是和数据库内核关系十分紧密的基础数据采集，通过外挂方式或者通过一些钩子向外输出数据库核心指标会引发一系列的性能与稳定性的问题。因此可观测性能力的构建必须从数据库核心做起才能够更为准确与有效。
目前我们的国产数据库也提供了一些可观测性的能力，只不过与Oracle比起来还有些不足。如果我们能够充分利用这些能力，还是可以获得不错的效果的。我们以openGauss为例，分析一下国产数据库提供的可观测性能力，以及我们利用这些能力能做些什么。
在openGauss数据库中我们可以看到的可观测性接口十分丰富。总结起来有以下几个方面：
- 基础运行状态：PG_STAT_*/DBE_PERF等
- 等待事件：pg_stat_activity/pg_thread_wait_status/dbe_perf.wait_events
- TOP_SQL:发现TOP SQL，慢SQL，进行SQL优化分析
- ASP:GS_ASP/DBE_PERF.LOCAL_ACTIVE_SESSION：分析当前和历史会话的情况，定位微观问题，类似Oracle的ASH
- WDR：一定时间内系统运行情况，用于分析性能问题，宏观方面的故障定位等，类似Oracle的AWR
利用这些可观测性接口我们可以构建起数据库的健康模型，通过健康模型展示数据库的健康状态。
从而帮助我们随时了解数据库的运行情况与问题所在。利用等待事件接口，我们利用知识图谱与智能诊断算法，可以大体定位系统存在的主要问题。
也可以通过可观测性接口，对系统进行快速分析，发现系统中需要优化的点，并推荐优化工具给DBA。
自动化巡检，安全审计，SQL优化等也就更不在话下了。说数据库只需要监控，不需要可观测性的说法已经过时了，随着业务系统复杂性的增加，数据库的复杂度也越来越大，因此数据库具有强大的可观测性能力十分重要。当然你也可以选择另外一条路，把复杂性交给应用，而让数据库变得十分简单。那么你可以使用APM去解决更为复杂而无序的应用，而不用考虑数据库的可观测性了。
