前段时间我参加一个平台型系统的故障分析会，开发商对前几天发生的一个系统故障做了分析，并分析可能是因为在并发流量比较高的时候，一个网络故障触发了底层平台的一个BUG，导致部分POD中的微服务无法正常对外服务。整个分析过程很严密，但是没有任何数据来支撑分析过程。我对此谈了一些自己的看法，希望他们的平台能够提供一些这方面的指标，一方面为了出现类似故障时进行分析，一方面也是可以用于故障预警。他们说近期他们会新增一些指标，如果再发生类似问题，不会像这回那样，花了几个小时才解决问题。用户也对指标的事情十分感兴趣，希望他们和在我会后继续沟通，尽快把需要的指标体系定义出来。

后来他们的技术人员与我讨论，就能够预警与分析前几天那个问题的指标的定义做了沟通，并且围绕那个故障把相关的指标体系做了完善。最后他们问我，我觉得这个平台还需要增加哪些指标，从而能够更好的进行故障预警，因为他们对这些缺少经验。当时我有点蒙圈，这套系统我并不熟悉，仅仅是这次故障分析会才第一次接触。而作为开发单位的核心人员，他们应该是最了解系统特性的，也应该知道哪些地方容易出问题，定义指标体系肯定他们更专业才对。

数据库系统是更为复杂的平台型软件系统，正应为复杂，因此才需要更为完善的指标体系来为DBA与用户提供相关的信息，从而更好的使用与运维数据库。经过几十年的发展，Oracle拥有了十分完整的指标体系，从最初的那个简陋的v$sysstat，到现在的 丰富完整的metric指标体系，Oracle给用户提供了十分精准与完善的指标体系。因此在Oracle数据库上做故障分析与性能优化，拥有大量的工具与手段。

现在的国产数据库都在模仿Oracle，V$SYSSTAT，AWR，ASH，等待事件，都给你整上了。不过面对这些和Oracle十分相似的可观测性能力时，我们总是觉得好像不是那回事。AWR报告中很难看出系统的问题到底在哪，ASH分析问题的时候也总是缺失关键数据。虽然东西好像都有，但是能力却差了一大截，这到底是怎么回事呢?

实际上根子还是出在基础指标上了，就像那个平台型软件一样，很多国产数据库的开发者并不知道他们需要向用户提供哪些指标。他们提供的指标都是模仿Oracle的，而不是真正为了解决与分析某个自己数据库产品的具体问题的。

比如说，一个会话内共享CURSOR而不是全局共享CURSOR的数据库系统里，解析比例指标的含义与一个全局共享CURSOR的解析比例指标的含义是完全不同的。在全局共享CURSOR的数据库系统中，执行数量、解析数量、硬解析/软解析数量这些指标就十分关键，这些指标对于评价CUSOR共享效率十分关键。而仅仅有这些指标是不够的，评价共享池争用情况与共享池效率的指标也十分关键，可以让我们知道CURSOR共享效率下降或者硬解析比例过高是否已经影响了共享池的效率。不完整的指标集虽然也是有用的，但是不够有效。

再举个例子，DB CACHE的命中率这个指标，在有些数据库中可以反映出数据库的部分性能问题，而对于某些数据库而言，50%的命中率与99%的命中率对于数据库的总体性能差异并不大，这种情况下，数据库仅仅提供一个DB CACHE命中率来标志DB CACHE的性能与效率就不够了。我们只能把这个命中率当成一个参考数据，而不能当成分析数据库性能的关键指标。

指标的真实含义只有数据库的开发者才知道，但是数据库厂商并没有让我们知晓这背后的一切。当我们的D-SMART与某个数据库产品做对接的时候，我最需要知道的是他们提供的指标背后代表的含义。我无一例外的和他们索要相关的文档资料，不幸的是，至今我还没有或得到一个数据库厂家给我的比较满意的文档资料。有时候为了解释一个指标的含义，数据库厂商的售后服务人员要和研发人员沟通好几天才能给我答案。不仅仅提供指标，也提供指标如何被使用，这也应该是数据库厂商的重要职责。

指标是构筑自动化运维与智能化运维的基石，应该与数据库的自身功能同等重要，因为数据库的使用与运维是长期的工作。也希望我们的国产数据库厂商能够在指标体系上下下功夫，不仅仅是比照着Oracle来提供指标，而是根据自己数据库的特性，以帮助用户用好数据库的角度来提供更加准确与有效的指标。

原文标题《指标的意义》