人(通常)是盲目的，自信不等於理性。

一個簡單網路設備監控(ping)的問題，困擾我好一陣了。

由於網路有瞬斷可能的特性，所以在20~30秒內同時處理500+個網路設備的回應情形，偶有(大量)斷線但隨即恢復的情形發生多視為正常合理。

前些日子因為寫了一個統計報表，發現有部分每日例行長時間中斷的設備會有怪異情形發生，也就是明明設備一直都是斷線狀態，卻偶而會出現線路恢復然後又馬上斷線的紀錄。

(人是盲目的，自信不等於理性)
一開始覺得不可能，因為一整天都沒事，為何只有半夜或凌晨才偶爾會出問題，一定是網路的問題，我的程式一定沒錯!

(科學辦案，尋找代罪羔羊)
是Cron有問題嗎? 不可能! 那是Linux系統的部份。 那麼應該是DBM::Deep，我(始終)對它沒有足夠的信心，更新DBM::Deep版本-沒用，於是改成DBD::SQLite，但怪怪的情形還是一樣存在，再更新DBD::SQLite版本，還是一樣，我是見鬼了嗎?

(反求諸己，但還是半信半疑)
是Primary Key沒設好嗎? 是執行太快嗎? sleep個1秒試看看? 沒用! 是DBIx::Class這個ORM內部處理鎖定的邏輯有問題嗎? 我該換成DBD::mysql嗎?

我能信賴什麼? 到底哪裡可能出錯? 我沒有答案!

(死馬當活馬醫，完全不知道原因為何? 只能說沒有頭緒... 慢，到底發生了什麼事!)
我為什麼不去觀察了解到底發生了什麼事，到底從頭到尾的執行過程中，真如我所預期的嗎? 真的每2分鐘檢查一遍，每次檢查不超過1分鐘嗎?

就算大部分是正常的，我也要看看什麼是'正常的'。

原來，不知道從何時開始? 每次檢查所需執行時間已超過2分鐘，往往一個檢查還沒完，另一個排程的檢查又開始，兩個檢查程序重疊了。

(哪位大師說過?...你沒有辦法管理/改善你無法量測的東西....之類的話)
仔細量測之前，先來調整一下參數及程式，讓檢查時間回到合理的20~30秒。
再在程式檢查前後放個記log的code，這樣就可以持續紀錄整個實際執行的時間。
有了這個日誌檔，我應該有能力進行監控管理了。

(既然都動手了，再來個防rerun機制吧)
由於檢查程式是透過Cron來啟動，無法操之在我，那麼在原程式裡新增個防止rerun的機制，就不怕哪一天又發生意想不到的事情，而我只要觀察最近的執行記錄，就可以確認是否如我預期般的執行著。

(陽光底下沒有新鮮事，也沒有怪事)
終於雨過天晴，地球的運轉又回到常軌，一切事物又顯得那麼的完美和諧，我又可以開始做夢了。