早上6點(diǎn)鐘, 收到zabbix的告警, 說(shuō)一臺(tái)服務(wù)器重啟了, 回到公司馬上查看系統(tǒng)日志,發(fā)現(xiàn)只有這些記錄: 　　這不是坑爹么! 肯定是意外關(guān)閉啊, 但是為什么會(huì)是意外關(guān)閉呀? 　　這個(gè)問(wèn)題后續(xù)需要再跟進(jìn), 現(xiàn)在暫不討論, 因?yàn)橛袀€(gè)更加急迫的故障需要處理: filebeat無(wú)法啟動(dòng). 　　既然系統(tǒng)無(wú)法啟動(dòng), 咱們?nèi)シ?wù)管理那邊試下: 　　運(yùn)行 - 輸入services.msc；找到filebeat的服務(wù)后, 手動(dòng)啟動(dòng)失敗, 得到錯(cuò)誤: 　　在谷歌上搜索一番之后, 找到一個(gè)解決辦法: 　　我的電腦-->右鍵-->管理-->本地用戶和組; 選擇“組”-->雙擊Administrators-->單擊“添加”-->單擊“高級(jí)”-->單擊“立即查找”-->在下面的列表中選擇Network Service用戶-->兩次單擊“確定”-->加入 　　但是并沒有什么卵用, 去filebeat的根目錄, 嘗試手動(dòng)運(yùn)行 filebeat.exe, 發(fā)現(xiàn)是可以執(zhí)行的, 這代表程序沒有問(wèn)題, 于是懷疑是機(jī)器重啟導(dǎo)致服務(wù)管理報(bào)錯(cuò)了, 于是嘗試重裝filebeat服務(wù), 但是服務(wù)啟動(dòng)還是失敗 　　查看filebeat的日志, 發(fā)現(xiàn)有段報(bào)錯(cuò): 　　Error decoding old state: invalid character '\x00' looking for beginning of value 　　大意就是: 在解碼舊狀態(tài)時(shí), 有無(wú)效的字符'\x00', 這個(gè)很像json解析失敗的報(bào)錯(cuò)! 難道這個(gè)跟json有關(guān)系么?這個(gè)json肯定是和日志的json無(wú)關(guān)的, 應(yīng)該是某些配置的json有關(guān), 但是會(huì)改動(dòng)的配置不多, 那應(yīng)該就是存放記錄文件偏移量的配置: registery. 　　于是在去根目錄的data目錄檢查下面的registery. old 和 registery, 但是都是很正常的兩個(gè)json文件, 并沒有所謂的 '\x00', 這就尷尬了.. 　　考慮到手動(dòng)執(zhí)行沒問(wèn)題, 但是通過(guò)服務(wù)管理器啟動(dòng)卻失敗, 難道是啟動(dòng)方式的姿勢(shì)不對(duì)導(dǎo)致? 事不宜遲, 將服務(wù)器啟動(dòng)的方式拷貝出來(lái)試下: filebeat-右鍵屬性-可執(zhí)行文件的路徑 　　在黑漆漆的CMD窗口運(yùn)行下: 　　雖然得到同樣的報(bào)錯(cuò), 不過(guò)我們好像發(fā)現(xiàn)有點(diǎn)問(wèn)題了, -path.data "c"\\ProgramData\\filebeat", 這個(gè)目錄應(yīng)該就是存放文件偏移位置的目錄, 但是為什么不是filebeat的根目錄下呢? 　　難道說(shuō)這個(gè)是服務(wù)注冊(cè)時(shí), 默認(rèn)的? 那可能出問(wèn)題的json文件就是在這里了, 于是直接去目錄查看, 還真的有registry文件, 用notepadd++ 打開, 終于找到原因了: 　　文件內(nèi)容全都是亂碼, 原因應(yīng)該是, 系統(tǒng)異常關(guān)閉, 程序沒有正常退出, 導(dǎo)致寫入了亂碼, 使得filbeat重新讀取時(shí), 無(wú)法解析. 　　將文件刪除后, filebeat啟動(dòng)正常! 這次故障排查暫告一段落,感謝大家.