Halo的可观测性之谛听

 概述

    无论是商业数据库如Oracle、还是开源数据库如PostgreSQL，它们都是庞大而复杂的软件系统，其架构涵盖存储引擎、查询优化、事务处理等多个核心模块，并常运行在可靠性要求很高的环境中。

    保障这些“庞然大物”稳定、高效运行绝非易事，数据库管理员想必对此深有体会--工作中常需面对配置调优、性能监控、故障解决等一系列挑战。

    数据库管理员在处理相关问题的时候，若能“深入”系统内部查看相关状态，例如通过实时监控关键指标（如锁状态、事务、I/O延迟等）、分析详细日志记录（如错误日志、慢查询日志）等追踪技术，

    对问题分析与解决将起到关键甚至不可或缺的辅助作用--这便是数据库的可观测性，它赋予管理员透视数据库内部动态的能力，从而保障数据库服务的稳定性和高效性。

    那么，数据库的可观测性是如何实现的呢？

    一般数据库内核会提供两种数据记录途径

•  动态性能视图

•  日志系统

下面以PostgreSQL为例来简要介绍这两种途径的优缺点

    PostgreSQL中提供了比较丰富的性能视图，如pg_stat_activity、pg_locks、pg_stat_statements等。

    这类视图通常使用直接读取内存数据或者使用内核提供的钩子函数等技术实现。

    这类视图通常比较固定，不够灵活，而且由于使用了较多的钩子函数，对性能的影响比较大。

    PostgreSQL中日志系统采用的是命名管道技术，是一种异步的日志记录技术。其基本工作原理如下：

PostgreSQL日志系统的优点如下：

•  采用日志分级(panic/fatal/log/error/warning/...)，日志输出的详略程度可通过日志级别调控。

•  日志记录采用异步机制，从而尽可能减少对进程的性能影响。

  PostgreSQL的日志系统已经非常优秀了，但还是存在几个比较明显的短板：

• 无法对特定的进程，如某个会话进程实时动态设定日志级别。假设某会话进程当前执行有异常，我们想让该进程输出更详细的信息，目前是做不到的。

• 如果需要让内核层面输出更多更详细的信息，就需要在代码里添加很多的elog/ereport，这会使得代码变得臃肿，因为会多出很多if (elevel >= ERROR)这样的判断，从而影响系统性能。

为此，我们殚精竭虑，冥思苦想，研发出了基于指令级热插拔技术的Halo数据库可观测功能--谛听。

通过谛听技术，用户可在不影响性能的情况下，随时深入Halo数据库内部观测运行情况，让用户真正具有掌控系统的能力。

总结起来，谛听的核心优势在于：

• 支持会话级动态开启和关闭

• 未开启时零性能损耗

介绍谛听

    我们目前实现了Halo数据库运行过程中15种子场景的状态信息动态采集和输出，覆盖到了Halo数据库运行过程中的全部主要环节，基本满足Halo数据库日常运行中的可观测性需要。

Halo数据库谛听功能的用法如下：

动态开启谛听功能："select halo_enable_session_trace(PID, '日志类型')"。

    参数中的“PID”为Halo数据库会话进程或者其他后台进程的进程ID，“日志类型”就是本文章上面说到的15种子场景中的一种或者多种或者全部。

    通过Halo客户端执行这条SQL后，就会将相关的状态信息输出到指定文件中，然后借助文件中的相关状态信息来分析和解决Halo数据库运行中遇到的各种问题。

动态关闭谛听功能："select halo_disable_session_trace(PID, '日志类型')"。

    参数含义和上面相同。

    通过Halo客户端执行了这条SQL后，就会停止输出相关的状态信息。

    目前我们已经完成的是Halo数据库谛听功能的第一期。

    从客户现场的反馈来看，在几次现场问题的分析和处理中，谛听功能发挥了非常重要的作用，达到了我们的预期。

    后续我们会接着开发第二期，将一些状态信息记录到内部表，纳入内部统计，这会进一步挖掘谛听功能的价值，提高Halo数据库的可观测性。