考慮 Kubernetes 監控的概念，熟悉 Prometheus 工具，並討論警報。
監控這個話題浩如煙海，不是一篇文章就能拆解的。 本文的目的是提供工具、概念和方法的概述。
文章的材料是擠壓自 。 如果您想參加完整的課程 - 報名參加以下課程 .
Kubernetes 集群中監控的內容
物理服務器。 如果Kubernetes集群部署在其服務器上，您需要監控其運行狀況。 Zabbix 處理這個任務； 如果你和他一起工作，那麼你不需要拒絕，不會有任何衝突。 Zabbix 監控我們服務器的狀態。
讓我們繼續進行集群級別的監控。
控制平面組件： API、調度程序等。 至少，您需要確保服務器或 etcd 的 API 大於 0。etcd 可以返回很多指標：通過其旋轉的磁盤、通過其 etcd 集群的運行狀況等等。
碼頭工人 很早以前就出現了，大家都清楚它的問題：很多集裝箱會出現凍結等問題。 因此，Docker本身作為一個系統，也應該受到控制，至少在可用性方面。
DNS。 如果集群中的 DNS 宕機，那麼整個 Discovery 服務也會隨之宕機，pod 之間的調用也會停止工作。 在我的實踐中，沒有出現這樣的問題，但這並不意味著不需要監控DNS的狀態。 請求延遲和一些其他指標可以在 CoreDNS 上跟踪。
入口。 有必要控制入口（包括入口控制器）作為項目入口點的可用性。
集群的主要組件已經被拆除——現在讓我們深入到抽象層面。
看起來應用程序在 Pod 中運行，這意味著它們需要受到控制，但實際上並非如此。 Pod 是短暫的：今天它們在一台服務器上運行，明天在另一台服務器上運行； 今天有 10 個，明天有 2 個。因此，沒有人監視這些 Pod。 在微服務架構中，控制整個應用程序的可用性更為重要。 特別是，檢查服務端點的可用性：有什麼作用嗎？ 如果應用程序可用，那麼它背後會發生什麼，現在有多少個副本 - 這些是第二個問題。 無需監視單個實例。
在最後一級，您需要控制應用程序本身的運行，獲取業務指標：訂單數量、用戶行為等。
普羅米修斯
監控集群的最佳系統是 。 我不知道有什麼工具可以在質量和易用性方面與 Prometheus 相媲美。 它非常適合靈活的基礎設施，因此當他們說“Kubernetes 監控”時，他們通常指的是 Prometheus。
開始使用 Prometheus 有多種選擇：使用 Helm，您可以安裝常規 Prometheus 或 Prometheus Operator。
- 普通的普羅米修斯。 他一切都很好，但是你需要配置 ConfigMap - 事實上，編寫基於文本的配置文件，就像我們之前在微服務架構之前所做的那樣。
- Prometheus Operator 更分散一些，內部邏輯更複雜一些，但使用它更容易：有單獨的對象，抽像被添加到集群中，因此它們更方便控制和配置。
要了解該產品，我建議先安裝常規的 Prometheus。 您必須通過配置來配置所有內容，但這將是有益的：您將弄清楚什麼屬於什麼以及它是如何配置的。 在《Prometheus Operator》中，您可以立即提升到更高的抽像水平，但如果您願意，您也可以深入研究。
Prometheus 與 Kubernetes 集成良好：它可以訪問 API Server 並與之交互。
Prometheus 很受歡迎，這就是為什麼大量應用程序和編程語言都支持它。 需要支持，因為 Prometheus 有自己的指標格式，要傳輸它，您需要應用程序內的庫或現成的導出器。 而且這樣的出口商還有不少。 例如，PostgreSQL Exporter：它從 PostgreSQL 獲取數據並將其轉換為 Prometheus 格式，以便 Prometheus 可以使用它。
普羅米修斯架構
普羅米修斯服務器 是後端，普羅米修斯的大腦。 指標在這裡存儲和處理。
指標存儲在時間序列數據庫（TSDB）中。 TSDB並不是一個單獨的數據庫，而是嵌入在Prometheus中的Go語言的一個包。 粗略地說，一切都在一個二進製文件中。
不要在TSDB中長期存儲數據
Prometheus 基礎設施不適合長期存儲指標。 默認保留期限為 15 天。 您可以超出此限制，但請記住：在 TSDB 中存儲的數據越多、存儲時間越長，消耗的資源就越多。 在 Prometheus 中存儲歷史數據被認為是不好的做法。
如果你有巨大的流量，指標的數量是每秒數十萬，那麼最好按磁盤空間或按週期限制它們的存儲。 通常，“熱點數據”存儲在 TSDB 中，只需幾個小時即可完成指標。 對於更長的存儲，外部存儲是在那些真正適合這樣做的數據庫中使用的，例如InfluxDB、ClickHouse等。 我看到了更多關於 ClickHouse 的好評。
Prometheus Server 在模型上工作 拉：他尋求我們為他提供的那些端點的指標。 他們說：“轉到 API 服務器”，他每隔 n 秒就去那裡並獲取指標。
對於在抓取周期之間出現的生命週期較短的對象（作業或 cron 作業），有一個 Pushgateway 組件。 來自短期對象的指標被推入其中：作業已啟動，執行操作，將指標發送到 Pushgateway 並完成。 一段時間後，Prometheus 會按照自己的節奏下來並從 Pushgateway 獲取這些指標。
要在 Prometheus 中配置通知，有一個單獨的組件 - 警報管理器。 以及警報規則。 例如，如果服務器 API 為 0，則需要創建警報。當事件觸發時，警報將傳遞到警報管理器以進一步調度。 警報管理器具有相當靈活的路由設置：一組警報可以發送到管理員的電報聊天室，另一組警報發送到開發人員的聊天室，第三組警報發送到基礎設施工作人員的聊天室。 通知可以發送到 Slack、Telegram、電子郵件和其他渠道。
最後，我會告訴你普羅米修斯的殺手級功能 - 發現。 使用Prometheus時，不需要指定監控對象的具體地址，設置它們的類型就足夠了。 也就是說，你不需要寫“這裡是IP地址，這裡是端口-監視器”，而是需要確定通過什麼原則來找到這些對象（目標 - 目標）。 Prometheus 本身會根據當前處於活動狀態的對象提取必要的對象並將其添加到監控中。
這種方法非常適合Kubernetes 結構，其中一切都是浮動的：今天有10 台服務器，明天有3 台。為了不每次都指定服務器的IP 地址，他們寫了一次如何找到它- 發現會做到這一點。
普羅米修斯語言被稱為 普羅姆QL。 使用這種語言，您可以獲取特定指標的值，然後對其進行轉換，基於它們構建分析計算。
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)普羅米修斯網絡界面
Prometheus 有自己的、相當簡約的 Web 界面。 僅適合調試或演示。
在表達式行中，您可以使用 PromQL 語言編寫查詢。
警報選項卡包含警報規則，它們具有三種狀態：
- inactive - 如果警報當前未激活，即一切正常，但不起作用；
- 待處理 - 這是警報有效但發送尚未通過的情況。 設置延遲是為了補償網絡閃爍：如果指定的服務在一分鐘內上升，那麼警報不應響起；
- 觸發是警報亮起並發送消息時的第三種狀態。
在“狀態”菜單中，您可以訪問有關 Prometheus 的信息。 還有一個到我們上面談到的目標（targets）的過渡。
有關 Prometheus 接口的更詳細概述，請參閱 .
與 Grafana 集成
在 Prometheus Web 界面中，您不會找到漂亮且易於理解的圖表來從中得出有關集群狀態的結論。 為了構建它們，Prometheus 與 Grafana 集成。 我們得到這樣的儀表板。
設置 Prometheus 和 Grafana 集成一點也不困難，您可以在文檔中找到說明： 好吧，我就這樣結束吧。
在接下來的文章中，我們將繼續監控主題：我們將討論使用 Grafana Loki 和替代工具收集和分析日誌。
作者：Marcel Ibraev，認證 Kubernetes 管理員，公司執業工程師 、演講者和課程開發者 Slurm。
來源： www.habr.com