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

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

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

1、Zabbix功能簡介

zabbix是一個基於WEB界面的提供分佈式系統監視以及網絡監視功能的企業級的開源解決方案。zabbix能監視各類網絡參數，保證服務器系統的安全運營；並提供靈活的通知機制以讓系統管理員快速定位/解決存在的各類問題。這是百度百科上對zabbix上的一段定義，市面上的監控軟件不少，爲何選擇zabbix呢？咱們來看一下它的幾個特色：

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

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

二、底層自動發現。

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

三、分佈式的監控體系和集中式的web管理。

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

四、支持範圍廣。

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

五、靈活的監控項設置。

zabbix自己已經支持不少常見的監控項，用戶也能夠本身寫腳原本靈活自定義監控項，能夠靈活組合多項報警閾值來準確報警，如監控硬盤的報警閾值能夠設置爲達到硬盤空間80%而且剩餘空間低於50G時報警；

六、高水平的業務視圖監控資源，監控狀況展現方面能夠垂直、水平對比展現。

好比一套數據庫的分片，能夠把全部主庫的某個性能指標作在一個Graphs中，能夠方便對比各個主庫的負載狀況是否均衡。也能夠將多個Graphs作成一個Screens，而後在一個Screens中能夠看到多種性能指標的各類狀況，方便直觀的進行對比；

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

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

八、基於zabbix報警的故障自愈。

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

九、強悍的內置API。

幾乎全部的zabbix服務器端web頁面配置操做，均可以經過他自身的API來完成，用戶能夠很是方便地對它進行二次開發，以知足本身的自動化運維需求。

Zabbix最大的一個缺點應該就是沒有合併報警這個功能，在極端的狀況下會出現報警風暴。不過不少監控軟件應該也沒有實現這個功能，用戶能夠經過對它進行二次開發，以實現合併報警的效果。

2、Zabbix的優化

有很多企業使用zabbix監控的設備數量達到一兩百臺，運行半年後性能極差，打開監控圖須要很長時間，甚至打不開。這個問題比較常見，主要是由於沒有對zabbix作到合理的規劃和優化。若是能對zabbix作出合理的優化及架構上的規劃，zabbix監控幾萬臺設備仍是很輕鬆的。

一、配置文件參數的優化

對於較大量級、海量設備的監控須要對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

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

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

監控項的類型最好使用數字，儘可能避免使用字符。字符在數據庫中的存儲空間使用較大，在設置trigger時也相對麻煩，而且zabbix自己處理數字的效率要相對高。若是業務須要字符類型的監控項，能夠適當的下降數據採集的時間間隔以提升處理效率。

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

三、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。

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

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

3、Zabbix自動化

運維自動化的真諦在於解放、簡化、方便運維人員的工做，提升效率，減小人爲故障，基本運維思路是能自動堅定不手動，運維人員要培養本身「懶」這個好習慣。自動化的基礎是基礎信息的準確性和各類配置信息規則的規範化。

一、監控自動化規範

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

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

報警等級的規範，這個主要是用於區分報警發給誰，怎麼發，如何作報警升級等，還能夠根據等級和監控項進行自動處理，等級較高的優先處理，較低的能夠集中處理等；

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

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

二、部署配置的自動化

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

三、平常運維自動化

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。

四、報警的自動化處理

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

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

五、LLD的使用

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

六、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兩張表中。趨勢數據是經過詳細的監控數據計算而來，每一個監控項每一個小時會產生最小值、最大值和平均值。

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

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

本文首發運維幫微信公衆號。