[QOTD]機器的異常不見得是在甚麼狀況是異常，而是
就既有的狀況來決定甚麼是正常後才去判斷異
常，因此若沒有歷史的資料，是很難判斷異常
的發生。
*1
最近一直在用 MRTG 跟 RRDTools 來玩一些時間
序列的事，而 MRTG 跟 RRDTools 畢竟只是個工具，
而要丟給它甚麼數字，然後用甚麼方式來呈現才有意
義這是工具做不到的。
這些工具的出發點都是為了要監視網路上伺服器
的狀態所架構出來的，尤其是透過 SNMP( Simple
Network Management Protocol) 來獲得一台機器上
的網路流量為最主要的目標 ( Target)，但不只一定
是要用流量來監視一台機器，只要是會因時間改變的
數字就會有用。
因此，會用來監視 CPU 的負荷，記憶體
(memory) 的使用，發信狀況 (Dispatch/Finish，
Run/Wait)，系統資源，各個 Process( 程序 )的狀
況，都可以監視之後，做為評量一台機器的數字。
而我也一直認為這樣的監視是有價值的，雖然他
的資料不多，但還是相當有用，因為說要用人眼去花
時間看這些狀態，還不如用電腦去記錄下來，只是要
記錄甚麼就是在於監看的目的是甚麼。
但的確不太可能用這樣簡單的東西找到最後的答
案，只是也提供了重要的參考，就像是判斷是 CPU
所造成的瓶頸呢？還是因為 Memory 所造成的瓶頸呢
？或者是造成負荷最大的原因是因為 Web Server 呢
？還是不是。
但這樣的記錄與分析本來就是很經驗的，因此可
能要隨時去改變或增加所監視的物件 ( Object)，這
樣才能真正有判斷的依據。
當然這樣的工具最大的功能就是時間，我們可以
透過這樣的時間軸變化來去判斷，因為一台機器的正
異常不見得是在甚麼狀況是異常，而是就既有的狀況
來決定甚麼是正常後才去判斷異常的定義，因此若沒
有歷史的資料，是很難判斷異常的發生。
在這邊寫一下一些給剛使用的網管的人來看。
CPU 的負荷 (Loading): 這是一個可能會超過 1
的數字，而在去整數值的情況下我們通常會乘上 100
，而當有 n 顆 CPU 的情況下，在不造成 CPU 的瓶
頸觀點就要小於 n，若大於 n 就代表程式 (程序 )
對 CPU 的須求時間超過 CPU 所能夠提供的，因此若
是這樣的話會造成有些 Process 會因為 CPU 資源不
足造成延遲 (Delay) 。而我們通常會用另外用
Proces 數來輔助，或者是直接用 CPU 使用率
(Utilization) 來輔助。
CPU 使用率 (Utiliization): CPU 的使用率在
n 顆 CPU 的系統下是一定是不會超過 n，因此若是
單顆 CPU 也代表不會超過 1，也會習慣的乘上 100
來做記錄，但 CPU 使用率高並不代表甚麼，尤其是
有些人會跑 UD 或 SETI@home 來利用浪費的 CPU
Time，因此即使維持在 99% 也是無所謂的，只是通
常若 CPU 真的在必要的 Process 使用到 70% 的
CPU Utiliation 時，就要看是否會發生 Thrashing
的狀態，但 CPU 使用率低也不代表沒問題，更有可
能是因為大部份都是在 I/O Waiting，如瓶頸發生在
硬碟，用這數字來看是沒有用的。
*2
Process Numer( 程序數 ):我們不可能只是監視
(monitor) 或記錄單純的程序總數，而是會多記
錄 httpd 或 mailerd 等等的數字以及所佔的比率，
但都是端看這是甚麼樣的伺服器來作判斷須要監視甚
麼樣的 Process，但若有不明的 Process 增加造成
主要用途的 Process 數比率降低，就代表有問題發
生，而 Process 數是基本會影響記憶體使用及 CPU
使用的最初原因，只是在基本計數下，分類計數也是
可以看出一台電腦最主要的負荷與功能。
*3
**********************************************
*1
10/25/02 8:59 am，剛寫一篇捷運日記到最後寫
不下去，正準備收起來時，突然想到有另一篇該寫的
。
*2
10/25/02 9:36 am，哇，寫文章寫的太認真了，
居然寫到昆陽站了，但我想這時間還算夠，除非又有
火車跟我作對，我才會遲到。
*3
10/28/02 8:56 am，現在到關渡站，看樣子是較
晚起床的一次，不然我通常在 9:00 前已經過北投了
，雖然昨天較早睡 (1:30 am)，但這幾天真的有點累
吧。
10/28/02 8:34 pm，因為這篇可能會有點小長，
所以就分幾篇吧。
文章定位：
