大家好，我是君哥。

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

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

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.總結

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