煉數成金 門戶 大數據 運維 查看內容

報警的哲學

2020-11-6 11:22| 發布者: 煉數成金_小數| 查看: 28153| 評論: 0|原作者: 姚鋼強|來自: 高可用架構

摘要: 審核和編寫報警規則時,需要考慮以下的這些原則:報警的(電話,短信)觸達應當是緊急的,重要的,可行動的,真實的。規則應當表示是你的服務處于過程中或者即將發生的問題。為了保持報警項的精確,有效;寧可過度移 ...
《My Philosophy on Alerting》[1]是我認為關于監控和報警較好的論文,我斗膽嘗試翻譯成中文。因為水平有限,翻譯肯定有紕漏。歡迎大家到這里《My Philosophy on Alerting》進行 comment ,一起改進翻譯質量。

譯者注:做任何事兒的時候,都要盡可能嘗試總結一定的方法,從而逐漸形成知識體系。不要讓知識是一個個孤零零的點。

譯文:
審核和編寫報警規則時,需要考慮以下的這些原則
報警的(電話,短信)觸達應當是緊急的,重要的,可行動的,真實的。
規則應當表示是你的服務處于過程中或者即將發生的問題。
為了保持報警項的較精確,有效;寧可過度移除報警噪音。因為過度監控比監控不足更難解決
你應該總是能夠將問題分為以下幾種:基本功能的可用性問題;延遲;正確性(數據的完整性、新鮮性和持久性);以及特定功能問題。
規則描述癥狀是更好的方法,可以更輕松,更全面,更可靠地捕獲更多的問題。
在基于癥狀的頁面或儀表板中包含基于原因的信息,但要避免直接針對原因發出警報。
報警越往上層的服務走,在一個報警規則中可以抓住的明顯問題就越多。但不要走得太遠,你無法充分區分發生了什么。
如果你想在值班時,報警系統保持安靜, 那么需要有一套系統和標準化的流程能夠自動處理那些需要被盡快處理,但不至于讓你半夜三點鐘爬起來上線的事件。

導論
在為各種不同的服務(包括大型和小型,快速發展的產品以及核心基礎架構的多個部分)服務了七年之后,我已經形成了一套監控和報警的理念。它反映了我對監控和報警的基本看法。

每次收到實時報警(傳呼機響起),我都應該能做出緊急反應。但是我每天只能這樣做幾次,否則會感到疲勞。
每個報警項都應該是可行動的,「報警又來了」這種信息不能指導行動。
每個報警項都應該需要人的智慧來處理,而不是機器人、腳本式的自動回應。

當我審核或者編寫新的報警規則時, 下面這些是我經常思考的一些問題:
它是否檢測到了原本未被檢測到的狀況,這些狀況是緊急的、可操作的、正在發生的或即將被用戶看到的。請注意,零冗余情況(本來是多活三個節點,現在只剩一個節點存活了)也算迫在眉睫,如你的服務中“幾乎已滿且越來越滿”的部分(如存儲已被耗盡)。
是否發生過無視這條報警的情況,并且知道他是良性報警?什么時候,為什么,我能改進規則來避免這種情況嗎?
它是否識別出肯定是(將會)傷害用戶的情況?是否有可檢測到的情況不會對用戶造成傷害,應該將其過濾掉?如具有測試流量的服務器集群之類的事情。

我可以針對這個警報采取行動嗎?該行動是緊急的,還是可以等到我醒來后,周末或者下一季度結束后?
是否有其他人需要同時被通知到?他們會不會解決問題?或者說我要替別人解決問題?我們能把這些事情聯系起來嗎?我的新添加的報警能不能等他們嘗試去解決?

下面的這些想法當然是有些理想化的;在一個不斷發展、不斷變化的服務中,沒有一個報警系統是完全干凈的。但也有一些技巧可以讓你更接近這個目標。

為用戶進行監控
我稱之為“基于癥狀的監測”,而不是“基于原因的監測”。你的用戶關心你的 MySQL 是否宕機了嗎?不,他們關心的是他們的查詢是否失敗。(也許你已經感到尷尬不安了,愛上你的MySQL 服務器的 Nagios 規則了?但是你的用戶甚至不知道你的MySQL服務器的存在!) 你的用戶關心非服務路徑的程序是否處于重啟循環中嗎?不,他們關心的是他們的功能是否失效。他們關心你的數據推送是否失敗嗎?不,他們關心的是他們是否拿到的是的結果。

通常情況下用戶只關心很少的一部分事情
基本的可用性和正確性。沒有 "Oops!",沒有 500,沒有掛起的請求、半加載的頁面;丟失的 Javascript,CSS,圖像,視頻。任何以某種方式破壞核心服務的事情都應該被認為是不可用的。
延遲,系統響應要足夠快。

完整性/新鮮度/持久性。你的用戶數據應該是安全的,應該在你要求的時候回來,搜索索引應該是的。即使暫時不可用,用戶也應該完全相信它會回來。

功能。你的用戶關心的是服務的所有功能是否正常工作--你應該監控任何對你的服務很重要的方面,即使它不是核心功能/可用性(例如,計算器和股票行情顯示在搜索結果中)。

差不多就是這樣了。數據庫服務器不可用和用戶數據不可用之間有一個微妙但重要的區別。前者是一個可能的原因,后者是一個癥狀。你不可能總是干凈利落地區分這些事情,特別是當你沒有辦法模擬用戶的視角時候。但如果你能做到模擬,你就應該去做。

基于原因的報警是糟糕的(有時是必要的)
你可能會說,"但是,我知道數據庫服務器無法訪問會導致用戶數據不可用。" 這很好。警惕數據不可用的問題。出現以下癥狀時發出警報:500, the Oops!但是一些白盒指標表示不是所有的服務都是從數據庫獲取數據然后到達客戶端的。基于原因報警是不夠好的,為什么呢?

你無論如何都要抓住癥狀。癥狀也許會因為網絡斷開,或 CPU 征用,或其他無數你還沒有想到的問題而發生。所以你必須抓住癥狀,而不是原因。
如果同時關注癥狀和原因,就會有冗余的報警;這些警報需要單獨調整和管理,并導致癥狀和原因報警的重復或復雜的依賴關系樹。
所謂不可避免的結果并不總是不可避免的:也許你的數據庫服務器不可用了,因為你要開啟一個新的實例或者關閉一個舊的實例。又或者是添加了一個功能來做請求的快速 failover,所以你不需要關心單個服務器的可用性。當然,可以用越來越復雜的規則來捕捉所有這些詳細的原因,但為什么要這么做呢?這樣會導致更多的虛假報警,更多的混亂,更多的調整,而且沒有任何收獲,這回導致你花在修復重要的警報上的時間變少。

但有時它們(基于原因的報警)是必要的。對于 "幾乎 "用完配額的情況,如內存,磁盤即將用滿時沒有(通常)任何癥狀,所以你需要這些報警知道系統即將出現問題。但是盡量少用這些,一定不要為你能捕捉到的癥狀寫基于原因的報警規則。

從出口(或更遠處)發出警報
在 C\S 系統中,較好的報警來自于客戶端。
客戶端可以看到重試的結果,客戶端與服務器之間的網絡延遲,并且可以比服務端更好地知曉面向用戶的延遲和錯誤

在許多情況下,客戶端(例如,混頻器或應用程序服務器)聚合來自許多后端的響應,例如緩存服務,數據庫,帳戶管理/授權服務,查詢分片等。當你在做基礎設施的變更時,如果你使用客戶端指標做監控,這個監控規則會更加健壯,不用頻繁地更改。

許多情況下,客戶端可以比后端呈現出更簡單的整體視圖。例如,如果一個請求打到數百個查詢服務器上,那么從每個查詢服務器的來看的話,視角就太有限了,是無法成為一個有用的警報來源的。

對于很多服務來說,這意味著要對最前端的負載均衡器所看到的延遲、錯誤等情況進行報警。這樣如果 server 宕機了,只有他們真正對于用戶產生影響時你才會看到報警。但是看到的問題比你從 server 看到的更大,覆蓋的角度更廣:如果 server 都宕機了,或者服務出了不計其數的500,或者 10% 的連接斷開了,你的負載均衡器知道,但你的服務器可能不知道。

不過請注意使用特別外層的監控,可能會引入你無法控制和負責的代理。如果你能可靠地捕捉到你的用戶到底看到了什么(例如,通過瀏覽器端工具),那就太好了!但請記住,這樣的信息充滿了噪音(ISP、瀏覽器、客戶端負載和性能);因此,最外層的監控不應該是的方法。如果你的外部監控不能總是與你保持暢通,它可能也是有損的。如果走到這種極端,這仍然是一個有用的信息,但可能并不是你想要的。

原因仍然有用
基于原因的規則仍然是有用的。特別是,它們可以幫助你快速跳到生產系統中的已知缺陷。

如果你在自動將癥狀與原因聯系起來的過程中獲得了很多價值,也許是因為有一些原因是你無法控制的,無法消除的,我提倡這樣做:
當你寫下(或發現)一個代表原因的規則時,檢查相關的癥狀的規則是否也在報警系統中。如果沒有,就將癥狀規則添加進系統。

在報警信息里寫一個簡短的摘要,列出所有基于原因的規則。一個人快速瀏覽一下,就可以確定他們剛剛被報警的癥狀是否有已經確定的原因。這可能看起來像:
TooMany500StatusCodes
Served 10.7% 5xx results in the last 3 minutes!
Also firing:
JanitorProcessNotKeepingUp
UserDatabaseShardDown
FreshnessIndexBehind

在這種情況下,很明顯最有可能的 500 來源是數據庫問題。相反,如果引發的癥狀是磁盤已滿,或者結果頁面返回為空或數據陳舊,就可能是其他兩個原因了。

刪除有噪聲的,持續的,低價值的基于原因的報警規則。

使用這種方法,那些不協調、嘈雜的規則所帶來的精神負擔已經從尋呼機的嗶嗶聲(以及調查、跟進等等)變成了一行要瀏覽的文本。最后,由于您無論如何都需要清晰的調試儀表板(對于不以警報開頭的問題),這是另一個公開基于原因的規則的好地方。

就是說,如果您的調試儀表板使您能夠從癥狀足夠快地轉移到引起原因的地方,那么您根本不需要花時間在基于原因的規則上。

工單、報告和電子郵件
你通常有一些警報需要盡快注意,但不需要馬上關注處理。我稱之為「次關鍵報警」。

工單跟蹤系統會很有用。 只要能將同一警報的多次觸發正確地放入單個故障單/錯誤中,讓報警系統在工單系統建立一個 bug 類型的工單,這樣用戶跟蹤效果就會很好。如果沒有后續負責分類和關閉 bug 工單的責任,此系統將失敗。如果報警系統打開的 bug 工單在數周內不被看到處理,那么這顯然無法作為在次關鍵警報警得嚴重之前處理報警的方式,系統會失敗。如果你的團隊只是超負荷工作或沒有分配足夠的人員來跟進,此系統也會失敗;你需要誠實地知道這需要花費多少時間,否則你會越來越落后。

每日(或更頻繁)的報表也是可行的。 一種可行的方法是編寫長期存在的次關鍵規則(例如,「數據庫容量已超過 90%」或「我們在過去一天處理了 1000 個非常慢的請求」,然后定期發出報表,用來顯示所有當前觸發的規則。但是同樣,如果沒有問責制,這意味著電子郵件警報會更加垃圾郵件,因此請確保指定值班人員(或其他人)每天(或每次交班或其他有效方式)進有效處理。

每個報警都應通過工作流系統進行跟蹤。 不要只將它們轉存到電子郵件列表或 IRC 頻道中。通常,這很快就會變成專門的垃圾郵件列表或渠道,以便可以將其忽略。除了要短暫(通常幾天,最多幾周)來審核新報警規會不會頻繁出發,這么做幾乎總是一個壞主意。這么做也容易忽略這些警報的數量,突然間,數千個應用程序服務器每分鐘都會觸發一些舊的,調整不當的規則,導致打爆了郵箱;這種情況十分槽糕。

根本的一點是要建立一個系統和標準化流程,這仍然需要有響應的問責制,但不會高成本地叫醒某人,打斷他們的晚餐,或阻止其與孩子的擁抱。

操作手冊
操作手冊是報警系統的重要組成部分;對于捕捉到的基于癥狀的每個報警,較好有一個條目可以進一步解釋警報的含義以及如何處理警報。

通常,如果您的操作手冊有很長的詳細流程圖,就有可能花較多時間來記錄可能出現的問題,而花很少的時間來修復它,除非根本原因完全不在您的控制范圍內,或者根本上不需要人工干預(例如 致電供應商)。我所見過的較好的操作手冊都對警報的含義做了一些說明,以及有關警報應該注意的點(我們從 VendorX 的小部件中發現了一系列斷電現象;如果你發現了這一點,請添加它到錯誤12345,我們將在對其進行跟蹤處理)。大多數類似說明應該是短暫,不能長期使用的,因此 Wiki 或類似的產品的是很好的工具。

跟蹤和問責
追蹤所有收到的報警。如果收到了報警,而人們只是說 "我看了,沒有什么問題",這是一個相當強烈的信號,你需要刪除報警規則,或者降級,或者以其他方式收集數據。準確率低于 50% 報警是不能使用的;即使是那些 10% 的假陽性警報,也值得多加考慮是否對齊進行修改。

擁有一個適當的系統(例如,每周對所有頁面進行檢查,每季度進行一次統計)可以幫掌握正在發生的事情,并弄清將報警從一個人轉移到另一個人時出現的問題。

你太天真了!

盡管我認為這些使用報警的原則是極其好的,但是如果遇到了下面這些情況是可以破壞這些原則的

在基于癥狀的報警噪音基礎上,有明確的導致癥狀的原因。例如,如果您的服務有99.99%的可用性,但您有一個導致 0.001% 請求失敗的事件,則不能將其作為一種癥狀進行警報(因為它處于基礎癥狀的報警噪音中),但可以捕獲導致癥狀的原因。也許值得嘗試在堆棧中傳遞這些信息,但也許最簡單的方法就是基于原因上發出報警。

您無法監控出口的數據,因為丟失了數據精度。 例如,也許可以容忍某些 handlers/endpoints/backends/URLs 響應慢(例如信用卡驗證相比與瀏覽待售的商品)或可用性低(例如收件箱的后臺刷新)。在負載均衡上,并不能將此類特殊的接口區別出來。需要從鏈路進行跟蹤,從能發現數據區別的地方發出報警。

癥狀要到很晚才會出現,比如你的配額用完了。當然,你需要今早報警,有時這意味著要找到一個基于原因的報警(比如使用率 > 80%,按照最近1h的增長速度,將在 <4h 內用完)。但如果你能做到這一點,你應該也能找到一個不那么緊急的類似原因(例如配額> 90%,按最近 1d 的增長速度將在< 4d內用完),可以涵蓋大多數情況,并以工單,郵件提醒或每日問題報告的方式處理,而不是報警時已經面臨最緊急的狀況了。

設置的報警規則比他們要檢測的問題更復雜。 有時候報警確實會這樣。我們的目標應該是趨向于簡單,健壯,自我保護的系統(您怎么沒注意到自己用完了配額?為什么這些數據不能轉移到其他地方?)從長遠來看,它們應該趨向于簡單化 。但為了保持報警的較精確,但是不要執著于此,因為這種局部最優對應的是相對復雜的規則。

文中鏈接:
[1]https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/edita

歡迎加入本站公開興趣群
軟件開發技術群
興趣范圍包括:Java,C/C++,Python,PHP,Ruby,shell等各種語言開發經驗交流,各種框架使用,外包項目機會,學習、培訓、跳槽等交流
QQ群:26931708

Hadoop源代碼研究群
興趣范圍包括:Hadoop源代碼解讀,改進,優化,分布式系統場景定制,與Hadoop有關的各種開源項目,總之就是玩轉Hadoop
QQ群:288410967 

鮮花

握手

雷人

路過

雞蛋

相關閱讀

最新評論

熱門頻道

  • 大數據
  • 商業智能
  • 量化投資
  • 科學探索
  • 創業

 

GMT+8, 2020-12-24 05:54 , Processed in 0.183753 second(s), 25 queries .

(*^▽^*)MG黑暗故事游戏规则 出售股票投资收益怎么算 亿客隆彩票 秒速飞艇助赢软件 辽宁快乐12预测一号码 自学做棋牌app 天津麻将hd 湖北双色球中奖分布图 俄罗斯vs沙特比分预测 狗狗币行情走势图 麻将来了猜猜乐任务怎么完成 真钱棋牌 百家乐玩法 1月3日篮彩分析 泰达币usdt 八个人玩扎金花技巧 安徽时时彩十一选五一首页