早上6点钟, 收到zabbix的告警, 说一台服务器重启了, 回到公司马上查看系统日志,发现只有这些记录: 　　这不是坑爹么! 肯定是意外关闭啊, 但是为什么会是意外关闭呀? 　　这个问题后续需要再跟进, 现在暂不讨论, 因为有个更加急迫的故障需要处理: filebeat无法启动. 　　既然系统无法启动, 咱们去服务管理那边试下: 　　运行 - 输入services.msc；找到filebeat的服务后, 手动启动失败, 得到错误: 　　在谷歌上搜索一番之后, 找到一个解决办法: 　　我的电脑-->右键-->管理-->本地用户和组; 选择“组”-->双击Administrators-->单击“添加”-->单击“高级”-->单击“立即查找”-->在下面的列表中选择Network Service用户-->两次单击“确定”-->加入 　　但是并没有什么卵用, 去filebeat的根目录, 尝试手动运行 filebeat.exe, 发现是可以执行的, 这代表程序没有问题, 于是怀疑是机器重启导致服务管理报错了, 于是尝试重装filebeat服务, 但是服务启动还是失败 　　查看filebeat的日志, 发现有段报错: 　　Error decoding old state: invalid character '\x00' looking for beginning of value 　　大意就是: 在解码旧状态时, 有无效的字符'\x00', 这个很像json解析失败的报错! 难道这个跟json有关系么?这个json肯定是和日志的json无关的, 应该是某些配置的json有关, 但是会改动的配置不多, 那应该就是存放记录文件偏移量的配置: registery. 　　于是在去根目录的data目录检查下面的registery. old 和 registery, 但是都是很正常的两个json文件, 并没有所谓的 '\x00', 这就尴尬了.. 　　考虑到手动执行没问题, 但是通过服务管理器启动却失败, 难道是启动方式的姿势不对导致? 事不宜迟, 将服务器启动的方式拷贝出来试下: filebeat-右键属性-可执行文件的路径 　　在黑漆漆的CMD窗口运行下: 　　虽然得到同样的报错, 不过我们好像发现有点问题了, -path.data "c"\\ProgramData\\filebeat", 这个目录应该就是存放文件偏移位置的目录, 但是为什么不是filebeat的根目录下呢? 　　难道说这个是服务注册时, 默认的? 那可能出问题的json文件就是在这里了, 于是直接去目录查看, 还真的有registry文件, 用notepadd++ 打开, 终于找到原因了: 　　文件内容全都是乱码, 原因应该是, 系统异常关闭, 程序没有正常退出, 导致写入了乱码, 使得filbeat重新读取时, 无法解析. 　　将文件删除后, filebeat启动正常! 这次故障排查暂告一段落,感谢大家.