所謂抖動，是指狀態在一定時間內變化過於頻繁。如果某個物件處於抖動狀態，那麼這時候的狀態變化也是無意義的。

Nagios提供了抖動狀態的檢查以及針對抖動狀態的處理。

1.判定抖動狀態

抖動是由於狀態變化過於頻繁導致，但是該如何定義“頻繁”？每次檢查得到的狀態都與上次不一樣？還是一定時間內狀態變化達到某個閾值？這個確實很難有統一的標準。

Nagios通過統計狀態變化的頻度，與使用者配置的閾值比對，來判定是進入還是退出抖動狀態。
Nagios在其物件配置定義中，提供了Host和Service進入、退出抖動的閾值。Nagios的全域性配置項low_host_flap_threshold，high_host_flap_threshold，low_service_flap_threshold，high_service_flap_threshold 分別定義Host和Service的退出和進入抖動狀態的閾值。
具體的Host和Service的配置項是low_flap_threshold，high_flap_threshold。

Nagios統計狀態變化頻度的方法大概描述為：

• 儲存Host或Service的21檢查結果
• 分析21次檢查結果種狀態變化次數
• 統計狀態變化的頻率
• 比對變化頻率與抖動閾值，確定是進入還是退出

Nagios計算抖動頻率的方法就是：（狀態變化次數／狀態可能的變化次數）＊100 。但是Nagios對狀態變化次數有一個權重，21次檢查結果中，近期的狀態變化權重比遠期的高。（關於權重這點實際上意義不大，如果需要更接近當前狀態，可以把21次縮短，然後增加retry，類似soft和hard狀態變化，這樣更準確）。

2.判定抖動的例子

下面圖中有21次檢查，OK狀態的是綠色，WARNING狀態的是黃色，CRITICAL狀態的是紅色。

3.Service的抖動檢測
Service的抖動檢測與上面例子一致無差異。

4.Host的抖動檢測
Host的抖動檢測比Service要複雜。因為Host可以不配置check_command（也可以配置），也就是說Host本身允許沒有檢查的command，Host的狀態都是由它上面的Service得到的。
所以，Host的抖動檢測，除了上面的Service邏輯外，還需要增加邏輯：

• 每次檢測Host（Host配置了check_command），active和passive檢查型別不區分。
• 每次檢測Service的狀態時候，判斷當前時間距離上次抖動檢測是否過了X秒。X的值是該Host上所有Service檢測週期平均值。這麼做就是為了適應Host上沒有配置check_command的場景。

5.抖動的處理
進入抖動狀態的處理：

• 記錄日誌
• 傳送進入抖動的通知
• 遮蔽其他狀態變化通知

退出抖動的處理：

• 記錄日誌
• 傳送退出抖動的通知
• 清除通知遮蔽