数据的 DNA:使用 Elastic Common Schema 提高效率
作者:来自 Elastic Peter Titov
Elastic ECS 有助于改善日志字段的语义转换。了解如何量化规范化数据的好处,不仅是为了提高基础设施效率,也是为了提高数据保真度。
Elastic Common Schema 是一种简化和统一搜索体验的绝佳方式。通过将不同的数据源整合到通用语言中,用户在解释感兴趣的事件、解决事故或寻找未知威胁时可以降低难度。但是,有底层基础设施原因可以证明采用 Elastic Common Schema 是合理的。
在本博客中,你将了解 ECS 的可量化运营优势、如何将 ECS 与任何数据采集工具结合使用以及应避免的陷阱。本博客中利用的数据源是从 Kaggle 获得的 3.3GB Nginx 日志文件。此数据集的表示分为三类:raw、self 和 ECS;其中 raw 数据集没有标准化,self 数据集是我与各种用户合作 5 年以上经验中观察到的常见错误的示例,最后是 ECS,它具有最佳的数据清理方法。
这种清理是通过解析、丰富和映射采集的数据来实现的;类似于 DNA 测序以表达遗传特征。通过了解数据的结构并分配正确的映射,可以表示、存储和搜索更全面的表达。
如果你想了解有关 ECS、本博客中使用的数据集或可用的 Elastic 集成的更多信息,请务必查看以下相关链接:
数据集验证
在开始之前,让我们先回顾一下有多少文档以及我们需要提取哪些内容。我们的 Nginx 日志文件中有 10,365,152 个文档/事件:
我们的目标最终状态中有 10,365,152 份文档:
数据集提取:raw 和 self 提取
为了实现 raw 和 self 提取技术,此示例利用 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" } }
对于 self 摄取,创建了一个带有简单 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 用例,我们将仅使用相关集成的资产。
安装的资产不仅仅是仪表板,还有摄取管道,它们不仅可以规范化数据,还可以丰富数据,同时通过组件模板将字段映射到正确的类型。我们要做的就是确保在数据进入时,它将遍历摄取管道并使用这些提供的映射。
创建索引模板,然后选择集成提供的组件模板。
将组件模板视为索引模板的构建块。这些模板允许重复使用核心设置,从而确保在整个数据中采用标准化。
对于我们的提取方法,我们仅指向在索引模板创建期间指定的索引名称,在这种情况下,nginx-ecs 和 Elastic 将处理所有其余部分!
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 个字段可供搜索,其中大多数都是出于聚合目的的重复项。
然而从发现的角度来看,我们仅限于 6 个字段!
我们的 self 解析索引有 37 个可用字段,但这些字段也是重复的,对于高效搜索来说并不理想。
从 Discover 的角度来看,我们几乎有 3 倍的字段可供选择,但如果没有正确的映射,搜索这些数据的难易程度就不理想。一个很好的例子是尝试计算文本(text)字段的平均 bytes_in。
最后,通过我们的 ECS 索引,我们有 71 个字段可供使用!请注意,得益于摄取管道,我们丰富了地理信息字段以及事件分类字段。
那么 Discover 怎么样?有 51 个字段可供我们直接搜索:
以 Discover 为基础,我们的 self 解析索引可搜索的字段增加了 283%,而我们的 ECS 索引则增加了 850%!
存储利用率比较
我们的 ECS 索引中包含所有这些字段,其大小肯定比 self 规范化索引大得多,更不用说 raw 索引了?结果可能会让你大吃一惊。
考虑到我们 3.3GB 大小数据集的数据副本,我们可以看到规范化和映射数据的影响对所需的存储量有显著的影响。
结论
虽然任何丰富的数据集所需的存储量都会增加,但 Elastic 提供了简单的解决方案,可以最大限度地提高要搜索的数据的保真度,同时确保操作存储效率;这就是 Elastic Common Schema 的强大之处。
让我们回顾一下我们如何能够最大限度地提高搜索能力,同时最大限度地减少存储
- 为我们将要提取的数据集安装集成(integration)资产。
- 自定义索引模板以利用所包含的组件来确保映射和解析与 Elastic Common Schema 保持一致。
准备好开始了吗?注册 Elastic Cloud 并试用我上面概述的功能和能力,以从你的数据中获得最大的价值和可见性。
原文:The DNA of DATA Increasing Efficiency with the Elastic Common Schema — Elastic Observability Labs

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
《进阶篇第8章:vuex》包括理解vuex、安装vuex、搭建vuex环境、四个map方法的使用、模块化+名命空间
@[toc] 8.1理解 vuex 8.1.1vuex 是什么 概念:专门在 Vue 中实现集中式状态(数据)管理的一个 Vue 插件,对 vue 应 用中多个组件的共享状态进行集中式的管理(读/写),也是一种组件间通信的方 式,且适用于任意组件间通信。 Github 地址: https://github.com/vuejs/vuex 注意点1:浏览器安装的Vue插件,实际是vue+vuex的插件。 8.1.2什么时候使用 Vuex 多个组件依赖于同一状态 来自不同组件的行为需要变更同一状态 8.1.3全局事件总线和vuex的区别 全局事件总线查询和修改共享数据,需要使用多次$emit+$on,非常不方便。 而vuex则是把共享数据单独提出来放在vuex中,通过双向箭头也就是提供的api就能实现查询和修改数据。 8.1.5vuex的工作原理图 举例:讲解原理图,以求和案例的下拉框选择2,点击+后的变化流程讲解 求和案例页面效果长这样 注意点1:vuex有3个组成部分:Actions、Mutations、State,且都是{}对象。 其中 Actions代表一堆动作或者一堆行为 Muta...
- 下一篇
MariaDB 和 GreatSQL 性能差异背后的真相
MariaDB 和 GreatSQL 性能差异背后的真相 前言 最近项目上遇到了两次 MariaDB 和 GreatSQL 的对比,GreatSQL受到客户质疑,最后经过排查抓到性能差异背后的真相。基于此做个分享。 版本 MariaDB版本:10.3.39 该版本为麒麟V10 yum安装 GreatSQL版本:GreatSQL-8-0-32-25 问题一:MariaDB和GreatSQL使用sysbench压测性能相差100倍 某天某客户反馈他们的sysbench压测结果,MariaDB 和 GreatSQL 压测性能相差100倍。 信息收集 架构:均为单机 版本如上文版本所示 配置文件:MariaDB yum安装后/etc/my.cnf 未曾更改 GreatSQL配置文件为GreatSQL用户手册中的配置文件链接如下: https://GreatSQL.cn/docs/8.0.32-25/3-quick-start/3-4-quick-start-with-cnf.html 两者在同一台机器上轮流运行(即开启MariaDB时关闭GreatSQL,开启GreatSQL时关闭MariaD...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Red5直播服务器,属于Java语言的直播服务器
- CentOS6,7,8上安装Nginx,支持https2.0的开启