请教logstash的多行日志问题，最后一行的日志总是不能获取

只是c:/datatxt里面的数据时静态的，logstash当然没法识别文件中的数据什么时候结束，现在你可以这样测试：

1删掉datatxt里面的数据

2把2014 aaa

2014 bbb

2014 ccc 这三行数据写到testtxt中

3cat testtxt >> datatxt

4观察结果，三行都出来了

5注意是在linux环境下测试，不是windows

6good luck to you

filebeat中message要么是一段字符串，要么在日志生成的时候拼接成json然后在filebeat中指定为json。但是大部分系统日志无法去修改日志格式，filebeat则无法通过正则去匹配出对应的field，这时需要结合logstash的grok来过滤，架构如下：

以系统登录日志格式为例：

这里需要定义两个field，Status和ClientIP来获取某个IP登录服务器的频率和状态

而单filebeat输出信息为：

message为字符串，且filebeat无法通过正则匹配出想要的数据，所以filebeat只负责在服务器上收索转发日志数据，过滤功能则交给logstash来处理，配置如下：

filebeat_sshyaml

logstash_sshconf

21 日志的采集

灵活性是我们选择日志采集方案更看重的因素，所以logstash属于首先方案， 它可以兼顾多种不同系统和应用类型等因素的差异，从源头上进行一些初步的日志预处理。

logstash唯一的小缺憾是它的不轻便， 因为它是使用jruby开发并跑在java虚拟机上的agent， 当然啦，同时也是优点，即各种平台上都可以用。

22 日志的汇总与过滤

kafka在我们挖财已经属于核心的中间件服务， 所以， 日志的汇总自然而然会倾向于使用kafka。

日志的过滤和处理因为需求的多样性，可以直接对接订阅kafka， 然后根据各自的需求进行日志的定制处理， 比如过滤和监控应用日志的异常，即使通过zabbix进行预警； 或者数据仓库方面在原始日志的基础上进行清洗和转换，然后加载到新的数据源中；

23 日志的存储

原始的日志存储我们采用ElasticSearch， 即ELK技术栈中E的原本用途，遵循ELK技术栈中各个方案之间的通用规范， 比如日志如索引采用logstash与kibana之间约定的index pattern。

日志的衍生数据则日志使用各方根据需求自行选择。

24 日志的分析与查询

ELK技术栈中的Kibana已经可以很好的满足这一需求，这里我们不折腾。

3 需要解决哪些技术问题？

因为我们在ELK技术栈的处理链路上插入了一些扩展点，所以，有些问题需要解决和澄清

31 logstash与kafka的对接

ELK技术栈中， Logstash和Elastic Search是通过logstash的elasticsearch或者elasticsearch_>

Logstash是一个接收，处理，转发日志的工具。支持系统日志，webserver日志，错误日志，应用日志，总之包括所有可以抛出来的日志类型。

在一个典型的使用场景下(ELK)：用Elasticsearch作为后台数据的存储，kibana用来前端的报表展示。Logstash在其过程中担任搬运工的角色，它为数据存储，报表查询和日志解析创建了一个功能强大的管道链。Logstash提供了多种多样的 input,filters,codecs和output组件，让使用者轻松实现强大的功能。

依赖条件：JAVA

Logstash运行仅仅依赖java运行环境(jre)。各位可以在命令行下运行java -version命令 显示类似如下结果：java -version

java version "170_45"

Java(TM) SE Runtime Environment (build 170_45-b18)

Java HotSpot(TM) 64-Bit Server VM (build 2445-b08, mixed mode)

为了确保成功运行Logstash建议大家使用较近期的jre版本。 可以获取开源版本的jre在：>

当需要做一个日志系统时，可能第一时间会想到ELK全家桶。

ELK分别表示：Elasticsearch , Logstash, Kibana 。他们组成了一套完整的日志系统的解决方案，方便我们使用。

在使用Logstash进行收集的时候，仅仅需要简单的一个配置文件就可以启动一个logstash-agent来进行日志收集。

上述示例简单的从某个文件目录下收集日志打印到控制台。

然后我们启动这个logstash-agent: bin/logstash -f conf/datafall/testconfig

往日志文件push数据：

echo "hello world" >> 1txt

就可以看到控制输出：

到此时是正确的一个流程。

误 *** 作开始了：

但是我们以 vim 命令进入日志文件的时候，在文件末尾追加一个数据 happy ，此时控制台会输出：

会发现logstash会从文件开始从新读取数据（此时就会造成数据的重复收集）。

为什么会出现这种情况呢？

Logstash有一个有趣的组件或功能叫做sincedb。该文件存储了当前logstash-agent收集的文件日志的offset。在前面 testconfig 配置了sincedb的位置。

如果不配置，它会默认在当前用户的根目录下创建一个 sincedb开头的文件 。

sincedb的具体内容：

看到上述内容，发现我们明明只收集了一个日志文件，为什么会又多出来一条记录呢。

这就要追述到使用 vim 命令编辑文件并保存时。相当于会创建拥有全新inode的文件。

此时logstash会发现一个文件名一样但是inode却不一样的文件。logstash还是会进行文件的收集工作。

通过debug模式可以看到更详细的细节：

从上述日志可以看出logstash会产生监控到一个新的inode文件，并且在原有 sincedb 文件中并没有这个inode记录，因此logstash会从头开始收集这个日志文件中的日志。

当我们在使用logstash收集日志文件时，尽量不要用 Vim、vi 命令去打开日志文件，尽量使用 cat、more 这之类的。

注：

inode: *** 作系统中的文件数据都储存在"块"中，当然，我们还必须找到一个地方储存文件的元信息，比如文件的创建者、文件的创建日期、文件的大小等等。这种储存文件元信息的区域就叫做inode，中文译名为"索引节点"

inode包含文件的元信息，具体来说有以下内容：

一般情况下，文件名和inode号码是"一一对应"关系，每个inode号码对应一个文件名。

vim、vi:为什么在编辑的时候会产生一个新的inode: 在使用vim打开文件是，会把当前打开的文件放入buffer中(内存)，然后进行 *** 作。当我们保存时，相当于替换了原来的文件。所以会有个新的inode的文件产生。

以上就是关于请教logstash的多行日志问题，最后一行的日志总是不能获取全部的内容，包括:请教logstash的多行日志问题，最后一行的日志总是不能获取、filebeat + logstash 对message提取指定字段、有熟悉elk 日志系统的吗等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！