配置合理的監控和告警規則對於安全、可靠地運行生產工作負載至關重要。在使用 Kubernetes 和 Rancher 時也是如此。幸運的是，集成的監控和告警功能使整個過程變得更加簡單。
Rancher 的監控文檔（ https://docs.rancher.cn/docs/rancher2.5/monitoring-alerting/_index ）描述了如何設置一個完整的 Prometheus 和 Grafana。開箱即用，它將從集群中的所有系統和 Kubernetes 組件中抓取監控數據，並提供合理的儀表盤和告警。但為了實現可靠的設置，您還需要監控自己的工作負載並使 Prometheus 和 Grafana 適應您自己的特定用例和集群大小。本文檔將為您提供這方面的最佳實踐。
需要監測的內容
Kubernetes 本身以及運行在其內部的應用，構成了一個分布式系統，不同的組件之間相互影響。對於整個系統和每個單獨的組件，你必須確保性能、可用性、可靠性和可擴展性。更多細節和信息的參考 Google 免費的Site Reliability Engineering Book（ https://landing.google.com/sre/sre-book/ ），尤其是關於監控分布式系統（ https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/ ）這一章。
配置 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])
然后與保留時間相乘，並添加幾個百分點作為緩沖區：
平均塊大小（以字節為單位） * 每秒的攝取速率 * 保留時間（以秒為單位） * 1.1 = 必需的存儲空間（以字節為單位）
你可以在這篇博客文章（ https://www.robustperception.io/how-much-disk-space-do-prometheus-blocks-use ）中找到更多關於如何計算必要存儲的信息。
你可以在Prometheus 文檔（ https://prometheus.io/docs/prometheus/latest/storage ）中閱讀更多關於 Prometheus 存儲概念的內容。
CPU 和內存的請求和限制
在較大的 Kubernetes 集群中，Prometheus 會消耗大量內存。Prometheus 需要的內存直接與它存儲的時間序列和標簽的數量以及填充這些標簽的 scrape 間隔有關。
你可以在這個博客文章（ https://www.robustperception.io/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestion ）中找到更多關於如何計算所需內存的信息。
所需的 CPU 數量與您正在執行的查詢數量相關。
長期儲存
Prometheus 並不是為了長期存儲指標，而只用於短期存儲。
為了長期存儲一些或所有的指標，你可以利用 Prometheus 的遠程讀/寫（ https://prometheus.io/docs/prometheus/latest/storage/#remote-storage-integrations ）功能將其連接到存儲系統，如Thanos（ https://thanos.io/ ）、InfluxDB（ https://www.influxdata.com/ ）、M3DB（ https://www.m3db.io/ ）或其他系統。你可以在這篇博客文章（ https://rancher.com/blog/2020/prometheus-metric-federation ）中找到一個示例設置。
抓取自定義工作負載
雖然集成的 Rancher Monitoring 已經可以從集群的節點和系統組件中抓取系統指標，但你部署在 Kubernetes 上的自定義工作負載也應該被抓取數據。為此，你可以配置 Prometheus 在一定的時間間隔內對你的應用程序的端點進行 HTTP 請求。然后，這些端點應該以 Prometheus 格式返回它們的指標。
一般來說，您要從集群中運行的所有工作負載中抓取數據，以便可以將它們用於告警或調試問題。很多時候，你會認識到，只有當你在事件中真正需要指標的時候，你才需要一些數據。如果它已經被抓取並存儲了，那就好辦了。由於 Prometheus 只是為了成為一個短期的指標存儲，所以抓取和保存大量數據通常並不那么昂貴。如果你使用的是 Prometheus 的長期存儲方案，那么你仍然可以決定數據的存儲位置。
關於 Prometheus Exporters
許多第三方工作負載，如數據庫、隊列或 Web 服務器，要么已經支持以 Prometheus 格式公開指標，要么有所謂的 exporter，可以在工具的指標和 Prometheus 理解的格式之間進行轉換。通常，您可以將這些 exporter 作為額外的 sidecar 容器添加到工作負載的 Pods 中。很多 helm charts 已經包含了部署 exporter 的選項。此外，你還可以在promcat.io（ https://promcat.io/ ）和ExporterHub（ https://exporterhub.io/ ）上找到一個由 SysDig 策划的 exporter 列表。
Prometheus 在編程語言和框架中的支持
要想把自己的自定義應用指標放到 Prometheus 中，你必須直接從你的應用代碼中收集和暴露這些指標。幸運的是，對於大多數流行的編程語言和框架來說，已經有一些庫和集成可以幫助解決這個問題。其中一個例子是Spring（ https://docs.spring.io/spring-metrics/docs/current/public/prometheus ）框架中的 Prometheus 支持。
ServiceMonitors 和 PodMonitors
一旦所有工作負載都以 Prometheus 格式公開了指標后，你必須配置 Prometheus 來獲取它。 Rancher 使用prometheus-operator（ https://github.com/prometheus-operator/prometheus-operator ），這使得使用 ServiceMonitors 和 PodMonitors 添加額外的目標變得容易。很多 helm charts 已經包含了一個選項來直接創建這些監控器。你也可以在 Rancher 文檔中找到更多信息。
Prometheus Push Gateway
有些工作負載的指標很難被 Prometheus 獲取。就像 Jobs 和 CronJobs 這樣的短期工作負載，或者是不允許在單個處理的傳入請求之間共享數據的應用程序，如 PHP 應用程序。
要想獲得這些用例的指標，你可以設置 prometheus-pushgateways（ https://github.com/prometheus/pushgateway ）。CronJob 或 PHP 應用程序將把指標更新推送到 pushgateway。pushgateway 匯總並通過 HTTP 端點暴露它們，然后可以由 Prometheus 獲取。
Prometheus Blackbox Monitor
有時，從外部監控工作負載是很有用的。為此，您可以使用Prometheus blackbox-exporter（ https://github.com/prometheus/blackbox_exporter ），它允許通過 HTTP、HTTPS、DNS、TCP 和 ICMP 探測任何類型的端點。
（微）服務架構中的監控
如果你有一個（微）服務架構，集群中的多個單獨的工作負載相互通信，那么擁有關於這些流量的詳細指標和跟蹤非常很重要，這是為了解所有這些工作負載是如何相互通信的，以及問題或瓶頸可能在哪里。
當然，你可以監控所有工作負載中的所有內部流量，並將這些指標暴露給 Prometheus，但這相當耗費精力。像 Istio 這樣的服務網格，可以通過單擊（ https://docs.rancher.cn/docs/rancher2.5/istio/_index ）在 Rancher 中安裝，可以自動完成這項工作，並提供關於所有服務之間的流量的豐富的遙測數據。
真實用戶監控
監控所有內部工作負載的可用性和性能對於運行穩定、可靠和快速的應用程序至關重要。但這些指標只能向你展示部分情況。要想獲得一個完整的視圖，還必須知道你的最終用戶是如何實際感知的。為此，你可以研究各種真實用戶監控解決方案（ https://en.wikipedia.org/wiki/Real_user_monitoring ）。
安全監控
除了監控工作負載以檢測性能、可用性或可擴展性的問題外，還應該監控集群和運行到集群中的工作負載，這可以發現一些潛在的安全問題。一個好的起點是經常運行CIS 掃描（ https://docs.rancher.cn/docs/rancher2.5/cis-scans/_index ）並發出告警，檢查集群是否按照安全最佳實踐進行配置。
對於工作負載，你可以看看 Kubernetes 和 Container 安全解決方案，比如Falco（ https://falco.org/ ）、Aqua Kubernetes Security（ https://www.aquasec.com/solutions/kubernetes-container-security/ ）、SysDig（ https://sysdig.com/ ）。
設置告警
將所有的指標納入監控系統並在儀表盤中可視化是很棒的做法，但你也希望在出現問題時能主動提醒。
集成的 Rancher 監控已經配置了一套合理的告警，這些告警在任何 Kubernetes 集群中都是可用的。您應該擴展這些內容並且覆蓋您的特定工作負載和用例。
在設置告警時，應為所有至關重要的工作負載配置告警。但也要確保它們不會太頻發送告警通知。理想情況下，你收到的每一個告警都應該是因為一個需要你關注並需要解決的問題。如果你的告警一直在發送，但並不是那么關鍵，那么你就有可能開始完全忽略你的告警，然后錯過真正重要的告警。先開始關注真正重要的指標，比如說如果你的應用離線了就發出告警。修復所有開始出現的問題，然后開始創建更詳細的告警。
如果告警開始發送，但你暫時無法處理，也可以將告警靜默一定時間，以便以后查看。
您可以在Rancher 文檔（ https://docs.rancher.cn/docs/rancher2.5/monitoring-alerting/_index ）中找到更多關於如何設置告警和通知的信息。