?1. 目前的困境

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

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

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

2. 優(yōu)化之前采用 exporter

2.1 agent部署

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

2.2 統(tǒng)一采集

各類不同中間件采用不同的監(jiān)控agent，不同的agent使用邏輯也是迥異的，例如node_exporter是將實例信息通過file_sd方式寫入target到prometheus中讀取，而pika_exporter卻是將實例信息維護在一個單獨的配置文件中，由agent直接讀取配置抓取數(shù)據(jù)，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']

當(dāng)agent類型有數(shù)十種時，運維成本急劇升高，工作變?yōu)橛山?jīng)驗和人力堆積的苦力活被監(jiān)控資源類型：

• 采集器
• 服務(wù)器 node_exporter
• redis redis_exporter
• mysql mysql_exporter
• mongodb
• mongo_exporter
• ... ...

2.3 標簽統(tǒng)一

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

標簽如何配置

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

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

2.4 安全采集

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

3. 優(yōu)化之后采用 telegraf 采集

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

3.1 agent部署 & 統(tǒng)一采集

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

[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 標簽統(tǒng)一

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

此處我們使用mapping構(gòu)造了 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

而配置文件的生成，需要編寫腳本去資源中心獲取到具體的實例信息，進行自動渲染。從而實現(xiàn)監(jiān)控的自動發(fā)現(xiàn)。這依賴于運維需要有一個統(tǒng)一的資源平臺能夠?qū)?nèi)服務(wù)，不多贅述。當(dāng)使用同一個監(jiān)控agent時，腳本的維護才會簡單，否則不同類型的中間件監(jiān)控都需要編寫不同腳本來實現(xiàn)自動發(fā)現(xiàn)。

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

3.3 安全采集

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

4. 總結(jié)

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

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