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