?1. 目前的困境

作為云平臺運維，對接了司內多個業務組的監控事宜。繁雜的業務帶來的是各類不同類型的指標處理，例如 LB/MySQL/MongoDB/Redis/Pika/Kafka 等數十類中間件或業務自行上報的 metrics。此場景下給我們帶來了一些挑戰

下面主要以四個方面展開討論:

• agent部署，監控 agent 在多云環境多種不同中間件維護方式下，如何部署?
•  統一采集，不同類型中間件的監控數據如何統一采集?
• 標簽統一，不同類型的metrics如何統一處理，確保監控視圖/告警能夠路由至正確的業務團隊？
• 安全采集，對于需要auth的中間件，agent需要有獨立的賬號密碼才能夠采集到監控指標，賬號密碼如何加密保障安全？

2. 優化之前采用 exporter

2.1 agent部署

基于混合云架構下，對于相同的中間件，不同業務組之間使用的方式是迥異的。例如mysql，A業務選擇了云廠提供的托管RDS，而B業務會選擇服務器上自建MySQL 使用mysql_exporter進行指標采集時，原生組件并不能提供一對多的方式，即單個exporter只能夠采集單個數據庫資源的指標。對于自建MySQL，我們將exporter部署在了中間件所在的服務器上；而對于云廠托管RDS，我們在每個VPC下選擇了一臺服務器，在這臺機器上啟動不同的exporter進程以監控多實例 因agent部署方式不統一，增大了當資源變更時的運維成本，對于監控的發現/下線等配置文件都需要人工維護。盡管使用了ansible編排監控配置文件，但是對于不同部署方式的資源，需要編寫多套playbook提供支撐

2.2 統一采集

各類不同中間件采用不同的監控agent，不同的agent使用邏輯也是迥異的，例如node_exporter是將實例信息通過file_sd方式寫入target到prometheus中讀取，而pika_exporter卻是將實例信息維護在一個單獨的配置文件中，由agent直接讀取配置抓取數據，prometheus只需要配置job

• node_exporter

[root@* ~]# cat /etc/prometheus/file_sd/node.yml |head -n 10
- labels:
  public_cloud: "huawei"  region: "***"  team_id: "***"  team_name: "***"  host_name: "***"  host_ip: "1.1.1.1"targets:
  - 1.1.1.1:9100

[root@ ~]# cat /var/lib/pika_exporter/pika.host

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

• pika_exporter

[root@ ~]# cat /var/lib/pika_exporter/pika.host

1.1.1.1:6300,passwd,cluster_name

[root@ ~]# cat/etc/prometheus/prometheus.yml

- job_name: 'pika_exporter'  scrape_interval: 30s
  static_configs:
    - targets: ['127.0.0.1:9099']

當agent類型有數十種時，運維成本急劇升高，工作變為由經驗和人力堆積的苦力活被監控資源類型：

• 采集器
• 服務器 node_exporter
• redis redis_exporter
• mysql mysql_exporter
• mongodb
• mongo_exporter
• ... ...

2.3 標簽統一

對于每個metrics，我們期望能夠進行溯源，定位到具體的業務下，這樣在監控視圖/告警時，才能夠精確定位到團隊，讓團隊聚焦于自己的監控告警。底層標簽的統一也方便了后續的上層運維應用能夠更好的抽象各類不同業務特性。使用prometheus，針對job或者job下的target附加業務相關lable，例如 team_id=***，team_name=***

標簽如何配置

回到上面說的問題，以MySQL為例，單個云廠的RDS實例需要啟用單獨的expoter進程采集數據，那么在prometheus配置時，lable只能附加在job層級。對于云廠提供的托管RDS/Redis/Mongo 等實例，部分宿主機相關指標，我們無法通過exporter進行采集。exporter采集的是中間件接口接口返回的數據，不具備采集中間件所在的宿主機指標的能力。例如無法獲取到CPU使用率/磁盤使用率/磁盤IOPS等指標 同時，對于一些資源指標，我們也無法使用社區的exporter進行收集，例如 LB/VPC 等相關云原生組件 當然，成熟的云廠會提供API或者它們定制的exporter用以獲取監控數據，但是metric/lable 與社區exporter完全不一致。即使我們能夠通過云廠exporter獲取到數據，但是并不能夠將lable使用prometheus精確的附加在每一個資源上。例如AWS提供的cloud watch，對接在prometheus時不需要配置target，那么lable只能夠寫在job層對所有資源附加相同的lable，不能滿足我們的需求

如果不能打平配置上的差異與使用不同方式獲取到的metric/lable的差異，不僅提高了運維復雜性，對于相同中間件的監控/告警 體驗是割裂開的，不夠完美。

2.4 安全采集

對于需要auth才能夠使用的中間件，我們需要維護一份密碼配置文件供exporter使用，而在服務器上明文保存密碼是不安全的

3. 優化之后采用 telegraf 采集

使用telegraf解決痛點 參考鏈接：https://github.com/influxdata/telegraf

3.1 agent部署 & 統一采集

對于常見的中間件資源，telegraf社區均已適配，可實現由統一的telegraf二進制包，同時啟動不同的systemd管理不同類型的中間件監控agent 并且telegraf input原生支持一對多，單機部署即可滿足對所有中間件資源的監控指標抓取

[root@ ~]# systemctl status telegraf-telegraf-mongo.service  telegraf-mysql.service  telegraf-pika.service   telegraf-redis.service

[root@ ~]# cat /etc/prometheus/prometheus.yml
  - job_name: "telegraf-mysql"    scrape_interval: 15s
    metrics_path: "/metrics"    static_configs:
      - targets:
          - 127.0.0.1:9274
  - job_name: "telegraf-pika"    scrape_interval: 15s
    metrics_path: "/metrics"    static_configs:
      - targets:
          - 127.0.0.1:9275

  - job_name: "telegraf-mongo"    scrape_interval: 15s
    metrics_path: "/metrics"    static_configs:
      - targets:
          - 127.0.0.1:9280

[root@ ~]# cat /etc/systemd/system/telegraf-mysql.service 
[Unit]
Description=Telegraf Exporter
After=network.target

[Service]
WorkingDirectory=/opt/apps/telegraf-mysql
ExecStart=/usr/local/bin/telegraf  --config /opt/apps/telegraf-mysql/telegraf.conf --config-directory /opt/apps/telegraf-mysql/telegraf.d
Restart=on-failure

[Install]
WantedBy=multi-user.target

3.2 標簽統一

telegraf的processors支持value mapping，可以依據已經存在的key-value映射新的lables到metrics中 參考鏈接：https://docs.influxdata.com/telegraf/v1.23/configuration/#metric-filtering

此處我們使用mapping構造了 team_id,team_name,instance_name三個lable，它會查詢所有抓取到的 mysql metrics中的lable，若存在server=1.1.1.1，則映射上述三個指定的key-values到metrics中 配置文件

[root@ ~]# cat /opt/apps/telegraf-mysql/telegraf.conf
[global_tags]  region = "***"
[agent]
  interval = "10s"  round_interval = true  metric_batch_size = 1000  metric_buffer_limit = 10000  collection_jitter = "0s"  flush_interval = "10s"  flush_jitter = "0s"  precision = "0s"  hostname = ""  omit_hostname = false [[outputs.prometheus_client]]
   listen = ":9274"

[[inputs.mysql]]
  gather_global_variables = true  gather_slave_status = true  interval_slow="10s"  servers = ["username:password@tcp(1.1.1.1:3306)/"]

[[processors.enum]]
  [[processors.enum.mapping]]
    tag = "server"    dest = "team_id"    default = "null"    [processors.enum.mapping.value_mappings]
      "1.1.1.1:3306" = "123"
[[processors.enum]]
  [[processors.enum.mapping]]
    tag = "server"    dest = "team_name"    default = "null"    [processors.enum.mapping.value_mappings]
      "1.1.1.1:3306" = "test-team"
[[processors.enum]]
  [[processors.enum.mapping]]
    tag = "server"    dest = "instance_name"    default = "null"    [processors.enum.mapping.value_mappings]
      "1.1.1.1:3306" = "test-instance"

測試

[root@ ~]# curl 127.0.0.1:9274/metrics|grep mysql_up{
mysql_up{instance_name="test-instance",region="***",server="1.1.1.1:3306",team_id="123",team_name="test-team"} 1

而配置文件的生成，需要編寫腳本去資源中心獲取到具體的實例信息，進行自動渲染。從而實現監控的自動發現。這依賴于運維需要有一個統一的資源平臺能夠對內服務，不多贅述。當使用同一個監控agent時，腳本的維護才會簡單，否則不同類型的中間件監控都需要編寫不同腳本來實現自動發現。

同時，telegraf支持多種不同的input數據輸入 對于aws cloud watch或者華為云的cloudeye，我們可以將他們先以job方式在prometheus抓取數據，此時不進行lable增添 而后通過telegraf的mapping和input prometheus data，利用從資源中心獲取到的key-valus，進行數據的二次格式化增加需要的lable，實現標簽的統一 參考鏈接：https://docs.influxdata.com/telegraf/v1.23/data_formats/input/

3.3 安全采集

可惜的是，telegraf原生也不支持對密碼的加密 好處是，telegraf各個組件代碼風格是統一的，不像各類exporter。對于telegraf的二次開發，只要實現對某個INPUT模塊的密碼編碼解碼，可以很快復用到其他INPUT模塊，高效實現各個不同中間件在使用監控時的密碼安全

4. 總結

本文是近期將監控采集器從 exporter 遷移到 telegraf 的一次總結，主要從 agent 部署、統一采集、標簽統一、安全采集四個方面，比較了優化前后的差異。

但 telegraf 也存在一些問題，telegraf 原生支持二百余個模塊，同時提供各類高級功能，實際使用中，發現某些模塊抓取的指標并不令人滿意。例如mysql_exporter中的up指標（探活），telegraf未進行采集 使用時可按需裁剪，保留需要的模塊，否則使用起來較重（二進制幾百M）。對于更多高級用法，需要進行一定的二次開發才能更好適配業務需求。同時 telegraf 的 Grafana 面板較少，因此我們需要花費點時間手工繪制。