Who is behind TopDigg?

TopDigg is created by Eric, a researcher focused on AI trends and SEO/GEO strategies.

How often is content updated?

Blog posts are published regularly. AI Daily is updated daily with the latest AI news.

Can I republish or share content from TopDigg?

Please contact us for content licensing and collaboration inquiries.

OpenObserve 深度解析：降低 140 倍存储成本的云原生可观测性平台

核心思想："Simplify Observability"（简化可观测性）。OpenObserve 认为，当前的可观测性工具要么太贵（Datadog、Splunk），要么太复杂（Elasticsearch），让很多组织望而却步。OpenObserve 的使命是：让每个组织——无论大小——都能负担得起完整的可观测性解决方案。它用 Rust 从零构建，结合 Parquet 列式存储、S3 原生设计和智能压缩，宣称将存储成本降低 140 倍。这不仅仅是"另一个监控工具"，而是对可观测性领域"成本结构"的根本性重构——用工程上的极致优化，让高端技术民主化。

文章背景与项目简介

背景：可观测性的困境

在云原生时代，系统的复杂性呈指数级增长。一个现代化的分布式系统可能包含数十甚至数百个微服务，每个服务产生日志、指标和追踪数据。在这种背景下，"可观测性"从nice-to-have变成了must-have。

但传统的可观测性解决方案面临着一个尴尬的现实：

Datadog：功能强大，但价格让中小企业望而却步（按主机数量和数据量计费）
Splunk：曾经的行业标准，但成本高得离谱（"如果你想知道花了多少钱，他们会说'这是机密'"）
Elasticsearch + Kibana：开源的替代方案，但运维复杂、存储成本高、扩展困难

OpenObserve 的出现，就是为了打破这个困局。

项目元信息

字段	值
仓库	https://github.com/openobserve/openobserve
Stars	14.5k+
Forks	800+
License	AGPL-3.0（开源）
语言	Rust（核心）+ TypeScript/React（前端 UI）
部署	单二进制（无需额外依赖）
平台	Linux、macOS、Windows、Docker、Kubernetes
官网	https://openobserve.ai
文档	https://openobserve.ai/docs

一句话定位

OpenObserve 是一个用 Rust 构建的云原生可观测性平台：统一处理日志、指标、追踪和前端监控，宣称比 Elasticsearch 降低 140 倍存储成本，支持单二进制部署，让每个组织都能负担得起完整的可观测性解决方案。

功能全景图

功能模块	描述
日志管理	全文搜索、SQL 查询、可视化查询构建器，基于 Parquet 列式存储
分布式追踪	基于 OpenTelemetry 标准，提供瀑布图、火焰图、甘特图
服务拓扑图	可视化服务间依赖关系，按请求数和健康状态着色
指标分析	支持 SQL 和 PromQL 两种查询语言，19+ 种图表类型
仪表板	拖拽式面板构建器、模板变量、地理地图
真实用户监控 (RUM)	核心 Web 指标、错误追踪、性能分析和会话回放
告警与事件	阈值告警、调度告警、实时告警、异常检测
数据管道	可视化编辑器，支持日志转指标、数据富化和脱敏
AI 可观测性	监控 GenAI/LLM 的 Token 消耗、成本、延迟和错误率
O2 AI 助手	自然语言转 SQL、VRL、PromQL 查询

核心思想：为什么需要 OpenObserve

1. 成本是可观测性的最大障碍

传统的可观测性工具定价模式存在根本性问题：

按主机计费：每增加一台服务器，成本就增加一份
按数据量计费：数据越多，成本越高，但没有上限
增值功能另收费：告警、追踪、AI 分析都是"豪华套餐"

这导致很多组织不得不：

减少数据保留时间：从 90 天降到 30 天，甚至 7 天
降低采样率：只收集 1% 的数据
放弃部分功能：只用日志，不用追踪或指标

OpenObserve 的判断是：成本的根源在于存储和架构设计的低效，而不是数据的价值。

2. Rust 的工程美学

OpenObserve 选择 Rust 不是追随潮流，而是务实的选择：

内存安全：可观测性系统处理海量数据，内存安全问题可能导致数据丢失或泄露
高性能：同样的硬件，Rust 程序通常比 Go 或 Java 快 2-10 倍
资源效率：低内存占用意味着更低的运行成本
无 GC 停顿：Rust 没有垃圾回收带来的延迟尖峰，适合实时系统

3. S3 原生设计的智慧

OpenObserve 的存储设计充分利用了现代云基础设施：

对象存储成本是 EBS 的 1/10：S3 的成本约为 $0.023/GB/月，而 EBS 是 $0.08/GB/月
持久性高达 11 个九：S3 提供 99.999999999% 的持久性，比任何本地存储都高
无限容量：不需要提前规划存储容量，按需扩展
全球分发：数据可以跨区域复制，支持多地域部署

项目说明：OpenObserve 的架构

整体架构

┌─────────────────────────────────────────────────────────────────┐
│                      OpenObserve 集群                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   ┌─────────────┐                                                │
│   │   Router    │  ←── HTTP/gRPC 请求入口                        │
│   └──────┬──────┘                                                │
│          │                                                       │
│    ┌─────┴─────┐                                                │
│    │           │                                                │
│    ▼           ▼                                                │
│ ┌──────┐   ┌──────┐                                             │
│ │Ingest│   │Querie│  ←── 数据写入 ←── 数据查询                   │
│ │ ers  │   │  rs  │                                             │
│ └──┬───┘   └──┬───┘                                             │
│    │         │                                                  │
│    └────┬────┘                                                  │
│         │                                                       │
│   ┌─────▼─────┐                                                │
│   │ Compactor │  ←── 文件合并、保留策略                           │
│   └─────┬─────┘                                                │
│         │                                                       │
│   ┌─────▼─────┐                                                │
│   │Scheduler  │  ←── 告警、报告、通知                            │
│   └───────────┘                                                │
│                                                                  │
│   ┌───────────────────────────────────────────────────────────┐ │
│   │                     对象存储 (S3/GCS/MinIO)                 │ │
│   └───────────────────────────────────────────────────────────┘ │
│                                                                  │
│   ┌───────────────────────────────────────────────────────────┐ │
│   │                     PostgreSQL (元数据)                     │ │
│   └───────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

五种节点类型

1. Router（路由节点）

职责：请求分发和 GUI 服务

用户请求 → Router → Ingester（写入）或 Querier（查询）

Router 是一个轻量级代理，负责：

将请求路由到正确的节点类型
响应浏览器中的 GUI 请求
负载均衡（可选）

2. Ingester（摄取节点）

职责：数据接收、转换和持久化

数据处理流程：

HTTP/gRPC 请求
    ↓
逐行解析数据
    ↓
应用转换函数
    ↓
检查时间戳字段
    ↓
检查流模式
    ↓
评估实时告警
    ↓
写入 WAL + Memtable
    ↓
Immutable（触发刷新）
    ↓
Parquet 文件
    ↓
上传到对象存储

三级存储：

Memtable：内存缓冲区（默认 256 MB）
WAL：预写日志（默认 128 MB）
对象存储：Parquet 文件（最终持久化）

3. Compactor（压缩节点）

职责：文件合并和存储优化

Compactor 执行以下任务：

小文件合并：将多个小 Parquet 文件合并为大文件（最大 2 GB）
保留策略：删除过期数据
完整删除：支持删除指定条件的数据
索引更新：更新文件列表索引

4. Querier（查询节点）

职责：执行搜索和分析查询

查询执行模型：

SQL 查询请求
    ↓
LEADER（接收节点）解析 SQL
    ↓
确定数据时间范围
    ↓
获取文件列表（分区索引）
    ↓
分配给 WORKER 节点并行处理
    ↓
收集、合并结果
    ↓
返回给用户

无状态设计：Querier 可以水平扩展，某个节点故障不影响其他节点。

内存缓存：Querier 默认将 Parquet 文件缓存在内存中（默认 50% 可用内存）。

5. Scheduler（调度节点）

职责：后台任务执行

Scheduler 负责：

告警查询：定期执行告警条件检查
报告生成：生成周期性报告
通知发送：发送邮件、Slack、PagerDuty 等通知

部署模式

单节点模式

适合：开发测试、小规模部署（< 10GB/天数据量）

┌────────────────────────────┐
│      OpenObserve          │
│  ┌──────────────────────┐ │
│  │    All-in-One        │ │
│  │  (单进程，SQLite)    │ │
│  └──────────────────────┘ │
│  ┌──────────────────────┐ │
│  │   本地磁盘 / S3      │ │
│  └──────────────────────┘ │
└────────────────────────────┘

配置示例：

docker run -d \
  --name openobserve \
  -v $PWD/data:/data \
  -p 5080:5080 \
  -e ZO_ROOT_USER_EMAIL="root@example.com" \
  -e ZO_ROOT_USER_PASSWORD="Complexpass#123" \
  public.ecr.aws/zinclabs/openobserve:latest

高可用模式

适合：生产环境、大规模数据量

┌─────────────────────────────────────────────────────────────┐
│                    Kubernetes 集群                          │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐                       │
│  │ Router  │ │ Router  │ │ Router  │  ← 3+ 副本            │
│  └─────────┘ └─────────┘ └─────────┘                       │
│                                                              │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐          │
│  │Ingester │ │Ingester │ │ Querier │ │Querier  │  ← 水平   │
│  │         │ │         │ │         │ │         │    扩展   │
│  └─────────┘ └─────────┘ └─────────┘ └─────────┘          │
│                                                              │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐                       │
│  │Compactor│ │Scheduler│ │  NATS   │                       │
│  └─────────┘ └─────────┘ └─────────┘                       │
│                                                              │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │        对象存储 (S3/GCS/MinIO) + PostgreSQL            │ │
│  └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

存储设计

Parquet 列式存储

OpenObserve 使用 Parquet 作为主要存储格式，这带来了几个关键优势：

特性	优势
列式存储	只读取查询需要的列，减少 I/O
压缩编码	高效的列压缩（字典编码、行程编码等）
谓词下推	只读取满足条件的行块
嵌套结构	原生支持日志的嵌套 JSON 结构

分区与索引

数据时间范围
    │
    ├── 2024-01-01 ─ 2024-01-07
    │       │
    │       └── partition_001.parquet (100MB)
    │
    ├── 2024-01-08 ─ 2024-01-14
    │       │
    │       ├── partition_002_001.parquet (50MB)
    │       └── partition_002_002.parquet (50MB)
    │
    └── 2024-01-15 ─ 2024-01-21
            │
            └── partition_003.parquet (200MB)

分区策略：

按时间分区：查询时快速定位时间范围
小文件合并：提高查询效率
bloom 索引：快速判断数据是否存在

详细教程：从入门到精通

第一部分：快速部署

1.1 Docker 单节点部署

# 创建数据目录
mkdir -p /data/openobserve

# 启动容器
docker run -d \
  --name openobserve \
  -v /data/openobserve:/data \
  -p 5080:5080 \
  -e ZO_ROOT_USER_EMAIL="admin@example.com" \
  -e ZO_ROOT_USER_PASSWORD="Complexpass#123" \
  public.ecr.aws/zinclabs/openobserve:latest

# 访问 Web UI
# http://localhost:5080

1.2 Docker Compose 部署

# docker-compose.yaml
version: '3.8'

services:
  openobserve:
    image: public.ecr.aws/zinclabs/openobserve:latest
    container_name: openobserve
    ports:
      - "5080:5080"
    environment:
      ZO_ROOT_USER_EMAIL: "admin@example.com"
      ZO_ROOT_USER_PASSWORD: "Complexpass#123"
    volumes:
      - ./data:/data
    restart: unless-stopped

docker compose up -d

1.3 Kubernetes Helm 部署

# 添加 Helm 仓库
helm repo add openobserve https://openobserve.github.io/helm-charts
helm repo update

# 安装
helm install my-openobserve openobserve/openobserve \
  --set admin.email="admin@example.com" \
  --set admin.password="Complexpass#123"

第二部分：数据接入

2.1 使用 OpenTelemetry 接入追踪

# 安装 OpenTelemetry Collector
docker run --rm \
  -v $(pwd)/otel-collector-config.yaml:/etc/otelcol-contrib/config.yaml \
  -p 4317:4317 \
  -p 4318:4318 \
  otel/opentelemetry-collector-contrib:latest

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  otlphttp/openobserve:
    endpoint: http://localhost:5080
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/openobserve]

2.2 使用 Fluentd/Fluent Bit 接入日志

# /etc/td-agent/td-agent.conf
<source>
  @type tail
  @id input_tail
  path /var/log/**/*.log
  pos_file /var/log/td-agent/tmp/td-agent.log.pos
  tag o2.logs.*
  <parse>
    @type json
    time_key timestamp
  </parse>
</source>

<match o2.logs.*>
  @type http
  endpoint http://localhost:5080/api/{organization}/logs
  <format>
    @type json
  </format>
  <buffer>
    flush_interval 10s
  </buffer>
</match>

2.3 接入 Prometheus 指标

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'my-app'
    static_configs:
      - targets: ['my-app:9090']
    remote_write:
      - url: http://localhost:5080/api/{organization}/prometheus/write

第三部分：查询与分析

3.1 日志查询（SQL）

-- 查找错误日志
SELECT * FROM "logs"
WHERE stream = 'application'
  AND level = 'error'
  AND time_range('2024-01-01 00:00:00', '2024-01-02 00:00:00')
ORDER BY _timestamp DESC
LIMIT 100

-- 聚合统计
SELECT
  date_trunc('hour', _timestamp) as hour,
  count(*) as error_count,
  count(distinct trace_id) as unique_traces
FROM "logs"
WHERE level = 'error'
GROUP BY hour
ORDER BY hour DESC

3.2 指标查询（PromQL）

# CPU 使用率
rate(container_cpu_usage_seconds_total{name="my-app"}[5m])

# 请求率
sum(rate(http_requests_total[5m])) by (service)

# P99 延迟
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

3.3 追踪查询

# 查找特定 Trace ID
trace_id = "abc123def456"

# 查找慢请求
duration > 1000ms AND service = "api-gateway"

# 服务拓扑
service = "user-service" AND downstream_service = "order-service"

第四部分：告警配置

4.1 创建告警

进入 Alerts → Create Alert
配置告警条件：

SELECT
  avg(cpu_usage) as avg_cpu,
  max(memory_usage) as max_mem
FROM "metrics"
WHERE service = 'my-app'
EVERY 1m

配置触发条件：

conditions:
  - avg_cpu > 80  # CPU > 80%
  - max_mem > 90  # 或 内存 > 90%

配置通知渠道：

notifications:
  - type: email
    to: ["oncall@example.com"]
  - type: slack
    webhook_url: "https://hooks.slack.com/..."

4.2 异常检测（ML 驱动）

alert:
  type: anomaly
  metric: request_rate
  sensitivity: high
  threshold: 3  # 3 倍标准差触发

第五部分：仪表板构建

5.1 创建仪表板

进入 Dashboards → New Dashboard
添加面板：

Panel Type: Line Chart
Query:
  SELECT
    date_trunc('minute', _timestamp) as time,
    avg(response_time) as p50,
    histogram_quantile(0.99, response_time) as p99
  FROM "logs"
  WHERE service = 'api'
  GROUP BY time

5.2 使用模板变量

-- 定义的变量
variables:
  - name: environment
    type: query
    query: SELECT DISTINCT env FROM "metrics"

  - name: service
    type: query
    query: SELECT DISTINCT service FROM "metrics" WHERE env = '${environment}'

5.3 地理地图

SELECT
  geo_ip(client_ip) as location,
  count(*) as request_count
FROM "logs"
WHERE _timestamp > NOW() - INTERVAL '1 hour'
GROUP BY location

第六部分：AI 可观测性（LLM 监控）

6.1 配置 LLM 监控

# 配置 LLM Provider
llm:
  providers:
    - name: openai
      type: openai
      api_key: sk-...

    - name: anthropic
      type: anthropic
      api_key: sk-ant-...

# 配置追踪
tracing:
  enabled: true
  llm_calls: true
  token_usage: true
  cost_tracking: true

6.2 LLM 可观测性仪表板

监控面板包括：

指标	说明
Token 消耗	每日/每周 Token 使用量
成本追踪	各模型、各应用的成本分析
延迟分析	请求延迟分布（P50/P95/P99）
错误率	LLM 调用失败率
Token 效率	输入/输出 Token 比例

性能对比：OpenObserve 的优势

存储成本对比

指标	OpenObserve	Elasticsearch	Datadog	Splunk
存储成本	基准（140x 更低）	高	非常高	极高
数据保留	90+ 天	通常 30 天	按需	按需
压缩比	10-50x	2-5x	取决于计划	取决于计划

功能对比

功能	OpenObserve	Elasticsearch	Datadog	Splunk
日志搜索	✅ SQL	✅ Lucene	✅ 专有	✅ SPL
指标	✅ SQL + PromQL	❌ 需额外组件	✅ 完整	✅ 有限
追踪	✅ OpenTelemetry	❌ 需额外组件	✅ 完整	✅ 有限
RUM	✅ 内置	❌ 需额外组件	✅ 完整	❌
AI 监控	✅ 内置	❌	❌	❌
单二进制部署	✅	❌	N/A	❌

运维复杂度对比

维度	OpenObserve	Elasticsearch	Grafana Loki
部署复杂度	⭐ 简单	⭐⭐⭐ 复杂	⭐⭐ 中等
运维难度	⭐ 简单	⭐⭐⭐ 复杂	⭐⭐ 中等
水平扩展	⭐ 简单	⭐⭐ 复杂	⭐⭐ 中等
故障恢复	⭐ 快（RTO 分钟级）	⭐⭐ 慢	⭐⭐ 中等

设计哲学：OpenObserve 的设计理念

1. 成本重构：让可观测性民主化

OpenObserve 最核心的设计哲学是成本重构。传统可观测性工具的高成本来自于：

架构低效：使用通用存储（非列式）
过度复制：多副本带来不必要的成本
商业 Licensing：开源组件加上商业增值

OpenObserve 的回应是：

列式存储：Parquet 提供 10-50x 压缩比
S3 原生：利用云对象存储的规模经济
开源核心：AGPL-3.0 许可证，无隐藏成本

2. 简单部署：Single Binary Philosophy

"部署应该像安装一个 app 一样简单。"

docker run -d -p 5080:5080 openobserve

不需要：

规划集群大小
配置分片和副本
安装多个组件
管理复杂的配置文件

这是简单性作为一门工程学科的体现——不是功能少，而是把复杂性隐藏在内部。

3. 多租户：第一等公民

OpenObserve 从一开始就把多租户作为核心设计：

组织隔离：每个组织的数据完全隔离
数据流隔离：stream 是数据组织的一等公民
配额管理：可以设置每个组织的存储配额
统一视图：管理员可以看到所有组织的数据

这使得 OpenObserve 可以作为 SaaS 服务提供，也可以服务于大企业的内部团队。

4. 无状态扩展：架构的可组合性

Ingester: 无状态 → 水平扩展
Querier:  无状态 → 水平扩展
Router:   无状态 → 水平扩展
Compactor: 有状态 → 按需扩展
Scheduler: 有状态 → 主备模式

无状态设计带来了：

快速启动：新节点立即参与工作
故障隔离：节点故障不影响其他节点
滚动升级：升级不影响可用性

5. 数据先本地，后云端

数据 → Memtable (内存) → WAL (本地磁盘) → Parquet (对象存储)
         ↓ 5s              ↓ 触发           ↓ 合并
      快速写入          持久化           长期存储

这个设计的智慧在于：

写入不等待云：数据先写入本地，性能好
本地先持久化：故障不会丢数据
异步上传云端：后台合并，不阻塞写入

6. Rust 作为工程选择

选择 Rust 不是为了"酷"，而是务实的工程决策：

内存安全：可观测性处理敏感数据，安全问题代价高昂
高性能：同样的硬件支持更多数据流
低资源：更低的运行成本
无 GC：没有垃圾回收的停顿，适合实时系统

7. 开放标准：拥抱 OpenTelemetry

OpenObserve 选择拥抱开放标准，而不是创造专有格式：

Ingestion：OpenTelemetry Protocol (OTLP)
Tracing：OpenTracing 兼容
Metrics：Prometheus 格式
Logs：拥抱 Parquet 和 Schema-on-Write

这降低了用户的使用成本——任何支持 OTLP 的客户端都可以接入。

观点归纳：OpenObserve 给我们的启示

1. 成本结构优化是创新的源泉

OpenObserve 的成功证明了一个道理：很多时候，颠覆一个行业的不是更强大的功能，而是更低的成本结构。当 Datadog 和 Splunk 依赖"高价=高质量"的商业模式时，OpenObserve 用工程优化打开了新的市场空间。

2. "简单"是系统工程的结果，而不是妥协

OpenObserve 的"单二进制部署"看起来简单，但背后是复杂的系统工程：

需要处理单节点和分布式两种模式
需要在简单和可扩展之间找到平衡
需要隐藏复杂性而不损失功能

这告诉我们：简单性是需要设计的，不是功能删减的结果。

3. Rust 在基础设施领域的崛起

OpenObserve 是 Rust 在云原生基础设施领域成功的又一个案例。这反映了：

内存安全的价值：在数据密集型应用中，安全问题代价高昂
性能的追求：在成本敏感的场景，每一点性能都转化为金钱
生态成熟：Rust 在云原生基础设施领域的生态系统已经成熟

4. 多租户是 SaaS 化的必经之路

OpenObserve 的多租户设计表明，如果一个开源项目想要商业化，多租户是不可回避的设计决策：

数据隔离：租户之间的数据必须严格隔离
配额管理：防止单个租户消耗全部资源
计量计费：精确跟踪每个租户的资源使用

5. 列式存储在日志领域的价值

Elasticsearch 使用的是倒排索引，适合全文搜索，但不适合日志分析的场景。OpenObserve 选择 Parquet 列式存储，证明了：

按列压缩效率高：只读取需要的列
聚合查询快：COUNT、SUM、AVG 等操作高效
时序数据友好：按时间分区，查询效率高

6. S3 作为数据湖的智慧

将对象存储作为主存储是一个大胆的设计，但事实证明是正确的：

成本低：S3 成本约为 EBS 的 1/10
持久性高：11 个九的持久性
弹性扩展：无需提前规划容量

这给我们的启示是：在云时代，充分利用云存储的弹性可以大幅降低成本。

7. 可观测性是 AI 时代的基础设施

OpenObserve 加入 LLM 可观测性支持，反映了一个趋势：

AI 应用需要可观测性，就像传统微服务需要日志和追踪一样。

LLM 的 Token 消耗、成本、延迟、错误率——这些指标对于运营 AI 应用至关重要。

合规与安全

OpenObserve 提供企业级的安全特性：

认证/合规	状态
SOC 2 Type II	✅ 认证中
ISO 27001	✅ 认证中
GDPR	✅ 合规
HIPAA	✅ 企业版提供 BAA

安全特性：

传输加密：TLS/SSL
静态加密：SSE-KMS
敏感数据脱敏（SDR）：内置 PII 检测和脱敏
SSO/SAML：企业版支持
RBAC：基于角色的访问控制

总结

OpenObserve 是一个令人印象深刻的开源项目，它展示了：

技术创新：用 Rust + Parquet + S3 重构可观测性存储
成本重构：140 倍存储成本降低，让可观测性民主化
简单部署：单二进制，5 分钟跑起来
多租户架构：SaaS 化的技术基础
AI 就绪：LLM 可观测性支持

无论你是运维工程师寻找 Splunk/Elasticsearch 替代，还是开发者需要低成本的可观测性方案，OpenObserve 都值得研究。它不是银弹，但它代表了一种工程上的极致追求——用更好的架构、更低的成本，让更多人用得上好东西。

参考资料：

GitHub: https://github.com/openobserve/openobserve
官网: https://openobserve.ai
文档: https://openobserve.ai/docs
Helm Charts: https://openobserve.github.io/helm-charts