1. 程式人生 > >PMM監控系統的使用思考

PMM監控系統的使用思考

alt upd replace type 數據采集 auth python 領導 mon

PMM監控系統的使用思考

[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

配置好之後,就會生成上圖中IPPORT兩個標簽 \

然後對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監控系統的使用思考