04-監控-手冊(Runbook)

前言

好的手冊在當警報觸發時，便於快速定位問題。在更復雜的環境中，團隊中的每一個人都不會對每一個系統都有所瞭解，並且Runbook是傳播這些知識的一個載體，更是好方法。

手冊 == RunBook， 請了解。

一、編寫RunBook的注意事項

爲特定服務編寫了一個好的Runbook，大體須要一下幾點：

• 這項服務是什麼，它的做用是什麼？
• 誰是項目負責？
• 它有什麼依賴關係？
• 它的基礎設施是什麼樣的？
• 它發出什麼指標和日誌，它們是什麼意思？
• 爲它設置了什麼警報，爲何？

對於每一個警報，咱們能夠包含指向該服務的Runbook的連接。當有人響應警報時，他們將打開Runbook並瞭解正在發生的事情，警報的含義以及潛在的補救步驟。

與許多好東西同樣，Runbook很容易被濫用。若是警報的補救步驟與複製粘貼命令同樣簡單，那麼說明已經開始濫用Runbook。對於上面說的狀況應該自動執行該修復或解決基礎問題，而後徹底刪除警報。

Runbook用於解決某些問題時須要人工判斷和診斷的時間。

二、基於Web App的RunBook示例

固然，這是一個示例，你徹底能夠根據你的狀況進行完善與調整。下面咱們來看下Demo。

服務名：Demo App

Demo App 是經過Python框架Flask進行開發，主要做用是Blog信息展現；服務主要依賴組件有Redis（緩存），MySQL（數據存儲）；服務採用Uwsgi+Nginx形式做爲部署架構。

Metadata

代碼庫位於http://10.0.0.1/app/blog。

服務責任人：Evan。

問題升級

若是須要協助來解決此服務的問題，則服務全部者沒法協助，問題升級聯繫備用人員XX。有關聯繫說明，請參閱公司聯繫表。

外部依賴

依賴公共Js庫mount.js來實現國際化時間；

依賴外部CDN進行加速，CDH域名：XXXX，CDH服務商：XXX。

內部依賴性

Nginx服務，運行在10.0.0.7的服務器上；

Redis服務，運行在10.0.0.7的服務器上，DB庫是：3;

MySQL服務，運行在10.0.0.8(Master)，10.0.0.9(Slave)；數據庫名稱：flask_blog；

技術棧

• Flask (1.0.1)
• Nginx (1.13.16)
• Redis(4.3.1)
• MySQL(5.6.40)

監控指標與日誌

指標以下：

• 用戶登陸（計數）
• 用戶註銷（計數）
• 發佈建立（計數）
• 刪除（計數）
• 評論建立（計數）
• 評論刪除（計數）
• 發佈時間（計時器）
• 刪除時間（計時器）
• 用戶註冊時間（計時器）
• 用戶登陸時間（計時器）
• 用戶註銷時間（計時器）

應用日誌內容：

• 用戶使用用戶ID，狀態（成功/失敗）和IP地址登陸
• 使用用戶ID，狀態（成功/失敗）和IP地址發佈建立
• 使用用戶ID，狀態（成功/失敗）和IP地址建立註釋

警報

問題：用戶登陸失敗率

緣由：當用戶登陸失敗率在5m時間內超過5％時，此警報將觸發。可能的緣由是部署不當（檢查最近的部署）或暴力攻擊（檢查用戶登陸日誌是否有攻擊跡象）。

問題：用戶登陸時間過長

緣由：當用戶登陸所需的時間超過一秒時，將觸發此警報。檢查最近的錯誤部署或MySQL性能問題。

問題：發佈時間太長

緣由：當用戶建立帖子所需的時間超過一秒時，將觸發此警報。檢查最近的錯誤部署或MySQL性能問題。

問題：評論創造時間太長

緣由：當用戶建立評論所需的時間超過一秒時，將觸發此警報。校驗對於最近的錯誤部署或MySQL性能問題。

上面就是Demo了，能夠根據你們的需求進行調整。