監控作為邊緣計算基礎設施的重要組成部分，是邊緣穩定性的基本保障。本文主要介紹火山引擎邊緣計算的監控實踐，分享火山引擎如何進行監控技術選型以及構建監控服務體系。主要內容如下：
邊緣計算監控初衷
基於 Prometheus 的監控系統
落地實踐
總結
01 邊緣計算監控初衷
監控作為邊緣計算基礎設施的重要組成部分，是邊緣穩定性的基本保障。在面對低時延、高頻寬、異構匯聚等特點的邊緣環境時，如何更加清晰的展現出邊緣叢集的執行狀態，應對邊緣環境複雜多變的線上挑戰？為此，火山引擎邊緣計算需要構建一套完善的邊緣計算監控和服務體系。
02 基於 Prometheus 的監控系統
火山引擎邊緣計算採用了雲原生架構，而 Prometheus 作為雲原生時代的指標監控利器，有其先天的優勢。相較於其他監控方案，Prometheus 具有以下優點：
原生支援 Kubernetes（以下簡稱 K8s） 監控，具有 K8s 物件服務發現能力，而且核心元件提供了 Prometheus 的採集介面；
基於 HTTP 的 pull 方式採集時序資料，可以滿足邊緣多叢集的監控需求；
無依賴儲存，支援 local 和 remote 儲存模式；
提供有資料查詢語言 PromQL，使用者可以直接透過 PromQL 從 Prometheus 裡查詢到需要的聚合資料。
支援多種多樣的圖表和介面展示，比如 Grafana 等。
基於 Prometheus 的監控系統的架構如圖所示，這裡詳細分享一下資料來源和 Prometheus Server 兩部分。
資料來源
在監控系統中，資料來源部分包含：
node-exporter
：採集物理節點指標；
kube-state-metrics
：採集k8s相關指標，包括資源使用情況，以及各種物件的狀態資訊；
cadvisor
：採集容器相關指標；
apiserver， etcd， scheduler， k8s-lvm，gpu 等核心元件的監控資料；
其他自定義 metrics，透過在 pod yaml 檔案 annotations 新增 prometheus。io/scrape： “true” 可實現自動抓取提供的 metrics；
Prometheus Server
Prometheus Server 是 Prometheus 最核心的模組。它主要包含抓取、儲存和查詢這3個功能：
抓取
：Prometheus Server 透過服務發現元件，週期性地從 Exporter 中透過 HTTP 輪詢的形式拉取監控指標資料。
儲存
：抓取到的監控資料透過一定的規則清理和資料整理（抓取前使用服務發現提供的 relabel_configs 方法，抓取後使用作業內的 metrics_relabel_configs 方法），把得到的結果儲存到新的時間序列中進行持久化。
查詢
：Prometheus 持久化資料以後，客戶端就可以透過 PromQL 語句對資料進行查詢了。
03 落地實踐
整體監控架構
邊緣計算基於 Prometheus、M3DB、自研 Metrix 等構建起一套監控架構，架構圖如下：
整個邊緣計算監控架構主要由資料採集、Prometheus、M3DB、Grafana、Metrix 幾個核心模組構成。
資料採集
Prometheus 對接元件監控資訊通常使用 exporter。exporter 不會主動推送監控資料到 server 端，而是等待 server 端定時來收集資料，即所謂的主動監控。邊緣計算使用的 exporter 包含：node_exporter、xlb_exporter、kubevirt-exporter 等。然後透過 Endpoints 物件定義需要監控的裝置IP及埠，Prometheus Pod 根據 ServiceMonitor 配置向分佈在各裝置上的 exporter 拉取 metrics 資料；
Prometheus
Prometheus Pod 將採集上來的資料根據 record-rules 進行 relabel、預聚合等操作，然後將所有資料打上 externalLabels（例如 cluster： bdcdn-bccu）remote write 寫入遠端的 M3DB；
M3DB
M3DB 是分散式時序資料庫，實現了 Pometheus 的 remote_read 和 remote_write 介面，同時支援 PromQL 等查詢語言。我們使用了 M3DB 作為儲存邊緣計算相關的監控資料，用於對接報警及展示。
Metrix 和 Grafana
透過 PromQL 語句向 M3DB 查詢資料，對接報警系統 Metrix 和檢視展示。
監控元件
透過以 Prometheus 為主的若干元件實現 K8s 全元件監控及業務監控，元件列表如下：
監控元件
功能點
prometheus
一套開源的監控&報警&時間序列資料庫的組合；
prometheus-adapter
轉換成 prometheus 的監控；
grafana
一個開源的度量分析與視覺化套件；
cAdvisor
機器上的資源及容器進行實時監控和效能資料採集，包括 CPU 使用情況、記憶體使用情況、網路吞吐量及檔案系統使用情況。現在已經整合到 kubelet 裡了；
node-exporter
收集 *NIX 系統中硬體、系統指標；
eventrouter
事件採集，可以採集叢集中的 event 到 es 中；
blackbox-exporter
主動監測主機與服務狀態；
儲存 M3DB
分散式時序資料庫；
Metrix
自研產品，用於報警；
儲存後端
儲存後端主要是 M3DB。M3DB 是原生的分散式時序資料庫，提供高度靈活和效能的聚合服務、查詢引擎等。M3DB 能夠透過提供不同的元件進行分離，讓分散式時序資料庫進行很好的擴充套件。
分散式數序資料儲存
（M3DB）：提供可水平擴充套件的時序資料儲存和反向索引；
一個 Sidecar 程式
（M3Coordinator）：可以使 M3DB 作為 Prometheus 的遠端儲存使用；
分散式查詢引擎
（M3Query）：支援 PromQL， Graphit 和 自研的 M3Query 語法；
聚合服務
（M3Aggregator）：對資料進行聚合和降級，以實現對不同指標執行不同儲存策略。
監控指標
K8s 的資源指標分類：
資源指標
：metrics-server 內建 API；
自定義指標
：透過 Prometheus 來採集，需要元件 k8s-prometheus-adapter；
（1）metrics-server：API server
kubectl api-versions 中預設不包含 metrics。k8s。io/v1beta1；
使用時需要新增 kube-aggregator 字首；
可以使用 kubectl top nodes 來獲取資訊。
（2）自定義指標
如 node_exporter 用來暴露 node 資訊，當然還有其他的 exporter；
PromQL 查詢語句，不能直接被 K8s 直接解析，需要透過 kube-state-metrics 元件轉 k8s-promethues-adpater 轉為 Custom Metrics API；
（3）HPA --- 基於資源值指標的伸縮
指定 Deployment、ReplicaSet 或 ReplicationController，並建立已經定義好資源的自動伸縮器。使用自動伸縮器可以根據需要自動增加或減少系統中部署的 pod 數量。
Metrics Server
：叢集級別的核心資源使用聚合器，透過各個節點的 /stats/summary 介面提供的資料來收集節點和 Pod 的 CPU 和記憶體使用情況。Summary API 是一種記憶體高效的 API，用於將資料從 kubelet/cAdvisor 傳遞到 Metrics Server。
API Server
：聚合 Metrics Server 提供的核心資源指標，透過 metrics。k8s。io/v1beta1 API提供給 HPA 做自動擴縮。
同時，我們採用 Grafana 將採集的資料進行查詢和視覺化。透過對系統拆解，分別在物理機、網路、K8s、儲存等層級做了監控匯聚及展示。以上是整個邊緣計算監控服務體系的主要模組。
04 總結
回顧一下本文介紹的主要內容：
首先，介紹了邊緣計算場景下的監控，包括邊緣計算監控場景面臨的挑戰及監控的重要性；
然後，介紹瞭如何實現邊緣計算的監控，基於 Prometheus 的監控系統；
最後，介紹了邊緣計算監控的落地實踐場景，包括監控架構及監控元件、儲存後端、監控指標等；
基於 Prometheus 構建的監控系統，不僅滿足了多樣化業務對監控的需求，還提升了火山引擎邊緣計算對邊緣叢集的管控、運維能力。而 Prometheus 作為新生代的開源監控系統，已成為雲原生體系的事實標準，也證明了其設計很受歡迎。
