数据库可观测性中的指标与TRACE

mahan

数据库可观测性由指标、日志、TRACE和体验等要素构成基础能力，DBA和运维工具通过采集这些要素来构建监控预警、运维诊断、根因溯源、巡检等能力。在运维Oracle数据库的时候，一般情况下通过指标、等待事件、ASH、日志等信息来进行日常运维，外加OS层面的oswbb，配合以MOS的知识库，运维起来得心应手。
不过DBA的好日子也快到头了，未来DBA们要更多的接触国产数据库了。国产数据库的可观测性能力如何决定了今后DBA的活是不是好干。很多正在使用国产数据库的DBA朋友有些觉得国产数据库很难用，有些觉得用起来也没啥困难的。这两种极端的观点和以前我们讨论过的其他问题一样，也都是真实感受，并没有撒谎。
认为很好用的DBA主要是因为国产数据库跑起来后，只要不宕机，也没啥可关注的，监控手段也十分有限，因此无为而治就行了。小问题不管也问题不大，大问题出了除了找原厂也没啥手段。大多数情况下让应用开发把SQL优化好，也能平稳运行。反正现在在跑的国产数据库大多数都是新建的，服务器资源富裕得很。
认为很难用的DBA大多数总想按照以前运维Oracle的方式去对国产数据库进行观测与分析，往深里一研究，就会发现很绝望。我也遇到过这方面的问题，刚开始的时候觉得是因为运维知识和运维经验缺失的原因。后来我发现，除了运维知识的缺失以外，国产数据库在可观测性方面的能力不足或者不完备是导致出现这种情况的最主要原因。
我们翻回头再去看看Oracle数据库的可观测能力，等待事件其实不是指标，是trace，Oracle从7.3.4开始开放了OWI，把以前内部使用的trace能力开放给了所有Oracle用户，这是一种革命性的进步。把以往需要通过开启某个开关的跟踪能力变成了常态化的输出，这个革命性的改进让Oracle数据库的运维变得更加容易了。从10g开始，将等待事件指标化，对关键等待事件建立了一系列的指标体系，更加丰富了运维能力。
ASH也不是指标，而是TRACE，以往我们只能通过自己采样来记录数据库的活跃会话情况，从10g开始，Oracle革命性地提供了1秒钟采样的活跃会话历史信息。
OWI的出现，让Oracle数据库的宏观TRACE能力得到了巨大的释放，而ASH的出现，让数据库问题分析与定位能力在微观方面得到了极大的增强。
从Oracle 11g开始，Oracle又补上了可观测性方面的另外一个短板，那就是oswbb，以前OSWatch是作为一个独立的免费工具，可以从MOS上下载的。很多DBA都发现，在诊断数据库问题的时候，往往离不开操作系统数据，如果缺失了这些重要的环节，会让推理的证据链缺失。oswbb的出现，将这个问题完美地补全了。oswbb也是一种trace,不过是针对操作系统的关键组件的trace，30秒的默认采样周期，对操作系统影响不大，不过收益却很大。
从Oracle数据库的客观性发展来看，是让数据这个黑盒子尽可能向用户开放数据，让用户能够更加容易地去使用数据库。因此能够开放的trace功能逐渐变成了常态化的数据输出。
反观国产数据库，虽然这些年也在可观测性方面做了大量的工作，不过与Oracle相比还相差甚远。其实除了Oracle数据库之外，其他的数据库在可观测性方面的差距都不小。DB2在这方面的设计理念与目前的国产数据库类似。DB2拥有比Oracle还要丰富的指标体系，不过大多数指标平时是不输出数据的，在运维过程中如果遇到某个问题，需要分析的时候，才会短暂打开。实际上这些指标虽然叫指标，实际本质上是TRACE。目前的国产数据库也是如此，设计了大量的指标，但是平时没法用，只有当打开某些不建议在生产环境长期打开的参数时才会输出数据。
采用这样的方法，虽然也提供了分析诊断问题的基础能力，但是也提高了运维的门槛。首先是当问题出现的时候，我们只能通过排除法来解决问题，首先要怀疑某个问题是数据库的某方面功能引发的，然后才能修改参数，打开跟踪。如果猜错了，就得找其他的参数去分析。这样的分析方法，与使用Oracle时采用的方法一比，就可以看出效率的差异了。
其次是TRACE的时候必须有原厂工程师或者水平较高的专家在现场才行，否则一旦打开了某些TRACE引发了问题，后果不堪设想。这会让本身就比较稀缺的原厂专家和高水平第三方专家资源变得更加捉襟见肘了。运维效率的降低，必然会带来数据库产品售后压力的增加。
目前国产数据库的这种现状，也让DBA的能力受到严重制约。普通的DBA除了简单监控、采集日志、优化SQL之外，想做得更多就困难重重，DBA的价值受到制约，也会影响DBA职场。一些学习和实践能力较强，技术功底很不错的DBA也可以尝试学习这些TRACE功能，从而掌握一些高级技能。不过因为这方面技术资料的缺失，以及故障场景比较难以模拟，因此学习这些技能也会比较困难。掌握这些技术的DBA会像20多年前能够看懂statspack报告的DBA一样，成为大家眼中的大师。
这种情况存在，对于数据库厂商来说也不是什么好事情。随着数据库国产化替代的深入进行，越来越多的国产数据库在关键业务系统上运行。如果数据库出了问题，必须原厂工程师到场后开启某些TRACE才能定位问题，那么原厂的运维支持成本将会越来越高。我想Oracle当年开放OWI，可能也是从这方面考虑的吧。
开放OWI不是简单的给用户开放一个接口那么简单。让一些原本需要TRACE的数据常态化输出，是需要在数据库内核上做巨大的调整才能够实现的。目前国产数据库在这方面的技术水平差距还是不小的，作为一个DBA，我也希望国产数据库在这方面能够投入更多的研发成本，尽快向Oracle看齐。