观测云 VS ELK：谁是日志监控的王者？

前言

作为 IT 信息系统运行状态感知和故障分析的重要手段，日志在行业兴起之初便为运维和开发环节所广泛应用。当应用和系统发生故障或出现问题时，日志数据成为了排查和诊断问题的重要依据。通过分析日志，开发人员和运维人员可以了解系统的运行状况、错误消息和异常情况。对于高负载的应用和系统，性能监控至关重要。通过分析日志数据，可以了解系统的吞吐量、响应时间、资源利用率等指标。这有助于识别瓶颈、优化性能，并提供更好的用户体验。同时，许多行业和法规对于数据的保留和审计有明确的要求。日志数据通常包含了关键的操作和事件信息，可以用于合规性审计和法律调查。

但随着信息技术的快速发展，现代应用和系统变得越来越复杂。企业和组织使用各种软件和硬件组件构建和运行复杂的应用程序和基础设施。这些系统产生大量的日志数据，包括应用日志、服务器日志、网络日志等。这些日志记录了系统中发生的事件、错误和警告等信息。这使得处理大规模的日志数据变得非常困难，传统的文本编辑器或命令行工具无法满足快速搜索、过滤和分析的需求。在这样的背景下，专用日志分析工具应运而生。

产品简介

ELK（Elasticsearch、Logstash和Kibana）套件始于 2010 年，是由 Elastic 公司开发的一组开源工具，用于处理、存储和可视化日志数据。与观测云类似，ELK 向用户提供了多端日志收集的能力，用于集中采集、分析、展示日志的相关内容。帮助用户监测管理并展示系统运行中各环节的运行状态。

其中，Elasticsearch 是一个分布式、实时的搜索和分析引擎，最初由 Shay Banon 于 2010 年创建。基于 Apache Lucene 搜索引擎库构建，通过使用倒排索引和分布式架构，提供了高性能的全文搜索和实时数据分析能力。Elasticsearch 的设计目标是处理大规模数据集，并具有水平扩展性和高可用性。

Logstash 是一个用于日志收集、转换和传输的开源工具，可以从各种来源（如日志文件、消息队列、数据库等）收集日志数据，并对其进行过滤、解析和转换，然后将其传输到多个目的地如 Elasticsearch、文件存储等）。Logstash 提供了丰富的插件生态系统，可以灵活地处理各种数据源和数据格式。

Kibana 创建于 2013 年。通过与 Elasticsearch 集成，提供了丰富的图表、仪表盘和报表功能，可以对日志数据进行实时查询、分析和可视化。Kibana 的用户友好的界面使得用户可以通过交互式的方式探索和理解数据，从而更好地发现数据中的模式和趋势。

观测云是一款面向开发、运维、测试及业务团队的实时数据监测平台，能够统一满足云、云原生、应用及业务上的监测需求，快速实现基础设施、中间件、应用层和业务层的可观测。基础设施监测、日志与指标管理、应用性能监测、用户访问监测、可用性监测、异常检测、系统级安全巡检、场景和仪表板等是观测云的可观测解决方案，通过统一的数据采集、全面的数据监控、无缝的关联分析、自定义的场景搭建、高度的可编程性，敏捷的成员协作，为用户提供了最快、最轻松、最全面、最自由的系统可观测平台。

组件对比

一个功能齐全的可观测平台，其技术架构中通常需具备收集、存储、处理、分析和可视化应这几个关键功能模块。下面以这几个主要功能为入口，在功能及性能方面对两款工具进行对比和分析。

数据采集

ELK 为日志采集提供了丰富的 Agent 矩阵，方便用户针对不同采集场景进行数据收集：

在日志采集方面，Elastic 提供了 Beats 系列作为日志采集器，其中包括 Filebeat、Winlogbeat、Packetbeat 等。Filebeat 用于收集和发送日志文件，Winlogbeat 用于收集 Windows 事件日志，Packetbeat 用于网络数据包分析。

对于基础设施的指标采集，Elastic 的 Metricbeat 主要用于收集和发送指标数据，当然除了 Metricbeat 外还有另一个专门的指标采集器，称为 Heartbeat。Heartbeat 可以监测和采集网络服务的可用性和性能指标，如 HTTP、TCP、ICMP 等。

近年来，随着可观测理论不断发展，日志采集的范围也从传统概念中的日志，逐步扩展至链路及用户访问记录等领域。为适应这种变化，Elastic 也陆续提供了 APM Agent 用于采集应用程序性能监控（APM）数据。Elastic APM 支持多种编程语言和框架，例如如 Java、Python、Go、Node.js 等。可以捕获应用程序的事务和跟踪数据，并将其发送到 Elasticsearch 进行存储和分析。同时，借助 APM Real User Monitoring (RUM) agent 实现对用户访问过程的数据记录。

ELK Agent 方案在提供丰富的数据接入体验的同时，缺点也比较明显，当同一套系统为不同采集目标配置多个 xBeats 采集器时，对系统资源的占用将变得难以控制。实际应用过程中经常出现 multi-agent 资源争用影响目标系统业务正常运行的情况，且对于运维管理人员而言，多 Agent 的部署方式也增加了很多配置维护负担。

基于上述原因，观测云在数据采集侧对这种模式进行了优化，通过 DataKit 采集套件，形成“One Agent + multi-inputs”的配置形态，降低资源占用，简化配置管理，大幅优化了数据采集器的部署及使用效率。

DataKit 是一款开源、一体式的数据集成 Agent ，它提供全平台操作系统（Linux/Windows/macOS）支持，拥有全面数据采集能力，涵盖主机、容器、中间件、Tracing、日志以及安全巡检等各种场景。用户只需要配置一个 Agent，并按需打开不同的数据接收端 (inputs)，即可方便的实现指标、网络、日志、应用链路、RUM 等数据的收集。为适配更多用户的使用场合，观测云对内置的数据接收端 (inputs) 进行了预置，超过 400+ 配置模板方便用户快速构建对目标系统的数据采集，配合可视化端配套的仪表板模板，实现采集到展现的开箱即用效果。

当然，受应用场景及部署形态的限制，RUM 真实用户体验监测的数据仍是通过独立 SDK ，即观测云 rum.js 的方式单独发放到端进行数据收集，这和 ELK 采用的方案是相同的。

数据存储

ELK

整个 ELK 技术栈的核心是 Elasticsearch 数据库（简称 ES ）。ES采用分布式架构，可以在多个节点上存储和处理数据。每个节点负责存储数据的一部分，并处理查询和分析请求。节点之间通过集群协作，实现数据的自动分片和负载均衡，提供高可用性和可伸缩性。

!

入库数据借助基于倒排索引（Inverted Index）的数据结构来支持快速的全文搜索。倒排索引将每个文档中的每个词项映射到出现该词项的文档列表，这样可以快速找到包含特定词项的文档。倒排索引还存储了词项的位置和频率信息，以支持更高级的查询操作。

同时为优化检索准确性，Elasticsearch 使用分析器（Analyzer）对文本进行分词和标准化处理。分词将文本切分成词项（Terms），并去除停用词、标点符号等。标准化会将词项转换成小写形式，并应用词干提取和词形还原等技术以提高搜索的准确性。

观测云

观测云采用自研的 GuanceDB 对数据进行管理，其底层基于 Apache Doris 构建。在设计上 GuanceDB 把 Schemaless 当成最重要的特征之一，可以支持任意字段的写入，也可以实时增删数据字段，无需手动维护数据模型。其数据存储采用分布式架构部署，一方面可以保证自身的高可用，另一方面也可以通过动态增删节点实现集群的横向扩展。

在数据存取性能方面，通过对数据排序和索引结构的简化，其查询性能相比 Elastic 有较大幅度的性能提升。配合分层存储策略等技术，有效减少用户整体的拥有成本。此外，全栈自研的 GuanceDB 数据库在国内某些应用场景中，相比于 ES 也有着更高的可靠性和安全性，可以适配更丰富的用户需求场景。

数据查询

ELK

数据的查询功能方面，Elasticsearch 支持丰富的查询语法和灵活的搜索功能。提供了诸如全文搜索、精确匹配、范围查询、布尔查询、模糊查询、聚合等多种查询类型。通过使用查询 DSL（Domain-Specific Language）和查询 API ，用户可以构建复杂的查询和过滤条件，并对结果进行排序、分页和聚合操作。

作为 ELK 套件可视化领域的前端工具，Kibana 同时提供了基于 DSL 的查询编辑器，称为 Kibana Query Language（KQL），这是一种简化的查询语言，专门用于在 Kibana 中查询和过滤日志数据和指标数据。

总体上讲，DSL 是 Elasticsearch 的通用查询语言，适用于广泛的领域和使用场景，而 KQL 是 Kibana 针对日志查询和分析而设计的简化查询语言。DSL 功能更为强大和灵活，适用于复杂的查询需求，而 KQL 更加简单易用，适用于日常的日志查询和过滤操作。

观测云

虽然 KQL 是对 DSL 的简单封装，其语法结构类似于 DSL 。但同一个平台中使用两种查询语言毕竟会导致学习成本的升高。为优化这个应用场景，观测云提供了 DQL 查询语言，为全平台提供统一的可观测查询语句。观测云中所有类型的数据，无论是指标、日志、链路，还是被观测的基础对象、用户访问行为等数据，都可以通过一套语法体系方便的查询及使用。

同时，为方便有其他产品使用习惯的用户查询指标数据，观测云的查询引擎兼容 PromQL 语法，用户可以使用 PromQL 对指标数据进行获取。无缝衔接旧的使用习惯，进一步降低用户使用观测云的技术门槛。

可视化

ELK

Kibana 提供了比较丰富的图表、图形和仪表盘，如柱状图、折线图、饼图、地图等，方便用户更直观地理解和分析数据。用户可以创建各种类型的可视化图表，并借助上面提到的 KQL 构建查询条件，来快速定位和筛选感兴趣的数据。仪表盘支持动态交互及报表生成，便于对外分享各类仪表板。另外 Kibana 还提供了丰富的探索和分析功能，以帮助您发现数据中的模式、异常和趋势。用户可以通过聚合查询、数据过滤、数据透视、时间序列分析等功能来深入挖掘数据。

观测云

相比于 Kibana 可视化组件，观测云提供了更加强大的可视化界面 GuanceStudio 。其中 GuanceStudio Scenes 场景模块除提供对标 Kibana 的完整可视化能力外，在图形组件类型及数据查询方面相比 Kibana 有着明显的优势。观测云 Studio 预置了 27 种仪表类型，满足不同场景的使用需求。所有数据的查询、过滤、筛选均基于DQL语言，避免了 Kibana 两套查询语言造成的查询能力限制。

基于多年的可观测场景积累，观测云在 Scenes 场景中为用户准备了多种监控仪表模板。用户点击对应的仪表板模板，即可完成仪表板创建。

除了 Scenes 场景外，GuanceStudio 还对一些基础场景仪表做了预置，例如 APM 应用分析控制台，RUM 用户体验分析控制台，基础设施监测控制台等。用户接入数据后只需要点击进入对应的控制台，即可开展对相关数据对象的分析和监控，如需基于这些控制台进行场景仪表板的构建，只需要将其克隆到对应的仪表板即可。无需自行从零开始搭建仪表板体系。

成本对比

对比两种可观测工具的获取方式，ELK 目前提供 Elastic Cloud ，通过将 ELK 堆栈部署在云平台上为用户提供 ELK 完整技术栈服务。目前已合作的云服务商在 ELK 官网可获取。如用户使用未列入名单的其他 IaaS 服务商，也可以通过下载 Elastic Stack 的方式，在自己环境中部署 ELK 套件。

部署费用方面，依底座规格的不同，ELK 套件的授权费用将有所差别。以云服务商托管为例，大致对应 1TB 热存、3TB 温存、7TB 冷存的基础配置版底座需要花费 $5.2/hour 的拥有成本（相当于 ￥27k/moth ）。对于接入初期较少数据量的情况，这种计费方式会造成比较大的浪费。后期随着数据量的增长，费用又会出现比较大的上升。对于用户的总体拥有成本会造成比较大的压力。

相比于 ELK ，观测云的服务提供方式就灵活很多了，目前提供的三种接入方案中，首推用户使用 SaaS 服务接入观测数据，这样可以以较少的费用支出，实现系统全链路可观测体系的建立。后期随着数据规模的增长，如希望进一步优化海量数据的存储成本，可考虑采用私有化输出和云上专属托管的方式，建立用户私有的观测云技术栈。相比于 ELK Cloud 版本，观测云私有化输出版本的成本也有着比较大的优势，尤其是在超大数据规模下，通过观测云的冷热分离版本，综合性价比可以做到将近 10 倍。通过 SaaS + 私有化的交付方式，可以为用户可观测平台的选型提供更多灵活性。

总结

通过几个维度的简单对比不难发现，观测云相比传统的 ELK 套件有着比较明显的优势:

• 在数据采集端，通过"One Agent"方式，简化了数据采集配置及安装，减少资源占用；
• 在数据存储端，通过自研 GuanceDB 数据库，降低数据存储成本，提升数据查询性能；
• 在数据应用端，GuanceStudio 除提供与 Kibana 相同的场景仪表板可视化能力外，还基于观测场景提供了更为丰富的可视化仪表板预置，减少用户自行编辑仪表板的工作量；
• 通过观测云 DQL 统一查询语言，降低查询语法的学习难度；
• 提供更加灵活的产品获取方式，优化用户的总体拥有成本。

总体来说，观测云是一款更加优秀的全链路观测工具，正在考虑 ELK 实施或产品替代的小伙伴一定不要错过观测云。