Elastic 通用模式是简化和统一搜索体验的绝佳方法。通过将不同的数据源对齐到通用语言中,用户在解释感兴趣的事件、解决事件或搜索未知威胁时遇到的障碍更少。然而,采用 Elastic 通用模式还有潜在的基础设施原因。
在本博客中,您将了解 ECS 的可量化运营优势、如何通过任何数据摄取工具利用 ECS 以及要避免的陷阱。本博客中使用的数据源是从 Kaggle 获取的 3.3GB Nginx 日志文件。该数据集的表示分为三个类别:原始、自建和 ECS;其中原始数据零规范化,自建数据演示了我过去 5 年多与各种用户合作时观察到的常见错误,最后 ECS 采用最佳的数据清理方法。
这种清理是通过对摄取的数据进行解析、丰富和映射来实现的;类似于对 DNA 进行测序以表达遗传特征。通过理解数据的结构,并分配正确的映射,可以更彻底地表示、存储和搜索数据。
如果您想了解更多关于 ECS、本博客中使用的数据集或可用的 Elastic 集成的信息,请务必查看以下相关链接
数据集验证
在我们开始之前,让我们回顾一下存在多少文档以及我们需要摄取什么。我们的 Nginx 日志文件中有 10,365,152 个文档/事件
我们的目标最终状态是拥有 10,365,152 个文档
数据集摄取:原始和自建
为了实现原始和自建摄取技术,此示例利用 Logstash 来简化操作。对于原始数据摄取,使用简单的文件输入,没有其他修改或索引模板。
input {
file {
id => "NGINX_FILE_INPUT"
path => "/etc/logstash/raw/access.log"
ecs_compatibility => disabled
start_position => "beginning"
mode => read
}
}
filter {
}
output {
elasticsearch {
hosts => ["https://mycluster.es.us-east4.gcp.elastic-cloud.com:9243"]
index => "nginx-raw"
ilm_enabled => true
manage_template => false
user => "username"
password => "password"
ssl_verification_mode => none
ecs_compatibility => disabled
id => "NGINX-FILE_ES_Output"
}
}
对于自建摄取,创建了一个带有简单 Grok 过滤器的自定义 Logstash 管道,没有应用索引模板
input {
file {
id => "NGINX_FILE_INPUT"
path => "/etc/logstash/self/access.log"
ecs_compatibility => disabled
start_position => "beginning"
mode => read
}
}
filter {
grok {
match => { "message" => "%{IP:clientip} - (?:%{NOTSPACE:requestClient}|-) \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:requestMethod} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})\" (?:-|%{NUMBER:response}) (?:-|%{NUMBER:bytes_in}) (-|%{QS:bytes_out}) %{QS:user_agent}" }
}
}
output {
elasticsearch {
hosts => ["https://myscluster.es.us-east4.gcp.elastic-cloud.com:9243"]
index => "nginx-self"
ilm_enabled => true
manage_template => false
user => "username"
password => "password"
ssl_verification_mode => none
ecs_compatibility => disabled
id => "NGINX-FILE_ES_Output"
}
}
数据集摄取:ECS
Elastic 包含许多可用的集成,其中包含您确保数据尽可能高效摄取所需的一切。
对于我们的 Nginx 用例,我们将仅使用相关的集成资产。
安装的资产不仅仅是仪表板,还有摄取管道,这些管道不仅可以规范化数据,还可以丰富数据,同时通过组件模板将字段映射到正确的类型。我们所要做的就是确保数据传入时,它将遍历摄取管道并使用这些提供的映射。
创建您的索引模板,并选择从您的集成提供的组件模板。
将组件模板视为索引模板的构建块。这些允许重用核心设置,确保在您的数据中采用标准化。
对于我们的摄取方法,我们只需指向在索引模板创建期间指定的索引名称,在这种情况下,是
input {
file {
id => "NGINX_FILE_INPUT"
path => "/etc/logstash/ecs/access.log"
#ecs_compatibility => disabled
start_position => "beginning"
mode => read
}
}
filter {
}
output {
elasticsearch {
hosts => ["https://mycluster.es.us-east4.gcp.elastic-cloud.com:9243"]
index => "nginx-ecs"
ilm_enabled => true
manage_template => false
user => "username"
password => "password"
ssl_verification_mode => none
ecs_compatibility => disabled
id => "NGINX-FILE_ES_Output"
}
}
数据保真度比较
让我们比较一下三个索引中可搜索的字段数量以及数据的质量。我们的原始索引只有 15 个可搜索的字段,其中大多数是用于聚合目的的重复字段。
然而,从“发现”的角度来看,我们仅限于
我们的自解析索引有 37 个可用字段,然而这些字段也是重复的,不利于高效搜索。
从“发现”的角度来看,这里我们有近 3 倍的字段可供选择,但是如果没有正确的映射,则搜索此数据的难易程度并不理想。一个很好的例子是尝试计算文本字段上的平均 bytes_in。
最后,在我们的 ECS 索引中,我们有 71 个可用字段!请注意,由于摄取管道,我们获得了地理信息以及事件类别字段的丰富字段。
现在“发现”如何呢?我们有 51 个字段可以直接用于搜索目的
以“发现”为基础,我们的自解析索引有 283% 的更多字段可供搜索,而我们的 ECS 索引有 850%!
存储利用率比较
当然,我们的 ECS 索引中有这么多字段,大小会比自规范化索引大得多,更不用说原始索引了?结果可能会让您感到惊讶。
考虑到我们 3.3GB 大小的数据集的副本,我们可以看到规范化和映射的数据对所需的存储量有显着影响。
结论
虽然任何富化的数据集所需的存储量都会增加,但 Elastic 提供了简单的解决方案,可以在确保操作存储效率的同时,最大限度地提高要搜索的数据的保真度;这就是 Elastic 通用模式的力量。
让我们回顾一下我们如何能够在最大限度地提高搜索效率的同时,最大限度地减少存储空间
- 为我们要摄取的数据集安装集成资产。
- 自定义索引模板以利用包含的组件,以确保映射和解析与 Elastic 通用模式对齐。
准备好开始了吗?注册 Elastic Cloud,并试用我上面概述的功能,以最大限度地提高数据的价值和可见性。