監(jiān)控可以涵蓋多種數(shù)據(jù)，包括監(jiān)控項(xiàng)、文本日志、結(jié)構(gòu)化事件日志、分布式跟蹤與事件自?。╡vent introspection）。本章主要介紹監(jiān)控項(xiàng)與結(jié)構(gòu)化日志。

監(jiān)控幫助你獲得系統(tǒng)的可視化，判斷服務(wù)健康和當(dāng)故障發(fā)生時(shí)診斷服務(wù)的問題。

目的：

1. 在指定情況產(chǎn)生預(yù)警

2. 調(diào)查與診斷問題

3. 可視化系統(tǒng)信息

4. 對(duì)于長期的資源使用與服務(wù)健康有預(yù)見性

5. 跨時(shí)間范圍的比較，或者是觀察實(shí)驗(yàn)組與控制組之間的區(qū)別

監(jiān)控策略的指標(biāo)

?

速度

數(shù)據(jù)實(shí)效

事件發(fā)生若與出現(xiàn)監(jiān)控結(jié)果的時(shí)間隔太久，你會(huì)認(rèn)為該事件沒有影響或者推出錯(cuò)誤的因果事件關(guān)聯(lián)。決定了你能多快地對(duì)一事件做出響應(yīng)。

數(shù)據(jù)檢索速度

尤其在查詢大量數(shù)據(jù)，影響圖表加載的時(shí)間，可以對(duì)普遍的查詢進(jìn)行預(yù)計(jì)算，監(jiān)控系統(tǒng)可以基于最新數(shù)據(jù)創(chuàng)建與儲(chǔ)存新的時(shí)間序列。

計(jì)算

?????? 以數(shù)月大小的時(shí)間窗口保存數(shù)據(jù)（分析系統(tǒng)長期的演變趨勢(shì)）

?????? 保存所有詳細(xì)的獨(dú)立監(jiān)控項(xiàng)（方便查看歷史系統(tǒng)行為、但存儲(chǔ)成本高且很難檢索）

?????? 時(shí)間粒度與數(shù)據(jù)聚合（聚合的數(shù)據(jù)無法深入挖掘有效信息）

界面

?????? 圖展示（包括熱點(diǎn)圖、直方圖和對(duì)數(shù)曲線圖）

?????? 創(chuàng)建儀表盤

?????? 實(shí)時(shí)展示某監(jiān)控項(xiàng)不同聚合結(jié)果的圖（機(jī)器類型、服務(wù)器版本、請(qǐng)求類型）（以發(fā)現(xiàn)數(shù)據(jù)的關(guān)聯(lián)與模式）

報(bào)警

?????? 報(bào)警分級(jí)

?????? 報(bào)警抑制（發(fā)生全局錯(cuò)誤時(shí)，僅報(bào)警一次；當(dāng)服務(wù)的依賴項(xiàng)已經(jīng)產(chǎn)生報(bào)警，該服務(wù)無需再報(bào)警）

監(jiān)控?cái)?shù)據(jù)來源

日志（事件）與監(jiān)控項(xiàng)（事件與屬性），其它還有分布式追蹤，運(yùn)行期自省。

?????? 結(jié)構(gòu)化日志相對(duì)于普通文本日志，更適用于豐富的查詢與聚合工具。

?????? 由于日志分析不具實(shí)時(shí)性，因此可以采用批處理系統(tǒng)分析日志，使用點(diǎn)到點(diǎn)查詢，并以儀表盤的形式展示。用Cloud Dataflow分析日志，BigQuery用于點(diǎn)到點(diǎn)的查詢，Data Studio用于儀表盤。

?????? 報(bào)警和儀表盤通常使用監(jiān)控項(xiàng)。基于監(jiān)控項(xiàng)的監(jiān)控系統(tǒng)具有實(shí)時(shí)性，幫助工程師快速發(fā)現(xiàn)問題。但我們常常使用日志發(fā)現(xiàn)某個(gè)問題的根本原因，我們需要的信息往往未作為一個(gè)監(jiān)控項(xiàng)。由于日志往往比監(jiān)控指標(biāo)生成更準(zhǔn)確的數(shù)據(jù)，所以當(dāng)報(bào)告實(shí)時(shí)性不高時(shí)，通常會(huì)利用日志分析系統(tǒng)生成詳細(xì)報(bào)告。

?????? 當(dāng)你需要關(guān)注某一特殊事件的發(fā)生時(shí)，可以使用基于日志的報(bào)警。以下場(chǎng)景更適用于基于監(jiān)控項(xiàng)的報(bào)警：當(dāng)某一特殊事件發(fā)生時(shí)，為其加上計(jì)數(shù)指標(biāo)，并對(duì)該計(jì)數(shù)值進(jìn)行配置。該方法使得所有統(tǒng)一監(jiān)控項(xiàng)的報(bào)警配置位于一處，方便管理。

舉例

移動(dòng)日志信息到監(jiān)控項(xiàng)上

?

問題???? HTTP狀態(tài)碼是用戶調(diào)試錯(cuò)誤的重要信號(hào)，可以從日志中獲取，而不能從監(jiān)控項(xiàng)中獲取。監(jiān)控項(xiàng)儀表盤只能提供全局錯(cuò)誤率，不包含具體的錯(cuò)誤碼或錯(cuò)誤原因等信息。因此，debug的過程包括：

1.? ? ?查看全局錯(cuò)誤趨勢(shì)圖，確定該錯(cuò)誤發(fā)生時(shí)間。

2.? ? ?查詢?nèi)罩疚募e(cuò)誤的行。

3.? ? ?嘗試將日志文件中的錯(cuò)誤與趨勢(shì)圖關(guān)聯(lián)起來。

日志工具對(duì)無法估計(jì)比例，很難確定一個(gè)日志中的某錯(cuò)誤是否頻繁發(fā)生。日志還包含許多無關(guān)行，很難追蹤根因。

提出的方法

?????? AppEngine團(tuán)隊(duì)選擇將HTTP狀態(tài)碼作為監(jiān)控項(xiàng)的一個(gè)標(biāo)簽（例如：requests_total{status=404} ?vs? requests_total{status=500}）。由于不同HTTP狀態(tài)碼的數(shù)量是相對(duì)有限的，沒有將監(jiān)控項(xiàng)數(shù)據(jù)增加到過大的規(guī)模，又能將趨勢(shì)圖的相關(guān)數(shù)據(jù)用于報(bào)警。

結(jié)果

?????? 新標(biāo)簽使得趨勢(shì)圖可以針對(duì)不同的錯(cuò)誤類型展示不同的曲線。用戶可以根據(jù)錯(cuò)誤碼快速推斷可能的問題。可以為客戶端與服務(wù)器的錯(cuò)誤設(shè)置不同的報(bào)警閾值，使得報(bào)警觸發(fā)更準(zhǔn)確。

管理你的監(jiān)控系統(tǒng)

?

把配置看作代碼

?????? 將系統(tǒng)配置看作代碼一般，將其存儲(chǔ)于校正控制系統(tǒng)：更改歷史，任務(wù)追蹤系統(tǒng)的具體更改鏈接，更方便的回滾和強(qiáng)制性的代碼review步驟。

鼓勵(lì)一致性

?????? 一個(gè)集中式的方法需要一致性，但每個(gè)團(tuán)隊(duì)可能想要全權(quán)設(shè)計(jì)各自的配置。

?????? 例如dashboard。可以快速理解其它團(tuán)隊(duì)的儀表盤，能更快解決問題。盡量使基礎(chǔ)監(jiān)控變得簡(jiǎn)單。如果所有服務(wù)需要輸出一組相同的基礎(chǔ)監(jiān)控項(xiàng)，可以自動(dòng)采集所有監(jiān)控項(xiàng)，并提供一組相同的儀表盤。任意新的機(jī)器接入，都能自動(dòng)構(gòu)建基礎(chǔ)監(jiān)控?？鐖F(tuán)隊(duì)人員也能使用該監(jiān)控?cái)?shù)據(jù)。

推薦松耦合

?????? 監(jiān)控系統(tǒng)在發(fā)生各種情況的故障后，需要不斷迭代其服務(wù)。推薦系統(tǒng)呈松耦合。這需要為每個(gè)模塊和監(jiān)控的數(shù)據(jù)流提供穩(wěn)定的接口。不同的模塊分別負(fù)責(zé)采集、存儲(chǔ)、報(bào)警與可視化。穩(wěn)定的接口讓每個(gè)模塊的置換更簡(jiǎn)單。

?????? 十年前，監(jiān)控系統(tǒng)例如Zabbix將所有功能集于一個(gè)模塊?，F(xiàn)代設(shè)計(jì)則常常包含了獨(dú)立的采集模塊、管理器（例如Prometheus server方法），長時(shí)間的存儲(chǔ)（InfluxDB），報(bào)警聚合（Alertmanager）與儀表盤（Grafana）。

目的明確的監(jiān)控項(xiàng)

?????? 第五章會(huì)提到如何實(shí)現(xiàn)監(jiān)控并利用SLI測(cè)量指標(biāo)，在系統(tǒng)錯(cuò)誤預(yù)算構(gòu)成威脅時(shí)觸發(fā)報(bào)警?；赟LO的報(bào)警觸發(fā)后，首先需要檢查的是SLI測(cè)量指標(biāo)。這些指標(biāo)會(huì)在服務(wù)的儀表盤中鮮明地展示出來，多為首頁。但在調(diào)查報(bào)警原因時(shí)，僅從SLO儀表盤無法獲取足夠信息，儀表盤還應(yīng)展示更多數(shù)據(jù)。

預(yù)期變化

?????? 為了定位問題，我們需要從關(guān)注報(bào)警監(jiān)控項(xiàng)轉(zhuǎn)移到引發(fā)報(bào)警的監(jiān)控項(xiàng)。最近該服務(wù)發(fā)生的改變也許正是問題所在。

監(jiān)控代碼的迭代版本。

監(jiān)控命令行的flag，尤其在該flag決定了服務(wù)的可用與不可用時(shí)。

如果該服務(wù)的配置數(shù)據(jù)是動(dòng)態(tài)的，監(jiān)控動(dòng)態(tài)配置的版本。

如果系統(tǒng)沒有進(jìn)行上述的版本管理，則需監(jiān)控上次新建或打包的時(shí)間戳。

如果你嘗試將某次故障與首次上線相關(guān)聯(lián)，在趨勢(shì)圖或儀表盤上與報(bào)警相關(guān)聯(lián)，比起通過查找CI/CD（持續(xù)集成與持續(xù)交付）的日志定位問題要方便多了。

依賴

?????? 如果服務(wù)未發(fā)生變化，其依賴項(xiàng)也許發(fā)生了變化或出現(xiàn)了問題，所以需要監(jiān)控來自直接依賴項(xiàng)的響應(yīng)。

?????? 輸出每個(gè)依賴項(xiàng)請(qǐng)求與響應(yīng)的大小、時(shí)延、響應(yīng)碼很有必要?？梢允褂帽O(jiān)控項(xiàng)的附加標(biāo)簽拆解出響應(yīng)碼、RPC（遠(yuǎn)程過程調(diào)用）方法名、同級(jí)工作名。

飽和度

?????? 為了監(jiān)控與追蹤各項(xiàng)資源的利用率，包括RAM、磁盤、分配到該應(yīng)用的CPU份額。其它資源例如打開文件描述符、線程池中的活躍線程、隊(duì)列中的等待時(shí)間、日志大小等。

?????? 使用不同的編程語言，還需監(jiān)控其它的資源：

?????? Java：根據(jù)所使用的垃圾回收機(jī)制種類，選取堆和元數(shù)據(jù)大小以及更具體的監(jiān)控項(xiàng)

?????? Go：goroutine的數(shù)量（Goroutine是輕量級(jí)的并行程序執(zhí)行路徑，與線程類似）

?????? 語言本身會(huì)為追蹤這些資源提供多種支持。

?????? 除了重要事件的報(bào)警，還需設(shè)置特殊資源可用率不足的報(bào)警：

該資源的使用率有硬性限制

超過某使用率閾值會(huì)引發(fā)性能退化

服務(wù)流的狀態(tài)

對(duì)于HTTP流，監(jiān)控所有的響應(yīng)碼無法充分提供報(bào)警所需的信號(hào)，因?yàn)橛行┛赡苁强蛻舻牟徽_操作觸發(fā)的。

如果對(duì)用戶限制速率與配額，需要監(jiān)控由于缺少配額而被拒絕請(qǐng)求的聚合值。

該數(shù)據(jù)的趨勢(shì)圖可以幫助你發(fā)現(xiàn)某個(gè)事件發(fā)生變化時(shí)，錯(cuò)誤數(shù)量的變化。

設(shè)置有用的監(jiān)控項(xiàng)

?????? 每個(gè)監(jiān)控項(xiàng)都應(yīng)為某個(gè)特定明確的目的服務(wù)。不能因?yàn)樵S多監(jiān)控項(xiàng)容易生成而大量輸出它們。在監(jiān)控項(xiàng)設(shè)計(jì)時(shí)，要思考每個(gè)監(jiān)控項(xiàng)將被如何使用。

?????? 只有在系統(tǒng)進(jìn)入異常狀態(tài)時(shí)，用于報(bào)警的監(jiān)控項(xiàng)指標(biāo)才能發(fā)生變化。當(dāng)系統(tǒng)正常運(yùn)行時(shí)，不要改變它們。而用于解決問題的監(jiān)控項(xiàng)則不具備以上要求。好的debugging metric能夠指出系統(tǒng)的潛在問題。在每次故障發(fā)生后，應(yīng)思考哪些監(jiān)控項(xiàng)可以幫助你更快地定位問題。

測(cè)試報(bào)警邏輯

?????? 理想情況下，監(jiān)控與報(bào)警的代碼從屬于同一測(cè)試標(biāo)準(zhǔn)。在Google，我們使用一種域特定語言生成綜合的時(shí)間序列。然后基于一段時(shí)間序列上的值寫斷言，或者特定報(bào)警的觸發(fā)狀態(tài)和標(biāo)簽值。

?????? 監(jiān)控和報(bào)警通常是多步驟的，因此需要多組單元測(cè)試。這塊區(qū)域仍然屬待開發(fā)狀態(tài)，如果你需要執(zhí)行監(jiān)控測(cè)試，我們建議一種三層方法，如下圖所示。

Figure 4-1 監(jiān)控測(cè)試環(huán)境層級(jí)

Binary reporting：檢查輸出的監(jiān)控項(xiàng)變量值在特定環(huán)境下是否如預(yù)期變化。

監(jiān)控配置：確保該監(jiān)控規(guī)則能產(chǎn)生預(yù)期的結(jié)果，在特定情況下能產(chǎn)生預(yù)期的報(bào)警。

報(bào)警配置：測(cè)試產(chǎn)生的報(bào)警，根據(jù)報(bào)警的標(biāo)簽值，可被路由到一個(gè)預(yù)定義的目標(biāo)。

如果你不能通過綜合的方法測(cè)試監(jiān)控，或者你的監(jiān)控某一階段無法測(cè)試，可以考慮創(chuàng)建一個(gè)運(yùn)行的系統(tǒng)，用于輸出常用的監(jiān)控項(xiàng)，例如請(qǐng)求與錯(cuò)誤的數(shù)量。你可使用該系統(tǒng)驗(yàn)證生成的時(shí)間序列與報(bào)警。你的報(bào)警規(guī)則非常有可能長年累月都未被觸發(fā)，但你需要有自信，當(dāng)該監(jiān)控項(xiàng)超過某個(gè)閾值時(shí)，相應(yīng)的工程師可以及時(shí)地接收到報(bào)警提醒。

總結(jié)

?????? 我們希望通過介紹我們監(jiān)控系統(tǒng)有價(jià)值的點(diǎn)，幫助你考量你的監(jiān)控策略在多大程度上符合你的需求，探索一些你想額外增加的點(diǎn)，并且思考你想要做的改變。你會(huì)發(fā)現(xiàn)在監(jiān)控策略中綜合多個(gè)來源的監(jiān)控項(xiàng)和日志非常有用；精確的結(jié)合分析需要做到高度的上下文相關(guān)。確保采集的每個(gè)監(jiān)控項(xiàng)都為一個(gè)特定目標(biāo)服務(wù)，這個(gè)目標(biāo)可以是更好的容量規(guī)劃，改進(jìn)debug的過程或能直接告訴你問題所在。