狀態跟蹤
介紹
狀態“跟蹤”是大多數用戶可能不會使用的功能。啟用后,即使主機或服務的狀態沒有更改,它也可以記錄輸出服務和主機檢查中的更改。為特定主機或服務啟用跟蹤功能后,Nagios Core將非常仔細地監視該主機或服務,并將其在檢查結果輸出中看到的所有更改記錄下來。如您所見,它在以后分析日志文件時對您很有幫助。
它是如何工作的?
在正常情況下,僅在主機或服務自上次檢查以來已更改狀態時才記錄主機或服務的檢查結果。對此有一些例外,但是在大多數情況下,這是規則。
如果您為特定主機或服務的一個或多個狀態啟用跟蹤功能,如果該檢查的輸出與前一個檢查的輸出不同,Nagios Core將記錄該主機或服務檢查的結果。采取以下對服務進行八次連續檢查的示例:
| 服務檢查編號: | 服務狀態: | 服務檢查輸出: | 正常記錄 | 跟蹤記錄 |
|---|---|---|---|---|
| X | 好 | RAID陣列最佳 | – | – |
| +1 | 好 | RAID陣列最佳 | – | – |
| x + 2 | 警告 | RAID陣列降級(1個驅動器損壞,1個熱備用重建) | ||
| x + 3 | 危急 | RAID陣列降級(2個驅動器損壞,1個主機備用在線,1個熱備用重建) | ||
| x + 4 | 危急 | RAID陣列降級(3個驅動器損壞,2個熱備用在線) | – | |
| x + 5 | 危急 | RAID陣列發生故障 | – | |
| x + 6 | 危急 | RAID陣列發生故障 | – | – |
| x + 7 | 危急 | RAID陣列發生故障 | – | – |
根據這種檢查順序,通常您只會看到兩次針對此災難的日志條目。當服務從OK狀態更改為WARNING狀態時,第一個將在服務檢查x + 2處發生。當服務從“警告”狀態更改為“嚴重”狀態時,第二條日志條目將出現在服務檢查x + 3處。
無論出于何種原因,您都可能希望在日志文件中包含此災難的完整歷史記錄。也許可以幫助您向經理解釋情況很快變得失控的原因,也許只是在當地一家酒吧喝了幾杯后就笑了起來。
好吧,如果您已為CRITICAL狀態啟用了跟蹤該服務的功能,那么除了x + 2和x + 3的事件外,您還將記錄x + 4和x + 5的事件。為什么是這樣?啟用狀態跟蹤后,Nagios Core將檢查每個服務檢查的輸出,以查看其是否與前一個檢查的輸出不同。如果兩次檢查之間的輸出不同且服務的狀態未更改,則將記錄更新的服務檢查的結果。
跟蹤的類似示例可能在檢查您的Web服務器的服務上。如果check_http插件由于404錯誤而首先返回警告狀態,而在隨后的檢查中由于未找到特定模式而返回警告狀態,您可能想知道這一點。如果您沒有為服務的警告狀態啟用狀態跟蹤功能,則只會記錄第一個警告狀態事件(404錯誤),并且您不會(將來在存檔日志中回頭)有任何想法要知道將來的警告狀態不是由于404,而是由于某些文本模式在返回的網頁中找不到。
我應該啟用跟蹤功能嗎?
首先,您必須確定是否確實需要分析存檔的日志數據以找到問題的確切原因。您可能會決定某些主機或服務需要此功能,但并非全部都需要。您可能還會發現只需要為某些主機或服務狀態而不是所有狀態啟用跟蹤功能。例如,您可能決定為服務的“警告”和“關鍵”狀態啟用跟蹤功能,而不為“確定”和“未知”狀態啟用跟蹤功能。
對特定主機或服務啟用狀態跟蹤的決定還取決于您用來檢查該主機或服務的插件。如果插件始終為特定狀態返回相同的文本輸出,則沒有理由為該狀態啟用跟蹤功能。
如何啟用跟蹤?
您可以使用主機和服務定義中的stalking_options指令為主機和服務啟用狀態跟蹤。
跟蹤與波動性服務有何不同?
易失性服務類似,但是將導致通知和事件處理程序運行。跟蹤純粹是為了記錄目的。
通知跟蹤
作為核心4.4.0的存在是基于通知特別跟蹤選項,?。定義此特殊選項后,每次發出通知時,都會記錄事件狀態。這意味著,如果每隔1個小時收到一次通知,并且設置了此選項,則當主機或服務的通知失效時,您將每小時看到一次記錄的事件狀態。
注意事項
您應該意識到,啟用跟蹤可能會帶來一些潛在的陷阱。這些都與各種CGI中的報告功能(直方圖,警報摘要等)有關。由于狀態跟蹤將導致記錄其他警報條目,因此報告生成的數據將顯示警報數量膨脹的證據。
作為一般規則,我建議您在未仔細考慮的情況下不要對主機和服務啟用跟蹤。不過,如果您需要并想要它,它就在那里。
Nagios Core中文使用教程