筆者做監控 11 年，在可(ke)觀測性(xing)領(ling)域(yu)創業(ye) 4 年，與各(ge)類客戶(hu)溝通較多，發現很(hen)多企(qi)業(ye)想要建設可(ke)觀測性(xing)體系，但是不(bu)得(de)章法，我把整個建設過程做了一個簡單總結，梳理一下(xia)其中的脈絡，希(xi)望對(dui)你有(you)所啟發。

整(zheng)個(ge)可觀測(ce)性體系建設，我總結為五個(ge)步驟(zou)：

• 明業務
• 立規范
• 采數據
• 顯特征
• 獲洞見

下面挨(ai)個說明(ming)(ming)，可觀測性體系(xi)涉(she)及(ji)(ji)到的內容太過駁(bo)雜龐(pang)大，本文(wen)更多(duo)是說明(ming)(ming)思路，不(bu)涉(she)及(ji)(ji)實操。

明業務

首(shou)先(xian)，要把您的業務梳理明白。理清楚您的最終(zhong)業務目標(biao)和(he)指標(biao)，通常稱(cheng)為北(bei)極星指標(biao)，舉例：

• 電商系統：訂單量、訂單金額等
• 游戲：在線人數、交易金額等
• 視頻播放：點擊 Play 的次數等

簡(jian)單而言(yan)，就(jiu)是(shi)把老板層(ceng)面(mian)（全公(gong)司(si)層(ceng)面(mian)）關(guan)注的(de)指(zhi)標理清楚，如果這些指(zhi)標出現異常（比如下跌），可能就(jiu)是(shi)重大業務故(gu)障，SRE、DEV 都要及時介入處理。

北極星指(zhi)標通常是一些結果(guo)(guo)性質的指(zhi)標，如果(guo)(guo)要做的更精細化(hua)，還應(ying)該(gai)拆解出過程指(zhi)標，比如電商系統的訂單(dan)(dan)(dan)量，我們就要分析，哪(na)(na)些關鍵環節(jie)影響訂單(dan)(dan)(dan)量，哪(na)(na)些過程指(zhi)標可以衡量客(ke)戶主流程（下訂單(dan)(dan)(dan)）健康與否，比如：

• 客戶登錄次數、登錄失敗次數
• 瀏覽商品的次數、瀏覽商品的響應速度
• 添加購物車的次數、成功率、延遲
• 結算次數、結算失敗次數、結算延遲
• 等等

理清楚這些(xie)(xie)關鍵的結果指(zhi)標(biao)和過(guo)程指(zhi)標(biao)之后，進(jin)而(er)從技術角度，就要梳(shu)理看(kan)哪(na)些(xie)(xie)系統(tong)(tong)、模塊(kuai)影響(xiang)了這些(xie)(xie)指(zhi)標(biao)，這些(xie)(xie)系統(tong)(tong)就應該定義為 P1 級別(bie)的系統(tong)(tong)，重點(dian)保障。這些(xie)(xie) P1 級別(bie)的系統(tong)(tong)的 SLI、SLO 數據就要重點(dian)管理起來(lai)。

立規范

如(ru)果公(gong)司較小，微服務數量 20 個以(yi)下，機器(qi)只有幾十(shi)臺，規范(fan)與否大家(jia)感(gan)受不(bu)深(shen)。如(ru)果微服務上千、機器(qi)過(guo)萬，那(nei)感(gan)受就(jiu)深(shen)了(le)。如(ru)果規范(fan)做(zuo)得好，就(jiu)可(ke)以(yi)批(pi)量干很多事情，很多知識也(ye)都是復(fu)用的。

從可觀測性(xing)角度(du)，可能需要立規范的一些點：

• 統一使用哪個指標、日志、鏈路追蹤的系統
• 日志打印方式
• 各類觀測數據的標簽
• 微服務自身暴露哪些可觀測性數據，以及如何暴露
• 變更事件如何統一收集呈現
• SLI、SLO 數據統一梳理、呈現、告警
• 告警規則的制定原則、分派規則
• 數據協議規范格式
• 等等

立規范這(zhe)個事情(qing)，做得越(yue)靠(kao)前，后面越(yue)省事，高階(jie)架(jia)構(gou)師(shi)做過很(hen)多橫向的體系(xi)設計，通常會(hui)把(ba)可觀(guan)測(ce)性(xing)這(zhe)攤事做得比較靠(kao)前，因為系(xi)統的可觀(guan)測(ce)性(xing)和系(xi)統的可用(yong)性(xing)、魯棒(bang)性(xing)類(lei)似，都是系(xi)統必須要(yao)關注的特性(xing)之一。

采數據

各類(lei)(lei)觀測數據(ju)（指(zhi)標(biao)、日志、鏈路、事(shi)件、Profiling）的(de)采集，要(yao)按照前面(mian)制定(ding)的(de)規范走，要(yao)考慮成(cheng)本、考慮數據(ju)未來的(de)價值(zhi)。對于各類(lei)(lei)中間件、數據(ju)庫(ku)，因為都是通用產品，采集哪些(xie)(xie)指(zhi)標(biao)、日志，重點關(guan)注哪些(xie)(xie)數據(ju)，在業(ye)內(nei)通常(chang)可以找到(dao)最佳(jia)實踐，而對于公司自研的(de)那些(xie)(xie)微服務，就稍微麻煩一些(xie)(xie)了。需要(yao)：

• 梳理自身業務，確定暴露哪些數據才能方便未來排查問題
• 從上到下推動埋點，否則難以落地

顯特征

這里的特征(zheng)(zheng)，指的是(shi)數據(ju)特征(zheng)(zheng)。海量的零散的觀(guan)測數據(ju)，人類是(shi)沒法一(yi)條一(yi)條查看的，要(yao)想從(cong)數據(ju)中獲取有價值的信息，很難。需要(yao)我們有效組織數據(ju)，從(cong)中發現一(yi)些(xie)特征(zheng)(zheng)規律(lv)。舉一(yi)些(xie)例子：

• 把指標數據放到折線圖里，可以看到趨勢特征，可以看到最大最小值，可以看到哪個時間有突變，就是典型的從數據中提取特征
• 把較大量的日志，通過聚類算法計算日志 pattern，比如 10000 條日志，最終提取出 20 條 pattern，這樣用戶更容易理解分析
• 把告警事件按照標簽做聚合，通常是按照告警規則標題做聚合，或者按照 region、severity、env、service 等做聚合
• 把近期的變更事件和關鍵告警放在一個圖上，可以從時間維度較為容易分析告警和變更的關系
• 把微服務按照層級聚合為子系統，然后聚合為系統，發生故障之后，就可以方便知道哪些系統受到影響，確認影響范圍
• 等等

從具(ju)體(ti)工具(ju)上來看，比如 Grafana、Flashcat 等，都是有力工具(ju)，幫助用戶快速(su)發(fa)現數據(ju)特征。

獲洞見

可觀測性體系要(yao)解(jie)決(jue)的最大的場景需求，就是故障定位，進而(er)執行止(zhi)(zhi)損(sun)(sun)動作。通(tong)過數(shu)據(ju)特(te)征，我們(men)最終要(yao)得到的洞見，就是“止(zhi)(zhi)損(sun)(sun)依據(ju)”！用戶通(tong)常需要(yao)建立各(ge)種(zhong)視(shi)圖，通(tong)過視(shi)圖分析數(shu)據(ju)特(te)征，進而(er)綜合分析，得到“止(zhi)(zhi)損(sun)(sun)依據(ju)”。

比(bi)如用戶(hu)訪問電商 App 延(yan)遲較高，我們可能(neng)要分析：

• 容量水位數據
• 變更數據
• 依賴的服務的健康狀況
• 基礎網絡
• 等等

通(tong)過特征分析，來(lai)確認對(dui)應的(de)方(fang)向是否有問題，綜合多個方(fang)向的(de)分析結(jie)論，最終得到故障(zhang)的(de)原因(yin)，知道原因(yin)了也就知道如何(he)止損了。

總結

本(ben)文提綱(gang)挈(qie)領(ling)(ling)梳理了整(zheng)個可觀(guan)測(ce)性體(ti)系(xi)的建(jian)設的五(wu)步法。只能算是一個梗概，希(xi)望(wang)對(dui)你(ni)有所(suo)幫助(zhu)(zhu)。我們創業這些(xie)年，一直聚焦在監控、可觀(guan)測(ce)性領(ling)(ling)域，深知(zhi)這個領(ling)(ling)域的駁雜，如果你(ni)需(xu)要(yao)乙方協(xie)助(zhu)(zhu)構建(jian)整(zheng)套(tao)體(ti)系(xi)，歡迎。

本文作(zuo)者秦曉(xiao)輝，監控領域(yu)從業 11 年，Open-Falcon、Nightingale 開源項目創(chuang)(chuang)始人(ren)，極客時間專欄《運維監控系統(tong)實戰筆(bi)記》作(zuo)者，現(xian)為 Flashcat 聯合創(chuang)(chuang)始人(ren)，創(chuang)(chuang)業中。