架構師面試：怎麼規劃公司的監控架構？

大家好，我是君哥。

監控系統在科技公司非常重要，它可以讓維運人員和研發人員提前發現問題、定位問題，進而解決問題。

在我們實際工作中，使用的監控往往五花八門，比較混亂，今天就來聊聊怎麼規劃公司的監控架構。

1.指標採集

監控指標採集為監控提供原始數據，是監控系統的基礎。

1.1 系統指標

當我們使用Prometheus 做監控時，我們可以使用Node Exporter 收集系統指標進行監控，例如記憶體、CPU、磁碟、檔案描述符等資訊。

1.2 資料庫/中介軟體

資料庫和中介軟體故障對業務影響會非常大，極端情況下可能會讓業務停擺。因此必須有配套的資料庫中間件監控。

對於資料庫和中間件，採集資料庫所在機器的系統資訊如記憶體、CPU、磁碟是必須的。

對於資料庫，也需要採集SQL 執行時長、資料庫日誌等作為監控指標。

對於中間件，可以擷取吞吐量、平均反應時長，以及中間件本身的一些指標。例如kafka 的ISRShrink/ISRExpand。

JVM 相關指標，例如堆疊記憶體、FULL GC 頻率和時長、執行緒使用情況。

1.3 業務指標

業務系統的監控指標因為業務的複雜性，會非常複雜和龐大。

介面請求數量、平均回應時間、成功率。這部分指標可以使用網路抓包來取得。

業務整體運作情況，這部分指標有兩種方式，一個是透過採集業務日誌來獲取，第二個業務代碼主動推送執行，例如把運行情況抽象化成指標保存資料庫，或透過訊息佇列傳送給擷取系統。

2.指標保存

收集到監控指標後，要想把這些指標展示給維運人員，就需要先把指標保存下來。 Prometheus 將監控資料保存在TSDB，有些公司選擇引入外部時序資料庫，例如VictoriaMetrics 這款時序資料庫就被許多公司採納。

有些指標採集的量比較小，也可以採用關聯式資料庫做存儲，對研發維運人員來說學習成本比較低。

小公司一般使用開源的工具就可以滿足指標保存的需求。在大公司，業務類型廣泛，指標資料量較大，需要規劃指標保存方案，引進多種保存方式。

3.指標加工

對於僅監控一些特定指標的情況下，只要收集到數據，正常展示出來，就可以達成監控目標。但這只能用於較簡單的監控指標，例如一個介面的請求次數。

從宏觀角度看，業務側更關注的是總體數據，例如昨天交易成功的業務數量，失敗的業務數量。他們只會花時間看監控大盤。這個時候就需要進行一些資料加工、總結。

因此，指標加工也是非常重要的。這個工作也可以交給公司的大數據團隊來承接。

4.指標展示

完成指標採集和加工後，如何清晰優雅地展示給用戶，是監控設計中的重要環節。

知名的監控工具例如Prometheus、Zabbix 都有成熟的視覺化介面，可以清楚地展示給使用者。但要滿足更複雜、更高要求的監控場景，這些工具很難滿足需求。

這時候就需要技術團隊自己開發指標視覺化工具，這裡不僅包括監控大盤，還包括給不同人員看的監控頁面，例如給業務看的，給運維看的，給研發看的。

5.監控告警

有了指標收集、加工和展示，其實只完成了監控系統的準備工作，監控警報是我們規劃監控系統的重要目標。

監控警報的目標是讓相關人員提前感知問題，及時採取措施，防止問題擴大。

為了節省系統資源，監控警報也是需要分等級的，根據問題嚴重程度、業務影響範圍來規劃警告等級。這就要求業務系統在需求階段就要明確業務的重要性，輔助確定監控等級。

例如涉及金錢的交易系統、支付系統、帳務系統，對於公司來說非常重要，可以把他們定義成嚴重級別，監控到問題後，透過簡訊、OA 訊息通知值班維運人員，這樣值班維人員可以根據問題狀況及時通知相關研發人員，即使問題發生在半夜也能很快採取措施。

對於影響較小的業務系統、批量交易，可以定義成主要級別，發生問題後，短信或OA 即時通知到系統負責人就可以。

對於沒有業務影響的交易，可以定義成次要級別，問題發生後，只需要郵件通知到開發人員，而且不用實時通知，每天集中一次或幾次就可以。

6.應急方案

應急方案需要事先進行設計、演練，這樣可以防患於未然。假如一個嚴重等級的告警半夜2 點觸發了，研發人員睡夢中被叫醒，如果沒有應急方案，勢必會非常慌亂。

應急方案可以根據系統的實際情況進行設計，例如重啟服務、介面限流、熔斷、群集擴容、故障節點摘除等。

7.總結

監控系統對科技公司來說，非常重要。我們可以從指標收集、指標保存、指標加工、指標展示、監控警告、應急方案這些方面來進行設計。希望這篇文章對你設計監控架構有幫助。