海外多區下的監控系統，你了解幾分？

作者：陳少文 2022-05-29 08:13:05

安全數據安全

每個區域是一個獨立的對外提供服務的單元，具有獨立的數據存儲、K8s 集群、API 網關等。這種分區的服務拓撲，會給運維帶來很大挑戰，需要在每個區逐一進行變更。

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

責任編輯：武曉燕來源：問其

監控系統數據存儲