騰佑小編知道用戶都聽說過服務器宕機這個問題,但是一說到服務器宕機檢測,可能會讓大家想到,服務器宕機了肯定能很快知道的,這個問題還有什么可做的呢?但是實際上,現(xiàn)在大部分的服務器宕機的時候,是不能被用戶及時感知的。今天這篇文章騰佑小編就來就來簡單介紹一下服務器“異常”的6個可能性預警。
宕機,指操作系統(tǒng)無法從一個嚴重系統(tǒng)錯誤中恢復過來,或系統(tǒng)硬件層面出問題,以致系統(tǒng)長時間無響應,而不得不重新啟動計算機的現(xiàn)象。它屬于電腦運作的一種正常現(xiàn)象,任何電腦都會出現(xiàn)這種情況。
服務器宕機,ping或者ssh這是最簡單的做法,但真正的工程實踐,沒這么簡單。
如果想要獲知服務器宕機怎么辦?用戶可以通過服務器宕機實時檢測:
1)發(fā)現(xiàn)宕機。
2)提前告警。
3)告知宕機的詳細原因,如硬件故障,內核bug,網絡異常等等。
4)自動報修生成工單。
我們用戶要知道,進行全網物理機宕機準確探測與實時發(fā)現(xiàn),可以給宕機分析提供第一現(xiàn)場,獲取第一現(xiàn)場的日志。也可以盡早將宕機數(shù)據(jù)推送給業(yè)務或運營感知并處理,如自動報修,業(yè)務遷移等,從而盡可能將業(yè)務影響降到最低。
更重要的是,準確的服器宕機發(fā)現(xiàn)數(shù)據(jù)可以為宕機預測提供準確的標注數(shù)據(jù),為后期宕機預測提供數(shù)據(jù)基礎,并且這些數(shù)據(jù)提供給運營部門進行整體分析,提升處理效率。
那么,用戶怎樣可以準確發(fā)現(xiàn)服務器宕機呢?減少誤報呢?可以有以下操作,比如:
1、異常排除
排除非物理機器,將系統(tǒng)中暫時不關注的VM等產生的異常信息排除掉。
排除非業(yè)務狀態(tài)的機器,如裝機狀態(tài)中的,包括生產中,維修中,遷移中,重裝中,銷毀中,重啟中,無管控狀態(tài),只監(jiān)控正常狀態(tài)的機器。
排除非正在工作的機器,如非working狀態(tài)機器。
2、網絡干擾排除
宕機分析中,較多誤報是由于網絡問題干擾,無法準確判斷出物理機是否宕機,有可能是網絡問題。
排除上網絡設備異常導致的誤報,包括機房斷網演練,小面積網絡故障,上聯(lián)網絡故障,如通過探測丟包情況,使用一些邏輯初步判斷網絡問題。
服務器本身未丟包的誤報,除了需要過濾出網絡問題,還要通過丟包數(shù)據(jù)分析,過濾掉SA誤報問題, SA異常會上報心跳異常,被誤理解為宕機。
icmp及tcp丟包分析,icmp采集頻率為固定數(shù)秒,tcp采集頻率固定數(shù)秒,包括多個不同大小包(16,32,64,128,256等)的丟包情況,根據(jù)分析時間窗內兩項數(shù)據(jù)的丟包情況
3、特殊情況干擾排除
個別機房有時候會出現(xiàn)大面積風暴式的無故心跳異常,同時網絡ping包異常,但上聯(lián)網絡設備ping包正常,這種誤報,一般根據(jù)具體case具體進行針對性的分析。如根據(jù)監(jiān)控每個機房的上報頻率,排除干擾。
4、進一步識別誤報
至此,大部分干擾已經過濾掉,但仍有一部分誤報隱藏其中。比如心跳異常,ping異常,都合乎宕機判斷的邏輯,會導致誤判成宕機,如導致網卡被打爆,或者重試率高,這種是業(yè)務原因導致網絡異常,但業(yè)務認為不是異常,需要排除掉。再例如服務器并沒有掛掉,但是IO延時和資源占用率各項指標都不正常等場景。針對以上等情況,增加uptime判斷以及帶外日志分析排查。
宕機時間點探測uptime確定是否發(fā)生重啟。
進一步通過分析日志是否連續(xù),判斷是否發(fā)生重啟。
日志重啟特征值匹配,確認是否發(fā)生重啟。
如果還不能確定,使用uptime的時間窗技術進行重啟。
仍不能確定的待處理,進入長尾處理名單。
5、長尾再次處理
未確認的待處理的,會加入到長尾列表中,像這種分鐘級的心跳異常,ping異常,但串口日志一直正常輸出的情況,一般就是某種死機,死到連網絡都不通的場景。會觀察一段時間,一個固定時間窗內仍未恢復或重啟的話,就暫時報宕機。后期會把這種死機單獨找劃分歸類。
6、心跳源檢測異常
顧名思義,通過心跳源,初步發(fā)現(xiàn)異常。通常心跳變化會有三類消息,update消息,delete消息和insert消息。心跳邏輯在于,正常情況下SA服務端與NC建立長連接,每數(shù)秒緩存一次心跳,每幾分鐘打包上報一次,但當NC異常時,長連接感知后,立即上報異常,并修改路由表。所以心跳異常做到秒級感知。
update消息,在有心跳發(fā)生變化情況下都會有,心跳異常和心跳恢復正常時都會發(fā)起,是主要的心跳來源。
delete消息,在心跳異常,并且SA判斷ping不通,且ssh不通情況下發(fā)起,刪除該條消息,避免延遲太長。
insert消息,在新增加機器, 或者重裝后重新上位的機器發(fā)起,該消息對宕機發(fā)現(xiàn)價值不大,配合uptime使用。
心跳源檢測任務邏輯,主要是監(jiān)聽并緩存uptime消息,同時避免時間窗內多次消息沖突,導致信息被覆蓋。
上面已經介紹這么多了,到底效果會怎么樣呢?
從準確率和覆蓋率來看:
準確率:目前發(fā)現(xiàn)的服務器宕機中有很高準確度,可以區(qū)分出真正宕機或者未宕機。而判斷為宕機的數(shù)據(jù)中,也存在少量的,由于缺少相關信息導致誤報,該部分將進一步優(yōu)化,逐漸降低誤報,在新的措施之后,該比例會接近0。
覆蓋率:當前統(tǒng)計的覆蓋率已經能很好的支撐日常服務器宕機處理,該數(shù)據(jù)在有足夠的特征后,會進一步提升。
目前,服務器宕機感知是宕機分析的基礎,通過服務器宕機實時檢測,會把相應的宕機原因分布整理出來,明確具體的原因,達成服務器極致可靠性。
看了以上騰佑科技小編為各位整理的關于服務器“異常”的6個可能性預警的介紹,希望用戶在遇到服務器宕機的時候會第一時間知道,上面所介紹的服務器宕機的一系列問題,希望能幫助到想要了解服務器宕機方面信息的朋友們。