系统测试
Elastic 程序包由数据流组成。系统测试会练习程序包数据流的端到端数据流——从接收来自程序包集成服务的数据,一直到将其索引到 Elasticsearch 数据流中。
从概念上讲,运行系统测试涉及以下步骤
- 部署 Elastic Stack,包括 Elasticsearch、Kibana 和 Elastic Agent。 此步骤需要时间。 因此,您通常应该执行一次,作为在多个数据流上运行系统测试的先决条件。
- 使用 Fleet 注册 Elastic Agent(在 Kibana 实例中运行)。 也可以执行此步骤一次,作为先决条件。
- 根据正在测试其数据流的 Elastic 程序包,部署程序包集成服务的实例。
- 创建测试策略,该策略为单个程序包配置单个数据流。
- 将测试策略分配给已注册的 Agent。
- 等待一段合理的时间,以便 Agent 从集成服务收集数据并将其索引到正确的 Elasticsearch 数据流中。
- 根据
@timestamp
查询前 500 个文档进行验证。 - 验证是否为索引文档中包含的字段定义了映射。
- 验证包含在
_source
中的 JSON 数据类型是否与为该字段声明的映射兼容。 - 删除测试工件并关闭程序包集成服务的实例。
- 系统测试所有所需的数据流后,关闭 Elastic Stack。
目前,系统测试存在限制。 主要问题是:* 无法断言索引数据与文件中的数据匹配(例如,黄金文件测试)。
程序包具有特定的文件夹结构(仅显示相关部分)。
<package root>/
data_stream/
<data stream>/
manifest.yml
manifest.yml
要定义系统测试,我们必须在至少一个级别上定义配置:程序包级别或数据流级别。
首先,我们必须定义用于部署程序包集成服务的配置。 我们可以在程序包级别定义它
<package root>/
_dev/
deploy/
<service deployer>/
<service deployer files>
或者数据流级别
<package root>/
data_stream/
<data stream>/
_dev/
deploy/
<service deployer>/
<service deployer files>
<服务部署器>
- 受支持的服务部署器的名称
docker
- Docker Composek8s
- Kubernetestf
- Terraform
使用 Docker Compose 服务部署器时,<服务部署器文件>
必须包含 docker-compose.yml
文件。 docker-compose.yml
文件定义了程序包的集成服务。 例如,如果您的程序包具有 logs 数据流,则来自程序包集成服务的日志文件必须写入卷。 例如,apache
程序包在其集成服务的 docker-compose.yml
文件中具有以下定义。
version: '2.3'
services:
apache:
# Other properties such as build, ports, etc.
volumes:
- ${SERVICE_LOGS_DIR}:/usr/local/apache2/logs
在此,SERVICE_LOGS_DIR
是一个特殊关键字。 我们稍后需要它。
使用 Terraform 服务部署器时,<服务部署器文件>
必须包含至少一个 *.tf
文件。 *.tf
文件使用 Terraform 语法定义基础架构。 基于 Terraform 的服务可以方便地启动使用选定的云提供商的资源并将其用于测试(例如,观察和收集指标)。
示例 main.tf
定义
variable "TEST_RUN_ID" {
default = "detached"
}
provider "aws" {}
resource "aws_instance" "i" {
ami = data.aws_ami.latest-amzn.id
monitoring = true
instance_type = "t1.micro"
tags = {
Name = "elastic-package-test-${var.TEST_RUN_ID}"
}
}
data "aws_ami" "latest-amzn" {
most_recent = true
owners = [ "amazon" ]
filter {
name = "name"
values = ["amzn2-ami-hvm-*"]
}
}
- AWS
请注意 TEST_RUN_ID
变量的使用。 它包含一个唯一的 ID,可以帮助区分在潜在的并发测试运行中创建的资源。
Kubernetes 服务部署器需要存在 _dev/deploy/k8s
目录。 它可以包含其他 *.yaml
文件,以在 Kubernetes 集群中部署自定义应用程序(例如,Nginx 部署)。 如果不需要任何资源定义(*.yaml
文件),则 _dev/deploy/k8s
目录必须包含一个 .empty
文件(以保留版本控制下的 k8s
目录)。
Kubernetes 服务部署器需要安装 kind 并使集群启动并运行
wget -qO- https://raw.githubusercontent.com/elastic/elastic-package/main/scripts/kind-config.yaml | kind create cluster --config -
在执行系统测试之前,服务部署器会将 Elastic Agent 的部署应用于集群一次,并将 kind 集群与 Elastic stack 网络连接起来 - 在 kind 集群中运行的应用程序可以访问 Elasticsearch 和 Kibana 实例。 Elastic Agent 的部署在测试后不会被删除,以缩短总测试执行时间,但可以重复使用。
了解如何为 Kubernetes 集成(pod
数据流)执行系统测试
elastic-package stack up -d -v
wget -qO- https://raw.githubusercontent.com/elastic/elastic-package/main/scripts/kind-config.yaml | kind create cluster --config -
elastic-package test system --data-streams pod -v # start system tests for the "pod" data stream
- 启动 Elastic stack
接下来,我们必须为要进行系统测试的每个数据流定义至少一个配置。 您可以为同一数据流定义多个测试用例。
提示:如果您计划仅定义一个测试用例,则可以考虑文件名 test-default-config.yml
。
<package root>/
data_stream/
<data stream>/
_dev/
test/
system/
test-<test_name>-config.yml
test-<test_name>-config.yml
文件允许您定义程序包和数据流级别变量的值。 例如,显示了 apache/access
数据流的 test-access-log-config.yml
如下所示。
vars: ~
input: logfile
data_stream:
vars:
paths:
- "{{SERVICE_LOGS_DIR}}/access.log*"
顶层 vars
字段对应于在 apache
程序包的 manifest.yml
文件中定义的程序包级别变量。 在上面的示例中,我们没有覆盖任何这些程序包级别变量,因此它们的默认值将在 apache
程序包的 manifest.yml
文件中使用。
data_stream.vars
字段对应于当前数据流(在上面的示例中为 apache/access
)的数据流级别变量。 在上面的示例中,我们覆盖了 paths
变量。 所有其他变量都使用其默认值填充,如 apache/access
数据流的 manifest.yml
文件中所指定。
请注意 {{SERVICE_LOGS_DIR}}
占位符的使用。 这对应于我们之前在 docker-compose.yml
文件中看到的 ${SERVICE_LOGS_DIR}
变量。 在上面的示例中,位于 Apache 集成服务容器内的 /usr/local/apache2/logs/access.log*
文件从 Elastic Agent 的角度来看可以在同一路径下使用。
当数据流的清单声明具有不同输入的多个流时,您可以使用 input
选项来选择要测试的流。 将测试其输入类型与 input
值匹配的第一个流。 默认情况下,将测试清单中声明的第一个流。
SERVICE_LOGS_DIR
占位符不是唯一可用于数据流的 test-<test_name>-config.yml
文件的占位符。 可用占位符的完整列表如下所示。
占位符名称 | 数据类型 | 描述 |
---|---|---|
主机名 |
字符串 | 集成服务的可寻址主机名。 |
端口 |
[]int | 集成服务正在侦听的可寻址端口的数组。 |
端口 |
整数 | Ports[0] 的别名。 为了方便起见提供。 |
Logs.Folder.Agent |
字符串 | Agent 可寻址的集成服务日志文件夹的路径。 |
SERVICE_LOGS_DIR |
字符串 | Logs.Folder.Agent 的别名。 为了方便起见提供。 |
根据 Handlebars 语法,test-<test_name>-config.yml
中使用的占位符必须用 {{
和 }}
分隔符括起来。
如上一节所述定义了两个级别的配置后,您就可以为程序包的数据流运行系统测试了。
首先,您必须部署 Elastic Stack。 这对应于 概念流程 部分中描述的步骤 1 和 2。
elastic-package stack up -d
要获得此命令的可用选项的完整列表,请运行 elastic-package stack up -h
或 elastic-package help stack up
。
接下来,您必须设置进一步的 elastic-package
命令所需的环境变量。
$(elastic-package stack shellinit)
接下来,您必须调用系统测试运行程序。 这对应于 概念流程 部分中描述的步骤 3 到 7。
如果要为程序包中的**所有数据流**运行系统测试,请导航到程序包的根文件夹(或其下的任何子文件夹)并运行以下命令。
elastic-package test system
如果要为程序包中的**特定数据流**运行系统测试,请导航到程序包的根文件夹(或其下的任何子文件夹)并运行以下命令。
elastic-package test system --data-streams <data stream 1>[,<data stream 2>,...]
最后,在完成运行所有系统测试后,关闭 Elastic Stack。 这对应于 概念流程 部分中的步骤 8。
elastic-package stack down
由于系统测试练习了从运行集成的服务一直到将从集成的数据流生成的数据索引到 Elasticsearch 的端到端集成,因此可以在运行这些测试时为每个集成的数据流生成 sample_event.json
文件。
elastic-package test system --generate