轻松测试 logstash 的配置文件

配置文件本身非常脆弱！所以修改配置文件自然会引入部署失败的风险。如果能够对配置文件进行自动化测试将会极大的降低这种风险。本文将介绍一个可以自动化测试 logstash 配置文件的工具，让大家可以像写单元测试用例一样为 logstash 配置文件创建测试 case，并以快速迭代的方式变更 logstash 配置文件。

噩梦

在很多真实环境中，变更 logstash 的配置文件几乎是个噩梦。日志不是结构化的格式(甚至是乱七八糟！)，导致我们几乎必须一个一个地处理日志，并对解析什么和不解析什么做出逻辑判定。这会导致我们在 logstash 的配置文件中写出复杂的日志处理逻辑。更加悲催的是，我们编写的仅仅是一个配置文件，大多数时候你找不到像 VisualStudio 那样豪华的带有拼写检查和语法检查的编辑工具。所以我们迫切的需要一个可以对 logstash 的配置文件做单元测试的工具，让我们更好的控制变更、执行迭代。

logstash-test-runner

logstash-test-runner 就是这样一个可以让我们应用 DevOps 原则来解决这个问题的工具。它具有下面几个特点：

  • 它是一个测试框架
  • 非常容易写测试用例
  • 不用学习一个新的 DSL(Domain-Specific-Language)
  • 能够快速的获得反馈

logstash-test-runner 的作者应该是饱受 logstash 的配置文件蹂躏之后创建的这个工具，所以这是一个写给自己用的工具，在使用的时候你能够切身体会到它的便利！

前提条件

运行 logstash-test-runner 依赖于下面三个条件：

  • Docker
  • NodeJS > v8
  • Bash > v4

其中 logstash 的测试用例是在 docker 容器中运行的，默认使用的镜像中 logstash 的版本为 5.5.1，我们可以通过第二个命令行参数指定其它的版本。

NodeJS 程序用来对比实际运行的输出结果与期望的输出结果。

logstash-test-runner 其实就是一个 Bash 脚本，把上面的工具组织起来完成任务。

在运行 logstash-test-runner 前请确保你的环境满足上述条件。然后从这里克隆 logstash-test-runner。如果你确定你要运行的 logstash 的版本，最好是提前先把对应的容器镜像拉下来，比如笔者最常用的是 logstash 6.2.4：

$ docker pull docker.elastic.co/logstash/logstash:6.2.4

运行下内置的 demo

准备就绪，让我们先运行下 logstash-test-runner 内置的 demo 体验一下。进入到 logstash-test-runner 目录下，执行下面的命令：

$ npm install
$ ./test.sh __tests__

test.sh 脚本的第一个参数是保存测试用例的根目录，第二个参数是 logstash 的 docker 镜像。也可以不指定 logstash 镜像，默认使用的镜像中的 logstash 版本为 5.5.1。该命令执行的结果如下：

__tests__ 目录的结构如下：

每个子目录代表一个测试用例，demo 中有三个测试用例，分别是 clustering、crawlers 和 mongo。每个测试用例下有三个文件，分别是 input.log、logstash.conf 和 output.log，他们的名称是固定的。input.log 模拟日志文件，保存的是日志记录；logstash.conf 则是待测的 logstash 配置文件；output.log 中是需要我们写入的期望结果(这就是 logstash 版的单元测试呀！)。

添加自己的测试用例

下面我们添加自己的测试用例来测试 multiline 功能(把应用程序中的异常堆栈合并到一条日志记录中)。先创建目录 __nick__/mlines，然后在 __nick__/mlines 目录中创建文件 input.log、logstash.conf 和 output.log。input.log 文件的内容如下：

2019-1
hello
world
2019-2
aa
2019-3
  bb
2019-4

模拟的日志记录以日期开头，非数字开头的记录则是异常堆栈。

logstash.conf 文件的内容如下：

input {
  stdin {
    codec => multiline {
      pattern => "^\d"
      negate => "true"
      what => "previous"
    }
  }
}
filter {
  mutate {
    replace => {
      "host" => "testing_host"
    }
  }
}

filter 中设置 host 主要目的是让测试用例忽略真正的 host 值(在容器中运行这个值是随机的字符串，无法执行比较操作，所以总是让他输出 testing_host)。

output.log 文件的内容如下：

{"tags":["multiline"],"host":"testing_host","message":"2019-1\nhello\nworld","@version":"1","@timestamp":"2019-03-05T09:30:26.820Z"}
{"tags":["multiline"],"host":"testing_host","message":"2019-2\naa","@version":"1","@timestamp":"2019-03-05T09:30:26.823Z"}
{"tags":["multiline"],"host":"testing_host","message":"2019-3\n  bb","@version":"1","@timestamp":"2019-03-05T09:30:26.824Z"}

这是我们期望 logstash 输出的 JSON 格式的日志记录。当然，在默认情况下 logstash-test-runner 会忽略 @timestamp。

接下来执行下面的命令运行测试：

$ ./test.sh __nick__ docker.elastic.co/logstash/logstash:6.2.4

该命令中笔者指定了 logstash 镜像，所以测试用例都是由 logstash 6.2.4 执行的，结果如下：

上图显示测试用例都通过了。如果有测试用例失败，就会输出详细的失败信息，非常有助于排除问题。

难点在于写 output.log

logstash-test-runner 非常简单易用，其实在整个使用过程中，笔者觉得写 output.log 是最困难的。因为你很难根据日志记录和 logstash 的配置文件直接推导出 logstash 输出的记录应该是什么样子的。logstash-test-runner 直接把 logstash 输出的日志记录输出到了 console 中：

这样我们就可以轻松的根据 console 中的输出来调整 output.log 文件了！

总结

使用者为自己编写的工具往往是直击痛点，logstash-test-runner 就是这样的工具。它让我们可以快速迭代 logstash 的配置变更。我们还可以自动化的执行 logstash-test-runner，作为 CI/CD 的一部分，从而确保每个配置变更都通过了测试。
对 logstash 之类的基础设施工具进行测试符合 DevOps(构建→测试→发布→运行)的实践。我想测试基础设施配置的实践会越来越普遍，并且在提高基础设施可靠性和交付方面体现出巨大的价值。

参考：
Dealing with Tight-Coupling
agolo/logstash-test-runner

原文地址：https://www.cnblogs.com/sparkdev/p/10564287.html

时间： 2024-10-14 05:04:27

轻松测试 logstash 的配置文件的相关文章

logstash 对配置文件conf敏感信息，密码等加密

logstash的配置文件conf经常会涉及敏感信息,比如ES,mysql的账户密码等,以下使用logstash导入mysql为例子,加密隐藏mysql的密码. 在向keystore中添加key及其secret值之后,你可以在配置敏感设置时使用key代替secret值. 引用key的语法与环境变量的语法相同:${KEY},KEY是key的名称. 例如,假设keystore包含一个名为ES_PWD的key,其值为yourelasticsearchpassword: 在配置文件中使用:output

使用Adobe Edge Inspect在各种设备中轻松测试同一页面

有过移动网站开发经历的开发者都知道,在各种设备中测试同一页面是一项非常繁琐的工作.现在,我们可以使用Adobe Edge Inspect来简化这一工作.如果使用Edge Inspect,可以在各种设备的浏览器中同时浏览同一页面.另外,该软件中也提供了用于调试的工具,可以轻松调试页面上所存在的任何问题.Web网站所需支持的设备越多,使用Edge Inspect软件所能节省的时间及工作量也将越多. 本文介绍Adobe Edge Inspect的安装及使用方法.虽然Adobe Edge Inspect

Asp.Net Core 轻松学-玩转配置文件

目录 前言 另类方式使用 hosting.json 使程序运行于多个端口 结语 前言 ????在 .NET Core 项目中,配置文件有着举足轻重的地位:与.NetFramework 不同的是,.NET Core 的配置文件都以 .json 结尾,这表示一个标准的 json 格式的文件:一个标准的 Asp.Net Core MVC 项目,一定带着一个 appsettings.json 文件,该文件便是项目默认配置文件,这和基于 .NetFramework 创建的 Asp.Net Web Appl

logstash server 配置文件

input {           redis {                   host => "10.10.45.200"                   data_type => "list"                   key => "elk_frontend_access:redis"                   port =>"5379"           }  

python程序如何在生产和测试环境自动调用对应的配置文件

经常在开发项目中,测试环境和正式环境的配置文件总是不同的.在测试或者发布正式环境的时候,总要去手动更改配置文件中的参数(如数据库的配置等),次数多了,总说很烦心的.如何实现程序自动根据环境来调用对应的配置信息呢?这里,主要利用python包的__init__.py文件来控制配置文件. 在调用python包配置文件的时候,首先会初始化__init__.py里内容.因此,可以在此文件进行控制. 如下图demo所示: 本机ip如下: 程序demo: 这样就轻松实现了正式环境和测试环境的配置文件的自动调

spring boot使用profile来区分正式环境配置文件与测试环境配置文件

转载请在页首注明作者与出处 一:前言 经常在开发的时候,项目中的配置文件,在个人开发的时候有一套配置文件,在测试环境有一套配置文件,在正式环境有一套配置文件,这个时候如果配置文件复杂,需要改的东西就特别多,而且由于迭代过程中,需要经常切换,难免发生问题. 二:SpringBoot的解决方式 其实准备的说应该说是spring的解决方式,因为spring boot中的这些也都是基于spring中的功能,当然spring boot肯定是要简单的多的. 2.1:准备多份配置文件 先准备两个文件放在src

logstash的各个场景应用（配置文件均已实践过）

场景: 1) datasource->logstash->elasticsearch->kibana 2) datasource->filebeat->logstash-> elasticsearch->kibana 3) datasource->filebeat->logstash->redis/kafka->logstash-> elasticsearch->kibana 4) kafka->logstash->

SpringBoot的Profiles根据开发环境和测试环境载入不同的配置文件

参考:https://www.cnblogs.com/bjlhx/p/8325374.html 1.需要有一个默认的配置文件,然后一个正式的配置文件,一个测试的配置文件.激活配置项,默认的配置文件application.properties也会加载进去的.编程的方式指定生效的profile. 默认的配置文件application.properties配置文件,然后再创建两个配置文件,一个是application-dev.properties,一个是application-test.propert

logstash使用操作部分

1.logstash的概念及特点.概念:logstash是一个数据采集.加工处理以及传输(输出)的工具.特点: - 所有类型的数据集中处理 - 不同模式和格式数据的正常化 - 自定义日志格式的迅速扩展 - 为自定义数据源轻松添加插件 2.logstash安装配置.①.下载安装[[email protected] ~]# wget https://download.elastic.co/logstash/logstash/packages/centos/logstash-2.3.4-1.noarc