设想一个周五深夜，值班工程师的手机响了。
一家小 SaaS 团队白天刚上线新版本。告警说某个接口的延迟突然上涨，可没人知道是数据库慢了、某个依赖挂了，还是机器的磁盘快写满了。大家登进日志页翻了半天，才发现一次配置改动放大了重试流量。
复盘的时候，问题不只在这次假设中的事故，还在一个更早就该解决的事：团队停掉原来的云端监控后，只剩零散的容器日志和一张 Grafana 看板。
不是不想花钱。是账单算下来太吓人。按主机数加数据量双重计费，团队一扩机器，监控成本跟着往上跳。财务问过一次“为什么监控比服务器还贵”，他们这才开始琢磨自己搭。
麻烦从这儿才真正开始。自托管可观测性这件事，装起来容易，掉坑很难受。OpenObserve 和 SigNoz 是被提得最多的两个开源选项，网上横评不少，但大多停在功能清单。对预算有限的团队来说，清单能看，坑看不出来。
所以这篇不打算再列一遍谁的功能多。我想聊的是：如果你只有一台还行的机器、一个兼职维护的人，和一笔说不清下个月会不会涨的预算，这两套东西会把你的日常带向哪里。
你在自建的不是一个工具，是一份长期维护合同
很多团队选型的第一个错误，是把开源软件当成免费软件。
OpenObserve 和 SigNoz 都不收 license 费，这话没错。但自托管真正吃掉的是运维时间。机器要有人管，磁盘满了要有人清，版本升级要有人跟，出了 bug 得有人去 issue 里翻。
先看两边的底子，差别比想象中大。
OpenObserve 用 Rust 写，卖点是“一个二进制跑起来”。它的官方架构文档写得很直接：默认的单机模式是 SQLite 加本地磁盘，适合轻量使用和测试；想要持久性和弹性，可以切成单机加对象存储，把数据写成 parquet 文件放到 S3、MinIO、Azure Blob 这类地方；再往上，高可用模式要 Kubernetes、对象存储、PostgreSQL 存元数据、NATS 做集群协调，还要 Router、Ingester、Compactor、Querier、Scheduler 五种节点各至少一个（见 OpenObserve 架构文档）。也就是说，单机是它的主路径，集群是给大流量另开的一条路。
SigNoz 走的是更标准的云原生栈。它本质上是 OpenTelemetry 加 ClickHouse：应用通过 OTel Collector 把数据送进来，落进 ClickHouse 这个列式数据库，再有一个打包好的 SigNoz binary 负责前端、查询 API、告警规则和 alertmanager（见 SigNoz 技术架构）。好处是生态对齐得好，OTLP 是行业通用协议，接入方式将来换工具也能复用；代价是你得接受 ClickHouse 这层东西存在，它对内存和磁盘 IO 有要求，扩容调优也更像在管一个数据库。
一句话概括我的判断：OpenObserve 把复杂度藏在“你可以先小”里，SigNoz 把复杂度摆在“你迟早要懂”上。
这不是谁高谁低。小团队最怕第一种复杂度，明明只想看日志，却被迫先学会运维一个数据库。反过来说，如果你本来就跑在 Kubernetes 上，身边有人懂 ClickHouse，那 SigNoz 这条路反而更顺。
日志、指标、追踪，别一次全上
第二个常见的坑，是第一天就想把可观测性三件套铺满。
完整的三块是日志、指标、追踪，但它们的接入成本差得很远。
日志最容易起步。应用本来就在打日志，改一下输出位置，或者挂一个采集 agent，数据就来了。它也是事故时最直接的信息来源，上面老周团队遇到的问题，翻日志就能定位。
指标次之。CPU、内存、请求量、错误率这些，用现成的 Prometheus 采集器就能拿到，几乎不用改代码。指标的价值是让你在出事之前看到趋势，而不是事后补记录。
追踪最贵。要在代码里埋点，要理解 span 和 trace 的关系，数据量还特别大，存起来就是钱。它解决的是“一个请求跨了八个服务，到底慢在哪一段”，很有用，但前提是你真有多服务、真需要精确定位。
我的建议是分三步走，每一步之间隔一两周：先只上日志，把收集、查询、保留策略跑通，确认团队真的会去看；再补指标，把机器和应用的基本健康度接进来，配几条最简单、真会有人响应的告警；最后才考虑追踪，而且从最关键的一条业务链路开始，不要全量埋点。
顺序不是随便排的，它对应的是你的第一反应。你出事第一反应是翻日志，就先保证日志好用；你开始想在出事前预警，就补指标；你已经在为慢查询和跨服务调用发愁，再上追踪。一步到位的结果，往往是三样都装了一半，每种都不好用，还烧掉一堆存储。
这里还有个容易忽略的细节：保留策略。很多团队默认“全都留着”，日志越堆越多，磁盘报警比业务报警还勤。合理的做法是按价值分层，近一周的日志留着随时查，更早的转冷存储或者干脆只留聚合结果。指标同理，采样率不是越低越省，采太狠了，出事时看到的曲线全是平的，等于白监控。
真正吃掉预算的，是存储和人的时间
自托管的成本有两块，一块是机器和存储，一块是你自己。
OpenObserve 在这件事上有个实在的设计：它把数据写成 parquet 文件，可以直接堆进对象存储。对象存储的单位成本远低于块存储，意味着你能用很便宜的方式长期保留日志。官方文档里还提到，单机默认配置在他们自家的 Apple M2 测试里，写入速度大约是每秒 31MB，折合每天 2.6TB 左右（见 OpenObserve 架构文档）。这个数字是他们自己环境测的，别直接拿来估你的量，但至少说明单机不是玩具。代价也要说清楚：用对象存储换持久性，读取延迟会比本地磁盘略高一点，查询频繁的场景要自己权衡。
SigNoz 这边，压缩是 ClickHouse 的强项，列式存储对日志和追踪这类结构化数据压得很好。代价是 ClickHouse 对内存敏感。官方安装文档给了个不算高的门槛：跑单机 Docker Compose，至少要给 Docker 分 4GB 内存（见 SigNoz 自托管安装）。这条数字很实用，说明一台 8GB 内存的小机器也能起步，但日志量一上来，内存会先成为瓶颈，然后你就开始研究分片、副本、磁盘选型这些原本不想碰的话题。
人的时间更难算账。按我的经验，OpenObserve 单机模式的日常维护，基本是守着磁盘别满、跟着升级别落下；SigNoz 则多一层“理解 ClickHouse 的运行状态”。团队里有人本来就对数据库有兴趣，这不算负担；没有的话，这就是一项得排进日程的工作。
另外别漏了备份和升级窗口。自托管意味着升级由你决定，也意味着你必须在某个时间点停下服务来做这件事。一个没被认真算过的现实是：升级之后万一面板打不开，你手上没有厂家的支持电话，只能自己回滚。所以定期导出配置、给数据留一份备份，是自托管的一部分，不是可选项。
还有个细节值得记：SigNoz 从 v0.130.0 起，旧的 install.sh 和仓库里那份 Docker Compose 已经不再维护，官方主推的是 Foundry 这套声明式安装工具（见 SigNoz 自托管安装）。这类变动在开源项目里很常见，不影响你能不能自托管，但影响你照着哪份教程走。网上搜到的老文章，可能一上来就让你跑已经过时的脚本。
动手之前，先估一下你的数据量
老周团队犯的另一个错，是直到装完才发现，自己根本不知道每天产生多少日志。
这件事应该放在选型之前做。方法不复杂：看单个服务平均每天写多少条日志，乘上单条日志的平均大小，再把所有服务加总。如果日志里塞了完整的请求体和响应体，单条轻松到几 KB，量级会和只打关键字段差出几十倍。
这个估算决定了后面几乎所有的选择。每天几百 MB 的团队，一台小机器加本地磁盘就够，没必要碰集群；到了每天几百 GB，单机迟早撑不住，要么上对象存储，要么往 SigNoz 那种带 ClickHouse 的路子走。存储和保留天数也是同一笔账，你打算留 7 天还是 90 天，成本能差出十倍。
有个省事的做法，是先把噪声大的服务做采样，或者干脆降一级日志级别，把 debug 关掉。很多团队磁盘吃紧，不是因为业务日志多，而是因为某几个服务一直在刷没人看的 debug。
开源自托管，不等于所有功能都免费
还有一件事容易被忽略：开源版本和企业版本，功能范围不一样。
OpenObserve 和 SigNoz 都有开源核心，也都有商业版或云托管版。社区版通常覆盖日志、指标、追踪的主体能力，但像单点登录、细粒度权限、审计这类偏企业运维的功能，往往落在商业版里。这不奇怪，开源项目总要有收入来源。
真正要避免的，是照着官网宣传页选型，装完才发现你需要的那个功能在另一个版本。我的建议很土但有效：把团队真正会用到的功能列一张短清单，对着文档确认它在开源版里有没有；最关键的那一两条，最好先在一台测试机上验证过再决定。
这么做的另一个好处，是你会顺带搞清楚自己的需求到底有多少。很多团队列完清单才发现，日常真正要用的就是日志搜索、几条告警和一个看板。剩下的功能，是为“万一以后要用”准备的，不构成今天选型的理由。
那到底怎么选
如果你只想听一句结论：多数预算有限、人手也有限的小团队，从 OpenObserve 单机起步会更省心；如果你已经深度用 Kubernetes 和 OpenTelemetry，并且团队里有人愿意维护 ClickHouse，SigNoz 的长期上限更高。
再展开一点。
选 OpenObserve 的情况：你想要一台机器、一条命令、一个能看日志和指标的面板，先把可观测性跑起来；你希望存储成本可控，愿意把数据丢到对象存储；你短期内不打算搞复杂集群。它的单机模式允许你后面再升级，不用一开始就买齐所有零件。
选 SigNoz 的情况：你的服务已经用 OTLP 上报数据，或者你计划认真做分布式追踪；你有 Kubernetes 环境，不想为监控单独维护一套异构架构；你接受前期多花几天摸清 ClickHouse 的脾气，换一个更接近行业标准的栈。
两种情况都不是终局。可观测性这行，工具会换，数据格式和采集方式尽量别换。这也是为什么，即便你现在选了 OpenObserve，也值得把接入方式统一到 OpenTelemetry 上。换后端的时候，改的是接收端，不是你的应用代码。
给老周团队的三十天方案
回到开头那个五人团队。
他们没有一次上齐三件套。第一周，只把应用日志接进 OpenObserve 单机版，跑在一台 8GB 的小服务器上，数据落对象存储，保留策略设成 30 天。第二周，开始有人真的每天去看一眼错误日志，顺手给几条常见错误加了注释。第三周，他们接上 Prometheus 采集器，给 CPU、内存、接口错误率配了三条约会响的告警。追踪他们暂时没碰，因为产品大部分逻辑还在一个单体里，暂时不需要跨服务定位。
一个月后，老周说感觉不像换了工具，更像终于有了个能问问题的地方。故障还是会来，但至少知道去哪儿找线索，不用再半夜靠猜。
也不是每个团队都该自托管。如果你的服务规模很小，又实在没有人愿意碰运维，那多花一点钱买托管服务、把时间留给产品，往往是更划算的选择。自托管是一种取舍，不是一种姿态。
这才是自托管可观测性真实的样子。它不会让你从此不出事故，也不会一夜之间把账单砍到零。它给你的是掌控感：数据在你自己机器上，成本可预期，出事的时候手里有东西。
如果你现在正盯着那张监控账单犹豫，不妨先做一个最小的决定。选一套，只上日志，跑两周。跑通了，再谈指标和追踪。真正的坑从来不在选哪套工具，而在一次想要太多。至于自托管还是买托管，答案也从来不在工具本身，而在你愿意为它留出多少时间。
Stay updated with our latest AI insights
