指标采集也是运维知识的一部分

指标采集也是运维知识的一部分

以前都说去北京就是开盲盒，说不定哪天就弹窗了。现在更有意思了，工作生活也变成开盲盒了，周一从深圳回南京，上了两天班，昨晚被要求居家健康监测，上门核酸了。深圳家里的小区都可以自由出入，到了南京反而不让出门了，早知如此还不如在家里远程办公呢。

今天我们聊聊指标采集，实际上指标采集也是一门学问，里面包含丰富的运维经验。昨天一个D-SMART社区版的用户在客服群里说他的一套Oracle数据库系统突然健康分下降了很多。我们帮助看了一下，在健康分下降时有几个SQL方面的报警，系统负载有点高，同时表空间使用率的采集失败了。表空间采集会失败，可能会让很多同学感到十分不可理解。这么简单的事情，一条SQL搞定的事情，为什么采集会失败呢？

这就涉及到指标采集中的运维经验的问题了，在大多数情况下，一个系统中的表空间使用率采集是秒钟级返回的。不过表空间采集涉及到全库扫描，不同规模的数据库，不同的数据库对象，可能扫描的时间会有不同，因为这条SQL实际上是要对数据库做一个全库扫描的。哪怕同一个数据库，有可能正常情况下1秒钟返回的采集，系统出现某种亚健康状态的时候会变成几分钟甚至几十分钟。当系统IO负载较高，系统性能较差，负载较高时，这个采集的返回延时也会大不相同。我曾经见过多次因为这个采集导致数据库系统出现严重问题的故障。

这是因为当数据库系统存在问题的时候，表空间采集会变得缓慢，如果你的系统设置了每5分钟采集一次表空间使用率，那么很可能上一次采集没有完成，这次又开始了，而且在一个IO存在一定问题的系统中，多个表空间采集任务并发执行，会恶化IO的性能，导致采集越来越慢，采集任务积压的越来越多，最终把系统搞死也是有可能的。我见过一套一体机系统中，因为有条IO链路不稳定，导致IO延时较高，5分钟一次的表空间采集居然积压了数十个并发，最后整个一体机的IO都HANG死了。

基于这种情况，我们的表空间采集是4小时一次的任务调度的，这种频度的采集任务工作不多，哪怕表空间采集慢一点，也不会影响其他数据的采集。大家可能又有疑问了，为什么表空间采集慢会影响其他指标的采集呢？为了防止大量的指标采集导致多次连接数据库，一个任务只会连接一次数据库，然后顺序采集相关的指标，这也是防止指标采集影响数据库运行的一个十分重要的手段。因此4小时任务中不仅仅包含了表空间采集，还包含了一些其他的定时任务。

扯的有点远了，再回头说表空间采集，表空间采集的时候，首先要看是不是上一个任务已经完成了，如果还没完成，那么就不能发起下一个任务。必须上一个任务超时或者被自动清理后才能发起下一个任务。这样就避免了在某些特殊情况下多个表空间采集任务搞死系统的情况出现了。作为一个运维自动化系统，哪怕采集不到数据也不能对系统产生较大的危害，这是数据库指标采集中应该坚持的原则。

另外表空间采集也没必要分钟级，因为表空间的变化也不应该太频繁，几个小时采集一次应该也足够了。在磁盘空间如此不值钱的今天，为我们的数据库多留点空闲空间也不是难事。我们只要通过容量审计，每天日检时对表空间的增长以及TOP SEGMENT做好分析，那些空间使用率异常的对象和表空间就能被发现了。在运维监控中，有些事情，采用迂回的方式效果会更好。

实际上表空间采集的知识还不止如此，如果我们针对RAC数据库系统的每个实例都做指标采集，那么表空间采集该如何做呢？最佳的模式就是只在一个固定的实例（比如负载较小的实例）采集表空间，供所有的数据库实例使用。这样就避免了一个公共数据被多个实例多次采集。说实在的现在多节点RAC越来越多了，这种策略就更为重要了。不过一次采集，多处使用依然不是一个简单的事情，RAC节点可能会故障，也可能某个节点会被关闭检修。而那个负载不重，不太重要的节点往往会有最大的几率被临时关闭，甚至长时间关闭。那么当采集表空间的那个节点关闭后，谁来接替这项工作呢？自动化的选择依然是必须的。

指标采集是一种观察，既然是观察，那就会有准确性问题，不同的采样频率，不同采样方式都会导致指标数据的不同。D-SMART曾经在很多客户那里运行的时候，客户都部署了多套运维自动化系统。在分析一些问题的时候，往往发现多个系统中的同一个指标存在较大的差异。这也是难免的，不过较好的策略可以获得比较好的观察效果。比如采集CPU使用率的时候，我们并不是只采样一个点，而是在一个采样中采样多个点，再取平均值。即使如此，我们依然不建议以CPU使用率指标作为运维告警的依据，而是把CPU使用率与LOAD一起来作为CPU负载的分析依据。

除此之外，开发人员往往对系统的指标理解不够准确，特别是操作系统的指标。这种理解不准确会导致对数据库状态理解的错误。去年我们给一个客户上D-SMART的时候，客户很严肃的说要考考我们系统的能力。说他们的系统存在一个问题，至今还没解决，看看我们的系统能不能找出来。

D-SMART接上后，发现了不少系统存在的性能问题，只不过没有发现用户想考我们的问题。最后客户揭晓谜底了，说这套系统总是会出现莫名其妙的换页，从而导致核心业务出现一些小卡顿，不过目前系统还能承受。当时我们就很纳闷，这套系统有512GB的内存，SGA只分配了100GB，业务最高峰也还有几百GB的空闲内存，哪来的换页呢？最后大家讨论一番才发现，原来他们以前那套运维自动化系统采集的换页数据是错误的，里面包含了文件IO。而那个时不时出现的换页实际上是一个大型的文件IO。而卡顿和那个文件IO的发生频率是相同的。经过分析，发现是因为数据库的BUG导致的CORE DUMP引发的。找到问题，打了补丁，这个问题就解决了。