指標是構築自動化運維與智慧化運維的基石

前段時間我參加一個平臺型系統的故障分析會，開發商對前幾天發生的一個系統故障做了分析，並分析可能是因為在併發流量比較高的時候，一個網路故障觸發了底層平臺的一個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來提供指標，而是根據自己資料庫的特性，以幫助使用者用好資料庫的角度來提供更加準確與有效的指標。

原文標題《指標的意義》