PMM監控系統的使用思考

時間 2021-02-15

標籤 html node python mysql nginx web sql docker shell 數據庫欄目興趣愛好简体版

原文原文鏈接

PMM監控系統的使用思考

[TOC]html

爲何須要監控

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

爲何是PMM

這裏貼一個官方示例網址node

監控信息最全，開源的監控方案我用過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對實例進行彙總python

須要sudo權限

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

服務端很差拆分

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

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

修改Ova的虛擬機的Linux密碼後，訪問監控頁面也須要輸入密碼，agent端註冊也須要密碼。固然若是你不去修改Ova的密碼也沒問題web

服務端load高

這裏簡單說下PMM的架構
sql

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

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

解決思路

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

這裏主要是使用了prometheus配置文件中的relabel功能將__meta_consul_tags從新打標籤爲IP和PORT。shell

# 截取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語言。