0x01 前言

10月28日在B站进行的主题为ELK安装与初始化设置的直播在结束之前翻车了。以下是当天的翻车现场:

因为直播时间长达2小时,所以视频分为Part1和Part2,在Part2的最后,已经完成ELK的安装配置,但解析日志的时候出现乱码,而且解析失败:

因为是在直播,而且时间已经很紧张了,当出现问题时我也是一脸懵逼。但问题已经出现,就得找到原因。因此,在第二天,我写了这篇文章。

0x02 DEBUG

出现上图中的乱码问题一般是由于日志文件编码问题导致的,而且我在准备测试用日志文件的时候是在windows系统上进行,所以当时我第一反应是日志编码问题。

在第二天我检查该日志文件的编码:

文件编码没问题,filebeat能正常那个读取,而且logstash也是可以解析的。这时候就剩下以一个原因了:logstash解析出错。

我回过头来检查logstash与filebeat的配置文件:

我在直播中给logstash配置了监听2个端口的配置文件:

在直播的环境中,因为日志文件是通过filebeat传入的,所以需要传到beats插件监听的5016端口,而不是TCP或UDP插件监听的5014端口。

然后检查filebeat的output部分:

发现filebeat将日志传输到5014端口,因为filebeat的数据使用了自由的编码,所以在logstash中需要用beats插件才能解析,当数据传输到TCP或UDP插件的时候,则会出现解析异常的问题。最终呈现出来的就是乱码。

这部分的错误我也从另一个特征识别到:在kibana中查看到的信息中没有我自定义的“tags”字段:

正常情况下应该是这样的:

出现这种情况只有一种可能,就是logstash无法正常解析filebeat传输过来的数据,这时候只需要检查filebeat与logstash的配置文件即可。

0x03 清理

找到原因后,需要重新配置filebeat与索引的相关信息。因为我这是全新的测试环境,因此可以通过删除filebeat registry文件的方式重置filebeat的记录:

注意!请不要删除生产环境中的这个问题件,这将会导致filebeat重新读取文件,使数据重复!

在重新启动filebeat之前还需要对索引继续一些操作。在这里我把旧的索引删除,新建一个索引并分配一个别名。先打开kibana的dev tools:

将旧的索引删除:

再新建索引并指向别名:

最后启动filebeat即可:

最终,分析出来的数据如下:

0x04 结语

其实整体的搭建思路没问题,就是不细致,直播前的准备不充分。

因为这次直播讲的内容太多,直播时间长达2小时,在以后的直播会将各部分内容拆分,将时间控制在45分钟至1小时以内。