1. 相關背景

待在工作崗位上，總得做點事，也想做點新鮮事。但并不是你想做就有機會去做，并能做好。

一個人做、還是能和大家一起做，最終的結果是不一樣的。這就涉及到時機，大家能否達成一致的動機。

今年是降本增效的一年，很多公司在裁員、減配降本。因此，對整個線上服務的負載情況匯總，精細化的監控數據有所需求。

為了合規，海外服務的架構分區，數據分散管理，以前很難想象可以集中數據。但是這種需求，現在有了解決辦法。

在內部的一些系統中，目前的監控系統無法程序化集成，無法通過規則拼接 URL 展示監控相關的數據。

對于終端用戶來說，監控能夠與業務形態相匹配，可以快速地找到業務相關的監控數據，將給業務帶來極大方便。

無論從公司預期背景，還是自身規范化需求出發，這都是一個時機成熟、可以嘗試推動的事情。

2. 海外服務的拓撲

對于海外服務，我們需要根據業務發展戰略，選擇區域部署服務。比如，如果準備在歐洲開展業務，那么就需要選擇華為、AWS 等云廠在該地區提供的云服務作為基礎設施。對于面向全球的業務，需要在很多區域建設服務節點，包括新加坡、日本、印度、美西等。由于各地區的數據保護條例，不允許將當地的數據傳輸到其他地區，因此數據和服務只能本地化。

每個區域是一個獨立的對外提供服務的單元，具有獨立的數據存儲、K8s 集群、API 網關等。這種分區的服務拓撲，會給運維帶來很大挑戰，需要在每個區逐一進行變更。在 面向全球的鏡像分發網絡[1] 一文中，我描述了跨地區構建的全球性運維網絡。如下圖:

基于公網，通過 StrongVPN、WireGuard 等軟件構建企業內網，可以實現在一個中心區域對全區的控制。這種控制包括，全區的應用發布、流量控制、鏡像分發、監控告警等。

在打通全區內網之后，我們接著對監控從三個方面進行了調整，分別是基礎資源監控，Kubernetes 監控，業務數據監控。其中，基礎資源和 Kubernetes 屬于短周期監控數據，而業務數據屬于長周期監控數據。短周期監控數據，需要補齊足夠的標簽方便業務人員過濾查詢，使用 Prometheus 監控即可。而長周期監控數據，采用的是 Thanos 方案，避免 Prometheus 查詢長周期數據時導致云主機宕機。

3. 基礎監控

在每個區域僅有一個 Prometheus 拉取全部基礎資源的監控數據，這些基礎資源包括云主機、Redis、MySQL 等中間件。直接上 Prometheus 的配置:

cat /etc/prometheus/prometheus.yml

- job_name: "node_exporter"
    file_sd_configs:
      - refresh_interval: 1m
        files:
          - "/etc/prometheus/file_sd/node*.yml"

  - job_name: 'mongo_exporter'
    file_sd_configs:
      - refresh_interval: 1m
        files:
          - "/etc/prometheus/file_sd/mongo*.yml"

  - job_name: 'elasticsearch_exporter'
    file_sd_configs:
      - refresh_interval: 1m
        files:
          - "/etc/prometheus/file_sd/es*.yml"

通過 file_sd_configs 指定 Prometheus 自動發現服務的目錄，通過 refresh_interval 指定 Prometheus 重新加載配置文件的周期，當有新的服務需要添加監控時，只需要修改所屬類型的資源列表即可。下面接著來看資源列表的定義:

cat /etc/prometheus/file_sd/node-prod.yml

- labels:
    region: "region-a"
    team_id: 123
    host_name: "a-b-c"
    host_ip: "0.0.0.0"
  targets:
  - 0.0.0.0:9100

如下圖，每個區一個 Prometheus 拉取監控數據，在中心區域通過 Thanos Query 匯總全部的監控數據，提供全區的監控數據查詢能力。

最終在 Grafana 上需要呈現兩個面板，一個是資源的匯總，一個是資源的詳情。如下圖是基礎資源匯總的面板:

通過匯總面板，我們能夠知道指定區域有多少資源、各個資源的負載情況。通過 Thanos Query 匯總數據源，我們能夠知道全區的資源概況。

4. Kubernetes 監控

對于 Kubernetes 監控，我們采用的部署策略是，每個集群安裝一個 Prometheus 僅存儲 3d 的數據，不進行持久化。在每個區域部署一個 Thanos Query 匯總全部 Kubernetes 的監控數據。下圖是相關拓撲：

根據社區的 Prometheus Helm Chart 包，我們新增了 Thanos Sidecar 重新打包之后，推送到內部 Habor 鏡像倉庫。新增集群時，只需要進行兩步操作：

• 安裝 Prometheus

export HELM_EXPERIMENTAL_OCI=1
helm chart pull harbor.chenshaowen.com/monitor/prometheus:15.0.1
helm chart export harbor.chenshaowen.com/monitor/prometheus:15.0.1
cd prometheus
kubectl create ns monitor
helm -n monitor install prom-k8s --set server.global.external_labels.cluster=cluster-1  --set server.global.external_labels.region=region-1 .

這里需要注意的是，通過 external_labels.cluster 給每個 Kubernetes 集群一個唯一的名字。

• 在 Thanos Query 中添加查詢 API可以參考前面的文檔 使用 Thanos 集中管理多 Prometheus 實例數據[2]。

在 Grafana 面板上，我們提供了兩個層級的視角: 分區和全區的數據源，匯總和詳情的面板。如下圖是其中的一個匯總面板:

5. 業務數據監控

業務數據主要是業務自行上報、關注的數據，比如，用戶登錄、下單、支付等。這類數據異構，無法統一進行管理，我們提供統一的解決方案、Grafana

服務，由業務自行繪圖即可。

這里采用的是 Thanos 方案，參考: Thanos 進階使用指南[3] 。

下面是部署拓撲圖:

下面是查詢長周期數據：

6. 總結

本篇主要是介紹了最近在做的一些工作，針對海外多區場景，我們將監控分為三層，基礎監控、Kubernetes 監控、業務監控數據。其中基礎監控，包括云主機、Redis 中間件等，而 Kubernetes 主要是面向應用，業務數據屬于業務關系的上報數據。

針對這三種層次的劃分，分別提供了三種部署的方案，滿足業務對監控查詢的需求。

參考資料

[1]面向全球的鏡像分發網絡:

https://www.chenshaowen.com/blog/a-global-images-distribution-network.html

[2]使用 Thanos 集中管理多 Prometheus 實例數據: https://www.chenshaowen.com/blog/manage-multiple-prometheus-using-thanos.html

[3]Thanos 進階使用指南: https://www.chenshaowen.com/blog/an-advanced-user-guide-about-thanos.html