## 简介
**OpenObserve** 是一个开源的云原生可观测性平台，与 Elasticsearch 相比，存储成本降低了约 140 倍（实际结果可能因测试数据而有所不同），测试用例包括真实的日志数据，其显著降低运营成本，并提高了易用性。它可以扩展到PB级别的数据量，具有很高的性能，您晚上可以睡得更好。如果您正在寻找一款适用于日志、指标和跟踪的可观测性工具，请查看 **OpenObserve** 以及其在可观测性方面如何帮助您构建更好的软件并节省观测成本。
我们构建 **OpenObserve** 时遵循以下设计原则：
1. 使用 **暴力搜索** 进行日志查询，而非倒排索引或bitfunnel；
1. 使用 **Rust** 作为编程语言以确保安全和高性能；
1. 使用 s3/MinIO/gcs/Azure blob/oss/cos 作为可观测数据存储；
1. 采用 **列式格式** 存储数据以加速分析；
1. 支持 **很高基数** 的字段；
1. 利用SIMD指令集（AVX-512和NEON）进行 **向量化处理** 以加速分析；
1. 采用无状态节点，真正实现 **计算与存储分离** ，；
1. 核心引擎从一开始就设计为提供 **完整的可观测性解决方案** （日志、指标、跟踪），而不是事后对现有功能进行改进。
我们将在一系列博客中深入探讨如何实现比现有可观测工具更高效率。但现在让我们先来看看为什么我们要构建 **OpenObserve** 。
## 又一个日志搜索引擎！为什么？
当我在2021年创建 [ZincSearch[1]](https://github.com/zincsearch/zincsearch) 时，我没有料到它会在大约一年内在GitHub上获得超过14k stars，并成为 [2022年GitHub上增长最快的项目[2]](https://runacap.com/ross-index/annual-2022/) 之一。尽管功能简单，但目前已经有数百家组织将ZincSearch应用于生产环境中的日志搜索和分析。
这些组织选择ZincSearch的原因是什么？绝大多数客户表示他们使用现有可观测性解决方案时遇到以下痛点：
1. **启动难度** ：通常包括：
1. 在用户环境中安装；
1. 提前规划，例如分片数量、需要索引哪些字段、设置映射（Elasticsearch）、以及预先定义标签（Loki）；
1. 各种配置使用户真正可用；
1. 有些系统甚至要求用户在大规模运行时使用Kafka以避免数据丢失；
1. **维护难度** ：我们都听说过关于Elasticsearch的恐怖故事，包括：
1. 配备资源；
1. 备份；
1. 升级；
1. 在发生故障时恢复系统正常运行；
1. 根据需要增减节点数量；
1. **功能和易用性** ：长期以来，Amazon CloudWatch默认从AWS各项服务中接收日志，但由于难以使用，用户自己使用Elasticsearch收集日志，或直接使用像Datadog这样的SaaS平台。当我第一次发现Elasticsearch时，我喜欢它的用户体验远远优于CloudWatch。Datadog构建了一个更好的界面，我非常喜欢使用它。重点是，即使你有像CloudWatch这样容易获得的东西，它仍然需要具备可用性和高效完成预期工作的功能，否则用户会寻找替代品。
1. **成本** ：像Splunk和Datadog这样的参与者尽管提供了出色的软件但是可能变得极其昂贵。看看这个 [关于Datadog定价和成本的reddit帖子[3]](https://www.reddit.com/r/devops/comments/zz4naq/datadog_i_do_not_understand_the_pricing_model/) 。一般来说，成本分为以下几类：
1. 许可；
1. 基础设施成本：有两种形式：
1. 计算：用户需要多少台服务器进行搜索和分析。
1. 存储：用户在可观测性数据（日志和跟踪数据可能会迅速变得庞大）方面使用了多少存储空间。EBS卷在大规模时可能变得非常昂贵。（规划卷及其生命周期管理又是另一个令人头痛的问题。）这也限制了您实际可以存储的数据的持续时间，因为存储数据的成本可能超过它提供的感知价值。
1. 人力成本：通常涉及两种角色：
1. 需要DevOps/SRE/管理人员花时间设置并确保系统的正常运行。
1. 开发人员被告知需要自行决定他们能推送多少可观测性数据，而且需要密切关注他们的日志数据来保证平台可用。还需要花时间与管理人员一起学习平台的各种事物，如索引映射、查询语法、基数等。
1. 对于大多数SaaS平台，定价基于您向其发送的数据量。
1. **学习曲线** ：尽管我喜欢学习新东西，但我讨厌为不同工具学习做同样事情的不同方法。我也不喜欢学习可以被避免的东西。所有的日志引擎似乎都为高级查询带来了自己的查询语言。
1. Elasticsearch有一个需要学习的自定义DSL。不过最近也支持SQL了；
1. Grafana Loki有LogQL；
1. Datadog有自己的查询语言；
1. **性能** ：考虑到如果其他所有事情都运行良好，他们可以只添加几个服务器，所以在这方面抱怨较少的人。然而，这对许多人来说仍然是一个问题。较低的性能可能导致性能下降、计算成本上升，或者在查询超时时根本无法完成工作。性能包括以下几点：
1. 采集：用户可以多快地采集数据；
1. 搜索：例如，在所有日志数据中搜索错误日志；
1. 聚合：例如，从NGINX日志中分析HTTP状态码的总计；
我们还看到了像Datadog、Loggly、Papertrail、Splunk和Sumologic这样的SaaS平台的局限性，它们可能很昂贵且缺乏必要的功能。此外，许多用户更喜欢将数据保留在自己的数据中心或AWS帐户中。我们的团队考虑到了这些挑战，并从零开始设计了一个解决每个问题的系统。
借鉴我们的团队成员和我作为AWS解决方案架构师与数百家AWS客户合作的经验，我们构建了一个既适合初学者又适合高级用户的系统。
与使用过时技术构建的现有系统不同，我们正在使用现代技术构建一个全面的可观测性平台，包括日志、指标和跟踪。
## 指导原则
当我们决定最终构建时，我们希望遵循以下原则：
1. **快速上手** ：
1. 用户应该能够在不到两分钟的时间内安装（对于私有部署）或注册（对于SaaS平台）；
1. 用户应该能够在两分钟内开始采集数据，并在没有任何复杂配置的情况下开始观测应用程序的行为；
1. **常态化运行** ：
1. 应用程序应该稳定，在出现问题时，它应该能够自动修复自己；
1. 大多数用户应该能够在零配置的情况下开始高效地使用系统；
1. 弹性扩展应该像更改AWS中自动缩放组中节点数量一样简单，或者像更改k8s中副本数量一样简单；
1. 大多数用户不需要备份，或者可以在无需DBA级别技能的情况下进行备份；
1. 升级过程顺畅且易于操作，并考虑到各个版本之间存在差异性。升级过程不能导致系统停机或数据丢失。
1. **功能和可用性**
1. 系统从一开始就应该具有高度可用性，能够提供极好的时间投资回报率。一个优秀的UI和API是实现这个目标非常重要的一点。
1. 仅通过日志无法查看整个软件，用户还需要指标和跟踪。
1. **成本** ：用户无需抵押房屋或公司资产就可以私有部署（有或无许可费用）或SaaS平台上运行系统。
1. **学习曲线** ：从未使用过该系统的用户也应能够安装和高效的使用基本功能，或者能够利用现有技能进行高级操作。
1. **性能**
1. 对于生产环境中的大多数情况，系统都应具备高性能；
1. 性能通常是一种权衡，在权衡之后，它依然能被绝大多数用户所接受，并能提供优秀的结果；
接下来我们花了几个月时间构建实际系统。
## 那么我能得到什么呢？
我们构建了一个开源的可观测性平台 **OpenObserve** ，它具有以下特点：
1. **超级易用**
1. 用户可以在不到两分钟的时间内，在笔记本电脑上尝试使用它，占用不到100 MB的内存，并体验其卓越的性能。
1. 用户可以在两分钟内将其安装在k8s集群中，并使系统正常运行。
1. 用户会喜欢这个功能齐全、简洁实用且强大的GUI界面。
1. 如果需要，用户还可以利用现有SQL技能进行高级查询。
1. **低操作成本**
1. 所有用户数据都存储在S3（其他云存储或本地），无需管理。
1. 根据用户需求快速弹性扩展。
1. 元数据存储在etcd中，这是一个高可用键值存储系统。
1. **低成本**
1. 与Elasticsearch相比，使用S3进行数据存储可降低约140倍的存储成本。而对于日志系统来说，这是主要成本之一。
1. 采集过程中极低的计算需求（基于数据和硬件约为6倍 **YMMV** [你可能得到不同的结果]）。
1. **高性能引擎**
1. OpenObserve采用Rust编写，充分发挥了其高性能优势；
1. 我们采用自动和手动分区以提高数据处理效率；
1. 我们还使用内存缓存，在其中将压缩数据存储在内存中，可以在不到35 GB的RAM中存储1 TB的数据（约30倍压缩比，尽管实际日志可获得更高的压缩比）。
1. **高级特性**
1. 日志、指标、跟踪、仪表板、警报、函数等；
1. 多租户；
1. 嵌入式脚本：
1. 采集函数 - 可以将其视为AWS Lambda函数，用户可以在每条记录上运行该函数以便在采集过程中进行修改。它允许减少、删除和丰富进入OpenObserve的日志数据。用户可以预处理输入系统的日志记录。用户可以构建他们能想象到的任何功能。
1. 查询函数 - 可以将其视为Lambda函数，在查询时对已经采集的每条日志上执行操作。例如，如果一个用户有一条像"1.2.3.4 - POST prabhat@zinc https://openobserve.ai"这样的日志记录，您可以在查询时解析并根据需要进行筛选。用户可以构建他们能想象到的任何功能。
1. **晚上睡得更好** ，因为即使节点发生故障也会自动修复并继续运行。
下面是我们将kubernetes集群日志同时导入 **OpenObserve** 和 **Elasticsearch** 后几个小时内所产生的存储利用率结果。
## 权衡
我们选择以不同的方式做某些事情，这可能会影响到它在您的环境中的表现。
**OpenObserve** 不像 **Elasticsearch** 那样对数据进行倒排索引，而是将其直接压缩并存储在 S3 上。这使得 **OpenObserve** 以极低的存储成本和很低的计算成本运行采集，但搜索时需要更多计算资源。由于 **OpenObserve** 使用了列式存储，理论上可以用更低的计算能力进行分析查询，并且速度更快。我们将适时进行基准测试来证实这一点。
我们选择使用 **etcd** 而不是 raft/paxos 进行集群协调，因为 etcd 允许更好地扩展和集群协调。然而，这引入了 etcd 管理问题。与全功能数据库相比，etcd 管理要容易得多，因为其占用空间较小；尽管如此，在备份和保持正常运行方面还是有一些工作要做。我们计划适时提供一个托管型 etcd 服务供用户使用以解决此问题。
## 结论
市场上有四十多种可观测性工具（可能还有更多），其中一些是开源的、一些是闭源的、另外一些只作为 SaaS 提供。但我们仍然看到人们因为一个或多个原因（功能、成本、管理困难等）在使用这些现有工具时遇到困扰。
所以我们决定构建 **OpenObserve** ，让团队能够高效地完成工作，有效地解决问题，并且晚上睡得安稳。引用我的一位导师 Anand Babu Periasamy（MinIO 的 CEO）关于进入拥挤的可观测性市场的话：
> 已经有那么多捕鼠器了为什么还要再造一个呢？因为鼠害问题依然存在（而现有的捕鼠器并没有解决问题）。
查看 [OpenObserve文档[4]](https://docs.openobserve.ai/) 以在两分钟内安装 OpenObserve 或者直接尝试 [OpenObserve 云平台[5]](https://cloud.openobserve.ai/) 。
有疑问加站长微信联系（非本文作者）
