提到服務器宕機檢測，大家會想到，宕機能夠很快知道，這個有什么可做的?實際上，很多時候服務器宕機，并不總是被及時感知。服務器宕機，ping或者ssh這是最簡單的做法，但真正的工程實踐，沒這么簡單。

想要獲知服務器宕機怎么辦?可以通過服務器宕機實時檢測：

1)發現宕機。

2)提前告警。

3)告知宕機的詳細原因，如硬件故障，內核bug，網絡異常等等。

4)自動報修生成工單。

我們知道，進行全網物理機宕機準確探測與實時發現，可以給宕機分析提供第一現場，獲取第一現場的日志。也可以盡早將宕機數據推送給業務或運營感知并處理，如自動報修，業務遷移等，從而盡可能將業務影響降到最低。

    更重要的是，準確的宕機發現數據可以為宕機預測提供準確的標注數據，為后期宕機預測提供數據基礎，并且這些數據提供給運營部門進行整體分析，提升處理效率。

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

心跳源檢測異常

    顧名思義，通過心跳源，初步發現異常。通常心跳變化會有三類消息，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判斷以及帶外日志分析排查。