监控与诊断一直是数据库运维中的两个十分重要的环节，在传统的运维模式中，监控与诊断都是以人为中心的，因此指标与数据的采集也都要围绕人来展开。
监控数据是需要人来看的，通过人的查看，可以发现监控数据中存在的异常或者值得警惕的地方。不同水平的DBA能从数据中看出不同级别的风险。因为是需要人看，所以展示的指标不能太多，否则监控人员就眼花缭乱了。实际上，上图的关键指标的数量对于监控来说已经太多了。
对于依靠人的监控而言，简要而直观的指标展示是十分必要的。对于数据库来说，只关注三五个关键指标才能更好的实现人工监控。我的一个金融客户，对于核心系统，他们只关注活跃会化数指标，有一个监控人员随时盯住这个指标看，一旦出现异常就点击相关的指标，进行诊断分析。
这是根据他们的需求修改的指标历史数据监控页，一旦活跃会话数指标超标就点击进去诊断。在这个页面中我们提供了一个“问题分析”工具。
问题分析工具可以根据时间窗口分析系统中存在的问题（当前问题或者历史问题），而等待事件分析工具则可以从等待事件的角度来帮助DBA分析系统中可能存在的性能问题。
不管怎么样，监控的目的是让DBA工作的更简单，还是为人服务的，以人为中心的。可能有朋友对此不认可，认为监控也可以自动化，比如基线告警。实际上基线告警也是类似的，比如基线告警可以通过短信告诉你活跃会话数异常了。但是如果基线告警模板设置了太多的指标，那么告警风暴的处理就很麻烦了。不精准的告警会让告警功能如同虚设。
传统的诊断也是以人为中心的，当系统出问题的时候才去系统中查找各种信息，进行分析。这种分析十分依赖于DBA的个人能力。当用户发生大问题的时候，总是希望高水平的专家能尽快到现场来处置。
随着企业数字化的发展，以人为中心的这种监控诊断模式的成本越来越高，专家也不太愿意在一线现场坐镇。因此节约人力成本，节约专家的时间成为了数据库运维中十分重要的需求。实际上随着硬件的发展，数据采集，存储与计算的成本已经十分低廉了。因此在现代的数据库监控系统中，采集并保存更为完整的监控数据已经不是成本太高的事情。
如果日常采集的数据足够丰富，那么自动化诊断和远程诊断就会变成可能。诊断工作所需的数据已经在离线采集的数据库中了，绝大多数诊断工具都不需要再从数据库实例中临时采集数据，那么当数据库出现异常的时候，自动诊断工具可以毫无风险的在后台进行自动分析。
这里说的毫无风险是指自动化诊断工作本身不会给数据库实例带来任何风险。如果在自动化诊断中还需要从数据库临时采集一些数据，那么如果这种采集本身带有风险，那么在一个本身就存在故障的数据库实例上，可能就是一种雪上加霜的举动。我们曾经做过一个共享池碎片自动诊断分析的工具，需要对KGH的数据进行分析，这个工具曾经就搞宕过数据库。因此在指标自动化采集与自动化诊断上，我们会尽可能规避此类风险的出现。
想要实现这一切，其后面最重要的力量是数据，数据时首先监控与诊断自动化的基础。实际上在数据库自动化运维中，指标集与数据采集本身就包含了丰富的运维知识。某种数据库应该采集哪些指标，该如何更好，无风险的采集数据库的指标，是十分有价值的运维知识。
今年，我们将会把D-SMART中Oracle，Mysql、Postgresql、达梦、金仓等数据库的指标集开源出来，也希望大家能够加入到我们这个行列里，共同丰富与完善这个开源指标集。
