logstash-filter-verifiter学习笔记

​背景：

最近架构师让我调研一个小工具。这个工具要实现检验logstash配置的运行结果是否达到预期。我们知道logstash的运行主要是要启动进程的。比如：

./logstash -f x.conf

如果我们大量的要检测是否达到预期，那么启动大量进程，资源耗费巨大，时间尺度太长。最后在架构师的指点下，作者主要调研了logstash-filter-verifiter这个工具。

​简介：

​

简单介绍一下：这个LFV主要用来比较logstash配置文件是否达到预期，或者说是用来做单元测试的。

最新版本的LFV提供了两种模式，分别为单体模式和守护者进程模式。单体模式就是针对一个测试用例启动一个lgs实例，所以时间消耗很大。为了避免这种问题提供了守护者进程模式。守护者进程模式需要用一个LFV作为守护者进程去实例化一个LGS进程池，进程池默认2个LGS进程。另外需要启动一个LFV作为客户端。客户端进程于守护者进程的通信采用UDS+Grpc的方式，也就是说守护者进程和客户端进程需要部署在同一台机器上。

守护者进程启动方式：

./logstash-filter-verifier daemon start -logstash-path=/mnt/d/logstash/bin/logstash

客户端进程启动方式：

./logstash-filter-verifier daemon run -pipelines /mnt/d/logstash/tjl/pipline.yml --testCases /mnt/d/tjl/*.ymal --addmissId

守护者模式是通过pipeline去实现的，所以需要编写一个pipeline，并指定配置文件地址。最后需要在启动脚本中指定测试用例的地址。这块详细的可以看下github文档，作者就不细说了。

​守护者模式大概流程

通过测试，发现守护者模式能达到一秒一个用例的速度。为了发掘其中的原理，作者看了下源码。在此说一下其中的大概过程。

首先是UDS进程通信，在此基础上加上了Grpc的包装。守护者进程在初始化时候实例化两个LGS实例，并以文件方式维护session，守护者进程只运行配置，客户端进程负责收发配置并进行预期比对。主要流程是客户端进程调用守护者创建session，并设置线程池中的LGS信号，然后将其缓存到Session中，最后将SessionId返回给客户端。客户端拿到SessinId然后发起测试用例执行，因为前一步拿到sessionid因此其他客户端无法抢占，这块获取session是代码层面的锁机制。如果创建session失败则快速失败，客户端直接抛出异常。测试用例执行完成以后，客户端对结果进行预期检测，并将报表返回。除此之外要金介绍的是守护者模式为什么快，主要是采用了LGS的热加载。

​单机模式流程

单机模式相对简单，低层实现机制主要通过不断的启动LGS进程实现。通过缓存执行结果和预期输出文件然后采用第三方组件的模式进行比对，再出报表的方式。

​其他

通过实例验证，​LFV支持Grok等插件，支持自定义LGS插件。但是LGS守护者模式只支持LGS 7.7以后得版本。

LFV的守护者模式只有Beta版本，还没有提供正式版本，目前社区活跃度低。

​结论

​LFV基本可以满足我们大批量检测LGS配置的能力，但为了解耦，LFV必须集群部署。除此之外LFV的守护者进程模型势必导致并发执行测试的大量失败情形，因此这块可采用MQ去解耦，采用异步双队列做消息传递+LFV集群配置。为达到高可用的目的，还需要自行实现LFV对接MQ的能力。

听首歌，祝大家好梦呦！