昨天我发了一篇数据库可观测性的文章，谈了可观测性与监控的差别。在运维领域，监控是一个强需求，无论如何，你的数据库在跑一些有价值的业务应用，你就必须去监控数据库。而可观测性并不是时时需要的，如果巡检做完以后，发现的问题也无法得到解决，那么巡检就变成了一个样子货了。
可观测性也是如此，平时的时候，一些小问题还不至于让人兴师动众。不过当系统出现了一个比较大的问题，导致了一些严重后果的时候，IT部门才发现，我们需要对日常发现的一些小问题做闭环管理，要防患于未然。实际上防患于未然这句话好说，却极难落地，因为这背后是巨大的成本。只有做到系统优化常态化的企业才能真正做到闭环管理和防患于未然，对于大多数运维经费有限的企业来说只能嘴上向领导表表态而无法真正去实施了。
D-SMART是一个基于数据库可观测性能力构建的深度运维工具，在研发之初，我们就希望充分利用数据库的可观测性能力，尽可能地将数据库系统数字化。因此每种数据库我们都采集了数百个指标与配置项。当我几年前和一个客户谈到我们的系统采集了数百个数据库的指标与配置项的时候，他直摇头，我们不需要那么多指标，有几个指标够我们监控就行了。太多了，我们也看不过来。实际上，D-SMART采集那么多数据并不是让你看的，运维监控人员确实只能聚焦在少量的几个指标上。D-SMART的指标大多数是用于分析的，并不是用于监控，如果要监控，只需要看“健康模型”或者监控主界面上的那几个关键指标就行了。
D-SMART利用数据库运维专家多年来积累的经验采集了数百个指标，这些指标来自于数据库的系统状态、METRIC、等待事件、日志、TOPSQL、跟踪数据等。为了减少D-SMART采集对于数据库的影响，这些采集都采用开销最小的方法，从系统视图中一次性获取，然后在D-SMART上加工的方式。
数据采集中已经包含了大量的专家经验，比如Oracle数据库的表空间使用率，实际上采集这个数据需要对数据库进行全库扫描，如果系统比较大，IO性能较差，系统比较繁忙的情况下，这个采集对数据库影响还是挺大的。我们以前也遇到过一个客户的数据库超融合一体机的一个故障，就是因为他们的一体机管理软件的表空间使用率采集是分钟级的，而一次采集需要30分钟才能完成，大量采集任务积压导致了一体机IO链路故障，导致了宕机。在D-SMART中，表空间使用率采集是4小时一次或者1天一次的，当上一次没有完成之前，新的采集不会发起，从而避免在一些极端的情况下因为运维监控导致数据库出问题。而在系统的指标体系中，使用了一些“风险”类和“可用天数”的指标来真正地反映出系统存在的风险，这些指标都是通过分析和计算后获得的。
从另外一个例子上可以看到D-SMART在监控指标设计上的专家经验特征。
很多监控软件在采集共享池信息时，喜欢把一些X$视图的数据采集回来做展示。实际上X$视图都是Oracle数据库的内存结构，采集时需要对这些数据加闩锁。如果数据库系统的共享池存在问题的时候，这种采集很可能成为骆驼身上添加的最后一根稻草。前阵子我们的一个商用版用户反馈说他们的共享池性能有点问题，就是用我们的一个共享池分析工具去分析共享池碎片情况，没想到触发了一个BUG，报了ORA-600错误。确实是的，当共享池有问题的时候，如果去访问那些X$视图去查看共享池的情况，是很容易触发一些BUG的，严重时候会出现实例宕机的情况。
为了既能够发现共享池存在的问题，又避免平时不过多干扰共享池，我们使用了上面的一些指标来综合评估共享池可能存在的风险。大家可以看出，这些指标都不需要去对共享池加闩锁。这种设计后面体现的是一帮老司机的经验。
有了强大的指标体系，才能更加充分地利用数据库的可观测性能力。基于如此丰富的指标数据，我们就可以实现各种深度的运维能力了。
比如我们给系统监控者提供的工具包括“健康模型”、“等待事件实时分析工具”，“等待事件历史分析工具”，“问题分析工具”（用于分析一段时间内系统可能存在的各种问题）、“运维经验告警”，“TOP SQL分析工具”、“SQL审计工具”，“关键SQL跟踪分析工具”，“容量分析工具”，“集群拓扑查看工具”、“日检、月检、特检、审计工具”等一系列的运维工具。运维人员不需要盯着指标看，甚至不需要盯着D-SMART看，把短信告警或者微信告警、邮件告警接好，收到告警信息再去看看系统就可以了。
充分利用数据库的可观测性可以干很多事情，专家直接看数据也行，利用数据库提供的工具（WDR/AWR/ASH等报告）也行，采集回来放着，一旦发生问题去回溯分析也可以。实际上D-SMART发布社区版的想法来自于一个合作伙伴的需求。当时我们的一个合作伙伴提出有几十个客户，没多少钱，希望出问题后我们能派专家去现场分析。我们算了一下，如果专家去现场，每年多出几次问题就亏了。于是提出能不能远程分析，不过那些客户里大多数是不允许VPN连上去分析的。于是我们提出来使用d-smart辅助。测试了一两个客户，发现效果还不错，用户出问题的时候，D-SMART生成几份报告，远程分析一下，就基本上解决问题了。不过让这些用户都买一套D-SMART，用户也买不起，那怎么办，经过几次讨论，我们想出了一个发布D-SMART社区版的方法。利用社区版日常采集的数据，到需要提供服务时就可以生成远程分析所需要的报告了。
