我們在組建產品團隊的階段就考慮建立一個監控系統。 很明顯，我們的業務——剝削——不屬於這些團隊。 這是為什麼？
事實上，我們所有的團隊都是圍繞著單一資訊系統、微服務和前端建構的，因此團隊看不到整個系統的整體健康狀況。 例如，他們可能不知道深層後端中的某些小部分如何影響前端。 他們的興趣範圍僅限於與其係統整合的系統。 如果一個團隊及其服務A與服務B幾乎沒有聯繫，那麼這樣的服務對團隊來說幾乎是看不見的。
反過來，我們的團隊與彼此整合非常緊密的系統合作：它們之間有很多連接，這是一個非常龐大的基礎設施。 線上商店的運作取決於所有這些系統（順便說一句，我們擁有大量系統）。
原來我們部門不屬於任何一個團隊，只是位置稍微靠邊一點。 在整個故事中，我們的任務是全面了解資訊系統如何運作、其功能、整合、軟體、網路、硬體以及所有這些如何相互連接。
我們的線上商店所經營的平台如下所示：
- 前
- 中台
- 內勤
無論我們多麼希望，所有系統都不會順利、完美地運作。 同樣，重點是系統和整合的數量——對於像我們這樣的系統，儘管測試品質很高，但一些事件是不可避免的。 此外，無論是在單獨的系統內還是在整合方面。 您需要全面監控整個平台的狀態，而不僅僅是平台的任何單一部分。
理想情況下，整個平台的健康監控應該是自動化的。 我們將監控作為這個過程中不可避免的一部分。 最初，它只是為第一線人員建構的，而網路專家、軟硬體管理員已經並且仍然擁有自己的層層監控系統。 這些人都只是在自己的層面上進行監控，沒有人有全面的了解。
例如，如果虛擬機器崩潰，大多數情況下只有負責硬體和虛擬機器的管理員知道。 在這種情況下，一線團隊看到了應用程式崩潰的事實，但沒有有關虛擬機器崩潰的資料。 而管理員可以知道客戶是誰，並大致了解目前在該虛擬機器上運行的內容，前提是它是某種大型專案。 他很可能不知道小孩子們的事。 無論如何，管理員需要去找所有者詢問這台機器上有什麼，需要恢復什麼以及需要更改什麼。 如果出現了非常嚴重的問題，他們就會開始原地踏步——因為沒有人看到整個系統。
最終，這些不同的故事會影響整個前端、使用者和我們的核心業務功能—線上銷售。 由於我們不是團隊的一員，而是作為線上商店的一部分從事所有電子商務應用程式的運營，因此我們承擔了為電子商務平台創建全面監控系統的任務。
系統結構及堆疊
我們首先為我們的系統確定幾個監控層，在這些監控層中我們需要收集指標。 所有這些都需要結合起來，這就是我們在第一階段所做的。 現在，在這個階段，我們正在最終確定所有層中最高品質的指標集合，以便建立相關性並了解系統如何相互影響。
在應用程式啟動的初始階段缺乏全面的監控（因為我們在大多數系統投入生產時開始建構它）導致我們在建立整個平台的監控方面背負著巨大的技術債。 我們無法集中精力對一個IS進行監控並制定詳細的監控方案，因為其餘系統將在一段時間內處於無人監控的狀態。 為了解決這個問題，我們確定了逐層評估資訊系統狀態最必要的指標列表，並開始實施。
因此，他們決定把大象分成幾部分吃掉。
我們的系統包括：
- 硬件;
- 操作系統;
- 軟件;
- 監控應用中的UI部分；
- 業務指標；
- 整合應用程式；
- 資訊安全;
- 網路；
- 流量平衡器。
該系統的核心是自我監控。 為了大致了解整個系統的狀態，您需要了解所有這些層上以及整個應用程式集上的應用程式發生了什麼。
那麼，關於堆疊。
我們使用開源軟體。 我們的中心有 Zabbix，我們主要將其用作警報系統。 大家都知道它是基礎設施監控的理想選擇。 這是什麼意思？ 正是每個維護自己的資料中心的公司（Sportmaster 也有自己的資料中心）所擁有的低階指標 - 伺服器溫度、記憶體狀態、raid、網路設備指標。
我們已將 Zabbix 與 Telegram Messenger 和 Microsoft Teams 集成，這些在團隊中積極使用。 Zabbix涵蓋了實際網路層、硬體層和部分軟體層，但它並不是萬能的。 我們從其他一些服務中豐富了這些數據。 例如，在硬體層面，我們透過API直接連接到我們的虛擬化系統並收集資料。
還有什麼。 除了 Zabbix 之外，我們還使用 Prometheus，它允許我們監控動態環境應用程式中的指標。 也就是說，我們可以透過 HTTP 端點接收應用程式指標，而不必擔心哪些指標要載入到其中，哪些不載入。 基於這些數據，可以開發分析查詢。
其他層的資料來源（例如業務指標）分為三個部分。
首先，這些是外部業務系統，Google Analytics，我們從日誌中收集指標。 我們從他們那裡獲得有關活躍用戶、轉換以及與業務相關的所有其他數據。 其次，這是一個UI監控系統。 應該更詳細地描述它。
曾幾何時，我們從手動測試開始，逐漸發展為功能和整合的自動測試。 由此我們進行了監控，只留下主要功能，並依賴盡可能穩定且不會隨時間經常變化的標記。
新的團隊結構意味著所有應用活動都僅限於產品團隊，因此我們不再做純粹的測試。 相反，我們從測試中進行 UI 監控，用 Java、Selenium 和 Jenkins 編寫（用作啟動和產生報告的系統）。
我們進行了很多測試，但最終我們決定走主路，也就是頂級指標。 而且如果我們有很多具體的測試，就很難保持數據的最新性。 每個後續版本都會嚴重破壞整個系統，我們要做的就是修復它。 因此，我們專注於很少改變的非常基本的事情，我們只監控它們。
最後，第三，資料來源是集中式日誌系統。 我們使用 Elastic Stack 來記錄日誌，然後可以將這些資料提取到我們的業務指標監控系統中。 除此之外，我們還有自己的監控 API 服務，用 Python 編寫，它透過 API 查詢任何服務並將資料收集到 Zabbix 中。
監控的另一個不可或缺的屬性是可視化。 我們的基於 Grafana。 它在其他視覺化系統中脫穎而出，因為它允許您在儀表板上視覺化來自不同資料來源的指標。 我們可以收集線上商店的頂級指標，例如，過去一小時內從 DBMS 下的訂單數量、Zabbix 運行該線上商店的作業系統的效能指標以及該應用程式實例的指標來自普羅米修斯。 所有這一切都將在一個儀表板上進行。 清晰易懂。
讓我注意一下安全性 - 我們目前正在完成該系統，稍後我們將與全球監控系統整合。 在我看來，電子商務在資訊安全領域面臨的主要問題與機器人、解析器和暴力破解有關。 我們需要密切注意這一點，因為從業務角度來看，所有這些都會嚴重影響我們應用程式的運作和聲譽。 透過所選的堆棧，我們成功地完成了這些任務。
還有一點很重要，應用層是由Prometheus組裝的。 他本人也與Zabbix整合。 而且我們還有sitespeed，一個可以讓我們查看頁面載入速度、瓶頸、頁面渲染、載入腳本等參數的服務，它也是API整合的。 因此，我們的指標是在 Zabbix 中收集的，相應地，我們也從那裡發出警報。 目前所有警報均發送至主要發送方式（目前為電子郵件和電報，MS Teams 最近也已連接）。 有計劃將警報升級到智慧機器人作為服務工作並向所有感興趣的產品團隊提供監控資訊的狀態。
對我們來說，指標不僅對於單一資訊系統很重要，而且對於應用程式使用的整個基礎設施的一般指標也很重要：運行虛擬機器的實體伺服器叢集、流量平衡器、網路負載平衡器、網路本身、通訊通道的利用率。 加上我們自己的資料中心的指標（我們有幾個資料中心，而且基礎設施相當大）。
我們的監控系統的優點在於，借助它，我們可以了解所有系統的健康狀況，並可以評估它們對彼此以及對共享資源的影響。 最終，它使我們能夠參與資源規劃，這也是我們的職責範圍。 我們管理伺服器資源 - 電子商務內的池、調試和退役新設備、購買額外的新設備、對資源利用率進行審核等。 每年，團隊都會規劃新專案、開發他們的系統，我們為他們提供資源非常重要。
在指標的幫助下，我們可以看到資訊系統資源消耗的趨勢。 基於它們我們可以計劃一些事情。 在虛擬化級別，我們收集資料並查看有關資料中心可用資源量的資訊。 在資料中心內部，您可以看到資源的回收、實際分配和消耗。 此外，無論是獨立伺服器還是虛擬機，以及所有這些虛擬機都在其上高速運轉的實體伺服器叢集。
前途
現在整個系統的核心我們已經準備好了，但是還有很多事情要做。 至少，這是一個資訊安全層，但到達網路、開發警報並解決相關問題也很重要。 我們有很多層和系統，每一層都有更多的指標。 原來是娃娃程度的套娃。
我們的任務是最終發出正確的警報。 例如，如果硬體出現問題，或者虛擬機器出現問題，並且有一個重要的應用程序，且服務沒有以任何方式備份。 我們發現虛擬機器已經死了。 那麼業務指標就會提醒你：使用者已經消失在某處，沒有轉化，介面中的UI不可用，軟體和服務也死掉了。
在這種情況下，我們將收到來自警報的垃圾郵件，這不再適合適當的監控系統的格式。 相關性的問題就出現了。 因此，理想情況下，我們的監控系統應該在一個警報的幫助下說：“夥計們，你們的物理機器已經死了，隨之而來的是這個應用程序和這些指標”，而不是用一百個警報瘋狂地轟炸我們。 它應該報告主要內容 - 原因，這有助於快速消除由於其本地化而導致的問題。
我們的通知系統和警報處理是圍繞 XNUMX 小時熱線服務而建構的。 所有被視為必備且包含在清單中的警報都會發送到此處。 每個警報必須有一個描述：發生了什麼、它實際上意味著什麼、它影響什麼。 還有儀表板的連結以及有關在這種情況下該怎麼做的說明。
這就是建造警報的要求。 那麼情況可能會朝兩個方向發展──要嘛出現問題需要解決，要嘛監控系統故障。 但無論如何，你都需要去弄清楚。
考慮到警報的關聯性尚未正確配置，我們現在平均每天收到大約一百個警報。 如果我們需要進行技術工作，並且我們強行關閉某些東西，那麼它們的數量就會顯著增加。
除了監控我們營運的系統並收集我們認為重要的指標之外，監控系統還允許我們為產品團隊收集數據。 它們可以影響我們監控的資訊系統內指標的組成。
我們的同事可能會要求添加一些對我們和團隊都有用的指標。 或者，例如，團隊可能沒有我們擁有的足夠的基本指標；他們需要追蹤一些特定的指標。 在 Grafana 中，我們為每個團隊創建一個空間並授予管理員權限。 此外，如果一個團隊需要儀表板，但他們自己不能/不知道如何做，我們會幫助他們。
由於我們處於團隊價值創造、發布和規劃的流程之外，因此我們逐漸得出這樣的結論：所有系統的發布都是無縫的，並且可以在不與我們協調的情況下每天推出。 對我們來說監控這些版本很重要，因為它們可能會影響應用程式的運作並破壞某些內容，這一點至關重要。 為了管理版本，我們使用 Bamboo，透過 API 接收數據，並可以查看哪些版本已在哪些資訊系統中發布及其狀態。 最重要的是在什麼時間。 我們將發布標記疊加在主要關鍵指標上，這在出現問題時在視覺上非常具有指示性。
這樣我們就可以看到新版本和新出現的問題之間的相關性。 主要想法是了解系統各層的工作原理，快速定位問題並儘快修復。 畢竟，很多時候花最多時間的不是解決問題，而是找原因。
未來在這個領域我們希望注重主動性。 理想情況下，我希望提前而不是事後了解即將出現的問題，以便我可以預防而不是解決它。 有時，由於人為錯誤和應用程式的更改，監控系統會發生誤報。我們致力於此，對其進行調試，並嘗試在對監控系統進行任何操作之前警告與我們一起使用它的用戶。 ，或在技術視窗中執行這些活動。
因此，該系統已經啟動，並且自春季開始以來一直在成功運行......並且正在顯示出非常實際的利潤。 當然，這不是它的最終版本；我們將引入更多有用的功能。 但現在，隨著如此多的整合和應用程序，監控自動化確實是不可避免的。
如果您還監控具有大量整合的大型項目，請在評論中寫下您為此找到的靈丹妙藥。
來源： www.habr.com