1. 相關背景

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

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

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

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

在內部的一些系統(tǒng)中，目前的監(jiān)控系統(tǒng)無法程序化集成，無法通過規(guī)則拼接 URL 展示監(jiān)控相關的數據。

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

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

2. 海外服務的拓撲

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

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

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

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

3. 基礎監(jiān)控

在每個區(qū)域僅有一個 Prometheus 拉取全部基礎資源的監(jiān)控數據，這些基礎資源包括云主機、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 自動發(fā)現服務的目錄，通過 refresh_interval 指定 Prometheus 重新加載配置文件的周期，當有新的服務需要添加監(jiān)控時，只需要修改所屬類型的資源列表即可。下面接著來看資源列表的定義:

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

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

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

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

4. Kubernetes 監(jiān)控

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

根據社區(qū)的 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 面板上，我們提供了兩個層級的視角: 分區(qū)和全區(qū)的數據源，匯總和詳情的面板。如下圖是其中的一個匯總面板:

5. 業(yè)務數據監(jiān)控

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

服務，由業(yè)務自行繪圖即可。

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

下面是部署拓撲圖:

下面是查詢長周期數據：

6. 總結

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

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

參考資料

[1]面向全球的鏡像分發(fā)網絡:

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