我叫安東·巴德林。 我在高科技中心工作，負責系統管理。 一個月前，我們的企業會議結束了，我們與本市的 IT 社群分享了我們累積的經驗。 我談到了監控 Web 應用程式。 該材料適用於初級或中級水平，他們並不是從頭開始建立此過程。
任何監控系統的基石都是解決業務問題。 為了監視而監視，誰都沒有興趣。 企業想要什麼？ 這樣一切就可以快速且無錯誤地進行。 企業希望積極主動，以便我們自己發現服務中的問題並儘快解決它們。 事實上，這些都是我去年在一個客戶的專案中解決的問題。
關於
該項目是該國最大的忠誠度計劃之一。 我們幫助零售連鎖店透過獎金卡等各種行銷工具提高銷售頻率。 該專案總共包括 14 個應用程序，在 XNUMX 台伺服器上運行。
在採訪過程中，我反覆注意到管理員並不總是正確地監控 Web 應用程式：許多人仍然關注作業系統指標，偶爾監控服務。
就我而言，客戶的監控系統之前是基於 Icinga 的。 它並沒有以任何方式解決上述問題。 通常，客戶會親自向我們告知問題，但更多時候，我們只是沒有足夠的數據來找出原因。
此外，人們清楚地認識到其進一步發展是徒勞無功的。 我想熟悉 Icinga 的人都會理解我。 因此，我們決定徹底重新設計該專案的Web應用監控系統。
普羅米修斯
我們選擇Prometheus主要基於三個指標：
- 大量可用指標。 在我們的例子中，有 60 萬個。 當然，值得注意的是我們並沒有使用其中的絕大多數（可能約 95%）。 另一方面，它們都相對便宜。 對我們來說，與之前使用的 Icinga 相比，這是另一個極端。 在其中，添加指標是一個特別痛苦的事情：現有的指標非常昂貴（只需查看任何插件的源代碼）。 任何插件都是 Bash 或 Python 中的腳本，其啟動就消耗的資源而言是昂貴的。
- 該系統消耗相對少量的資源。 600 MB 的 RAM、一個核心的 15% 和幾十個 IOPS 足以滿足我們的所有指標。 當然，您必須運行指標導出器，但它們都是用 Go 編寫的，而且不是很耗電。 我認為在現代現實中這不是一個問題。
- 提供遷移到 Kubernetes 的能力。 考慮到客戶的計劃，選擇是顯而易見的。
麋鹿
以前，我們不收集或處理日誌。 缺點大家都很清楚。 我們選擇 ELK 是因為我們已經有這個系統的經驗。 我們只在那裡存儲應用程式日誌。 主要選擇標準是全文搜尋及其速度。
克里克豪斯
最初，選擇落在了 InfluxDB 上。 我們意識到需要收集Nginx日誌、pg_stat_statements的統計資料以及儲存Prometheus歷史資料。 我們不喜歡 Influx，因為它會定期開始消耗大量記憶體並崩潰。 另外，我想透過remote_addr對查詢進行分組，但在這個DBMS中只能透過標籤進行分組。 標籤很昂貴（記憶體），它們的數量是有條件限制的。
我們再次開始尋找。 我們需要的是一個資源消耗最少的分析資料庫，最好在磁碟上進行資料壓縮。
Clickhouse滿足所有這些標準，我們從未後悔我們的選擇。 我們不會在其中寫入任何大量資料（插入次數僅為每分鐘 XNUMX 左右）。
NewRelic的
NewRelic 一直與我們合作，因為它是客戶的選擇。 我們將其用作 APM。
ZABBIX
我們專門使用Zabbix來監控各種API的黑盒子。
定義監控方法
我們希望分解任務，從而使監控方法系統化。
為此，我將我們的系統分為以下幾個等級：
- 硬體和VMS；
- 操作系統;
- 系統服務、軟體堆疊；
- 應用;
- 商業邏輯。
為什麼這種方法很方便：
- 我們知道誰負責每個級別的工作，並據此發送警報；
- 我們可以在抑制警報時使用該結構 - 當整個虛擬機器不可用時發送有關資料庫不可用的警報會很奇怪。
由於我們的任務是識別系統運行中的違規行為，因此我們必須在每個層級突出顯示一組在編寫警報規則時值得關注的指標。 接下來，我們來看看「VMS」、「作業系統」和「系統服務、軟體堆疊」三個層級。
虛擬機
託管為我們分配處理器、磁碟、記憶體和網路。 我們在前兩個方面遇到了問題。 所以，指標：
CPU 被盜時間 - 當您在 Amazon 上購買虛擬機器（例如 t2.micro）時，您應該明白，您沒有分配到整個處理器核心，而只是分配了其時間配額。 當你耗盡它時，處理器就會從你身邊被奪走。
此指標可讓您追蹤此類時刻並做出決策。 例如，是否需要採取更豐厚的資費或將後台任務和API請求的處理分散到不同的伺服器上？
IOPS + CPU iowait 時間 - 由於某種原因，許多雲端主機因無法提供足夠的 IOPS 而犯錯。 此外，低 IOPS 的調度對他們來說並不是一個論點。 因此，值得收集CPU iowait。 有了這對圖表 - 具有低 IOPS 和高 I/O 等待 - 您已經可以與主機交談並解決問題。
操作系統
作業系統指標：
- 可用內存量（%）；
- 交換使用活動：vmstat swapin、swapout；
- 檔案系統上可用 inode 和可用空間的數量（以 % 為單位）
- 平均負載；
- tw狀態下的連線數；
- 追蹤表的完整性；
- 可以使用 ss 實用程式（iproute2 套件）來監控網路品質 - 從其輸出中取得 RTT 連接的指示符，並按目標連接埠進行分組。
同樣在作業系統級別，我們有一個進程這樣的實體。 在系統中識別一組在其運作中發揮重要作用的進程非常重要。 例如，如果您有多個 pgpool，那麼您需要收集每個 pgpool 的資訊。
指標集如下：
- 中央處理器;
- 記憶主要是駐留的；
- IO－最好以IOPS為單位；
- FileFd－開啟和限制；
- 嚴重的頁面失敗 - 這樣您就可以了解正在交換哪個進程。
我們將所有監控部署在 Docker 中，並使用 Advisor 來收集指標資料。 在其他機器上，我們使用進程導出器。
系統服務、軟體堆疊
每個應用程式都有自己的具體情況，很難挑選出一組特定的指標。
通用集是：
- 請求率；
- 錯誤數量；
- 潛伏;
- 飽和。
在這個層級上，我們最引人注目的監控範例是 Nginx 和 PostgreSQL。
我們系統中負載最多的服務是資料庫。 過去，我們常常很難弄清楚資料庫在做什麼。
我們看到磁碟負載很高，但緩慢的日誌並沒有真正顯示任何內容。 我們使用 pg_stat_statements 解決了這個問題，這是一個收集查詢統計資料的視圖。
這就是管理員的全部需求。
我們建立讀寫請求活動的圖表：
一切都簡單明了，每個請求都有自己的色彩。
一個同樣引人注目的例子是 Nginx 日誌。 很少有人解析它們或在必備清單中提及它們，這並不奇怪。 標準格式資訊量不大，需要擴充。
就我個人而言，我新增了 request_time、upstream_response_time、body_bytes_sent、request_length、request_id。我們繪製回應時間和錯誤數：
我們建立響應時間和錯誤數量的圖表。 記住？ 我有談業務任務嗎？ 快速且無錯誤？ 我們已經用兩張圖表涵蓋了這些問題。 您已經可以使用它們呼叫值班管理員。
但還有一個問題仍然存在──確保迅速消除事件起因。
事件解決
從發現問題到解決問題的整個過程可以分為幾個步驟：
- 識別問題；
- 通知值班管理員；
- 對事件的反應；
- 消除原因。
重要的是我們必須盡快做到這一點。 如果在發現問題和發送通知的階段我們無法獲得太多時間——無論如何都會花費兩分鐘，那麼後續的改進就只是未耕耘的領域。
讓我們想像一下，值班人員的電話響了。 他會做什麼？ 尋找問題的答案－什麼壞了，壞在哪裡，如何反應？ 我們是這樣回答這些問題的：
我們只需將所有這些資訊包含在通知文本中，為其提供一個 wiki 頁面的鏈接，該頁面描述如何響應此問題、如何解決問題併升級問題。
應用層和業務邏輯我還沒說。 不幸的是，我們的應用程式尚未實現指標收集。 這些級別的任何資訊的唯一來源是日誌。
有幾點。
首先，編寫結構化日誌。 訊息文字中無需包含上下文。 這使得它們難以分組和分析。 Logstash 需要很長時間才能讓這一切正常化。
其次，正確使用嚴重性等級。 每種語言都有自己的標準。 就我個人而言，我分為四個層次：
- 沒有錯誤；
- 客戶端錯誤；
- 錯誤在我們這邊，我們不賠錢，我們不承擔風險；
- 錯誤在我們這邊，我們賠了錢。
讓我總結一下。 您需要嘗試建立基於業務邏輯的監控。 嘗試監控應用程式本身並使用銷售數量、新用戶註冊數量、當前活躍用戶數量等指標進行操作。
如果你的整個業務就是瀏覽器中的一個按鈕，那麼你需要監控它是否點擊並正常運作。 其餘的一切都沒關係。
如果你沒有這個，你可以嘗試在應用程式日誌、Nginx 日誌等中追趕它，就像我們所做的那樣。 您應該盡可能接近應用程式。
作業系統指標當然很重要，但企業對它們不感興趣，我們沒有為此付費。
來源： www.habr.com