Windows服务器重启导致filebeat无法启动

系统 Windows 服务器
文件内容全都是乱码, 原因应该是, 系统异常关闭, 程序没有正常退出, 导致写入了乱码, 使得filbeat重新读取时, 无法解析.

早上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启动正常! 这次故障排查暂告一段落,感谢大家.

责任编辑:武晓燕 来源: oschina博客
相关推荐

2022-03-31 10:00:53

NVMe 驱动器Linux 服务器谷歌

2012-09-20 15:11:31

Unix服务器

2019-08-19 08:00:00

服务器Ubuntu Live漏洞

2010-12-21 09:27:06

Windows服务器

2011-05-13 10:19:03

2011-12-31 08:58:04

服务器重启Unix

2011-09-05 14:00:12

容错服务器stratus

2014-12-26 09:52:08

Go

2018-05-14 10:16:34

服务器机房识别

2023-02-17 12:55:23

微软Windows

2022-10-25 08:56:16

2010-12-21 14:26:18

2022-01-18 14:08:38

微软/Windows10Windows

2020-07-15 10:05:47

微软浏览器Windows

2021-09-09 14:54:39

REvil勒索团伙网络攻击

2019-03-01 15:57:00

服务器硬件数据量

2013-05-14 15:47:27

MySQL监控错误日志

2023-12-13 18:46:51

Docker容器进程

2023-02-17 13:31:30

微软Windows 11

2023-03-01 20:44:27

微软Windows
点赞
收藏

51CTO技术栈公众号