[TOC]

為什麽需要監控

1. 查看數據庫的趨勢，觀測當前QPS/TPS等信息，這是最基本的了。開發或者領導問現在實例情況如何的時候，你還吭哧吭哧的登錄跳板機，運行腳本打印實例情況，一套操作下來半分鐘沒了，已經錯過現場
2. 忽悠開發，開發問為啥這麽卡，看下監控，數值都正常—>你們的應用有問題。數值不正常—>我們已經註意到了問題，正在排查。
3. 未雨綢繆，為擴容，提升機器效能（指收縮機器占用，下線不用的實例）提供參考。負載比較高的要考慮擴容，性能差的要考慮優化。負載低的基本沒有連接的考慮要申請下線，

為什麽是PMM

這裏貼一個官方示例網址

1. 監控信息最全，開源的監控方案我用過zabbix,open-falcon,自己采集+ES+Kibana/grafana。采集的指標項很多是數據有誤，不及時，或者根本無數據。這樣的抽風的監控系統會給自己的分析帶來不自信，有存在的必要嗎？
2. 界面最直觀，細節較多。你能想到的，想不到的都給你提供了。這對我這樣菜逼DBA來說是很重要的。可以根據監控圖形趨勢猜出實例crash或者高負載前後的信息。信息少的監控系統分析不出什麽花樣來，瞎摳浪費時間。
3. 支持的數據庫類型最多，PG/MySQL(含PXC,MGR,TOKU,ROCKS)/MongoDB(含MONGOS)/OS。分析一個業務的OS/MONGODB/MYSQL性能要跨越兩三個web網站，煩不煩？
4. 支持慢查詢分析,比annometer或者logstash的配置比起來簡單一萬倍。只要配置監控就可以，agent可以根據可調節的開關從IS或者慢日誌中捕捉慢查詢，高頻SQL
5. 基於grafana，可以引入oauth或者Ldap方便對現有的組織結構進行引入，根據業務對於圖形進行分別授權。防止業務的活躍信息，IP等有價值信息被泄露
6. 集成了Orchestrator用於復制拓補管理和可視化（這個我也沒用過）

PMM又有哪些缺點

PMM 默認使用主機名作為唯一識別數據庫實例的關鍵字。

在docker環境下,單機單實例,實例名和主機名保持一致，比較方便，但是不對外展示IP和端口還是蹩腳。也有可能是我的視野比較窄，或許根本不需要。但是在我們這邊沒有數據庫微服務的情況下，IP和端口還是比較關鍵的信息點，而且單物理機多數據庫實例下的使用效果並不好。主要體現在無法使用IP對實例進行匯總

需要sudo權限

在某些權限管理比較嚴格的情況下，dba沒有sudo權限，無法運行pmm-client

服務端不好拆分

官方采用單節點Prometheus來存儲監控Metric，小環境還可以，數千數萬臺的情況下ova或者docker化的服務端容易爆盤。這個時候易於部署的ova或者docker分發方式反而變成了缺點。

ova分發方式修改ova密碼麻煩

修改Ova的虛擬機的Linux密碼後，訪問監控頁面也需要輸入密碼，agent端註冊也需要密碼。當然如果你不去修改Ova的密碼也沒問題

服務端load高

這裏簡單說下PMM的架構

1. 客戶端（agent）向consul的kv中註冊自己監控的服務信息
2. 存儲端(prometheus)從consul提供的服務發現服務地址去分別獲取agent註冊的信息，然後去一個個抽取exporter產生的監控數據
3. Grafana通過讀取存儲端存儲的數據進行展示
4. 圖中的地址不是直接對外暴露的，有一層nginx轉發
5. QAN的查詢語句分析功能是通過另外的QAN服務單獨進行分析並推入prometheus的
6. 有一個MySQL實例用於存儲整套系統的元數據信息。
7. 還有一個大多數人不會投入使用的Orchestrator

這裏顯然可以得出，在監控數據量增大，監控節點增多的情況下，整個docker或者ova都會被qan的分析和prometheus的讀寫拖慢

解決思路

使用relabel功能分離IP和端口信息，修改grafana頁面

這裏主要是使用了prometheus配置文件中的relabel功能將__meta_consul_tags重新打標簽為IP和PORT。

  # 截取IP和PORT zrz 20181112
  - source_labels: [__meta_consul_tags]
    separator: ;
    regex: .*,alias_([-\w:\.]+):.*
    target_label: IP
    replacement: $1
    action: replace
  - source_labels: [__meta_consul_tags]
    separator: ;
    regex: .*:([-\w:\.]+),.*
    target_label: PORT
    replacement: $1
    action: replace

為了找到這個功能，我花費了很長時間，需要使用正則的分段匹配和替換的方式進行截取。\

突破點在於Prometheus的管理web上，這裏貼出來，相信大家會馬上明白

只要在添加數據實例監控時指定ip加端口，當然最好自定義生成下客戶端的pmm.yml配置文件

vim /usr/local/percona/pmm-client/pmm.yml

server_address: 250.250.250.250 # 服務端的地址，若變更了端口，請加上端口
client_address: 1.1.1.1         # 本機IP
bind_address: 1.1.1.1           # 本機IP
client_name: 1.1.1.1            # 這裏通常會是主機名，但是建議改成IP，方便生成IP端口

# agent在本地添加數據庫監控實例時:
pmm-admin add mysql --socket /home/dba/heart/break1/mysqld.sock --user flattery --password dog 1.1.1.1:4306
pmm-admin add mysql --socket /home/dba/heart/break2/mysqld.sock --user at --password last 1.1.1.1:5306
pmm-admin add mysql --socket /home/dba/heart/break2/mysqld.sock --user have --password nothing 1.1.1.1:6306

配置好之後，就會生成上圖中IP和PORT兩個標簽 \

然後對granfana的variable進行自定義

label_values(mysql_up,IP)

label_values(mysql_up,PORT)

在對圖形的query進行修改，如圖：

到這裏，剩下的想必聰明的你就知道該怎麽做剩下的了。

需要註意的是在cross頁面，需要使用sum函數（可以省略by），可以對整個實例的QPS進行匯總求和。這裏的sum函數可以對實例級別的QPS進行匯總，而不是對時段內單實例進行匯總

tags功能需要使用查詢CMDB來實現，也就是根據業務對機器和實例進行匯總，然後查詢業務名傳給tags，然後查詢IP端口給tags，

拆分pmm-client

• 需要sudo權限的原因是某些Os級別的監控需要權限，而且pmm-client使用了supervisord對監控進程進行了照顧。這兩方面其實可以省略。那麽就需要修改代碼去掉這兩個方面就可以了。

• 官方使用了pmm-managed包對node_exporter,mysqld_exporter等的的添加進行了包裝，其中比較重要的是，監控的部分元數據采集到MySQL（連接方式，監控類型等），接收連接方式的配置並餵食給exporter，調用consul包對監控服務的發現進行了add,update,delete,對應了pmm-admin的purge,uninstall,repair等等命令

• 我不會go語言。

服務端拆分

可以從docker分發的/opt/entry.sh腳本入手，天不早了。這裏留給聰明的你 自己探索

服務端拆分可以（也是必須）解決如下問題：

• load高，把各個服務分到不同的機器上
• 監控數據爆盤，利用Prometheus的federate功能，也就是垂直拆分的方式，拆分promethus。或者將Prometheus的存儲換為可以分片的es,opentsdb等等

總結

• 如若解決了Pmm-client的IP和端口采集問題，pmm-server的拆分的難度，我相信Pmm的易用性會大大提升

• 雖然有上述問題，但pmm目前還是個沒有對手的開源監控系統

PMM監控系統的使用思考