benjamin @Wiki

note

2006-06-03T23:31:52+09:00

搞不清楚我在幹嘛每隻股票都有配當以及eps 看配當及eps 或許可以確認現在買的股票是不是好的有點混亂今天我很特別的什麼都沒有做不停的娛樂不過真的很空虛我知道我有很多事要做不過我還是拿不定主義該從那一件事情下手我決定先錄音錄了之後下週聽這種「倒推回來」的方法附合七個習慣裡的第二種以始為終我打算在投資這件事上可下功夫這一波的捐失讓我的資產回到了去年12月時的水準也就是我損失了六個月的努力有點不太好研究企業並且找尋更好的解答讓事情變得簡單今天和朋友去美式餐聽聊了一個下午實在是無所意義只是醫治自已的無聊病下了一天的雨大概梅雨季到了。去留學一年吧！去試試看其他的可能性吧！確實的在心裡反覆思考這七個習慣像旅遊一樣的心情學習去計劃每一天然後回顧以過這一週來的進度。我今天這麼做了，發現我完成了不少的工作這是時間所累積出來的成果。我今天也去租了dvd。為什麼，因為今天的人很少，排隊在我前面的，竟然只有一個人。而在週五的晚上，或是週來週日，至少要有20多個人等在你的面前。現在租的dvd，可以看到下週二。由這個小小的事例，讓我們發現，原來把一些事情做好規畫，可以有這麼好的結果。我今天也去品川的書店看了一下，至少有一個月沒有去日本的書店的，發現了很多的新書，這是很多很多的人努力工作之後的產出。光看了標題，每本書都令我的思考refresh 面式要點：第一：不要在電話中談錢第二：談談這工作的遠景，及這工作將來的可能性第三：談談該公司的組成，及裡面的構成成員第四：談談這工作可以給我的交接時間我選擇的重點：第一：天空的大小第二：不在一個人生活時所多出來的需要，包括房屋的大小與經濟的負擔。第三：創業這條大路線是否偏離。待解決的問題：至少需要一個月的交接期房屋，在日本需要擁有一個住所加油～別急，一步一步的慢慢來

第３節進階選項的調適

2006-03-04T11:46:24+09:00

*EVENT BROKER OPTIONS # Controls what (if any) data gets sent to the event broker. # Values: 0 = Broker nothing # -1 = Broker everything # = See documentation event_broker_options=-1 *EVENT BROKER MODULE(S) # This directive is used to specify an event broker module that should # by loaded by Nagios at startup. Use multiple directives if you want # to load more than one module. Arguments that should be passed to # the module at startup are seperated from the module path by a space. # # Example: # # nebmodule= [moduleargs] #broker_module=/somewhere/module1.o #broker_module=/somewhere/module2.o arg1 arg2=3 debug=0 *LOG ROTATION METHOD # This is the log rotation method that Nagios should use to rotate # the main log file. Values are as follows.. # n = None - don't rotate the log # h = Hourly rotation (top of the hour) # d = Daily rotation (midnight every day) # w = Weekly rotation (midnight on Satur

第9節主動監視與被動監視(2)

2006-02-28T23:07:13+09:00

*被動監視 ---- 談到這個主題，令人想到我們已前學英文時，常常提到的主動詞與被動詞。但是一點關系也沒有就是了。為了實現被動的監視，nagios必須要有一個管道來接收，從外頭進來的回報，用來確定該服務是正常的被執行的。這個管道就是我們之前所提到過的nagioscmd。這個流程圖如下所示外部來的監視回報->nagios的監視介面->nagios的狀態檔案裡記錄然後這個狀態檔就會被web的cgi的程式所讀取，然後在畫面上被表示出來。這個時候會出現的問題點，就是如果從外面送進來的資料，如果nagios不認識的話，也沒有意義，所以要先定義好一定的格式，讓彼此都可以認識，所以外頭來的監視回報，不管是監視什麼的回報，都需要符合下列的類型。然後nagios收到回報之後，才能夠判斷那一個服務，或是那一台主機現在是ok的。所以，在nagios裡面，事先對這一個服務或是主機，進行定義，是有必要的。 *新鮮度檢查 ---- 即然是nagios被動的等待資訊的進來，nagios也不甘於只是等待，nagios所要採取的行動，就是主動的去檢查，是否進來的資訊，是最新的，即時的。如果資訊太舊，那就代表已經很久的時間沒有新的回報進來了，這個時候，nagios就可以很合理的對於該監視項目的安危提出合理的懷疑。而對於相關人士發出警告。為了實現這一個邏輯，在nagios裡有一個設定的選項，叫做…… 這個項目用來設定資訊過期的時間。也就是說超過這一個時間，資訊如果沒有被更新，那nagios就應該要產生合理的懷疑，將狀態報知相關人員。 *分散式架構被動模式是一個在nagios本體程式裡提供的模組，使用的方法很廣泛，可以使用的情況就交給各位讀者的想像力去發揮，在多台主機同時監視之時，也可以使用這個工能，此時擔任主控的機器，需要將各地來的資料，收集起來在一個畫面上顯示，不需要真正的去監視各台server，這一台機器如果要實現這一個「資訊的集散中心」的腳色，就必須要利用這一個功能。比方說在名居屋的公司裡有1000台機器，在北海道裡也有1000台機器，在東京的總部，要如何確認這2000台機器的狀況，這個時候比較合理的作法，就是在名古屋的機房裡，分別設置幾台監視用的機器，而名古屋的相關人員，可以利用這幾台機器來監視其他

第２節巨集的使用

2006-02-28T23:55:44+09:00

在nagios裡頭，有很多事先定義好的變數名稱，我們利用這些變數名稱，來與nagios作溝通。這些變數的最主要目的，就是用來作溝通。比方說我們寫程式的時後，寫了十隻程式，第一隻程式執行的結果，要來第二隻程式知道，有很多方法可以達成，最簡單的方式，就是生成一個檔案，這個檔案可以讓第二隻程式來讀取。這個巨集的運用，也是類似這樣子的觀念。為了要使資訊能夠傳遞，nagios的本體裡定義了很多的巨集。這些巨集都是以2個$記號給包了起來。舉例來說： $SERVICESTATETYPE$ 這一個巨集，就是用來傳遞該服務，或是該主機目前所處在的狀態，是soft狀態，或是hard狀態。當nagios的核心，對一個服務進行檢查，確認了該服務的狀態之後，這個狀態的資訊，只有nagios才知道。如果其他的元件，想要知道該服務是處於什麼狀態，以變針對該狀態作出對應時，nagios會針對它們的需要，將這些資訊傳給它們。而巨集就是用來代表這些資訊。有點抽像，舉個例子來說：我們在checkcommand的檔案裡定義了一個命令，這個命令，需要我們傳入主機的位置，主機目前的狀態。此時我們可以這麼寫： define check_XXX{ $HOST$ } 接下來，我們列出一些我們經常會使用的巨集。 *為什麼是巨集因為在nagios裡，監視是分成很多個服務或主機的。所以每個主機或是服務裡，都有同樣的變數。nagios使用巨集，以便適用於各個定義項目。 *利用巨集來與nagios溝通：同樣地，我們要與每個設定好的服務作溝通之時，也要透過巨集。比方說，我們要將設定值，透過cgi介面傳給nagios，希望nagios能夠為我們動態的改變該服務或是主機的設定值。此時，也需要利用該巨集。我們在定義命令需要將這一個資訊傳達給它們。

第１節第一個NAGIOS 插件

2006-01-18T02:23:10+09:00

*開發開發nagios的插件，是一件可大可小的事情。本章從一個最簡單的插件開始，我們稱之為插件的hello world! 這個插件是用shell script語言所寫的，雖然只有一行，不過確好象是阿姆斯裝在月球上走的那一小步一樣，具有特別的意義。 *測式我們執行一下這一個script，如下所示： sh test>sh 然後得到了以下的結果。我們剛剛所作的動作，將來雖然說會由nagios來幫我們作，但是執行的過程是一樣的。 *布暑接下來我們將所有的事情完成之後，我們要開始來進行布暑的動作，我們將以以下的流程來進行。首先，定義這一個插件到command的區塊裡，並且給它一個代號check_nothing。第二步，將這個commmand apply到其中一個主機或是服務上，比方說我們將他布暑到win1這一個主機。注意，這裡並不是我們要讓這個程式幫我們監視主機，只是command像個寄生蟲一樣，一定要依附在主機或是服務上才能夠被執行。 *布暑的測式 ok，到這裡我們已經完成了作業，我們使用nagios這一個命令，幫我們檢查一下我們是否布暑成功。 *重新啟動nagios主程式接下來一切都就緒了，我們可以啟動nagios。然後打開web畫面，在過一下子之後，畫面上就會出現我們所定義的這一個命令了。這個命令的畫面，我們可以看到最右邊的地方有一排文字。也就是我們在執行command之後的輸出。簡單地說，也就是nagios的主程式幫我們執行了這個插件，這個插件反回了結果，然後這個結果被保存在狀況保存檔裡，在由web的cgi將它們用圖形介面顯示出來。 *總結這一章給我們看到了如何進行一連串的流程，來安裝並且布暑。如下圖所示，插件這個黑盒子之外，其他的流程都是固定的，插件可以用任何方式來實現，也就是我們底下要舉的例子。

第２節基本選項的調適

2006-03-04T11:39:51+09:00

*前言本章開始要進入nagios的核心設定檔。這一個設定檔的內容，掌握了nagios的主要動作，「可以」設定的選項非常的多，但是大多可以不用理它。用預設值就可以了，但是如果你想要多了解一下這一個工具，那或許可以好好讀讀這一章，我會努力將它用簡單的方式，呈現給大家。這一個設定檔，nagios的主程式，以及cgi程式，都會去讀，所以簡單的說，就是這個設定檔裡規範了nagios的動作之外，也規範了cgi的動作，有的選項是用來調適cgi的，而有的選項是用來調適nagios的。在安裝的時後，當我們執行config的命令之時，make就會幫我們生成一個最原始的file。我們就以這個隨手可得的設定檔原型當作範例，來作說明。我們在執行設定config的時後，如果執行： ./configure -h 之時，會出現很多的選項，其實在這個選項裡所指定的內容，都會在這個設定檔裡被反應。所以換句話說，在設定之時，也不用設定的太複雜，在安裝好之後，在進行設定就可以了。我們只要仔細作個判斷，nagios本體的程式，也就是核心的部份，主要負責的部份，以及cgi所擔當的任務，可以作出下列的歸類： *記錄檔的設定：這一個選項是用來指定設定當的吐出位置。所有的程式，只要是比較建全設計，都會吐出記錄檔。這個記錄檔裡將記錄很多細節的動作，以及按照時間，記錄每一個動作。我們如果要查看nagios在那個時間出現了什麼事，只要看一下這一個紀綠檔，都可以得到確切的資料。 log_file=/usr/local/nagios/var/nagios.log *物件設定檔案接下來的設定，是對於被監視的對像進行設定的設定檔的位置。這個位置可以是在一個檔案裡，也可以作分類在不同的檔案裡，全看實際的情況來作調整。語法也相當的簡單： cfg_file=檔案的路徑及檔案的名字。這其實是一個include的觀念，這裡的設定檔在啟動時會被讀進來。把所有的物件定義全部寫在一個檔案裡時，當你的系統很小，這是一個最簡單的方式(所謂的簡單，應該是說在設定時，只要編輯一個檔案就好了，不需要不時的切換到別的檔案)可以用以下的方式： cfg_file=/usr/local/nagios/etc/minimal.cfg 這個mi

狀態的種類

2005-12-18T00:45:27+09:00

*狀態的種類 **簡介因為在監視裡頭，重試(retry)的概念有被包括進去，所以在nagios裡頭，將retry時主機或服務所處的狀態，定義為soft，軟的狀態。而將retry仍然不成功時的狀態，定義為hard也就是硬狀態。 State Types Introduction The current state of services and hosts is determined by two components: the status of the service or host (i.e. OK, WARNING, UP, DOWN, etc.) and the type of state it is in. There are two state types in Nagios - "soft" states and "hard" states. State types are a crucial part of Nagios’ monitoring logic. They are used to determine when event handlers are executed and when notifications are sent out. Service and Host Check Retries In order to prevent false alarms, Nagios allows you to define how many times a service or host check will be retried before the service or host is considered to have a real problem. The maximum number of retries before a service or host check is considered to have a real problem is controlled by the option in the service and host definitions, respectively. Depending on what attempt

開始設定service

2005-12-21T07:38:35+09:00

#contents *一個簡單的範例 service裡有很多的選項，為了更貼近現實，假設我們現在有兩台機器，一台win1，一台win2，這兩台機器上都運行了web server。我們想要在運行nagios的機器上，進行設定，使得nagios能夠認識這兩台機器上所運行的服務，並且讓nagios來對這兩台機器的web server進行監視的工作：首先定義第一個服務： define service { use generic-service host_name win1 service_description test check_command check_http max_check_attempts 5 normal_check_interval 3 retry_check_interval 20 check_period 24x7 notification_interval 60 notification_period 24x7 notification_options w,u,c,r contact_groups contact_g1 } 看到這麼大串的設定檔，是否有點感到無法吞的下去。如果你會這麼覺得，那你是正常的。老實說，很多人都與你有同樣的想法。其實你在這裡所看到的，只是用來定義service屬性的一部份而已。不過這些屬性都很常用，所以先列出這些。如果你很趕時間想要把設定完成，那你可以先把這幾個項目弄懂，在百分之八十你所遇到的情況裡，都可以派得上用場。其實這裡的設定檔與關連式資料庫有很多異曲同功之妙，所以也有些幫助你設定的軟體，是將設定先寫到資料庫裡，然後在從資料庫裡將檔案給輸出到文字檔。我們先一項一項的從上往下看： **host_name win1 故名思義，這裡定義了主機的名稱。不過請不要誤解，這裡的主機名稱，並不是直接對應到真正機器的主機名稱，乃是對應到在主機設定檔裡所設定的主機名。以資料庫的概念來講，這裡的win1是一個ForeignKey，它對應到另外一個table的primary key，如下圖所示： **service_description test 這一行比較無關緊要，主要是用來描述這一

第５節設定時間細節

2005-12-17T17:29:11+09:00

*關於時間(timeperiod )的設定在其他的設定檔案裡，有一個timeperiod 的關鍵字，然後在這後面跟著一個名稱： timeperiod 24x7 這個關鍵字的後面跟著 24x7，事實上是一個已經定義好的物件。如果要將上頭的文字用中文來作表示，應該是會像：使用timeperiod物件名稱名為24x7的物件在nagios裡我們需要定義監視的時間。基本上，時間的模式也可以說是一個物件，所以它也具有物件的特性。定義時間的語法如下所示： define timeperiod { timeperiod_name 24x7 #名稱 alias 24 Hours A Day, 7 Days A Week #別名 sunday 00:00-24:00 #星期，時間帶 monday 00:00-24:00 tuesday 00:00-24:00 wednesday 00:00-24:00 thursday 00:00-24:00 friday 00:00-24:00 saturday 00:00-24:00 } **timeperiod 的代表 timeperiod_name 在以上這一個範例裡，我們定義了一個timeperiod 的物件，這個物件的名稱叫做24x7，也就是7天，每天24個小時的意思，這裡的 timeperiod_name 是用來識別每一個timeperiod 的判斷條件，就好像是資料庫裡每一個表格所具有的primary key一樣，具有唯一性，如果不小心使用了重覆的名字，那在啟動nagios之時，會出現錯誤的訊息。當我們在其他的設定檔裡，要使用這裡所定義的timeperiod 物件之時，所以用的名稱就是這個timeperiod_name。 **timeperiod的別名相對於主鍵所具有的唯一性，別名就比較沒有限制，別名的目的是為了讓這個timeperiod物件的內容，更容易被人所了解。 **時間帶接在別名下方的，是這個timeperiod的主要內容，它的格式大致上是前面是星期，然後後面跟著是時間。 sunday 00:00-24:00 後面的時間，如果是不連續的情況，可以用豆點區隔，作多個時間

第２節設定服務

2005-12-21T08:04:12+09:00

繼承的概念：

進行了上述的解示之後，接下來我們進入第一個詳細的設定項目。服務。

如果服務是一個物件的話，那將會是如下面的uml所示的：

這一個物件可以產生很多的實例，以uml來表示的話，將會是如下圖所示：

這物件也能夠使用繼承的概念：

如下圖所示：

benjamin @Wiki

note

第３節 進階選項的調適

第9節 主動監視與被動監視(2)

第２節 巨集的使用

第１節 第一個NAGIOS 插件

第２節 基本選項的調適