「開始設定service」の編集履歴（バックアップ）一覧はこちら
「開始設定service」(2005/12/21 (水) 07:38:35) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
#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
這一行比較無關緊要，主要是用來描述這一個service的詳細內容，以供將來後人維護時作參考之用
**check_command check_http
這一行是用來設定用來監視之時，所使用的命令。不過同樣的，請不要誤解，這裡的命令並不是真正的對應到server裡頭的那一個可以執行的命令，而是對應到命令的設定檔。在另外一個設定檔裡，有關於這個命令的真正的路徑，要帶入的參數，以及實行時的細節。
以資料庫的概念來講，這裡的check_http是一個ForeignKey，它對應到另外一個table的primary key，如下圖所示：
**max_check_attempts 5
這一個選項的值被設為5。這個值代表最大的檢查次數，講的更白話一點，也就是nagios利用上面的check_http的命令，來檢查win1這一台server。當檢查時發現server異常時，因為有可能只是一時網路太擁擠，或是一些風吹草動，讓server受到了一點影響，所以不要馬上把server判斷為狀況危急，而是多試(retry)幾次，這裡的5就是至少試5次的意思。
這個值的設定要看現場的真正情況。比方說筆者目前所擔當的網站，由於訪問的流量非常的大，所以常常會發生server反應遲緩，而讓nagios判斷為緊急的情況，此時為了防止狼來了的場景一直發生，所以我會把這裡的值給設的高一點。當然這樣設會有一些問題，如果server真正發生問題，查覺得時間會比較晚，甚至客戶會比我們先查覺，所以為了防止這個情況，在將retry的次數調高的同時，也最好將每個retry之間的時間間隔縮短一點。不過這也有可能會有一點問題，如果將retry的時間縮短，那麼對於正在忙碌中的server來說不見得是一件好事。有時這真是一件令人拿不定主意的事，不過總而言之，還是要強調，一切都需要看現場的情況。
**normal_check_interval 3
故名思議這裡是用來設時間的間隔，也就是說，這一次的檢查和下一次的檢查之間，所隔的時間為3分。
這樣子設定之後，我們可以看一下apache的access log檔：
127.0.0.1 - - [18/Dec/2005:00:20:36 +0900] "GET / HTTP/1.0" 200 1494 "-" "check_http/1.81 (nagios-plugins 1.4.2)"
127.0.0.1 - - [18/Dec/2005:00:23:36 +0900] "GET / HTTP/1.0" 200 1494 "-" "check_http/1.81 (nagios-plugins 1.4.2)"
每間隔約3分鐘，nagios就會送出一個監視的訪問
&color(green){關於時間的單位}
在nagios的設定裡，在指定間隔時間之時，如果只有數字的話，通常的單位是以分為單位。但是分並不是最小的單位，你也可以以秒來指定。
用秒指定的時候，需要在數字之後加s(second)，比方說：
normal_check_interval 3s #每隔三秒檢查一次
如果是無限大的時間的話可以指定為0。而無限短的時間則是以-1來作指定。所謂的無限短，簡單的說，就是叫nagios儘可能的(asap)不斷執行監視的命令。
normal_check_interval 0 #隔無限長的時間檢查一次…也就是不檢查
normal_check_interval -1 #隔無限短的時間檢查一次…也就是儘量的不斷作檢查
**retry_check_interval 20
當狀態發生改變，從ok的狀態變化到不ok的狀態之時，nagios提供我們一個改變監視頻率的功能。
這一個頻率的改變可以是變快或是變慢，你可以自由的設定，這是一個很好的彈性，幫助我們可以更準確的判斷問題的發生。
但是這一個選項是在retry發生之時才會生效。就好像我們上面所說的，當第一次不ok的狀態發生時，此時過渡的soft狀態，nagios會開始用max_check_attempts裡所設的值開始為retry的次數倒數，此時監視的頻率也會發生改變，改變成這一個值裡所設定的。當retry的次數到達了max_check_attempts-1時，如果狀態還是不ok，那nagios就會將這個不ok的狀態過渡到hard的狀態，並且恢復監視的頻率為我們在check_interval裡所設的頻率。
**check_period 24x7
這裡的check_period 是要告訴nagios什麼時間是適當的時間作檢查。並不是所有的監視都是24小時不斷進行的，這個選項提供了我們設定這一個service的上班時間設定的自由。
有些service不是24小時全年無休，所以我們只要在這個service提供服務時進行監視就行了。
這裡的24x7同樣也是定義在另外一個物件裡，這裡只是一個引用的代碼，詳細的名為24x7的設定，需要參照另外一個物件(time_period)的設定。
**notification_interval 60
當一個主機或是服務，處於一個hard的非ok的狀態時，由nigous會發出通知，提醒聯絡人該主機或是服務處於一個非ok的狀態。當這一個通知發出之後，經過了一段時間之後，這一個主機或是服務，仍然處於非ok的狀態，有時可能是因為聯絡人沒有接到通知，或是聯絡人乎略了nagios所發出的通知，所以這個非ok的狀態一直持續著。
此時，我們可以設定nagios，在非ok狀態經過了一段時間之後，再度對使用者發出通知，而需要經過多長一段時間，再發出通知，就是使用這一個選項來進行設定。
當然有的情況並不是聯絡人沒有查覺到通知，可能真的是遇到了難題，所以遲遲不能夠將主機或是服務調整到ok的狀態。所以這個時間的設置，該設置多長，也是應該因情況由當事人自行判斷。
如果你覺得，所有的事件只需要一次通知就夠了，可以把這裡的選項設為0。此時nagios對於一個發生的事件，只會進行唯一一次的通知。
**notification_period 24x7
這個notification_period同樣的也是一個時間的設定，不過這一個選項所針對的是「發出通知」這一個行為。
這也是nagios設計上我覺得很有彈性的地方，因為通常我們都會想辦法省一下麻煩，將監視的時間與發出通知的時間默認為是同樣的東西，但是nagios必竟是為了全世界的使用者的需要，所以設計上非常有彈性。有了這個選項，你就可以把notification_period與check_period設為一樣，或是不一樣。
這一個check其實是一封通知要發出去之前，所需要通過眾多的檢查中的一道。
**notification_options w,u,c,r
這一個選項也是與「通知」有關，剛剛我們說明了通知可以進行的時間，這裡我們要定義的是「通知可以被發出的情況」。
在notification_options這個選項的後頭接了幾個用豆點區隔的英文字母，別被他嚇到了。這是一些英文單字的簡寫而已。
這些單字分別代表的意義如下：
|w |warn|警告狀態|
|u|unknown|不明狀態|
|c|criticle|緊急狀態|
|r|recover|回復狀態|
這些狀態就好象我們上一張講的，主機和服務有所不同。但都是來自於nagios進行監視之後的結果。
依照這些結果，在那些情況之下，需要寄出通知，是這個選項最主要的目的。
如果你不想收到太多的警告信的話，或許活用這個選項是個不錯的主意。
這一個check也是一封通知要發出去之前，所需要通過眾多的檢查中的一道。
**contact_groups contact_g1
這一個選項一看就知道，就是發出通知時要寄給那些人的設定了。這裡是以contact_groups的方式，也就是你必須在這裡設定一個已經定義好的聯絡人群組。這一個聯絡人群組的設定，我們會在接下來的章節裡作解示。
----
在設定完以上的內容之後，我們或許想要先測式看看是否我們真的設定正確了。我們可以式著執行nagios的verify選項，看看設定是否正確無誤。
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
此時這一個命令會出現以下的結果：
Error: Could not find any host matching 'win1'
Error: Could not expand hostgroups and/or hosts specified in service (config file '/usr/local/nagios/etc/services.cfg', starting on line 20)
nagios檢查之後，發現它找不到設定檔案有任何一個地方有定義名為win1的主機。所以報出了一個錯誤的訊息。這個錯誤訊息的第二行，有著這個錯誤訊息發生的行數。
#ref(http://www.okjp.net/book/searchnotfound-1.jpg)
#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
這一行比較無關緊要，主要是用來描述這一個service的詳細內容，以供將來後人維護時作參考之用
**check_command check_http
這一行是用來設定用來監視之時，所使用的命令。不過同樣的，請不要誤解，這裡的命令並不是真正的對應到server裡頭的那一個可以執行的命令，而是對應到命令的設定檔。在另外一個設定檔裡，有關於這個命令的真正的路徑，要帶入的參數，以及實行時的細節。
以資料庫的概念來講，這裡的check_http是一個ForeignKey，它對應到另外一個table的primary key，如下圖所示：
**max_check_attempts 5
這一個選項的值被設為5。這個值代表最大的檢查次數，講的更白話一點，也就是nagios利用上面的check_http的命令，來檢查win1這一台server。當檢查時發現server異常時，因為有可能只是一時網路太擁擠，或是一些風吹草動，讓server受到了一點影響，所以不要馬上把server判斷為狀況危急，而是多試(retry)幾次，這裡的5就是至少試5次的意思。
這個值的設定要看現場的真正情況。比方說筆者目前所擔當的網站，由於訪問的流量非常的大，所以常常會發生server反應遲緩，而讓nagios判斷為緊急的情況，此時為了防止狼來了的場景一直發生，所以我會把這裡的值給設的高一點。當然這樣設會有一些問題，如果server真正發生問題，查覺得時間會比較晚，甚至客戶會比我們先查覺，所以為了防止這個情況，在將retry的次數調高的同時，也最好將每個retry之間的時間間隔縮短一點。不過這也有可能會有一點問題，如果將retry的時間縮短，那麼對於正在忙碌中的server來說不見得是一件好事。有時這真是一件令人拿不定主意的事，不過總而言之，還是要強調，一切都需要看現場的情況。
**normal_check_interval 3
故名思議這裡是用來設時間的間隔，也就是說，這一次的檢查和下一次的檢查之間，所隔的時間為3分。
這樣子設定之後，我們可以看一下apache的access log檔：
127.0.0.1 - - [18/Dec/2005:00:20:36 +0900] "GET / HTTP/1.0" 200 1494 "-" "check_http/1.81 (nagios-plugins 1.4.2)"
127.0.0.1 - - [18/Dec/2005:00:23:36 +0900] "GET / HTTP/1.0" 200 1494 "-" "check_http/1.81 (nagios-plugins 1.4.2)"
每間隔約3分鐘，nagios就會送出一個監視的訪問
&color(green){關於時間的單位}
在nagios的設定裡，在指定間隔時間之時，如果只有數字的話，通常的單位是以分為單位。但是分並不是最小的單位，你也可以以秒來指定。
用秒指定的時候，需要在數字之後加s(second)，比方說：
normal_check_interval 3s #每隔三秒檢查一次
如果是無限大的時間的話可以指定為0。而無限短的時間則是以-1來作指定。所謂的無限短，簡單的說，就是叫nagios儘可能的(asap)不斷執行監視的命令。
normal_check_interval 0 #隔無限長的時間檢查一次…也就是不檢查
normal_check_interval -1 #隔無限短的時間檢查一次…也就是儘量的不斷作檢查
**retry_check_interval 20
當狀態發生改變，從ok的狀態變化到不ok的狀態之時，nagios提供我們一個改變監視頻率的功能。
這一個頻率的改變可以是變快或是變慢，你可以自由的設定，這是一個很好的彈性，幫助我們可以更準確的判斷問題的發生。
但是這一個選項是在retry發生之時才會生效。就好像我們上面所說的，當第一次不ok的狀態發生時，此時過渡的soft狀態，nagios會開始用max_check_attempts裡所設的值開始為retry的次數倒數，此時監視的頻率也會發生改變，改變成這一個值裡所設定的。當retry的次數到達了max_check_attempts-1時，如果狀態還是不ok，那nagios就會將這個不ok的狀態過渡到hard的狀態，並且恢復監視的頻率為我們在check_interval裡所設的頻率。
**check_period 24x7
這裡的check_period 是要告訴nagios什麼時間是適當的時間作檢查。並不是所有的監視都是24小時不斷進行的，這個選項提供了我們設定這一個service的上班時間設定的自由。
有些service不是24小時全年無休，所以我們只要在這個service提供服務時進行監視就行了。
這裡的24x7同樣也是定義在另外一個物件裡，這裡只是一個引用的代碼，詳細的名為24x7的設定，需要參照另外一個物件(time_period)的設定。
**notification_interval 60
當一個主機或是服務，處於一個hard的非ok的狀態時，由nigous會發出通知，提醒聯絡人該主機或是服務處於一個非ok的狀態。當這一個通知發出之後，經過了一段時間之後，這一個主機或是服務，仍然處於非ok的狀態，有時可能是因為聯絡人沒有接到通知，或是聯絡人乎略了nagios所發出的通知，所以這個非ok的狀態一直持續著。
此時，我們可以設定nagios，在非ok狀態經過了一段時間之後，再度對使用者發出通知，而需要經過多長一段時間，再發出通知，就是使用這一個選項來進行設定。
當然有的情況並不是聯絡人沒有查覺到通知，可能真的是遇到了難題，所以遲遲不能夠將主機或是服務調整到ok的狀態。所以這個時間的設置，該設置多長，也是應該因情況由當事人自行判斷。
如果你覺得，所有的事件只需要一次通知就夠了，可以把這裡的選項設為0。此時nagios對於一個發生的事件，只會進行唯一一次的通知。
**notification_period 24x7
這個notification_period同樣的也是一個時間的設定，不過這一個選項所針對的是「發出通知」這一個行為。
這也是nagios設計上我覺得很有彈性的地方，因為通常我們都會想辦法省一下麻煩，將監視的時間與發出通知的時間默認為是同樣的東西，但是nagios必竟是為了全世界的使用者的需要，所以設計上非常有彈性。有了這個選項，你就可以把notification_period與check_period設為一樣，或是不一樣。
這一個check其實是一封通知要發出去之前，所需要通過眾多的檢查中的一道。
**notification_options w,u,c,r
這一個選項也是與「通知」有關，剛剛我們說明了通知可以進行的時間，這裡我們要定義的是「通知可以被發出的情況」。
在notification_options這個選項的後頭接了幾個用豆點區隔的英文字母，別被他嚇到了。這是一些英文單字的簡寫而已。
這些單字分別代表的意義如下：
|w |warn|警告狀態|
|u|unknown|不明狀態|
|c|criticle|緊急狀態|
|r|recover|回復狀態|
這些狀態就好象我們上一張講的，主機和服務有所不同。但都是來自於nagios進行監視之後的結果。
依照這些結果，在那些情況之下，需要寄出通知，是這個選項最主要的目的。
如果你不想收到太多的警告信的話，或許活用這個選項是個不錯的主意。
這一個check也是一封通知要發出去之前，所需要通過眾多的檢查中的一道。
**contact_groups contact_g1
這一個選項一看就知道，就是發出通知時要寄給那些人的設定了。這裡是以contact_groups的方式，也就是你必須在這裡設定一個已經定義好的聯絡人群組。這一個聯絡人群組的設定，我們會在接下來的章節裡作解示。
----
在設定完以上的內容之後，我們或許想要先測式看看是否我們真的設定正確了。我們可以式著執行nagios的verify選項，看看設定是否正確無誤。
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
此時這一個命令會出現以下的結果：
Error: Could not find any host matching 'win1'
Error: Could not expand hostgroups and/or hosts specified in service (config file '/usr/local/nagios/etc/services.cfg', starting on line 20)
nagios檢查之後，發現它找不到設定檔案有任何一個地方有定義名為win1的主機。所以報出了一個錯誤的訊息。這個錯誤訊息的第二行，有著這個錯誤訊息發生的行數。
#ref(http://www.okjp.net/book/searchnotfound-1.jpg)
這一個錯誤的發生是我們所預料之中的，因為我們還沒有對主機進行定義。這將會是我們接下來的工作。
