跳至主要内容

監控最佳實踐

配置合理的監控和警報規則對於安全可靠地執行任何生產工作負載至關重要。在使用 Kubernetes 和 Rancher 時,這並沒有什麼不同。幸運的是,整合的監控和警報功能使整個過程變得更加容易。

Rancher 監控文件描述了如何設定完整的 Prometheus 和 Grafana 堆疊。開箱即用,它將從叢集中的所有系統和 Kubernetes 元件抓取監控資料,並為它們提供合理的儀表板和警報以開始使用。但對於可靠的設定,你還需要監控自己的工作負載,並根據自己的特定使用案例和叢集大小調整 Prometheus 和 Grafana。本文件旨在為你提供此方面的最佳實踐。

監控什麼​

Kubernetes 本身,以及在其中執行的應用程式,形成了一個分散式系統,其中不同的元件相互互動。對於整個系統和每個單獨的元件,你必須確保效能、可用性、可靠性和可擴展性。一個包含更多詳細資訊的好資源是 Google 免費的 Site Reliability Engineering Book,尤其是關於監控分散式系統的章節。

配置 Prometheus 資源使用​

在安裝整合監控堆疊時,Rancher 允許配置多個設定,這些設定取決於叢集的大小和其中執行的工作負載。本章節更詳細地介紹這些內容。

儲存和資料保留​

Prometheus 所需的儲存量與你儲存的時間序列和標籤的數量以及你配置的資料保留時間直接相關。重要的是要注意,Prometheus 不打算用作長期指標儲存。資料保留時間通常只有幾天,而不是幾週或幾個月。原因是 Prometheus 不會對其儲存的指標執行任何聚合。這很好,因為聚合會稀釋資料,但這也意味著所需的儲存會隨著時間線性成長,而沒有保留。

計算必要儲存的一種方法是使用此查詢查看 Prometheus 中儲存區塊的平均大小

rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[1h])

接下來,找出每秒的資料擷取速率:

rate(prometheus_tsdb_head_samples_appended_total[1h])

然後將此值乘以保留時間,加上幾個百分點作為緩衝:

average chunk size in bytes * ingestion rate per second * retention time in seconds * 1.1 = necessary storage in bytes

你可以在此部落格文章中找到有關如何計算必要儲存的更多資訊。

你可以在 Prometheus 文件中閱讀有關 Prometheus 儲存概念的更多資訊。

CPU 和記憶體請求與限制​

在較大的 Kubernetes 叢集中,Prometheus 可能會消耗相當多的記憶體。Prometheus 所需的記憶體量與它儲存的時間序列數量和標籤數量以及填充這些資料的抓取間隔直接相關。

你可以在此部落格文章中找到有關如何計算必要記憶體的更多資訊。

必要的 CPU 數量與你執行的查詢數量相關。

聯邦和長期儲存​

Prometheus 不適合長時間儲存指標,而應僅用於短期儲存。

為了長時間儲存一些或所有指標,你可以利用 Prometheus 的遠端讀取/寫入功能將其連接到儲存系統,例如 Thanos、InfluxDB、M3DB 或其他系統。你可以在此部落格文章中找到範例設定。

抓取自訂工作負載​

雖然整合的 Rancher Monitoring 已經從叢集的節點和系統元件抓取系統指標,但你在 Kubernetes 上部署的自訂工作負載也應該被抓取資料。為此,你可以配置 Prometheus 在特定間隔內對應用程式的端點執行 HTTP 請求。然後,這些端點應以 Prometheus 格式回傳其指標。

一般來說,你希望從叢集中執行的所有工作負載抓取資料,以便可以將它們用於警報或除錯問題。通常,你只有在事件期間實際需要指標時才意識到需要某些資料。如果它已經被抓取和儲存,那就太好了。由於 Prometheus 僅適用於短期指標儲存,因此抓取和保留大量資料通常並不昂貴。如果你正在使用 Prometheus 的長期儲存解決方案,那麼你仍然可以決定實際持久化和保留哪些資料。

關於 Prometheus Exporters​

許多第三方工作負載,例如資料庫、佇列和 Web 伺服器,已經支援以 Prometheus 格式公開指標,或提供在工具指標和 Prometheus 理解的格式之間轉換的 exporters。你通常可以將這些 exporters 作為額外的 sidecar 容器新增到工作負載的 Pods 中。許多 Helm 圖表已經包含部署正確 exporter 的選項。你可以在 ExporterHub 上找到 exports 的精選清單。

程式語言和框架中的 Prometheus 支援​

要將你自己的自訂應用程式指標匯入 Prometheus,你必須直接從應用程式的程式碼收集和公開這些指標。幸運的是,對於大多數流行的程式語言和框架,已經有可用的函式庫和整合來幫助完成此操作。一個例子是 Spring Framework 中的 Prometheus 支援。

ServiceMonitors 和 PodMonitors​

一旦所有工作負載都以 Prometheus 格式公開指標,你必須配置 Prometheus 來抓取它們。在底層,Rancher 使用 prometheus-operator。這使得使用 ServiceMonitors 和 PodMonitors 新增抓取目標變得容易。許多 Helm 圖表已經包含直接建立這些監視器的選項。你也可以在 Rancher 文件中找到更多資訊。

Prometheus Push Gateway​

有一些工作負載傳統上很難被 Prometheus 抓取。這些範例包括短期工作負載,如 Jobs 和 CronJobs,或不允許在處理的個別傳入請求之間共享資料的應用程式,如 PHP 應用程式。

為了仍然能夠獲取這些使用案例的指標,你可以設定 prometheus-pushgateways。CronJob 或 PHP 應用程式會將指標更新推送到 pushgateway。pushgateway 聚合並透過 HTTP 端點公開它們,然後可以由 Prometheus 抓取。

Prometheus Blackbox Monitor​

有時從外部監控工作負載很有用。為此,你可以使用 Prometheus blackbox-exporter,它允許透過 HTTP、HTTPS、DNS、TCP 和 ICMP 探測任何類型的端點。

在(微)服務架構中監控​

如果你有一個(微)服務架構,其中叢集內的多個個別工作負載相互通訊,那麼擁有關於此流量的詳細指標和追蹤就非常重要,以了解所有這些工作負載如何相互通訊以及問題或瓶頸可能在哪裡。

當然,你可以監控所有工作負載中的所有內部流量,並將這些指標公開給 Prometheus。但這很快就會變得相當耗費工作。像 Istio 這樣的 Service Meshes 可以一鍵在 Rancher 中安裝,可以自動執行此操作並提供有關所有服務之間流量的豐富遙測資料。

真實使用者監控​

監控所有內部工作負載的可用性和效能對於執行穩定、可靠和快速的應用程式至關重要。但這些指標只顯示了部分情況。要獲得完整的視圖,還需要知道你的最終使用者實際上如何感知它。為此,你可以查看各種真實使用者監控解決方案。

安全監控​

除了監控工作負載以偵測效能、可用性或可擴展性問題外,還應監控叢集和其中執行的工作負載以發現潛在的安全問題。一個好的起點是頻繁執行和警報合規性掃描,它會檢查叢集是否根據安全最佳實踐進行配置。

對於工作負載,你可以查看 Kubernetes 和容器安全解決方案,例如 NeuVector、Falco、Aqua Kubernetes Security、SysDig。

設定警報​

將所有指標匯入監控系統並在儀表板中視覺化它們非常好,但你也希望在出現問題時主動收到警報。

整合的 Rancher 監控已經配置了一組合理的警報,這些警報在任何 Kubernetes 叢集中都有意義。你應該擴展這些警報以涵蓋你的特定工作負載和使用案例。

在設定警報時,為所有對應用程式可用性至關重要的工作負載配置它們。但也要確保它們不會太嘈雜。理想情況下,你收到的每個警報都應該是因為需要你注意和需要修復的問題。如果你的警報一直觸發但並不那麼關鍵,則存在你開始完全忽略警報然後錯過真正重要警報的危險。在這裡,少即是多。首先專注於真正重要的指標,例如在你的應用程式離線時發出警報。修復所有開始出現的問題,然後開始建立更詳細的警報。

如果警報開始觸發,但你目前無法對其採取任何行動,那麼將警報靜音一段時間也是可以的,這樣你就可以稍後再查看它。

你可以在 Rancher 文件中找到有關如何設定警報和通知通道的更多資訊。