京東MySQL監控之Zabbix優化、自動化

作者：王偉 2017-01-18 10:57:24

MySQL數據庫的使用更加普及、服務器量級飛速增長，這對京東MySQL DBA團隊的要求也越來越高。監控系統為數據庫管理和維護提供了精確的數據依據，是數據庫運維人員的千里眼和順風耳。

隨著京東業務的飛速發展， MySQL數據庫的使用更加普及、服務器量級飛速增長，這對京東MySQL DBA團隊的要求也越來越高。監控系統為數據庫管理和維護提供了精確的數據依據，是數據庫運維人員的千里眼和順風耳。

準確、及時、有效的監控，能夠使運維人員對生產服務系統運行情況了如指掌。通過分析獲得的監控信息，判斷被監控數據庫的運行狀態，對可能出現的問題進行預測，可以及時制定出適當的優化方案，從而保證整個系統正常、高效地運行。這也就在很大程度上保證了數據庫的安全性，避免了一些不必要的損失。所以，我們有必要對Zabbix系統有更加深刻的認識和理解。

一、Zabbix功能簡介

zabbix是一個基于WEB界面的提供分布式系統監視以及網絡監視功能的企業級的開源解決方案。zabbix能監視各種網絡參數，保證服務器系統的安全運營;并提供靈活的通知機制以讓系統管理員快速定位/解決存在的各種問題。這是百度百科上對zabbix上的一段定義，市面上的監控軟件很多，為什么選擇zabbix呢?我們來看一下它的幾個特點：

1、自動發現服務器和網絡設備。

這功能有點雞肋，在多種應用、多種設備混合場景下不實用，給zabbix整體運維管理帶來不便。這在實際使用中也存在各種問題，特別是在設備種類繁多、數量較大的情況下，不建議使用這個功能，zabbix監控添加設備結合CMDB來完成，這樣定位設備用途和添加模板將會更加準確;

2、底層自動發現。

這點很方便實用，比如自帶的自動發現系統分區、自動發現多網卡等。這個功能也是可以自定義的，比如監控一臺主機上的MySQL多實例服務，通過這個功能可以輕松搞定;

3、分布式的監控體系和集中式的web管理。

zabbix支持主動監控和被動監控模式(模式是相對于客戶端來說的，主動推監控數據給服務器端或是服務器端來拉取監控數據。建議使用主動模式，以便減輕服務器端壓力)，并且可以實現秒級監控，這點是一些監控軟件達不到的，但對重要業務來說，這點很重要;

4、支持范圍廣。

支持監控多種設備以及目前市面常見的各種OS、服務、日志等，可以使用自帶的agent監控，也有無agent監控等多種監控方法，如SNMP;

5、靈活的監控項設置。

zabbix本身已經支持很多常見的監控項，用戶也可以自己寫腳本來靈活自定義監控項，可以靈活組合多項報警閾值來準確報警，如監控硬盤的報警閾值可以設置為達到硬盤空間80%并且剩余空間低于50G時報警;

6、高水平的業務視圖監控資源，監控情況展示方面可以垂直、水平對比展示。

比如一套數據庫的分片，可以把所有主庫的某個性能指標做在一個Graphs中，可以方便對比各個主庫的負載情況是否均衡。也可以將多個Graphs做成一個Screens，然后在一個Screens中可以看到多種性能指標的各種情況，方便直觀的進行對比;

7、靈活的用戶權限設置。

支持自定義事件和郵件發送，也支持報警升級及日志審計;

8、基于zabbix報警的故障自愈。

Zabbix具有規范化的故障處理流程，對報警進行分級、分類，可以自動處理一些低級別、固化處理方法的故障，以達到快速恢復故障的效果。這點很重要，做的好可以***限度的保證業務的可用性穩定性，降低人為操作失誤風險以及人員成本;

9、強悍的內置API。

幾乎所有的zabbix服務器端web頁面配置操作，都可以通過他自身的API來完成，用戶可以非常方便地對它進行二次開發，以滿足自己的自動化運維需求。

Zabbix***的一個缺點應該就是沒有合并報警這個功能，在極端的情況下會出現報警風暴。不過很多監控軟件應該也沒有實現這個功能，用戶可以通過對它進行二次開發，以實現合并報警的效果。

二、Zabbix的優化

有不少企業使用zabbix監控的設備數量達到一兩百臺，運行半年后性能極差，打開監控圖需要很長時間，甚至打不開。這個問題比較常見，主要是因為沒有對zabbix做到合理的規劃和優化。如果能對zabbix做出合理的優化及架構上的規劃，zabbix監控幾萬臺設備還是很輕松的。

1、配置文件參數的優化

對于較大量級、海量設備的監控需要對zabbix相關參數進行調整，主要包含進程數量、緩存大小、超時時間三個方面，根據實際監控情況對zabbix自身的參數進行調整，禁用掉如VMware、Java等方面不使用的監控方式：

StartPollers=200 
StartPollersUnreachable=100 
StartTrappers=200 
StartPingers=100 
StartTimers=50 
StartDBSyncers=100 
Timeout=30 
TrapperTimeout=30 
StartProxyPollers=50 
HistoryTextCacheSize=1024M 
TrendCacheSize=1024M 
HistoryCacheSize=1024M

2、監控項和報警項的優化

監控項越多，對zabbix數據庫和它本身的性能的考驗就越大。精簡監控項，只監控必要的監控項，對運維沒有幫助的監控項可以取消，以減少系統資源的浪費。最典型的一個MySQL監控模板，是網上比較流行的percona官方出品的zabbix監控模板，監控項高達200多個，基本囊括show global status中的所有項目，好多監控項對運維來說是沒有意義的，卻對數據庫和zabbix自身性能產生嚴重的影響，當監控量級達到一定程度后，性能之差可想而知。

監控項的類型***使用數字，盡量避免使用字符。字符在數據庫中的存儲空間使用較大，在設置trigger時也相對麻煩，并且zabbix本身處理數字的效率要相對高。如果業務需要字符類型的監控項，可以適當的降低數據采集的時間間隔以提高處理效率。

Trigger中，正則表達式函數last(),nodata()的速度最快，min()、max()、avg()的速度最慢。在使用過程中，盡量選擇速度較快的函數。配置Trigger時，也應注意使用正確的邏輯，錯誤的邏輯可能導致數據庫查詢較慢的現象。

3、zabbix數據庫的優化

對數據庫進行分區是必須要做的，這便于刪除歷史數據。同時要關閉zabbix自身刪除歷史數據的設置。如果不做分區和刪除規則設置的話，隨著時間的推移，zabbix本身查詢和二次開發時查詢性能都會變得很低，甚至查詢不出數據。表分區的相關內容可以參考如下文件：https://www.zabbix.org/wiki/Docs/howto/mysql_partition。

關閉zabbix自身刪除歷史數據的設置SQL語句如下：

UPDATE config SET hk_events_trigger=60,hk_events_internal=60, 
hk_events_discovery=60,hk_events_autoreg=60,hk_audit=60,hk_sessions=60, 
hk_history=30,hk_history_mode=0, 
hk_history_global=1,hk_trends_mode=0, 
hk_trends_global=1,hk_trends=730,hk_services=60;

在頁面上設置位置為：

建議對歷史表中時間字段添加索引，在二次開發時這個字段用到的幾率比較大。建議對歷史數據表啟用innodb壓縮，具體做法如下：

/*啟用innodb壓縮，設置歷史表啟用壓縮*/ 
SET GLOBAL innodb_file_format='barracuda'; 
SET GLOBAL innodb_file_format_max='barracuda'; 
/*innodb_file_format和innodb_file_format_max要寫入my.cnf配置文件中*/ 
ALTER TABLE history ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE history_log ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE history_str ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE history_str_sync ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE history_text ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE history_uint ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE history_uint_sync ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE history_str ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE history_uint_sync ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE trends ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; 
ALTER TABLE trends_uint ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;

MySQL的版本建議使用PerconaDB5.6，設置thread_handling= pool-of-threads，啟用線程池。MySQL配置文件其他參數的優化這里不多說，可以參考如鏈接中的配置文件：http://wangwei007.blog.51cto.com/68019/1623329。

4、zabbix監控系統的架構優化

Zabbix架構的優化，主要原則是server端的壓力分擔到proxy端，proxy端的壓力分擔到agent端，監控項采用被動模式server端和proxy端均做高可用，防止單點造成監控不可用。以下是zabbix的架構和流程圖，僅供參考：

三、Zabbix自動化

運維自動化的真諦在于解放、簡化、方便運維人員的工作，提高效率，減少人為故障，基本運維思路是能自動堅決不手動，運維人員要培養自己“懶”這個好習慣。自動化的基礎是基礎信息的準確性和各種配置信息規則的規范化。

1、監控自動化規范

約定主機名規范，以期達到見名知意的效果，見到主機名大概知道這個設備是什么業務在使用，角色是什么。出問題時運維也可以快速的知道影響范圍和影響的嚴重性，方便運維。主機規范一般可以包含機房信息、業務信息、業務登記、業務中的角色信息、IP等相關信息;

約定主機組的名字，這點主要是方便相同業務、相同研發查看自己主機的監控，接收報警信息，也方便zabbix本身做組圖在screen中展現，做性能對比圖。比如數據庫的一個sharding集群，可以定義一個主機組，再做成Graphs匯總圖時方便研發直觀對比各個分片上的性能指標是否均衡;

報警等級的規范，這個主要是用于區分報警發給誰，怎么發，如何做報警升級等，還可以根據等級和監控項進行自動處理，等級較高的優先處理，較低的可以集中處理等;

主機維護暫停報警的規范。報警很重要，暫停監控需謹慎，不建議使用自帶的Maintenance預維護，主要是因為處于維護狀態的主機依然會顯示在監控首頁，雖然有標記，但是主機量大的時候不方便運維查看監控。建議進行二次開發，約定處于維護狀態的主機關閉trigger，維護結束后自動打開;

不建議手動的修改主機監控的各種配置，這樣容易遺忘，而且手工效率低下，容易造成各種設置和規則的混亂，后續問題堆積起來更加復雜，可維護性差。對zabbix進行二次開發時，配置的改動需要記錄修改的原因，生效的時間段等信息;監控的增刪改都自動完成，各種規范用程序來約束，由程序去自動完成。

2、部署配置的自動化

Zabbix的服務器端和客戶端的部署較為簡單，網上教程也比較多，把整個部署過程腳本化，然后和CMDB結合，自動批量部署和添加主機到監控中。部署過程可以參考此鏈接：http://wangwei007.blog.51cto.com/68019/1047953。

3、日常運維自動化

Zabbix自身提供了豐富的API接口，可以通過調用這些API，規范化操作配置zabbix。可以去http://www.zabbix.com/documentation.php查看各個版本的使用說明，包含zabbix的各種操作;

在API的說明中，也講述了zabbix數據庫中表的數據庫字典，每個字段代表什么，都有詳細說明。zabbix的二次開發和自動化運維主要是調用zabbix的API和讀取zabbix的數據庫來搞定的，不建議直接對zabbix數據庫原表進行直寫操作，一般也沒有必要。大家可以參考一下這個python寫的API：http://wangwei007.blog.51cto.com/68019/1139982。

4、報警的自動化處理

Zabbix可以在action中設置調用系統命令，在保證安全的情況下，可以使用這個功能來自動處理指定報警。設置如下圖：

用戶可以對常見的報警歸納總結，對一些固定處理方法的報警，把過程腳本化，當達到某個閾值的時候，自動的處理，比如清理固定位置的日志等，達到報警快速恢復的目的。

5、LLD的使用

Zabbix中的LLD是一個非常好的擴展，方便監控主機上多實例MySQL、Redis等服務、端口、硬盤多分區、多網卡等情況。用戶可以自定義discovery rules，可以自動的生成指定items、triggers、graphs等，較為靈活，極大地方便了監控的運維。

6、zabbix的二次開發

Zabbix的二次開發主要是對監控數據的二次分析，可以***限度地發揮這些數據的作用，從而更好的服務和指導運維。

Zabbix的詳細歷史數據按照數據采集的類型存在于以下的表中：

history,history_log,history_str,history_str_sync,history_sync,history_text,history_uint,history_uint_sync，events

zabbix的趨勢數據存放在trends,trends_uint兩張表中。趨勢數據是通過詳細的監控數據計算而來，每個監控項每個小時會產生最小值、***值和平均值。

利用這些歷史數據，可以自動生成一些性能參數的統計匯總報表，比如某個性能指標壓力較大的***00等，方便運維排查安全隱患。通過對對報警歷史進行分析，可以找出經常報警的監控項，對可用性進行評估等。

***，感謝我們DBA團隊老大樊健剛樊總對本文的指導和建議，同時也感謝他對MySQL監控這塊一直以來的重視和支持。

【本文是51CTO專欄作者王偉的原創文章，轉載請聯系作者本人獲取授權】

戳這里，看該作者更多好文

責任編輯：武曉燕來源： 51CTO博客