ast 對比 ping 不定 reload key 容易 qps mysq

介紹

本文是一個使用ELK來監控mysql的介紹，基本監控了一些關鍵指標，當然根據業務的不同，可能有不同的指標需求，但使用該方法監控，原理不會變化，非常適合入門。

ELK是一個非常強大的軟件組合，在github上有開源，star數大的驚人，感興趣的朋友可以了解下，這套工具學習曲線比較陡峭，推薦使用本文提到的mysqlbeat這類簡單的工具作為采集工具開始，一開始先不使用官方提供的beat，一方面是因為默認的配置什麽數據都上報，浪費存儲空間，另一方面復雜的嵌套表結構（document）更增加了學習難度，更具體的原因後面還會提及。而本文涉及到的表結構（document）只有一層，說不定你輸入一個key:value，例如INNODB_PAGE_SIZE:16384，就把pagesize為16KB的記錄全部列出來了。但這並不意味著你不會掉到坑裏去，學好這套工具還是需要大量的學習和摸索，其實ELK的難點在於ES，建議可以讀一下它的原版教程ElasticSearch權威指南。

監控工具

mysqlbeat

mysqlbeat是一個高度可定制的mysql監控agent，通過查詢information_schema.global_status中部分字段，並上報到ElasticSearch進行存儲，並通過Kibana進行可視化展示。代碼量少，建議閱讀，github地址。

數據上報

安裝後主要對/etc/mysqlbeat/mysqlbeat.yml文件進行配置（不同平臺上路徑可能有差異），有以下設置項：

mysqlbeat：配置mysql賬號，上報間隔，查詢語句等
output：ElasticSearch集群的地址（也可以輸出到logstash），可以同時設多個，例如：hosts: ["192.168.1.1:9200", "192.168.1.2:9200"]

template：ElasticSearch mapping模板路徑，默認為/etc/mysqlbeat/mysqlbeat.template.json，定義了文檔字段（初學者可以理解為關系數據庫的表結構），如果你偶爾要添加或修改字段，請設置overwrite: true字段，同時需要在Kibana界面reload一下該模板
配置中最重要的是queries字段，定義了一系列SQL語句，mysqlbeat通過執行這些語句，會生成一張表，這張表就是你要監控的數據，它只有兩個字段VARIABLE_NAME和VARIABLE_VALUE，分別代表你要監控的監測名和監測值，其中value有兩種類型

第一種是差值類型，因為global status中的一些數據是不斷累加的，所以要得到1s內的數據，需要用當前時間取到的值減去前一個間隔取到的值，然後除以間隔的秒數，當然這些都不需要你來完成，你只需要在監測名後面加一個後綴__DELTA即可：CONCAT(VARIABLE_NAME, ‘__DELTA‘)

第二種是像內存值這樣的不需要進行差值操作的類型。
總之使用很簡單，看一下配置，然後馬上就try吧

數據展示

使用這個工具導出的數據很容易配置可視化，我目前使用的是標配Kibana作為UI，下圖是mysqlbeat可視化配置和官方beat可視化配置的一個對比

用ElasticSearch監控MySQL
對比

左圖X軸是時間軸，Y軸是QPS的平均值，非常清晰明了。再看右圖，我只展示了X軸，X軸是一個外部是時間軸，內部還嵌套了一個過濾器，這個效果卻是對垂直空間做了劃分，對於初學者來說非常不直觀，可以想象當初我為了實現這個展示是花了很多時間去摸索的，即便如此，也不能否認ElasticSearch本身非常強大的事實。

監控指標

QPS和TPS

用ElasticSearch監控MySQL
QPS and TPS

qps是每秒的查詢數，即information_schema.global_status中的QUESTIONS字段
tps是每秒的事務數，是information_schema.global_status中COM_ROLLBACK和COM_COMMIT之和連接
用ElasticSearch監控MySQL
連接

使用數據庫的時候會出現"mysql connection error"的錯誤，一般有兩個原因

連接數到達配置的最大值
內存或線程不足（每個連接對應一個線程）
所以需要設置如下幾個監控

THREADS_CONNECTED：當前連接數，對照MAX_CONNECTIONS，如超過總連接的80%，或陡然突增的情況，需要設置報警
ABORTED_CONNECTS：表示存在服務器拒絕client連接的情況，此時下面兩個指標中的一種或兩種會增長
CONNECTION_ERRORS_MAX_CONNECTIONS：連接失敗是因為當前連接超過最大連接數
CONNECTION_ERRORS_INTERNAL：主要用於排查連接失敗是因為內存或線程不足造成的參數
緩存

用ElasticSearch監控MySQL
緩存

緩存在互聯網時代的重要性不可估量，主流的兩個數據庫引擎InnoDB和MyISAM的緩存作用有所區別，前者的緩存包括了索引和實際數據，而MyISAM僅緩存了索引，它把數據緩存交給了操作系統，在這裏我們的監控原理一樣，只是字段有差別:

監控緩存使用率
監控緩存命中情況
緩存使用情況需要兩個參數，緩存使用大小和緩存總大小

MyISAM：KEY_BLOCKED_USED / (KEY_BLOCKED_UNUSED + KEY_BLOCKED_USED)
InnoDB：INNODB_BUFFER_POOL_PAGES_DATA / (INNODB_BUFFER_POOL_PAGES_FREE + INNODB_BUFFER_POOL_PAGES_DATA)
同樣，緩存命中情況也只需要緩存訪問量和磁盤訪問量兩個參數，這一組字段不好記，記住讀緩存次數的變量名比讀磁盤次數的變量名多個requests後綴就好了。

MyISAM：讀命中 KEY_READ_REQUESTS / (KEY_READS + KEY_READ_REQUESTS)；寫命中 KEY_WRITE_REQUESTS / (KEY_WRITE_REQUESTS + KEY_WRITES)
InnoDB：緩存命中 INNODB_BUFFER_POOL_READ_REQUESTS / (INNODB_BUFFER_POOL_READ_REQUESTS + INNODB_BUFFER_POOL_READS)
需要註意的是，緩存的讀/寫命中率應該以最近一段時間（比如10s）為基準（作者取的是累積值），這樣數據更真實，而基數太大會把數據壓得更平滑，不利於監測突發情況。

TODO

主從同步延遲，其實mysqlbeat已經實現了，只是老是出現類型沖突，所以就無法可視化，需要查代碼定位
mysql錯誤，這種以表格的形式展示更好，對錯誤語句、原因根據錯誤次數倒序展示
最慢的mysql語句，同樣是以表格形式展示
報警，使用ElastAlert的spike rule監控陡然增減的情況、frequency rule設置閾值，出現這些情況進行報警
latency，這種優先級比較低，一般上層接口的監控latency即可，因為一般情況下，mysql都是瓶頸。

用ElasticSearch監控MySQL