眾所周知，在生產(chǎn)的程序都需要有監(jiān)控，但估計大部分人都沒有認真考慮過怎么監(jiān)控。

我們也實施了監(jiān)控，但其實我們都沒有認真設計過，自然也沒有什么原則，所以即使有了告警，像是游離在一個只“監(jiān)”不“控”的狀態(tài)：

1. 各種各樣，從各個渠道彈出來的告警信息，很多時候恨不得把告警都直接彈到運維的眼前。
2. 各種五顏六色的指數(shù)、圖表、電視屏，怎么才能一眼就看出問題呢。
3. 告警多了也很煩，同一個問題收到好幾個告警，又或者這個告警其實不需要處理，但又不能完全忽略。
4. 收到告警，也不知道要找誰，下一步要干什么。
5. 一個系統(tǒng)很大，看上去好像全身上下都是監(jiān)控點，要從哪里開始定義監(jiān)控點比較合適呢？

…………

最近看了一本書，《監(jiān)控運維時間：原則與策略》，書很薄，100多頁，沒有什么深入經(jīng)驗和理論，但就專門介紹了「監(jiān)控」這件事，都是直接實戰(zhàn)實操，指導如何更好地監(jiān)控。

「監(jiān)控」是一個管理過程，其管理的對象就是「告警」，管理「告警」產(chǎn)生直到消亡的一生。

在討論「告警」一生之前，我們先看「告警」的意義何在。我們都知道要監(jiān)控，但有沒有想過為什么要監(jiān)控呢？

我們監(jiān)控一個系統(tǒng)的意義在于，證明這個系統(tǒng)在“正常運行”，在理想狀態(tài)下，如果一個系統(tǒng)沒有告警，我們就可以認為他是在正常運作的狀態(tài)；反之，那就是系統(tǒng)哪里出了問題。如果沒有告警，但又收到用戶的保障，那只能說告警缺失，需要補充；也有反面的情況，有告警，但用戶其實又沒有影響，那其實這個告警就需要裁剪。

補充一下，這個“正常運行”是站在用戶的角度上來看的，用戶從這個系統(tǒng)獲得預期結(jié)果，那就是正常。這個講得太抽象，因為無論是系統(tǒng)、還是正常的定義對于每個系統(tǒng)都不一樣，我舉一個例子。

比如，現(xiàn)在要監(jiān)控一個web應用，而web應用有一個http的api，那這個系統(tǒng)怎么為之正常呢。我們可以直接調(diào)用這個api，看是否返回200；但200就是完全正常嗎，不是，我們還要在一定的時間內(nèi)返回200才正常，比如5秒內(nèi)。那這時候需要監(jiān)控的內(nèi)容就是，調(diào)用這個api在5秒內(nèi)返回200，我們就認為這個web應用是正常的。所以，監(jiān)控服務器等其他參數(shù)，就變成次要，因為內(nèi)存高并不表示用戶不能用；而cpu低也不是表示一定用戶可用。所以這個“正常運行”是站在用戶的角度來說；當然，我們可以繼續(xù)對返回的內(nèi)容進行監(jiān)控以進一步完善“正常”的定義。

討論完意義，我們要看一下「告警」的一生，先說產(chǎn)生。

假如現(xiàn)在要重新設計系統(tǒng)的告警，要從哪里開始呢，服務器的cpu內(nèi)存硬盤這些基礎指標嗎？HTTP返回碼嗎？異常日志嗎？我們回到上面說的監(jiān)控的「意義」，是證明這個系統(tǒng)在用戶的角度來說正常運行。

所以一開始要定義監(jiān)控點的話，添加監(jiān)控的最佳地點，首先就是用戶和應用程序交互的點。用戶不會關心應用程序?qū)崿F(xiàn)的細節(jié)，比如運行著多少節(jié)點、或者有多少后臺任務，而會關心應用程序是否可用。因此，首先要從他們的角度看問題。不是說這是監(jiān)控唯一的點，只是說可以從這里開始考慮。

「告警」的點找到了，那「告警」應該長什么樣子。

我們平常遇到的告警其實分為2類，一類是不管時間地點，都需要馬上通知運維人員并行動的，比如服務器宕機了；另一類是通知，問題不會產(chǎn)生立即影響，關注即可，比如某個定時備份服務失敗了。現(xiàn)在關注的是第一類告警，要馬上行動的。

關于立項的的告警要素，有6點：

1. 停止使用電子郵件發(fā)送告警

• 郵件容易被其他信息淹沒
• 建議用即使通信，而且需要有專門的告警群，避免跟其他消息混在一起。

2. 針對每個告警撰寫運行手冊，其實就是SOP，這個告警來了要怎么行動。手冊包含以下幾點

• 這是什么服務，這個服務做什么？這是起碼知道告警影響到哪個系統(tǒng)。
• 誰負責這個服務？相關負責人。
• 這個服務有什么依賴關系？知曉影響范圍。
• 它的基礎設施什么樣？這是系統(tǒng)相關的各種架構(gòu)圖，可以定位告警所在的位置。
• 它會產(chǎn)生什么樣的指標以及日志，這些指標和日志的含義是什么？就是告警的具體含義。
• 應該為它設置哪些告警，為什么要設置這些告警？這個我理解是站在用戶角度闡述影響范圍。

3. 任意的靜態(tài)閾值不是唯一的方法

• 涉及到統(tǒng)計數(shù)學的方法，主要是從諸多采集到的數(shù)據(jù)，使用一些數(shù)學手段，把數(shù)據(jù)可視化，從中看到一些暗藏的趨勢和規(guī)律。
• 比如平均值、中位數(shù)的統(tǒng)計會把波動較大的數(shù)據(jù)平滑化，讓我們更容易看出規(guī)律。

4. 刪除告警和優(yōu)化告警；

• 需要不斷定時檢視告警，以刪減精簡出沒有必要的告警，以避免告警疲勞。

5. 使用維護周期；

• 發(fā)布維護期間，需要添加“維護周期”，否則正常運維期間的告警也是一種冗余告警。

6. 優(yōu)先嘗試自動修復。

• 有的告警緊急SOP可以嘗試使用程序自動修復，減少人工參與的風險，自動修復也可以節(jié)省響應時間。

那定義的告警在生產(chǎn)真的觸發(fā)了，肯定不能置之不理，那要怎么做呢。

這個其實在業(yè)界里面，叫「事件管理」，最出名的就是傳說的ITIL里面的「事件管理框架」，我們先看看ITIL教科書上完整的事件管理流程是如何的。

asset.png

1. 第1步：事件日志記錄。
2. 第2步：事件分類。
3. 第3步：事件優(yōu)先級。
4. 第4步：事件的任務。
5. 第5步：任務創(chuàng)建和管理。
6. 第6步：SLA管理和升級。
7. 第7步：事件解決。
8. 第8步：事件關閉

這個框架很完整，但我們實際可能未必用到這么完整的框架，我們可以簡化必須的要素。告警事件處理建議流程，如下：

1. 事件定義（監(jiān)控識別一個問題）
2. 事件記錄（監(jiān)控自動為該事件打開一個工單）
3. 事件診斷、分類、解決，以及關閉（待命值班人員排查故障，解決問題，通過注釋和其他數(shù)據(jù)解決該工單）
4. 根據(jù)需要，在整個事件中進行溝通
5. 在事件解決后，想出補救計劃以便增強系統(tǒng)彈性

參與事件處理也要分清以下的角色：

1、事件指揮官（IC）

事件指揮官的工作就是做決定。他們既不會參與任何調(diào)查和修復工作，也不會與客戶或內(nèi)部進行溝通，只會監(jiān)督中斷調(diào)查。

2、記錄員

記錄員的工作就是記下發(fā)生的一切。什么人在什么時候說了什么，做出了哪些決定，后續(xù)事項有哪些被確定下來了。同樣，這個角色也不應該參與任何調(diào)查和修復工作。

3、通信聯(lián)絡人

通信聯(lián)絡人的工作就是向干系人（不管是內(nèi)部人員還是外部人員）傳達情況更新。在某種意義上，他們是處理事件的人與想要了解事態(tài)進展的人之間的唯一聯(lián)絡人。這個角色的一個作用是防止干系人（例如經(jīng)理）直接向努力解決問題的人詢問情況更新，進而干擾事件調(diào)查。

4、領域?qū)＜遥⊿ME）

這些人才是真正在處理事件的人。

其實說到這里，監(jiān)控從它的意義開始，講到監(jiān)控對象的「告警」的定義、產(chǎn)生、管理，都有了一個閉環(huán)，基本上我們就可以做到「監(jiān)」和「控」都具備了。

書中后面還細分講了前端、安全、網(wǎng)絡、服務器等各自細分領域的監(jiān)控策略，以及一些推薦的工具，大家有興趣可以翻一下。

里面提到一個StatsD的工具，蠻有趣，后續(xù)有需要可以研究一下。

image.png