容器監控種類大盤點
當討論容器監控時，我們需要先談談「監控」一詞。不同的行業中監控可能代表著不同的意義，在容器以及基於雲的運營世界，它有以下四個主要用途：
- 知道什麼時候出現問題。
- 擁有調試問題的信息。
- 趨勢和報告。
- 探測。
下面就讓我們來看看這些用途以及最好的實現方法。
擁有調試問題的信息
你的監控系統現在會提醒你延遲時間很長。 現在你要做什麼呢？ 你可以登錄到每台機器上，運行top命令，檢查syslog並開始tailing應用日誌。 但這樣沒有任何效率可言，而且隨著你的數據流和機器資源的擴充，問題檢查的效率會越來越低。 你的監控需要提供一種方法，可以讓你可以有條不紊地處理問題，為你提供縮小問題範圍所需的工具。
微服務通常可以被視為樹，遠程過程調用（RPC）從頂部流到底部。 服務中的高延遲的問題通常由該服務或其後端之一的延遲引起。 比起嘗試從儀錶板上的數百個圖表獲得靈感，您可以轉到根服務的儀錶板，並檢查其後端是否出現過載和延遲的跡象。 如果延遲在後端，請重複此過程，直到找到出問題的服務。
Advertisements
知道什麼時候出現問題
告警是監控的最關鍵的部分之一，但一個重要的問題是：什麼樣的問題值得在午夜喚醒一個工程師去看呢？可以為任何事設立告警機制的確誘人，比如設立預警線甚至為輕微的小問題創建告警，但這也可能會迅速導致警惕疲勞。
假設你正在運行一組面向用戶的微服務，並且您關心請求的延遲。CPU在每台機器上的用量監控是否有用呢？監控可能會提醒你計算機上的CPU容量已用完。它同時也可能在後台進程需要比平常更長的時間時出現誤報，以及在死鎖或者沒有足夠的線程來使用所有CPU時出現漏報。
CPU是導致問題的潛在原因，高延遲才是你應該嘗試監測的問題現象。在My Philosophy on Alerting, Rob Ewaschuk一書中指出造成高延遲的許多潛在原因，並且很難枚舉所有原因。所以說最好監控並告警這種問題現象，因為這樣你更有可能會在更少的告警頁面中看到一個真正值得在深夜喚醒工程師的問題。在動態容器環境中，機器只是一個計算資源，對於現象而不是原因告警才是正道。
Advertisements
擁有調試問題的信息
你的監控系統現在會提醒你延遲時間很長。 現在你要做什麼呢？ 你可以登錄到每台機器上，運行top命令，檢查syslog並開始tailing應用日誌。 但這樣沒有任何效率可言，而且隨著你的數據流和機器資源的擴充，問題檢查的效率會越來越低。 你的監控需要提供一種方法，可以讓你可以有條不紊地處理問題，為你提供縮小問題範圍所需的工具。
微服務通常可以被視為樹，遠程過程調用（RPC）從頂部流到底部。 服務中的高延遲的問題通常由該服務或其後端之一的延遲引起。 比起嘗試從儀錶板上的數百個圖表獲得靈感，您可以轉到根服務的儀錶板，並檢查其後端是否出現過載和延遲的跡象。 如果延遲在後端，請重複此過程，直到找到出問題的服務。
Figure 1: 微服務中的組件數據流
這個過程可以更進一步。 就像微服務組成樹一樣，單個微服務中的子系統，庫和中間件也可以表示為樹。 然後可以應用相同的問題識現象別方法來進一步縮小問題範圍。 要繼續從這裡開始調試，你可能會使用各種工具挖掘流程內部，調查請求日誌中的模式並跨主機交叉關聯請求。
趨勢和報告
告警和調試通常在幾分鐘到幾天的時間範圍內。 趨勢和報告關注從周到年的時間範圍。
一個使用較好的監控系統收集各種信息，從原始硬體利用率和API請求數到高級業務指標。 對於這些信息有明顯的應用場景，比如配置和容量規劃如何能夠滿足未來的需求，但除此之外，還有更為廣泛的方面，數據可以幫助工程和業務的決策。
知道請求彼此之間有多麼相似可能帶來緩存的方面的益處，或者可能有助於爭取移除一個緩存來簡化架構簡單。 了解每個請求如何使用您的有限資源有助於確定你的定價模式。 跨服務和跨機器統計信息可以幫助您將時間花在潛在的系統優化上。 你的監控系統應能幫助你使進行這些分析成為可能。
探測
當你有一把鎚子，一切都開始看起來像一個釘子。
探測與其他用途不同，因為它涉及將數據從系統A移動到系統B，而不是直接支持響應決策。 一個示例可能是將每小時的銷售數量的數據發送到商業智能儀錶板。 探測是關於建立這個管道，而不是從最終結果採取什麼行動。 這不一定是監控; 然而，使用監控系統將一些數據移動到需要移動的位置通常會很方便。
從頭開始構建量身定製數據移動的解決方案可能需要幾個星期，如果可以有效地使用你的監控系統做同樣的事情，那麼為什麼不呢？ 所以，在評估監控系統時，不要僅僅要考慮其圖形化和警報的能力，還要了解添加自定義數據源和稍後提取捕獲的數據是否容易。
監控的類型
現在我們已經建立了監控的概念，讓我們再談談那些插入到我們監控系統中的數據吧。
總體來說，大多數監控系統使用相同的數據：事件。事件是在觀察節點之間發生的所有活動。 事件可以是正在執行的指令，正在進行的函數調用，被路由的請求，接收到的遠程調用過程（RPC）或返回的響應。 事件具有上下文信息，例如什麼數據觸發它們以及什麼數據它們正使用。
我們將看看使用事件的幾種不同的方式; 每種方法都做出不同的折衷，並為我們展示了系統的不同角度。 完整的容器監控系統將具有以下每種方式的方方面面。
指標
指標，有時稱為時間序列，涉及隨時間聚集的事件。 它們計算每種類型的事件發生的頻率，每種類型的事件需要多長時間以及不同事件類型處理多少數據。
指標不關心事件的上下文。 您可以添加上下文，例如通過HTTP端點分解延遲，但是您需要為每個端點的指標消耗資源。 在這種情況下，endpoint的數量需要相對較小。 這限制了分析事件的個別事件的能力; 然而，好處是它允許在單個服務內跟蹤成千上萬的事件類型。 這意味著您可以深入了解代碼在整個應用程序中的表現。
我們將更深入地探討基於指標的監控的組成部分。
Figure 2: 收集、存儲、現實指標的架構圖
收集
收集是將系統狀態和事件轉換為指標的過程，可以稍後由監視系統收集。 收集可以通過下面幾種方式進行：
1.完全在一個進程中。 Prometheus 和 Dropwizard instrumentation libraries就是例子; 他們將所有狀態保存在進程的內存中。
2.通過將來自另一進程的數據轉換為可用格式。 collectd 以及 Agentless System Crawler 通過從 proc filesystem 中提取數據來執行此操作。
3.由兩個進程協作：一個捕獲事件，另一個將它們轉換為指標。StatsD就是一個例子，其中每個事件都是由應用程序通過網路發送到StatsD中。
攝取
攝取，從收集中獲取指標，並將其送入監測系統。 這可以是歌涉及排隊系統（例如Apache Kafka）或直接從集合的簡單數據傳輸的多階段過程。 在這一點上，必須提及push與Pull的爭論。 這兩種方法都有優點和缺點，我們不會在這裡做更多的討論，但是簡單來說兩種方法都可以擴展，並且兩種方法都可以在容器化的環境中工作。
存儲
一旦數據被攝取，它通常會被存儲起來。 它可以是對最近結果的短期存儲，但它也可以是特定分鐘，小時或天的數據存儲。
一旦存儲的數據容量超出了在一台機器上的內存範圍，就需要進行操作性和可靠性的權衡，並且這裡根據組織對監控數據的需要也有利弊。 磁碟上進程的生存期之外的持久數據意味著需要備份或者意味著在機器故障時丟失數據。 在多台機器間傳播數據帶來了分散式系統的基本挑戰。如果數據是安全的結束現有的系統並不難，但新的數據不能被攝取和處理。
數據處理和報警
如果你不做任何數據處理，數據就沒有太大用處。 大多數指標系統提供了一些方法來對接收的數據進行數學計算，通常還提供方法來對異常情況告警。 這可能會發生在數據被攝取或作為單獨的非同步過程。
不同的數據處理解決方案中複雜性差異很大。 一方面，像Graphite這樣的解決方案沒有第三方工具支持就沒有數據處理或告警功能; 然而，在繪圖時有基本的聚合和算術能力。 另一方面，有像Prometheus或Sysdig這樣的解決方案，不僅具有成熟的數據處理和告警系統，而且還有的額外的聚合和重複數據刪除系統用於告警。
可視化
能發到手機的告警是不錯，但是對於調試，報告和分析，我們希望有儀錶板可以可視化這些監控數據。
可視化工具通常分為三類。 低端的，有內置的方法在監控系統本身產生專門的圖表。 中端的，監控系統有內置的儀錶板，但是內容有限或不能自定義，這是用於監控特定系統所常見的系統設計。 最後，有完全可定製的儀錶板，你可以創建幾乎任何你喜歡的數據呈現樣式。
他們如何結合在一起
現在，您已經了解了指標監控系統中涉及的組件，讓我們來看看一些具體示例。
Nagios
Nagios伺服器通常調用主機上的腳本（稱為檢查），並記錄它們是否根據其退出代碼正常工作。 如果檢查失敗太多，它會發出警報。 可視化部分通常由單獨的內置儀錶板提供。 它可以從腳本中獲取1KB的數據，包括指標（稱為「perfdata」），並將其傳遞到另一個監視系統。
Figure 3: Nagios 架構
Nagios設計用於靜態設置，需要重新啟動才能載入新配置。 其有限的數據處理，專註於基於主機的監控以及僅處理少量指標數據的能力使得它不適合於在容器環境中進行監視。 但是，它仍然可用於基本黑盒監控。
Collectd, Graphite 和 Grafana
許多常見的監控棧將幾個組件組合在一起。 collectd，Graphite和Grafana組合就是這樣一個例子。 collectd是收集器，從內核和第三方應用程序（如MySQL）中提取數據。 要從您自己的應用程序收集自定義指標，您可以使用StatsD協議，該協議會發送用戶數據協議（UDP）數據包來收集個別事件。 collectd將指標發送給Carbon，後者使用Whisper資料庫進行存儲。 最後， Graphite和Grafana本身都可以用於可視化。
Figure 4: collectd, Graphite, Grafana 組合監控方案示例
StatsD的收集方法在規模方面是有限制的; 為了獲得性能，選擇放棄一些事件並不少見。 Collected每機器方法在容器化環境中也是限制性的。 例如，如果有動態部署的MySQL容器，那麼collectd需要每次更新它的配置。
Prometheus
Prometheus採取了不同於我們之前例子的方法。 監控數據收集在應用程序內部發生。 每個應用程序有一個導出器，而不是每台機器有一個收集器。 這種方法可以更容易管理，雖然是以以增加資源使用為代價。 在像Kubernetes這樣的容器化環境中，導出器將作為主容器的附屬容器來管理。 Prometheus伺服器處理提取，處理，告警和存儲。 但是，為了避免將分散式系統綁定到關鍵監控中，本地Prometheus存儲更像是一個緩存。 單獨的非關鍵分散式存儲系統處理長期存儲。 這種方法提供了長期數據的監測可靠性和耐久性。
Figure 5: Prometheus 架構
Prometheus決定發出什麼警報，但它不會向用戶發送電子郵件或信息。 告警信息會被發送到Alertmanager，它對來自多個Prometheus伺服器的警報進行重複數據刪除和聚合，併發送通知。
Sysdig Cloud
前面的部分給出了各種開源解決方案的架構。 為了比較，本節描述了Sysdig Cloud的一種商業解決方案的架構。 Sysdig Cloud使用基於每個主機的內核級別收集模型。 此工具可通過單個收集點捕獲應用程序，容器，統計信息和主機指標信息。 它收集事件日誌，如Kubernetes scaling，Docker容器事件和代碼推送與指標相關聯。 每個主機代理可以減少監視代理的資源消耗，並且不需要修改應用程序代碼。 然而，它需要一個特權容器。
Figure 6: Sysdig 商業版架構
Sysdig Cloud存儲後端包括Cassandra（指標），MySQL（事件）和Redis（服務內部代理）的水平可伸縮集群。 基於這些組件提供高可靠性和規模來存儲多年的數據用於長期趨勢和分析。 所有數據都可以通過REST API訪問。 這整個後端可以通過Sysdig的雲服務使用，或作為軟體部署在私有雲中，以提高安全性和隔離性。 此設計允許您避免運行多個系統進行實時監控和長期分析或數據保留。
除了處理指標數據之外，Sysdig Cloud還收集其他類型的數據，包括來自Kubernetes和Docker容器的事件日誌，以及來自編排引擎（如Kubernetes）的元數據。 這用於豐富從度量提供的信息，而且指標系統具有超出指標數據處理功能情況並不罕見。
日誌
日誌，有時稱為事件日誌，都是關於獨立事件的上下文。 比如有多少請求去了一個endpoint？ 哪些用戶正在使用或調用endpoint？
日誌於指標相反。 它們不隨時間進行任何聚合。
區分正在使用的日誌類型很重要，因為它們具有各種不同的用途和可靠性要求：
- 業務和事務日誌：這些是你必須不計成本保證安全的日誌。涉及計費的任何事務都是業務或事務日誌的一個很好的例子。
- 請求日誌：這些是通過你的系統發出的每個請求的日誌。它們經常用於系統的其他部分用於優化和其他處理。丟失一些不好，但不會成為世界末日。
- 應用程序日誌：這些是來自應用程序的關於一般系統狀態的日誌。例如，它們將指示何時完成垃圾回收或其他某些後台任務。通常，您每分鐘只需要一些日誌消息，因為人們會直接讀取日誌。通常只在調試問題時需要它們。
- 調試日誌：這些是非常詳細的日誌，用於調試。因為這些日誌僅在特定情況下需要，所以它們具有比應用日誌更低的可靠性要求。
下一次有人談到日誌時，了解一下他們正在談論的日誌類型，以便更好的加入對話中。
性能分析
性能分析具有指標和日誌的相同的優點。 它可以讓你在整個應用程序中查看有關各個事件的數據。 缺點是應用起來往往比較困難。
有各種Linux性能分析工具，包括 eBPF , gdb , iotop , strace , tcpdump 和 top。 還有一些商業選擇, 如 Sysdig，它們將性能分析工具的功能集成到一個包中。
結語
在本文中，我們涵蓋了監控的用途，這將幫助您了解可以通過監控來解決的問題。我們了解了使用事件的不同方法：指標，日誌，性能分析。在分解基於指標的方法時，我們研究了如何收集，攝取，存儲，處理，告警和可視化數據。
現在，相信對監控系統的類型和他們解決的問題有了更好的認識，你將能夠徹底評估許多不同的解決方案。有許多方法來設計監控系統，並且每個都有自己的優點和缺點。當評估監控解決方案時，首先要評估它是否主要基於指標，日誌或性能分析。
每個解決方案都有其優點和缺點，你肯定需要多個工具來創建一個全面的解決方案來監控容器。
文末福利：請大家關注本公眾號並回復【進群】，睿雲小助手會第一時間拉你進入【 Docker企業落地實踐群】，我們分享的各個企業案例項目的技術專家與用戶代表，正在敬候您的光臨，期待大家就項目的更多細節與疑問與群里的大牛們進行諮詢探討。
需要了解更多有關睿雲智合的客戶項目細節，請在Wise2C公眾號中最佳實踐菜單中查看。
乾貨放送系列之（四）：某中型人壽保險公司系統架構改造規劃諮詢實戰案例
年度盤點系列：年度盤點 | 2016年金融行業容器技術應用 - 保險篇
年度盤點系列：年度盤點 | 2016年金融行業容器技術應用 - 銀行篇
若需要了解更多有關Wise系列PaaS產品的詳情，請與我們的市場團隊聯繫：