如果還不能確定，使用uptime的時間窗技術進行重啟。
更重要的是，準確的宕機發現數據可以為宕機預測提供準確的標注數據，為后期宕機預測提供數據基礎，并且這些數據提供給運營部門進行整體分析，提升處理效率。
長尾再次處理
3）告知宕機的詳細原因，如硬件故障，內核bug，網絡異常等等。
服務器本身未丟包的誤報，除了需要過濾出網絡問題，還要通過丟包數據分析，過濾掉SA誤報問題， SA異常會上報心跳異常，被誤理解為宕機。
日志重啟特征值匹配，確認是否發生重啟。
我們從準確率和覆蓋率來看：
進一步識別誤報
目前，宕機感知是宕機分析的基礎，通過服務器宕機實時檢測，會把相應的宕機原因分布整理出來，明確具體的原因，達成服務器極致可靠性。
4）自動報修生成工單。
那么，如何可以準確發現宕機，減少誤報呢？我們可以有以下操作，比如：
排除非正在工作的機器，如非working狀態機器。
排除非業務狀態的機器，如裝機狀態中的，包括生產中，維修中，遷移中，重裝中，銷毀中，重啟中，無管控狀態，只監控正常狀態的機器。
異常排除
未確認的待處理的，會加入到長尾列表中，像這種分鐘級的心跳異常，ping異常，但串口日志一直正常輸出的情況，一般就是某種死機，死到連網絡都不通的場景。會觀察一段時間，一個固定時間窗內仍未恢復或重啟的話，就暫時報宕機。后期會把這種死機單獨找劃分歸類。
1）發現宕機。
覆蓋率：當前統計的覆蓋率已經能很好的支撐日常宕機處理，該數據在有足夠的特征后，會進一步提升。
icmp及tcp丟包分析，icmp采集頻率為固定數秒，tcp采集頻率固定數秒，包括多個不同大小包（16，32，64，128，256等）的丟包情況，根據分析時間窗內兩項數據的丟包情況
update消息，在有心跳發生變化情況下都會有，心跳異常和心跳恢復正常時都會發起，是主要的心跳來源。
網絡干擾排除
仍不能確定的待處理，進入長尾處理名單。
提到服務器宕機檢測，大家會想到，宕機能夠很快知道，這個有什么可做的？實際上，很多時候服務器宕機，并不總是被及時感知。服務器宕機，ping或者ssh這是最簡單的做法，但真正的工程實踐，沒這么簡單。
排除上聯網絡設備異常導致的誤報，包括機房斷網演練，小面積網絡故障，上聯網絡故障，如通過探測丟包情況，使用一些邏輯初步判斷網絡問題。
講了這么多，到底效果怎么樣？
