捕獲診斷數據（）
當出現間歇性問題時需要盡可能多地收集所有數據而不只是問題出現時的數據雖然這樣會收集大量的診斷數據但總比真正能夠診斷問題的數據沒有被收集到的情況要好
在開始之前需要搞清楚兩件事
一個可靠且實時的觸發器也就是能區分什麼時候問題出現的方法
一個收集診斷數據的工具
診斷觸發器
觸發器非常重要這是在問題出現時能夠捕獲數據的基礎有兩個常見的問題可能導致無法達到預期的結果誤報（false positives）或者漏檢（false negatives）誤報是指收集了很多診斷數據但期間其實沒有發生問題這可能浪費時間而且令人沮喪而漏檢則指在問題出現時沒有捕獲到數據錯失了機會一樣地浪費時間所以在開始收集數據前多花一點時間來確認觸發器能夠真正地識別問題是劃算的
那麼好的觸發器的標准是什麼呢？像前面的例子展示的Threads_running 的趨勢在出現問題時會比較敏感而沒有問題時則比較平穩另外SHOW PROCESSLIST 中線程的異常狀態尖峰也是個不錯的指標當然除此之外還有很多的方法包括SHOW INNODB STATUS的特定輸出服務器的平均負載尖峰等關鍵是找到一些能和正常時的阈值進行比較的指標通常情況下這是一個計數比如正在運行的線程的數量處於freeing items狀態的線程的數量等當要計算線程某個狀態的數量時grep 的c 選項非常有用
$ mysql e SHOW PROCESSLIST\G | grep c State: freeing items
選擇一個合適的阈值很重要既要足夠高以確保在正常時不會被觸發又不能太高要確保問題發生時不會錯過另外要注意要在問題開始時就捕獲數據就更不能將阈值設置得太高問題持續上升的趨勢一般會導致更多的問題發生如果在問題導致系統快要崩潰時才開始捕獲數據就很難診斷到最初的根本原因如果可能在問題還是涓涓細流的時候就要開始收集數據而不要等到波濤洶湧才開始舉個例子Threads_connected 偶爾出現非常高的尖峰值在幾分鐘時間內會從 沖到 或者更高所以設置阈值為 也可以捕獲到問題但為什麼非要等到這麼高的時候才收集數據呢？如果在正常時該值一般不超過將阈值設置為 或者 會更好
回到前面關於Threads_running 的例子正常情況下的並發度不超過但是阈值設置為 並不是一個好注意很可能會導致很多誤報即使設置為 也不夠可能還是會有很多正常的波動會到這個范圍當並發運行線程到 的時候可能也會有少量堆積的情況但可能還沒到問題的引爆點但也應該在糟糕到一眼就能看出問題前就清晰地識別出來對於這個例子我們建議閥值可以設置為
我們當然希望在問題確實發生時能捕獲到數據但有時候也需要稍微等待一下以確保不是誤報或者短暫的尖峰所以最後的觸發條件可以這樣設置每秒監控狀態值如果Threads_running 連續 秒超過就開始收集診斷數據（順便說一句我們的例子中問題只持續了 秒就消失了這是為了使例子簡單而設置的 秒的故障不容易診斷而我們碰到過的大部分問題持續時間都會更長一些）
所以我們需要利用一種工具來監控服務器當達到觸發條件時能收集數據當然可以自己編寫腳本來實現不過不用那麼麻煩Percona Toolkit 中的ptstalk 就是為這種情況設計的這個工具有很多有用的特性只要碰到過類似問題就會明白這些特性的必要性例如它會監控磁盤的可用空間所以不會因為收集太多的數據將空間耗盡而導致服務器崩潰如果之前碰到過這樣的情況你就會理解這一點了
ptstalk 的用法很簡單可以配置需要監控的變量阈值檢查的頻率等還支持一些比實際需要更多的花哨特性但在這個例子中有這些已經足夠了在使用之前建議先閱讀附帶的文檔ptstalk 還依賴於另外一個工具執行真正的收集工作接下來會討論
[] []
From:http://tw.wingwit.com/Article/program/MySQL/201311/29700.html
