OpenObserve · 用 Rust 写的开源可观测性平台

客服转来一句"下单转圈"，你要开四个页面

周三下午，客服丢过来一条投诉：提交订单时页面一直转，最后失败了。只有一部分用户遇到，你复现不出来。

你开始查。日志在三台机器上，一台一台 ssh 上去 grep；指标在 Grafana，CPU、内存、QPS 看着都正常；链路追踪一直想上，但那意味着再装一套 Jaeger 加一套存储，排期排到了下个季度，所以没有；前端那边只有用户的一句口述。四个来源，两块屏幕，你靠时间戳手动对齐，查到下班还在猜。

真正难受的是最后一步：你想确认这问题是不是上周就有了。可上个月磁盘告警，日志保留期从 30 天砍到了 7 天——那段数据已经没了。

一个二进制，四种信号

OpenObserve 是一个开源的可观测性平台：日志、指标、链路追踪和前端用户数据都进同一个地方，用 SQL 查，一个二进制就能跑起来。

它用 Rust 写，底层是 Parquet 列式存储加对象存储，所以同样的数据量占的空间和机器都少得多——这就是为什么你可以不再为省磁盘而砍保留期。查询用的是 SQL 和 PromQL，没有专有查询语言要学，也没有分片、副本、堆大小这类参数要调。

边界也说清楚：

• 它做：接入日志／指标／链路／前端 RUM 四类数据（原生 OTLP，不绑厂商）、SQL 与 PromQL 查询、仪表盘、告警与事件、摄入阶段的数据管线
• 它不做：数据进来之后不可修改、也不能删单条——只能按保留期整段丢弃。这是它有意的设计（对日志和审计场景是好事），但意味着写错的数据改不了
• 开源版本的日志、指标、链路、仪表盘、告警、管线都是完整可用于生产的；单点登录、细粒度 RBAC、审计日志、跨集群联邦搜索、敏感数据脱敏属于官方商业版，不在这里部署的范围内
• 你部署的是开源自托管版本（AGPL-3.0，允许商业使用），数据全部落在你自己的 ECS 上

通过阿里云计算巢部署，几分钟开箱可用，不用自己拉镜像、配存储、想端口怎么暴露。

它解决了什么问题

回到那条投诉：这次同样的现象再来，你直接在链路里搜下单这个操作，瀑布图一眼看到购物车服务那一段吃掉了绝大部分时间；点开那个环节，对应的日志就在旁边；前端数据告诉你哪批用户受影响、影响了多久。十几分钟，不用猜。

而更深一层的变化是：可观测性从"一件不断被砍的事"变成"一件可以一直全开着的事"。以前你在做减法——链路追踪因为"还要多装一套"没上，日志因为磁盘贵砍到 7 天，前端数据干脆没有。这些取舍不是因为你不想看，而是每多看一类数据就要多付一份钱和一份运维。当接入变成一个端口、存储变成原来的零头，"要不要留""要不要看"就不再是预算问题了。

核心能力

四类数据，同一个界面

对应开头最耗时间的那件事：在四个系统之间对时间戳。

• 日志与链路都用 SQL 查 —— 全文检索、快捷筛选、可视化查询构建器，指标另可用 PromQL，没有专有语言要学
• 顺着一个请求点下去 —— 瀑布图、火焰图、甘特图三种视角，点任意一个环节钻进去；服务依赖图按健康状况着色，一眼看出哪段是问题源头

存得下，所以留得久

• 列式存储加对象存储 —— 官方口径是相较 Elasticsearch 大幅降低存储开销、约四分之一的硬件；对你的直接意义是保留期不用再跟磁盘余量较劲
• 没有集群参数要调 —— 不分片、不配副本、不调堆大小，单个二进制就能扩到 TB 级

从"报警了"到"处理完了"

告警响完不等于事情有人管。

• 多种告警方式 —— 按阈值、按计划、实时触发，带告警历史和异常检测
• 告警自动汇成事件 —— 相关告警关联成一个事件，按打开／已确认／已解决走完整流程，不用另开一套工单

数据进来之前先过一遍

• 可视化摄入管线 —— 拖出源、转换、目标三类节点，在写入前做富化、脱敏、降噪和格式归一，不需要额外的采集端工具
• 日志转指标 —— 把高频日志在管线里直接聚成指标，既省存储又能拿来配告警

谁最该用

技术支持

• 官方仓库：github.com/openobserve/openobserve
• 官方文档：openobserve.ai/docs
• 问题反馈：GitHub Issues

🚀 立即体验

→ 一键部署 OpenObserve

部署完成后，在服务实例详情页的输出里点开访问地址，用刚才填的管理员邮箱和密码登录。第一件该做的事：进左侧「数据 - 数据源」页面拿到上报地址和令牌，先把一个服务的日志接进来，看着它出现在列表里。