是不是經常會遇到，有人在群裡 @你，告訴你你的系統出故障了，你在猶豫是不是真的出故障的同時還得慌亂地去查找？
老闆問你系統現在到底健康與否，能不能快速給個判斷，你卻不敢斷言？
業務方說你的系統有問題，但你認為沒問題，又無法自證？
這一切都源自于你的系統沒有做好監控和告警：
- 沒有監控或者沒有一個好的監控，導緻你無法快速判斷系統是不是健康的；
- 沒有告警或者沒有一個精準的告警，當系統出問題時不能及時通知到你，并且告訴你哪裡出了問題，影響是什麼以及具體怎麼解決。
一、監控告警為什麼重要？
除了在上面提到的幾個常見的場景，監控告警在我們保障系統的穩定性和事故快速恢複的全周期中都是至關重要的。這裡提到了一個事故全周期的概念，它包含發現、定位、解決 3 個階段，其中快速發現和定位是關鍵，而這部分主要依靠的就是監控和告警，解決問題也需要依靠監控和告警提供的具體的資訊。
是以它關乎我們是否能發現或者快速的發現，定位和解決事故。特别是在業務高峰期，早一分鐘解決就能減少很多損失，如果一個事故出現較長時間沒有解決，甚至沒有定位，将會直接影響使用者的實際使用體驗，這對公司形象和業務産生的影響與損失都是不可估量的。監控告警的重要性也就不言而喻了，可以那麼說做好了監控告警能事半功倍。那監控和告警應該怎麼做呢？
二、監控與告警體系該怎麼搭建？
監控的定義就是監測和控制，監測某些事物的變化，以便進行控制。在常見的軟體系統中，大多分為四大觀察類别：
- 業務邏輯：項目所對應的服務及其承擔的業務邏輯，通常需要對其進行度量。例如：單量，庫存量。
- 應用程式：應用程式。例如：統一的基礎架構，接口耗時，接口 QPS。
- 硬體資源：伺服器資源情況等。例如：CPU Load，記憶體使用量。
- 網絡情況：比如網絡丢包情況等。
1、明确監控告警的目标
要想讓監控發揮它本有的價值，那我們必須先明确做監控的目标是什麼。從現實層面出發，做監控的初衷，就是希望能夠及時的發現線上環境的各種各樣奇奇怪怪的問題，為業務的正常運轉保駕護航。是以整體分為下圖四項：
- 預測故障：故障還沒出現，但存在異常。監控系統根據流量模型、資料分析、度量趨勢來推算應用程式的異常趨勢，推算可能出現故障的問題點。
- 發現故障：故障已經出現，客戶還沒回報到一線人員。監控系統根據真實的度量趨勢來計算既有的告警規則，發現已經出現故障的問題點。
- 定位故障：故障已經出現，但未找到具體故障位置，此時是需要協調公司内的多個元件，例如：鍊路追蹤系統、日志平台、監控系統等，來定位故障點。
- 故障恢複：出現故障後，我們根據 SOP 或者其他方式(hotfix 等)來恢複故障。
2、确定具體監控名額
有了目标，下一步我們就是要确定監控什麼，監控哪些名額。這些在業内其實是有優秀的經驗可以借鑒的，給大家介紹兩個概念，希望可以給大家一些啟發。
2.1 基礎監控名額——黃金名額
《Google SRE 運維解密》 總結出了 4 個黃金名額，在業界廣為流傳和借鑒：
1）延遲：服務處理某個請求所需要的時間。
- 區分成功和失敗請求很重要，例如：某個由于資料庫連接配接丢失或者其他後端問題造成的 HTTP 500 錯誤可能延遲很低。是以在計算整體延遲時，如果将 500 回複的延遲也計算在内，可能會産生誤導性的結果。
- “慢” 錯誤要比 “快” 錯誤更糟糕。
2）流量：使用系統中的某個高層次的名額針對系統負載需求所進行的度量。
- 對 Web 伺服器來講，該名額通常是每秒 HTTP 請求數量，同時可能按請求類型分類（靜态請求與動态請求）。
- 針對音頻流媒體系統來說，名額可能是網絡 I/O 速率，或者并發會話數量。
- 針對鍵值對存儲系統來說，名額可能是每秒交易數量，或每秒的讀者操作數量。
3）錯誤：請求失敗的速率。
- 顯式失敗（例如：HTTP 500）；
- 隐式失敗（例如：HTTP 200 回複中包含了錯誤内容）；
- 政策原因導緻的失敗（例如：如果要求回複在 1s 内發出，任何超過 1s 的請求就都是失敗請求）。
4）飽和度：服務容量有多 “滿”，通常是系統中目前最為受限的某種資源的某個具體名額的度量，例如：在記憶體受限的系統中，即為記憶體；在 I/O 受限的系統中，即為 I/O。
- 很多系統在達到 100% 使用率之前性能會嚴重下降，是以可以考慮增加一個使用率目标。
- 延遲增加是飽和度的前導現象，99% 的請求延遲（在某一個小的時間範圍内，例如一分鐘）可以作為一個飽和度早期預警的名額。
- 飽和度需要進行預測，例如 “看起來資料庫會在 4 小時内填滿硬碟”。
如果已經成功度量了這四個黃金名額，且在某個名額出現故障時（或者快要發生故障）能夠發出告警，那麼從服務的監控層面來講，基本也就滿足了初步的監控訴求。也就是可以做到知道了出了問題，是一個從 0 到 1 的起步階段。
2.2 核心監控名額——指南針名額
一般的情況下，黃金名額确實是非常重要且通用的名額，是每個系統都是必須要有的基礎監控。但是對于一個複雜的業務系統來說，黃金名額這些通用的名額是不足以或者不能精确的回報業務系統的核心價值的。每個業務系統的業務架構都不同，當然衡量業務系統的名額也應該是不一樣的。
是以我們 B 站在實際情況中提出了“指南針名額”的概念：
- 指南針名額是系統對業務的核心價值展現，指南針名額同時也展現系統的健康與否
- 指南針名額的波動，一定意味着業務出現波動，業務出現問題，指南針名額一定異常
同時，一旦建立了指南針名額，每天就要關注自己的指南針名額：
- 出現波動需要給出解釋
- 要對指南針名額設定告警
指南針名額不能很多，最好就一個名額，如果實在難以定義成一個名額，也不要超過 3 個，而且盡量精确簡潔明了。對于技術管理者來說，指南針名額非常重要，他可以每天通過檢視自己團隊負責業務的指南針名額，提前預知一些風險和目前團隊服務的健康情況。這也是為什麼我說指南針名額不能太多，否則會讓人抓狂。
以上是我們給出的指南針名額的定義，接下來舉個詳細的例子友善大家了解：
對于彈幕系統來說，彈幕成功率就是指南針名額。這裡需要解釋一下，這是一個業務名額不是一個技術名額。彈幕往往涉及到風控，登陸等業務邏輯，比如在發送彈幕的時候被風控了而導緻沒有成功，在業務上我們不認為是發彈幕失敗了，因為他不是彈幕系統本身的原因，而是跟風控系統的規則相關。同時彈幕發送耗時在這裡我們也不算做是指南針名額，因為在發彈幕場景，往往是異步的，使用者是能接受一定程度的延時的。如果延時有一定增長但是又在某個範圍内，實際上時并不影響最終的結果，是以彈幕發送耗時這個名額不是指南針名額，但并不是說他不重要，他還是可以作為一個系統的核心名額。
2.3 日志監控
其實除了系統名額的監控，現在日志監控也是經常用到的。對錯誤日志進行監控和告警是解決故障的重要因素。日志監控跟具體的業務相關性比較大，這裡給出的建議是：
- 錯誤日志量要有監控
- 核心鍊路上易出問題的地方務必設定日志監控和告警
3、結合監控設定合理的告警
監控往往并不是單獨使用的，會有對應的告警設定，因為大多數情況下，大家都不會一直盯着監控，那樣耗時又費力，是以如何合理的設定告警就成了關鍵。
3.1 一些實用的告警原則
再好的監控體系，閉環做不好，就無法發揮出很大的作用。是以我們給告警設定了一些實用的原則：
- 告警不要太多，否則會導緻“狼來了”。
- 告警出現時，應當要有具體的操作，或者 SOP。
- 不需要人工響應/處理的告警規則，應當直接删除。
- 告警資訊應當有告警級别，影響面，如何處理等。
簡單來講就是告警要少要精确，事件需要解決，處理要人工介入。
3.2 故障等級與告警設定
定義故障的等級，在 B 站我們除了使用損失 pv、收入來定義故障等級，故障的持續時間也是很重要的一個名額，對于一個核心服務，如果：
- 故障時間超過 40 分鐘，屬于 P0 事故；
- 故障時間超過 30 分鐘，屬于 P1 事故；
- 故障時間超過 20 分鐘，屬于 P2 事故；
- 故障時間超過 10 分鐘，屬于 P3 事故。
是以如何讓事故在短時間内解決其實也是在考驗我們告警設定的能力。前面我講過事故全周期的概念，其中發現和定位其實很大程度依賴于告警，特别是發現故障。是以告警怎麼設定，這裡有幾點可以供參考：
- 告警分級别，根據嚴重性，我們可以分為：提示，預警，嚴重，災難
- 告警分原因
- 告警要有解決方案
如果是日志告警，我們還需要加上：
- 輸入和傳回參數
4、明确告警的人員和方式
4.1 漸進式告警到負責人
告警給誰？這是一個需要斟酌的問題，在告警的規範上，要盡可能遵循最小原則，再逐級上報。也就是先告警給 on-call 人，若超出 X 分鐘，再逐級上報到全業務組，再及其負責人，一級級跟蹤，實作漸進式告警。逐級上報的資料來源，可通過員工管理系統來擷取，在員工管理系統中有完整的上下級關系（類似 OA 審批上看到的流程節點） 。
4.2 告警投群
往往還有另外一種情況，就是服務負責人不能立馬看到告警，針對這種情況我們可以提前準備告警群，把告警投入小組的群裡，這樣群裡的其他同學也能看到告警，幫負責人處理告警或者提醒負責人處理告警。
4.3 告警拉群
對于一些核心服務的災難級别告警，我們可以使用告警拉群的方式，因為過往的經驗告訴我們出現事故時不少時間都花在拉人進群上，而且當核心服務出現災難級别告警就意味着核心系統出現了故障，有必要直接拉群進行故障處理工作。
三、監控告警平台的搭建
監控告警應該有自己的一套流程與标準，一般會通過平台搭建的形式來落實與營運。在這裡主要給大家介紹一下業内常用的兩個監控告警平台：Prometheus 和 CAT，此外還會再給大家介紹一個日志監控和告警平台 ELK。
1、Prometheus
Prometheus 是一款基于時序資料庫的開源監控告警系統，基于 golang。Prometheus 的基本原理是通過 HTTP 協定周期性抓取被監控元件的狀态，任意元件隻要提供對應的 HTTP 接口就可以接入監控。
Prometheus 提供了從名額暴露，到名額抓取、存儲和可視化，以及最後的監控告警等一系列元件，整體架構如下：
Prometheus Server：用于收集名額和存儲時間序列資料，并提供一系列的查詢和設定接口。
Grafana：用于展示各類趨勢圖，通過 PromQL 從 Prometheus 服務端查詢并建構圖表。
Alertmanager：用于處理告警事件，從 Prometheus 服務端接收到 alerts 後，會進行去重，分組，然後路由到對應的 Receiver，發出報警。
Promethus 有以下特點：
- 多元度資料模型，一個時間序列由一個度量名額和多個标簽鍵值對确定；
- 靈活的查詢語言，對收集的時序資料進行重組；
- 強大的資料可視化功能，除了内置的浏覽器，也支援跟 Grafana 內建；
- 高效的存儲，記憶體加本地磁盤，可通過功能分片和聯盟來擴充性能；
- 運維簡單，隻依賴本地磁盤，Go 二進制安裝包沒有任何其他庫包依賴；
- 精确告警；
- 非常多的用戶端庫；
- 提供了許多導出器來收集常見系統名額；
- 可以通過中間網關進行時序列資料推送；
- 通過服務發現或者靜态配置來發現目标服務對象。
詳細可見：https://zhuanlan.zhihu.com/p/267966193
2、CAT
CAT 是基于 Java 開發的實時應用監控平台，為美團點評提供了全面的實時監控告警服務。CAT 作為服務端項目基礎元件，提供了 Java, C/C++, Node.js, Python, Go 等多語言用戶端，已經在美團點評的基礎架構中間件架構（MVC 架構，RPC 架構，資料庫架構，緩存架構等，消息隊列，配置系統等）深度內建，為美團點評各業務線提供系統豐富的性能名額、健康狀況、實時告警等。
詳細可見：https://github.com/dianping/cat
3、ELK&ElastAlert
3.1 ELK
ELK 是 ElasticSearch、 LogStash、 Kibana 三個開源工具的簡稱，現在還包括 Beats，其分工如下:
- LogStash/Beats: 負責資料的收集與處理
- ElasticSearch: 一個開源的分布式搜尋引擎，負責資料的存儲、檢索和分析
- Kibana: 提供了可視化的界面。負責資料的可視化操作
基于 ELK 可以建構日志分析平台、資料分析搜尋平台等非常有用的項目。
詳細可見：https://blog.csdn.net/Ahri_J/article/details/79609444
3.2 ElastAlert
但是對于錯誤日志的監控 ELK 架構并沒有提供，是以我們需要使用到第三方工具 ElastAlert，來幫助我們及時發現業務中存在的問題。
ElastAlert 通過定期查詢 Elasticsearch，并将資料傳遞到規則類型，該規則類型确定何時找到比對項。發生比對時，将為該警報提供一個或多個警報，這些警報将根據比對采取行動。
四、B 站的實踐案例
講了那麼多方法論，可能大家還是沒有一個特别清晰的概念，我這邊就拿 B 站的實際應用監控來給大家具體說說，先給大家展示一下。
1、黃金名額類的監控
- 服務常用名額監控：
- 服務接口監控：
- 依賴的服務監控
- 依賴的元件監控
2、指南針名額類監控
- 彈幕指南針名額
- 相關下鑽名額
那監控其實是我們安插在應用身上的眼睛，它做的事情是觀察和收集，要怎麼有效利用這些資料名額，還是得靠人。仍舊以前面的彈幕發送成功率這個名額為例，來說說 B 站的告警是怎麼做的。
一般我們會根據業務需求設定一些告警觸發條件，當成功率低于一定數值就會産生提示/預警，我們采取的是告警投群的方式，這種方式的好處前面也有提，友善協作也不至于遺漏重要告警的處理。
告警拉群的方式 B 站也在積極嘗試中，希望能夠達到當核心服務的災難級别的告警出現，可以直接觸發拉群，将相關服務負責人及其上級、運維相關同學自動拉入群中的一個效果，目前該功能 B 站還在研發中。
五、總結
監控告警的最佳狀态就是實作“一五十”，所謂“一五十”，就是指我們能一分鐘發現事故，五分鐘定位，十分鐘解決。相信這也是衆多企業 SRE 的想要達成的目标，希望今天給大家講的這些内容能夠幫助大家實作精準的監控和告警，把問題扼殺在搖籃裡，減少故障帶來的業務損失。
👉更多精彩内容點選【故障經驗庫】