运维监控中的抽样数据与统计数据

白鳝的洞穴 2022-04-19

1445

2006年的时候，Oracle公司的《Oracle通讯》杂志向我约稿，那时候正好是Oracle公司在大力推广Oracle 10g的时候，当时我问编辑，对这篇文章有什么要求。编辑说，对于优化中数据采集工作的频率与效果的问题，希望我能针对Oracle 10g提供的新功能来写一写。那篇文章最后发表在2017年初的一期《Oracle通讯》杂志上了。那篇文章叫《应用系统生命周期和 Oracle 数据库优化》，不过在那篇文章里，我并没有涉及关于指标采集的频率和效果的问题，因为那时候，我还没有问起考虑好这个问题。那时候客户大多数还正在从古老的Oracle 7、Oracle 8、Oracle 8i向对于Oracle来说已经快过时的Oracle 9i迁移。我们在优化工作中遇到的Oracle 10g也比较少，而且我们也是按照Oracle 9i的方法在分析10g数据库。

后来随着我参与的优化项目越来越多，对这个问题的思考也不断地深入。在2010年左右的一个技术沙龙上，我第一次把这个思考的内容写成了一页PPT。

在整个数据库性能优化工作中的第一个流程环节，也是最重要的一个环节就是监控采集。这个监控采集必须包含当前状态、近期状态、历史状态、长期运行规律、系统变更情况等内容。当前状态肯定是实时的状态数据，而近期状态是粒度较细的抽样数据或者较为精准的统计数据。长期运行规律可以根据较粗粒度的采样数据中获得。

通过对数据库运行指标与日志信息的采集以及人工监控工作，从中我们需要识别处一些有价值的现象与数据，包括看资源争用的情况、关键资源使用的情况、SQL执行时间、系统状态不好时的争用情况等。当我们已经识别到了足够的信息，足以完成本次优化工作了，那么我们就进入了分析阶段。

在DBA人群里，人们往往都比较恋旧，对于技术体系也是一样。十多年过去了，Oracle 10g开始提供的指标体系在11g里就已经变得相当完善了，而目前最新的一个长期支持版本也已经升级到了几年前推出的19c，不过有时候我和一些Oracle DBA交流的时候，他们还不知道除了awr、v$sysstat和OWI核心视图之外的其他监控视图。

实际上从Oracle 10g开始，Oracle的监控指标体系做了巨大的提升，首先出现了ASH这个按照一秒钟间隔高密度采样的活跃会话状态数据。这些采样数据被首先存放在共享池内，然后被AWR的SNAP刷新到磁盘上，并以和AWR一样的周期进行短期保存。

ASH还算是广为人知的“新”监控数据，另一组监控数据知道的人或者经常在运维分析中使用的就是METRIC。Metric也是Oracle 10g开始引入的监控指标体系。其丰富程度与保存方式甚至可以完全替代v$sysstat。

Oracle 10g提供了相当丰富的Metric指标数据，其中包括METRIC、EVENTMETRIC、FILEMETRIC、SERVICEMETRIC、SESSMETRIC、SYSMETRIC、WAITCLASSMETRIC等，针对很多Metric还提供了HISTORY信息，以便于进行历史回溯。实际上，从Oracle 10g开始，Oracle的监控指标体系的完善基本上都体现在了对Metric的完善上了。

Oracle 11g的Metric监控视图又有了新的扩展，WLM、IOFUNC、RESOURCE MANAGER等也具有了Metric。在12C以后，Oracle还在继续增强Metric的能力。

值得注意的是，针对SYSMETRIC这个系统级的指标，Oracle提供了三张视图，V$SYSMETRIC、V$SYSMETRIC_SUMMARY 和V$SYSMETRIC_HISTORY。V$SYSMETRIC存储的是某些系统指标的短时间（5秒钟）平均值和长时间（1分钟）平均值。而V$SYSMETRIC_SUMMARY里存储的是一个时间段内（比如60分钟）的统计信息。

包含了均值，方差，MAXVAL/MINVAL等信息，这对于诊断分析十分有价值。而v$sysmetric_history里则存储的是一个较长时间的历史数据。这个视图和openGauss的等待事件统计信息很类似，不过就像我上周评价openGauss等待事件统计信息一样，这个一小时的平均值加上和AWR一样保留一定时间历史数据的做法，对于DBA分析问题来说更有价值，设计也更为合理。

实际上，在优化工作中指标采集的粒度和周期间隔都十分关键。对于一些细小非主因问题的分析，其采集粒度越细越容易把问题定位清晰，而对于一些十分明显的问题，那么可能很粗的粒度就可以实现定位了。在不同的分析场景中，数据采集的粒度是完全不同的，更细粒度的数据采集也需要更多的分析成本，不过可以看到一些细节。而过于注重细节也会让我们忽略一些宏观的现象，可能最终抓住了次要矛盾，放掉了主要矛盾。

而粗粒度的采样让我们更容易抓住宏观现象，不过容易让我们忽略一些微观的细节。当我们要分析的问题不是当前系统最宏观的问题的时候，粗粒度采样可能会让我们更难抓住问题的关键。

采样和全量的统计数据对于分析诊断，特别是自动化诊断算法的影响也是很大的。我们来看一个实际例子，因为openGauss支持等待事件的统计数据，因此我们是用统计数据来分析一个时间段（比如20秒钟）内数据库等待事件的总体情况。

可以看出等待数量十分大，能够看到的等待事件数量也很多。

通过这些数据，智能分析算法给出的结论是问题主要集中在并发和IO方面。我们再来看一个在同样压力下的Highgo数据库，这个数据库因为没有等待事件统计数据，因此我们智能采用1秒钟一次的采样来进行分析。

我们可以看到，同样是20秒钟的分析，使用一秒钟一次采样（和ASH的频率相同），我们能够看到的等待事件内容要少了很多（当然openGauss的等待事件种类比Highgo要多一些）。

两次同样时间长度的采样中的等待事件也不完全相同，这是采样经常会遇到的问题，那就是丢失部分细节。

虽然两种方法对并发类的问题的看法是类似的，不过试用采样数据还是丢失了一些细节。

今天写这篇文章主要是给两种人看的，一种是做运维的DBA，不管是Oracle DBA还是开源、国产数据库DBA，通过Metric的统计数据和采样数据去分析数据库状态，定位问题，需要了解每种方法的优缺点，从而选择更适合的数据去做分析。

另外一个目的是我看到很多国产数据库也在加强监控指标采集与接口开放工作。我们的国产数据库在设计这些监控指标接口的时候，能否也兼顾一下这两种分析需求。学习Oracle的经验，给我们提供更有价值，更便捷的分析接口。

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

运维监控中的抽样数据与统计数据

评论