OpenObserve | 开源可观测平台 – 日志指标链路统一分析 – 自托管

OpenObserve 是可自托管的开源可观测平台，后端主要使用 Rust，开源版采用 AGPLv3 许可。它把日志、指标、分布式链路、前端监控、仪表盘与告警放在同一套界面里，适合希望关联多种观测数据、并愿意维护采集和存储环境的团队。

从“请求变慢”开始，几种数据各回答一部分

假设一次接口请求突然变慢，指标可以先显示延迟、错误率和请求量何时变化；链路帮助定位哪个服务或调用跨度耗时增加；日志再提供相关错误和业务上下文。如果服务端正常、浏览器仍卡顿，前端 RUM 可以补充页面性能和前端错误。这个例子描述的是排障思路，不是本文实测结果。

平台原生支持 OpenTelemetry，日志与链路使用 SQL，指标可用 SQL 或 PromQL。把数据送进同一平台以后，还要让服务名、环境、时间和请求标识能够对应；缺少采集或关联字段时，界面不会自动补出一条完整请求。

因此可以先接一个服务，让常用时间筛选和查询跑通，再补链路或前端信号。需要定期观察的查询放进仪表盘，需要采取行动的异常再配置告警，避免图表越来越多，却没有明确的异常处置办法。

日志写入之前整理一次，查询时少处理一次

日志页面提供全文搜索、字段筛选、时间分布和 SQL。先按时间与服务收窄数据，再下钻记录，通常比在全部数据里反复换关键词更容易定位。

流水线可以在写入时规范字段、转换内容和组织数据流。例如不同服务使用不同严重级别名称，可以在采集或处理阶段统一，后面的查询和告警就不必重复写转换逻辑。具体内置脱敏能力要看所选版本与版本功能范围；企业版的 Sensitive Data Redaction 不应当作开源版默认条件。

保密字段最好在进入平台之前过滤。官方 FAQ 将写入数据描述为不可变，不能把它当成可逐条修改的业务数据库。若存在误采集纠正或个人数据删除要求，应先核对当前删除粒度和保留策略，再接正式数据。

存储方式改变了哪些成本

OpenObserve 使用 Parquet 列式文件，集群路线依赖 S3 兼容对象存储，并通过分区、索引和缓存控制扫描范围。查询少数字段时，列式组织有助于减少读取；长期数据保留则可以利用对象存储。单机本地验证与集群对象存储不是相同部署规模。

README 中的“最高约 140 倍存储成本差异”是项目方的比较，不是本文测试结论。实际账单还包含写入量、保留天数、压缩率、请求费、缓存、查询并发和跨区流量。评估时拿自己的日志和常用查询比较，才能知道降低存储费用后，计算和运维是否仍符合预算。

单机试用，把入口先留在本地

Linux/macOS 等使用 Bash 的环境，可按官方 Docker 入口启动，以下示例把端口仅绑定本机。示例邮箱和密码必须替换，./data 用于保留数据：

docker run -d \
  --name openobserve \
  -v "$PWD/data:/data" \
  -p 127.0.0.1:5080:5080 \
  -e ZO_ROOT_USER_EMAIL="root@example.com" \
  -e ZO_ROOT_USER_PASSWORD="replace-with-a-strong-password" \
  public.ecr.aws/zinclabs/openobserve:latest

打开 http://localhost:5080，再按界面的摄取说明接入测试数据。这条命令用于试用；需要持续运行时固定已验证的镜像标签或摘要，规划 TLS、采集端凭据、数据卷与备份。

单机验证解决的是“能否接入和查询”，不会提供节点冗余。需要高可用时，再按官方 HA 文档安排角色、元数据与对象存储，并单独监控平台自身的写入失败、磁盘和查询资源。

开源版与企业版，按治理需求比较

小团队主要需要采集和查询时，可以从开源版评估。若必须接组织身份系统、隔离部门权限或跨区域检索，就要先核对功能矩阵与商业条件。自托管位置和开源代码许可，并不决定所有企业功能都能免费使用。

源码调整可从 src/ 的服务端和 web/ 的前端分开入手；修改查询、摄取或界面时，依赖和构建流程见仓库贡献文档。对外提供修改后的服务或再分发前，还要阅读 AGPLv3 和所用构建产物的许可。

• 仓库与功能范围：https://github.com/openobserve/openobserve
• 快速开始：https://openobserve.ai/docs/quickstart/
• 高可用部署：https://openobserve.ai/docs/ha_deployment/
• 架构说明：https://openobserve.ai/docs/architecture/