採用prometheus 監控mysql

1. prometheus 是什麼

開源的系統監控和報警工具,監控項目的流量、內存量、負載量等實時數據。mysql

它經過直接或短時jobs中介收集監控數據,在本地存儲全部收集到的數據,而且經過定義好的rules產生新的時間序列數據,或發送警報。經過其它api能夠將採集到的數據可視化。git

2. 怎麼實現監控

簡單的說,主要就是如下幾個步驟:github

  1. 配置待監控的各個服務器,在每一個服務器本地收集並存儲數據。若是採用第三方系統收集數據metrics,且數據不是prometheus時序對,則須要定義exporter將那些metrics export爲prometheus時序對。如今有不少已經定義好的官方或第三方的exporters有些軟件抓取的數據直接就是prometheus格式的。
  2. 找一臺服務器部署prometheus服務。而後修改配置文件,設定監控對象的ip地址和端口等。啓動prometheus,以後prometheus就會用輪詢的方式去各個服務器pull數據。
  3. 分析數據。prometheus提供了強大的查詢庫,能夠定製收集到的數據。prometheus提供了browser的結果呈現,也能夠配置使用第三方的數據可視化平臺。

部署監控mysql

以一個例子來講明部署流程。sql

安裝和運行prometheus

有不少種安裝方法,這裏我使用預編譯的二進制文件。到這裏下載。以後解壓,terminal中輸入./prometheus,回車啓動prometheus服務。docker

監控prometheus本身

打開解壓後的prometheus目錄,發現其中有個prometheus.yml文件。prometheus.yml是設置監控對象等的配置文件。打開prometheus.yml,默認的prometheus.yml的初始配置以下:數據庫

global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: 'codelab-monitor'

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # Override the global default and scrape targets from this job every 5 seconds.
    scrape_interval: 5s

    static_configs:
      - targets: ['localhost:9090']

這裏設定監控目標爲localhost:9090,即prometheus本身。瀏覽器打開localhost:9090,就能訪問prometheus提供的可視化界面。localhost:9090/metrics提供了全部的監控數據信息。其中有一條prometheus_target_interval_length_seconds,表示真實的數據獲取間隔,在prometheus首頁輸入它並回車,就能夠看到一系列的數據,它們有不一樣quantile,從0.01至0.99不等。quantitle表示有多少比例的數據在這個值之內。若是隻關注0.99的數據,能夠輸入prometheus_target_interval_length_seconds{quantile="0.99"}查詢。查詢還支持函數,好比count(prometheus_target_interval_length_seconds)可 以查詢數量。
若是想要查詢結果直接包含數量那個數據,建立一個prometheus.rules文件,在文件中定義這條規則,而後在prometheus.yml中配置rules文件。express

//prometheus.rules
test:prometheus_target_interval_length_seconds:count = count(prometheus_target_interval_length_seconds)

//prometheus.yml
# my global config
global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.
  evaluation_interval: 15s # By default, scrape targets every 15 seconds.
  # scrape_timeout is set to the global default (10s).

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
      monitor: 'codelab-monitor'

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  - "prometheus.rules"
  # - "second.rules"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # Override the global default and scrape targets from this job every 5 seconds.
    scrape_interval: 5s

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ['localhost:9090']

以後,就能夠直接輸入test:prometheus_target_interval_length_seconds:count查詢數據了。這裏rule比較簡單,若是有一些經常使用的但比較複雜的數據,均可以用rule的方法來定義獲取。api

監控mysql

修改prometheus.yml,在文件最後添加:瀏覽器

- job_name: 'mysql'

    # Override the global default and scrape targets from this job every 5 seconds.
    scrape_interval: 5s

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ['localhost:9104']
        labels:
          instance: db1

重啓prometheus服務:服務器

$ ./prometheus -config.file=prometheus.yml

再打開localhost:9090,查看Status -> Targets頁面下,就能夠看到配置的兩個target:一個是prometheus自己,StateUP,另外一個是mysql,StateDOWN,由於咱們尚未配置監控mysql的服務。

安裝並運行mysql exporter

在在這裏下載並解壓mysql exporter,或者直接使用docker:

$ docker pull prom/mysqld-exporter

mysqld_exporter須要鏈接到mysql,須要mysql的權限,須要先爲他建立用戶並賦予所需的權限:

CREATE USER 'mysqlexporter'@'localhost' IDENTIFIED BY 'msyqlexporter';
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost'
  WITH MAX_USER_CONNECTIONS 3;

而後在docker中運行exporter,其中DATA_SOURCE_NAME是環境變量,用於鏈接數據庫。

$ docker run -d \          
-p 9104:9104 \        
-e DATA_SOURCE_NAME="mysqlexporter:mysqlexporter@(localhost:3306)/data_store" prom/mysqld-exporter

此時再刷下localhost:9090/targets,就能夠看到mysql的state轉爲UP,即已經成功的監測了mysql。

總結

核心的幾個點:

  1. 數據收集
    1. 經過中介網關支持短期序列數據收集
    2. 經過http pull的形式採集時間序列
    3. 能夠經過自定義的rules產生新的時間數據系列(即定義一個rule,這個rule可能以已有的監控數據爲輸入,計算以後獲得加工後的監控數據。加入該監控規則後,再監控時就能直接拿到這個加工後的數據了),例如官網的這個例子
    4. 監控目標:服務發現/靜態配置。基於服務收集數據,而不是基於服務器收集數據。
  2. 數據存儲
    1. 不依賴分佈式存儲,單個服務器節點工做
    2. 多維度數據模型(鍵值對肯定的時間序列模型),解決了分佈式存儲的問題。就是說你的項目是分佈在多個容器(例如每一個服務器有一個容器)中,要得到整個項目的數據,須要監控這全部的容器。能夠利用cAdvisor等從每一個容器中拿數據,這樣獲得的數據是分散的,而後採用多維度數據模型配合查詢語法就能夠查到整個項目的流量數據。
  3. 數據查詢
    1. 靈活的查詢語言來利用上述維度數據模型
  4. 數據展現
    1. 各類展現面板:expression browser(無需配置)、Grafana等

侷限和適用

侷限:

  1. 單機缺點。由於它是以單個服務器節點工做爲基礎的,所以每一個節點要存儲監控數據,那麼每一個節點的監控數據量就會受限於存儲空間。
  2. 內存佔用量大(能夠配置改善)。由於集成了leveldb(高效插入數據的數據庫),在ssd盤下io佔用高。

適用於監控全部時間序列的項目。

相關文章
相關標籤/搜索