PMM監控系統的使用思考
 

為什麼需要監控
檢視資料庫的趨勢，觀測當前QPS/TPS等資訊，這是最基本的了。開發或者領導問現在例項情況如何的時候，你還吭哧吭哧的登入跳板機，執行指令碼列印例項情況，一套操作下來半分鐘沒了，已經錯過現場
忽悠開發，開發問為啥這麼卡，看下監控，數值都正常—>你們的應用有問題。數值不正常—>我們已經注意到了問題，正在排查。
未雨綢繆，為擴容，提升機器效能（指收縮機器佔用，下線不用的例項）提供參考。負載比較高的要考慮擴容，效能差的要考慮優化。負載低的基本沒有連線的考慮要申請下線，
為什麼是PMM
這裡貼一個官方示例網址

監控資訊最全，開源的監控方案我用過zabbix,open-falcon,自己採集+ES+Kibana/grafana。採集的指標項很多是資料有誤，不及時，或者根本無資料。這樣的抽風的監控系統會給自己的分析帶來不自信，有存在的必要嗎？
介面最直觀，細節較多。你能想到的，想不到的都給你提供了。這對我這樣菜逼DBA來說是很重要的。可以根據監控圖形趨勢猜出例項crash或者高負載前後的資訊。資訊少的監控系統分析不出什麼花樣來，瞎摳浪費時間。
支援的資料庫型別最多，PG/MySQL(含PXC,MGR,TOKU,ROCKS)/MongoDB(含MONGOS)/OS。分析一個業務的OS/MONGODB/MYSQL效能要跨越兩三個web網站，煩不煩？
支援慢查詢分析,比annometer或者logstash的配置比起來簡單一萬倍。只要配置監控就可以，agent可以根據可調節的開關從IS或者慢日誌中捕捉慢查詢，高頻SQL
基於grafana，可以引入oauth或者Ldap方便對現有的組織結構進行引入，根據業務對於圖形進行分別授權。防止業務的活躍資訊，IP等有價值資訊被洩露
集成了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的架構
PMM架構

客戶端（agent）向consul的kv中註冊自己監控的服務資訊
儲存端(prometheus)從consul提供的服務發現服務地址去分別獲取agent註冊的資訊，然後去一個個抽取exporter產生的監控資料
Grafana通過讀取儲存端儲存的資料進行展示
圖中的地址不是直接對外暴露的，有一層nginx轉發
QAN的查詢語句分析功能是通過另外的QAN服務單獨進行分析並推入prometheus的
有一個MySQL例項用於儲存整套系統的元資料資訊。
還有一個大多數人不會投入使用的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上，這裡貼出來，相信大家會馬上明白

PMM監控系統的使用思考

只要在新增資料例項監控時指定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進行修改，如圖：

PMM監控系統的使用思考

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

需要注意的是在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目前還是個沒有對手的開源監控系統