那麼，如何可以準確發現宕機，減少誤報呢?我們可以有以下操作，比如：

心跳源檢測異常

顧名思義，通過心跳源，初步發現異常。通常心跳變化會有三類消息，update消息，delete消息和insert消息。心跳邏輯在於，正常情況下SA服務端與NC建立長連接，每數秒緩存一次心跳，每幾分鐘打包上報一次，但當NC異常時，長連接感知後，立即上報異常，並修改路由表。所以心跳異常做到秒級感知。

update消息，在有心跳發生變化情況下都會有，心跳異常和心跳恢復正常時都會發起，是主要的心跳來源。

delete消息，在心跳異常，並且SA判斷ping不通，且ssh不通情況下發起，刪除該條消息，避免延遲太長。

insert消息，在新增加機器， 或者重裝後重新上位的機器發起，該消息對宕機發現價值不大，配合uptime使用。

心跳源檢測任務邏輯，主要是監聽並緩存uptime消息，同時避免時間窗內多次消息衝突，導致信息被覆蓋。

異常排除

• 排除非物理機器，將系統中暫時不關注的VM等產生的異常信息排除掉。
• 排除非業務狀態的機器，如裝機狀態中的，包括生產中，維修中，遷移中，重裝中，銷毀中，重啟中，無管控狀態，只監控正常狀態的機器。
• 排除非正在工作的機器，如非working狀態機器。

網路幹擾排除

宕機分析中，較多誤報是由於網路問題幹擾，無法準確判斷出物理機是否宕機，有可能是網路問題。

• 排除上聯網路設備異常導致的誤報，包括機房斷網演練，小面積網路故障，上聯網路故障，如通過探測丟包情況，使用一些邏輯初步判斷網路問題。
• 伺服器本身未丟包的誤報，除了需要過濾出網路問題，還要通過丟包數據分析，過濾掉SA誤報問題， SA異常會上報心跳異常，被誤理解為宕機。
• icmp及tcp丟包分析，icmp採集頻率為固定數秒，tcp採集頻率固定數秒，包括多個不同大小包(16，32，64，128，256等)的丟包情況，根據分析時間窗內兩項數據的丟包情況

特殊情況幹擾排除

個別機房有時候會出現大面積風暴式的無故心跳異常，同時網路ping包異常，但上聯網路設備ping包正常，這種誤報，一般根據具體case具體進行針對性的分析。如根據監控每個機房的上報頻率，排除幹擾。

進一步識別誤報

至此，大部分幹擾已經過濾掉，但仍有一部分誤報隱藏其中。比如心跳異常，ping異常，都合乎宕機判斷的邏輯，會導致誤判成宕機，如導致網卡被打爆，或者重試率高，這種是業務原因導致網路異常，但業務認為不是異常，需要排除掉。再例如伺服器並沒有掛掉，但是IO延時和資源佔用率各項指標都不正常等場景。針對以上等情況，增加uptime判斷以及帶外日誌分析排查。

• 宕機時間點探測uptime確定是否發生重啟。
• 進一步通過分析日誌是否連續，判斷是否發生重啟。
• 日誌重啟特徵值匹配，確認是否發生重啟。
• 如果還不能確定，使用uptime的時間窗技術進行重啟。
• 仍不能確定的待處理，進入長尾處理名單。

長尾再次處理

未確認的待處理的，會加入到長尾列表中，像這種分鐘級的心跳異常，ping異常，但串口日誌一直正常輸出的情況，一般就是某種死機，死到連網路都不通的場景。會觀察一段時間，一個固定時間窗內仍未恢復或重啟的話，就暫時報宕機。後期會把這種死機單獨找劃分歸類。

講了這麼多，到底效果怎麼樣?

我們從準確率和覆蓋率來看：

• 準確率：目前發現的宕機中有很高準確度，可以區分出真正宕機或者未宕機。而判斷為宕機的數據中，也存在少量的，由於缺少相關信息導致誤報，該部分將進一步優化，逐漸降低誤報，在新的措施之後，該比例會接近0。
• 覆蓋率：當前統計的覆蓋率已經能很好的支撐日常宕機處理，該數據在有足夠的特徵後，會進一步提升。

目前，宕機感知是宕機分析的基礎，通過伺服器宕機實時檢測，會把相應的宕機原因分佈整理出來，明確具體的原因，達成伺服器極致可靠性。