監控死了嗎？ — 長期即時監控

自2008年以來，我們公司主要從事網路專案的基礎設施管理和全天候技術支援：我們擁有400多家客戶，約佔俄羅斯電子商務的15%。 因此，支援非常多樣化的架構。 如果有東西掉落，我們有義務在 15 分鐘內修復。 但要了解事故已經發生，您需要監控項目並對事件做出回應。 這個怎麼做？

我認為組織適當的監控系統有問題。 如果沒有遇到麻煩，那麼我的演講將包含一個主題：“請安裝 Prometheus + Grafana 和插件 1、2、3。” 不幸的是，現在不再這樣了。 主要問題是每個人仍然相信 2008 年存在的軟體組件方面的東西。

關於監控系統的組織，我敢說…具有足夠監控能力的專案並不存在。 而且情況非常糟糕，如果有東西掉落，就有可能被忽視——畢竟，每個人都確信「一切都受到監控」。
或許一切都被監控著。 但如何呢？

我們都遇到過這樣的故事：某個開發人員、某個管理員正在工作，一個開發團隊找到他們並說：“我們已發布，現在進行監控。” 監控什麼？ 怎麼運作的？

好的。 我們以老式的方式進行監控。 而且它已經在改變了，事實證明你監控了服務 A，它變成了服務 B，服務 B 與服務 C 交互。但是開發團隊告訴你：“安裝軟體，它應該監控一切！”

那麼發生了什麼變化呢？ - 一切都變了！

2008年一切都好

有幾個開發人員，一台伺服器，一台資料庫伺服器。 一切都從這裡開始。 我們有一些信息，我們安裝zabbix、Nagios、cacti。 然後我們對 CPU、磁碟操作和磁碟空間設定明確的警報。 我們還進行了一些手動檢查，以確保網站響應並且訂單到達資料庫。 就是這樣——我們或多或少受到了保護。

如果我們比較管理員當時為提供監控所做的工作量，那麼 98% 是自動的：進行監控的人必須了解如何安裝 Zabbix、如何配置它以及配置警報。 2% - 用於外部檢查：網站是否回應並向資料庫發出請求，新訂單是否已到達。

2010年負荷越來越大

我們開始擴展網絡，添加搜尋引擎。 我們希望確保產品目錄包含所有產品。 產品搜尋有效。 資料庫正在工作，正在下訂單，站點從外部響應並從兩個伺服器響應，並且在重新平衡到另一台伺服器時用戶不會被踢出站點，等等。 還有更多的實體。

此外，與基礎設施相關的實體仍然是管理者頭腦中最大的實體。 我的腦海裡仍然有一個想法，就是進行監控的人是會安裝zabbix並能夠配置它的人。

但同時，還需要進行外部檢查、建立一組搜尋索引器查詢腳本、一組用於檢查索引過程中搜尋是否發生變化的腳本、一組用於檢查貨物是否已轉移到倉庫的腳本。發送貨服務等等等。

註：「一套腳本」我寫了3次。 即負責監控的人不再是單純安裝zabbix的人了。 這是一個開始編碼的人。 但團隊的想法還沒改變。

但世界正在發生變化，變得越來越複雜。 新增了虛擬化層和幾個新系統。 他們開始互相互動。 誰說「聞起來像微服務」？ 但每項服務看起來仍然像一個單獨的網站。 我們可以求助於它並了解它提供了必要的資訊並且可以自行工作。 如果您是一名管理員，不斷參與一個已經開發了5-7-10 年的項目，那麼這種知識就會積累：一個新的級別出現- 您意識到了，另一個級別出現了- 您意識到了.....

但很少人會陪伴一個計畫長達 10 年。

監控員履歷

假設您來到一家新創公司，該公司立即僱用了 20 名開發人員，編寫了 15 個微服務，並且您是一名管理員，被告知：「建立 CI/CD。 請。” 您已經建立了 CI/CD，突然您聽到：「如果不了解應用程式如何在其中運行，我們就很難在「立方體」中進行生產。 讓我們在同一個「立方體」中成為一個沙箱。
您在這個立方體中創建一個沙箱。 他們立即告訴您：“我們想要一個每天從生產中更新的階段數據庫，以便我們了解它可以在數據庫上運行，但同時不會破壞生產數據庫。”

你生活在這一切之中。 距離發布還剩 2 週時間，他們告訴你：「現在讓我們監視這一切......」就是這樣。 監控叢集基礎設施、監控微服務架構、監控與外部服務的工作...

我的同事們把通常的計劃從他們的頭腦中拋開，說：「好吧，這裡一切都清楚了！ 安裝一個程式來監控這一切。” 是的，是的：Prometheus + Grafana + 插件。
他們補充說：“你有兩週時間，確保一切安全。”

在我們看到的許多項目中，都會分配一個人來進行監控。 想像一下，我們想僱一個人做兩週的監控，我們寫一份履歷給他。 鑑於我們到目前為止所說的一切，這個人應該具備哪些技能？

• 他必須了解鋼鐵基礎設施運作的監控和細節。
• 他必須了解監控Kubernetes 的細節（每個人都想進入“立方體”，因為你可以從所有事物中抽象化、隱藏，因為管理員將處理其餘的事情）——它本身、它的基礎設施，並了解如何監控應用程式裡面。
• 他必須了解服務以特殊方式相互通信，並了解服務如何相互互動的細節。 很可能會看到一些服務同步通訊的項目，因為沒有其他方法。 例如，後端透過 REST、gRPC 到達目錄服務，接收產品清單並將其傳回。 你不能在這裡等。 它與其他服務非同步工作。 將訂單轉交給外送服務、發送信件等。
  你可能已經擺脫了這一切？ 需要監控這一點的管理員變得更加困惑。
• 他必須能夠正確地計劃和計劃——隨著工作變得越來越多。
• 因此，他必須根據創建的服務創建策略，以便了解如何具體監控它。 他需要了解專案的架構及其開發+了解開發中使用的技術。

讓我們記住一個絕對正常的情況：有些服務是 PHP 的，有些服務是 Go 的，有些服務是 JS 的。 他們以某種方式互相合作。 這就是「微服務」一詞的由來：有太多單獨的系統，開發人員無法理解整個專案。 團隊中的一部分人用 JS 編寫服務，這些服務獨立工作，不知道系統的其餘部分如何運作。 另一部分則用Python編寫服務，不干擾其他服務的工作方式；它們在自己的區域中隔離。 第三個是用 PHP 或其他東西寫服務。
這 20 個人全部分為 15 個服務，只有一位管理員必須了解這一切。 停止！ 我們只是將系統拆分為 15 個微服務，因為 20 個人無法理解整個系統。

但它需要以某種方式進行監控......

結果如何？ 結果，有一個人想出了整個開發團隊無法理解的一切，同時他也必須知道並且能夠做我們上面指出的事情——硬體基礎設施、Kubernetes 基礎設施等。

我能說什麼...休士頓，我們有問題。

監控現代軟體專案本身就是軟體項目

從「監控是軟體」的錯誤信念，我們開始相信奇蹟。 但遺憾的是，奇蹟並沒有發生。 你不能安裝 zabbix 並期望一切正常。 安裝 Grafana 並希望一切都會好起來是沒有意義的。 大部分時間將花在組織檢查服務的運作及其相互之間的交互，檢查外部系統如何運作。 事實上，90%的時間不會花在寫腳本上，而是花在開發軟體上。 它應該由了解專案工作的團隊來處理。
如果在這種情況下將一個人投入監控之中，那麼災難就會發生。 這是到處都會發生的事情。

例如，有多個服務透過 Kafka 相互通訊。 訂單到達，我們向 Kafka 發送了一條有關訂單的訊息。 有一項服務可以偵聽有關訂單的資訊並運送貨物。 有一項服務可以偵聽有關訂單的資訊並向用戶發送一封信。 然後出現更多服務，我們開始感到困惑。

如果您還在發布前不久的階段將其提供給管理員和開發人員，那麼他們將需要了解整個協議。 那些。 這種規模的專案需要花費大量時間，這應該被納入系統開發中。
但很多時候，尤其是在新創公司中，我們會看到監控是如何推遲到以後的。 「現在我們將進行概念驗證，我們將推出它，讓它落下——我們準備好做出犧牲。 然後我們將監控這一切。” 當（或如果）專案開始賺錢時，企業希望添加更多功能 - 因為它已經開始工作，所以需要進一步推出！ 現在，您首先需要監控之前的所有內容，這需要的時間不是 1%，而是更多。 順便說一句，開發人員需要監控，並且讓他們更容易開發新功能。 結果，新功能被寫出來，一切都搞砸了，你陷入了無盡的僵局。

那麼如何從頭開始監控一個項目，如果你拿到一個需要監控的項目，但你不知道從哪裡開始呢？

首先，你需要製定計劃。

抒情題外話：他們通常從基礎設施監控開始。 例如，我們有 Kubernetes。 讓我們先使用 Grafana 安裝 Prometheus，安裝用於監控「立方體」的插件。 不僅開發人員，而且管理員也有這樣的不幸做法：“我們將安裝這個插件，但插件可能知道如何做到這一點。” 人們喜歡從簡單直接的事情開始，而不是從重要的行動開始。 而且基礎設施監控很容易。

首先，決定要監控的內容和方式，然後選擇工具，因為其他人無法為您思考。 他們應該嗎？ 其他人自己想到了一個通用系統 - 或者在編寫這個插件時根本沒有想到。 僅僅因為這個插件有 5 個用戶並不意味著它有任何用處。 也許你會成為第 5001 名，因為之前已經有 5000 人了。

如果您開始監控基礎架構並且應用程式的後端停止回應，則所有使用者都將失去與行動應用程式的連線。 將會出現錯誤。 他們會來找你並說“應用程式無法運行，你在這裡做什麼？” - “我們正在監視。” —“如果您沒有發現應用程式無法運行，您如何進行監控？！”

1. 我認為您需要準確地從用戶的入口點開始監控。 如果用戶看不到應用程式正在運行，那就是失敗。 監控系統應該先對此發出警告。
2. 只有這樣我們才能監控基礎架構。 或並行進行。 有了基礎設施就更容易了——在這裡我們終於可以安裝 zabbix 了。
3. 現在，您需要深入應用程式的根源，以了解哪裡出現問題。

我的主要想法是監控應該與開發過程並行。 如果您將監控團隊的注意力分散到其他任務（創建CI/CD、沙箱、基礎設施重組），那麼監控將開始滯後，您可能永遠無法跟上開發的步伐（或者遲早您將不得不停止它）。

一切按等級劃分

這就是我對監控系統組織的看法。

1）應用程式等級：

• 監控應用程式業務邏輯；
• 監控服務的健康指標；
• 整合監控。

2）基礎設施層面：

• 編排級監控；
• 系統軟體監控；
• 鐵含量監測。

3）再次是應用層面－但作為工程產品：

• 收集和監控應用程式日誌；
• APM；
• 追踪。

4）警報：

• 組織警報系統；
• 組織值班制度；
• 組織事件處理的「知識庫」和工作流程。

這一點很重要：我們不是在之後而是立即收到警報！ 無需啟動監控並「稍後」確定誰將收到警報。 畢竟，監控的任務是什麼：了解系統中哪裡出現問題，並讓合適的人員知道這一點。 如果你把這個留到最後，那麼正確的人只會透過說「沒有什麼對我們有用」來知道出了什麼問題。

應用層-業務邏輯監控

在這裡，我們討論的是檢查應用程式是否為用戶工作。

這個級別應該在開發階段完成。 例如，我們有一個有條件的 Prometheus：它會轉到伺服器進行檢查，拉取端點，然後端點會檢查 API。

當經常被要求監視主頁以確保網站正常運作時，程式設計師會提供一個句柄，每次需要確保 API 正常運作時都可以拉取該句柄。 而此時的程式設計師仍然採取並編寫 /api/test/helloworld
確保一切正常的唯一方法是什麼？ - 不！

• 創建此類檢查本質上是開發人員的任務。 單元測試應該由編寫程式碼的程式設計師編寫。 因為如果你將其洩露給管理員，“夥計，這是所有 25 個功能的 API 協議列表，請監控一切！” - 一切都不會成功。
• 如果你列印“hello world”，沒有人會知道 API 應該並且確實可以工作。 每個 API 變更都必須導致檢查的變更。
• 如果您已經遇到這樣的問題，請停止這些功能並指派將編寫這些檢查的開發人員，或者接受損失，接受沒有任何檢查並且會失敗的事實。

技術提示：

• 一定要組織一個外部伺服器來組織檢查——你必須確保你的專案可以被外界存取。
• 組織檢查整個 API 協議，而不僅僅是單一端點。
• 使用測試結果建立一個 prometheus 端點。

應用層-健康指標監控

現在我們討論的是服務的外部健康指標。

我們決定使用外部檢查來監視應用程式的所有“句柄”，我們從外部監視系統呼叫外部檢查。 但這些是用戶「看到」的「句柄」。 我們希望確保我們的服務本身有效。 這裡有一個更好的故事：K8s 具有健康檢查功能，因此至少「立方體」本身可以確信該服務正在運行。 但我見過的一半支票都是一樣的「hello world」字樣。 那些。 所以他部署後拉一次，他回答說一切都很好——僅此而已。 而且，如果服務提供自己的 API，那麼該服務就會有大量同一個 API 的入口點，這也需要監控，因為我們想知道它是否有效。 我們已經在裡面監視它了。

如何從技術上正確實現這一點：每個服務都會公開一個有關其當前性能的端點，並且在 Grafana（或任何其他應用程式）的圖表中我們可以看到所有服務的狀態。

• 每個 API 變更都必須導致檢查的變更。
• 立即使用健康指標建立新服務。
• 管理員可以找到開發人員並要求“添加一些功能，以便我了解所有內容，並將有關此資訊的資訊添加到我的監控系統中。” 但開發人員通常會回答：“我們不會在發布前兩週添加任何內容。”
  讓開發經理知道會有這樣的損失，也讓開發經理的管理階層知道。 因為當一切都崩潰的時候，還是會有人打電話要求監控「不斷下降的服務」(c)
• 順便說一句，分配開發人員為 Grafana 編寫插件 - 這對管理員來說將是一個很好的幫助。

應用層-整合監控

整合監控著重於監控關鍵業務系統之間的通訊。

例如，有 15 個服務相互通訊。 這些不再是單獨的站點。 那些。 我們無法單獨拉取該服務、獲取 /helloworld 並了解該服務正在運行。 因為訂購 Web 服務必須將有關訂單的資訊從總線發送到總線，所以倉庫服務必須接收此訊息並進一步處理它。 電子郵件分發服務必須以某種方式進一步處理這個問題，等等。

因此，我們無法透過查看每個單獨的服務來理解它是否全部有效。 因為我們有某種總線，所有事物都透過它進行溝通和互動。
因此，這個階段應該標誌著測試服務與其他服務互動的階段。 不可能透過監控訊息代理來組織通訊監控。 如果有一個服務發出數據，又有一個服務接收數據，那麼在監視代理時，我們只會看到從一邊飛到另一邊的數據。 即使我們以某種方式設法在內部監控這些數據的交互 - 某個生產者發布數據，有人讀取它，這個流繼續進入 Kafka - 如果一個服務以一個版本發送消息，這仍然不會給我們信息，但其他服務沒有想到這個版本並跳過了它。 我們不會知道這一點，因為服務會告訴我們一切正常。

我建議做什麼：

• 對於同步通訊：端點向相關服務發出請求。 那些。 我們採用這個端點，在服務內拉取一個腳本，該腳本會到達所有點並說“我可以拉到那裡，拉到那裡，我可以拉到那裡......”
• 對於非同步通訊：傳入訊息 - 端點檢查總線上的測試訊息並顯示處理狀態。
• 對於非同步通訊：傳出訊息 - 端點將測試訊息傳送到總線。

正如通常發生的那樣：我們有一個將資料發送到總線的服務。 我們來到這項服務並請您告訴我們其集成狀況。 如果服務需要在更遠的地方（WebApp）產生訊息，那麼它將產生此測試訊息。 如果我們在 OrderProcessing 端運行一個服務，它首先發布它可以獨立發布的內容，如果有一些依賴的內容，那麼它會從總線讀取一組測試訊息，了解它可以處理它們，報告它並，如果有必要，進一步發布它們，對此他說- 一切都很好，我還活著。

我們經常聽到這樣的問題：“我們如何在戰鬥數據上測試這一點？” 例如，我們正在談論相同的訂購服務。 訂單向貨物被註銷的倉庫發送訊息：我們無法在戰鬥數據上測試這一點，因為“我的貨物將被註銷！” 解決方案：從一開始就規劃整個測試。 您也可以進行模擬的單元測試。 因此，請在更深層次上進行，確保有一個不會損害業務運營的溝通管道。

基礎建設層面

基礎設施監控長期以來被認為是監控本身。

• 基礎設施監控可以而且應該作為一個單獨的流程啟動。
• 即使您確實想要，也不應該從對正在運行的專案進行基礎設施監控開始。 這對所有 DevOps 來說都是一個痛苦。 「首先我將監控集群，我將監控基礎設施」——即首先，它將監視下面的內容，但不會進入應用程式。 因為應用對於DevOps來說是一件難以理解的事情。 它被洩露給他，他不明白它是如何運作的。 但他了解基礎設施並從它開始。 但不行 - 您始終需要先監視應用程式。
• 警報的數量不要過多。 考慮到現代系統的複雜性，警報不斷出現，您必須以某種方式忍受這堆警報。 值班人員在查看了接下來的一百個警報後，將決定「我不想考慮它」。 警報應該只通知重要的事情。

作為業務單元的應用程式級別

關鍵點：

• 麋鹿。 這是業界標準。 如果您因為某些原因沒有聚合日誌，請立即開始聚合。
• APM。 外部 APM 作為快速關閉應用程式監控的一種方式（NewRelic、BlackFire、Datadog）。 你可以暫時安裝這個東西，至少以某種方式了解你發生了什麼事。
• 追踪。 在數十個微服務中，您必須追蹤所有內容，因為請求不再獨立存在。 以後添加非常困難，因此最好立即安排開發中的追蹤 - 這是開發人員的工作和效用。 如果您還沒有實施，那就實施吧！ 參見 Jaeger/Zipkin

警報

• 通知系統的組織：在監控一堆事物的情況下，應該有一個統一的通知系統。 你可以在 Grafana 中。 在西方，每個人都使用 PagerDuty。 警報應該清晰（例如它們來自哪裡...）。 建議完全控制通知的接收
• 值班制度的組織：警報不應發送給所有人（要么每個人都在人群中做出反應，要么沒有人做出反應）。 開發人員還需要oncall：一定要明確職責範圍，明確指示，寫明周一週三具體給誰打電話，週二週五給誰打電話（不然即使在工作日也不會打電話給任何人）如果出現大問題- 他們會害怕叫醒您或打擾：人們通常不喜歡打電話或叫醒其他人，尤其是在晚上）。 並解釋尋求幫助並不意味著無能（「我尋求幫助，這意味著我是一個糟糕的員工」），鼓勵尋求幫助。
• 組織事件處理的「知識庫」和工作流程：對於每個嚴重事件，應規劃事後分析，並作為臨時措施，記錄解決事件的行動。 並養成一種習慣，即重複發出警報是一種罪； 它們需要在程式碼或基礎設施工作中修復。

技術棧

假設我們的堆疊如下：

• 數據採集——Prometheus + Grafana；
• 日誌分析——ELK；
• 用於 APM 或追蹤 - Jaeger (Zipkin)。

選項的選擇並不重要。 因為如果您一開始就了解如何監控系統並寫下計劃，那麼您就可以開始選擇適合您要求的工具。 問題是您首先選擇監視什麼。 因為也許你一開始選擇的工具根本不符合你的要求。

最近隨處可見的幾個技術點：

Prometheus 被推入 Kubernetes -誰想出了這個？ ！ 如果您的叢集崩潰了，您會做什麼？ 如果內部有一個複雜的集群，那麼集群內部應該有某種監控系統，外部也應該有一些監控系統，它們將從集群內部收集資料。

在集群內部，我們收集日誌和其他所有內容。 但監控系統必須在外面。 通常，在內部安裝了 Promtheus 的叢集中，還有對站點運作進行外部檢查的系統。 如果您與外界的連線中斷並且應用程式無法運作怎麼辦？ 事實證明，內部一切都很好，但這並沒有讓使用者的事情變得更容易。

發現

• 監控開發不是實用程式的安裝，而是軟體產品的開發。 如今 98% 的監控都是編碼。 在服務中編碼，對外部檢查進行編碼，檢查外部服務，僅此而已。
• 不要將開發人員的時間浪費在監控上：這可能會佔用他們 30% 的工作量，但這是值得的。
• DevOps，不要擔心你無法監控某些東西，因為有些東西是完全不同的思考方式。 你不是程式設計師，監控工作正是他們的工作。
• 如果專案已經在運作且不受監控（並且您是經理），請指派資源進行監控。
• 如果產品已經投入生產，並且您是開發人員，被告知「設定監控」 - 嘗試向管理層解釋我寫的所有內容。

這是 Saint Highload++ 會議報告的擴展版本。

如果您對我對此以及相關主題的想法和想法感興趣，那麼在這裡您可以 閱讀頻道 🙂

來源： www.habr.com