Traceway 完全指南：MIT 许可的自托管可观测性平台，90 秒部署

发布日期：2026-05-13 • 阅读时间：12 分钟 • English Version

Traceway 是一个 MIT 许可、原生基于 OpenTelemetry 的可观测性平台，把日志、链路追踪、指标、会话回放、异常监控和 AI 可观测性整合到一套自托管系统中。最吸引人的数字是：一条 docker compose up -d 命令，大约 90 秒就能跑起来。

在 Hacker News 上，这个项目获得了 31 分，讨论主要围绕它和 SigNoz、Grafana 的 Loki+Tempo+Mimir 等现有开源可观测性工具的对比。Traceway 的关键区别是：纯 MIT 许可，没有任何"开源核心"限制——没有 BSL，没有需要付费才能解锁的功能。所有功能都在包里，装好就有。

如果你是一个中小团队，厌倦了 SaaS 可观测性平台的高额账单，或者因为隐私原因不想把遥测数据发送到第三方云，Traceway 值得认真看看。本文带你完整了解它。

Traceway 是什么

Traceway 是一个围绕 OpenTelemetry 从头构建的可观测性后端。你把任何 OTel SDK 的 OTLP 导出器指向它——不需要 Collector，不需要胶水代码，不需要每种语言各自的厂商 SDK。直接通过 OTLP/HTTP 接收链路、指标和日志，原生支持 Protobuf 和 JSON 格式。

项目自己的定位是"你唯一需要知道发生了什么以及怎么修复的工具"。这个说法挺自信的，但功能列表确实够全面：

• 分布式追踪——跨服务的端到端 Span 瀑布图。点一条日志直接跳到对应的链路。完整的 W3C 链路上下文传播。
• 指标收集——主机指标、运行时指标、自定义指标，支持任意维度的图表和自定义仪表盘组。原生 OTel 指标接收。
• 日志聚合——结构化、关联追踪 ID 的日志存储，支持亚秒级搜索。不需要单独的日志采集器。
• 异常监控——SHA-256 归一化的堆栈跟踪，自动分组排序。支持 webpack、esbuild、Vite 的源码映射。
• 会话回放——精确回放用户出错前的操作。支持 Web（任意 JS 框架）和 Flutter。
• AI 可观测性——LLM 成本追踪、Token 计数、延迟监控、完整对话捕获。通过 OpenRouter 或任何 OTel 兼容的 AI 网关接入。
• 告警——支持 Slack、GitHub、邮件和 Webhook 等通知渠道。
• 多租户——基于角色的权限管理，支持团队协作。

MIT 许可：没有隐患

Traceway 最值得注意的设计决策是 MIT 许可。这一点很重要，因为可观测性工具在开源世界里有一段复杂的许可历史。

很多流行的替代方案用了限制性更强的许可证。Grafana 的 Loki 和 Tempo 是 AGPLv3，Elasticsearch 从 Apache 2.0 切换到了 SSPL/Elastic License，还有不少项目用 BSL（商业源码许可）或"开源核心"模式——部分功能需要付费订阅。HashiCorp 把 Terraform 和 Consul 从 MPL 改成 BSL 的做法，让很多团队对这类项目持谨慎态度。

Traceway 走了相反的方向。整个平台——包括会话回放、AI 可观测性、多租户和告警系统——全部 MIT 许可。自托管的 Traceway 没有任何付费版。项目通过 Traceway Cloud（托管服务）盈利，但跑在云上的代码和你在自己服务器上跑的是同一份 MIT 代码。

Traceway 的 README 里有一个清晰的对比表：

• 企业方案（Datadog / New Relic）：按事件、按主机、按席位计费。专有许可，每种语言需要各自的 vendor SDK。
• 自建 OSS 方案（Prometheus + Loki + Tempo + Mimir + ...）：免费，但把六七个工具粘在一起的运维成本是真实存在的。混合许可（部分 BSL / 开源核心）。需要跑 OTel Collector。
• Traceway：自托管免费。MIT 许可，没有隐藏条件。原生 OTLP/HTTP 接收，不需要 Collector。一套系统，一个 Trace ID 贯穿日志、链路、指标和回放。

90 秒部署：怎么做到的

Traceway 最让人印象深刻的部分是部署体验。完整流程只有两步：

git clone https://github.com/tracewayapp/traceway
cd traceway && docker compose up -d
# ✓ 打开 http://localhost 就能看到面板

没了。Docker Compose 栈运行三个服务：

• Traceway——Go 后端，负责 OTLP 接收、REST API 和 SvelteKit 2 前端
• ClickHouse——列式存储，存链路、指标和日志
• PostgreSQL——关系数据库，存用户、项目配置和告警规则

启动后打开 http://localhost/register 注册账号，然后把任意 OTel SDK 指向 http://localhost/api/otel/v1/traces（或 /metrics、/logs），链路数据就立刻出现在面板上了。

对于想要更少基础设施的团队，Traceway 还支持 嵌入式模式——把整个可观测性后端跑在 Go 进程内部，用 SQLite 替代 ClickHouse + PostgreSQL：

go get github.com/tracewayapp/traceway/backend

import tracewaybackend "github.com/tracewayapp/traceway/backend"

func main() {
  go tracewaybackend.Run(
    tracewaybackend.WithPort(8082),
    tracewaybackend.WithDefaultUser("admin@localhost.com", "admin"),
    tracewaybackend.WithDefaultProject("My App", "go", "dev-token"),
  )
}

这种嵌入式模式特别适合开发环境、CI/CD 流水线，或者那些跑 ClickHouse 有点大材小用的单实例部署。

技术栈

Traceway 的架构选择非常务实：

• 后端：Go 1.25 + Gin Web 框架。编译成单个二进制，运行时资源占用低。
• 前端：SvelteKit 2 + Svelte 5 + Tailwind CSS v4。响应快速，打包体积小。
• 遥测存储：ClickHouse（独立模式）或 SQLite（嵌入式模式）。ClickHouse 处理链路搜索和指标聚合这类 OLAP 工作负载是标准选择。
• 关系存储：PostgreSQL（独立模式）或 SQLite（嵌入式模式）。管理用户、项目和告警规则。
• 接收协议：OTLP/HTTP，支持 Protobuf 和 JSON，统一接收链路、指标和日志。
• 构建标签：pgch 标签启用 ClickHouse + PostgreSQL 模式；默认（不加标签）全部用 SQLite。

选择 Go 后端是有意为之——单个二进制部署，除了数据库没有其他运行时依赖。不需要 JVM，不需要 Node.js 服务进程，不需要 Python 运行时。加上 Docker Compose，"90 秒部署"确实不是吹的。

客户端 SDK 和集成

Traceway 兼容所有 OTel SDK，同时也提供了自带会话回放功能的一方集成：

后端集成（Go 生态）

• Gin 中间件
• Chi 中间件
• Fiber 中间件
• FastHTTP 中间件
• net/http 中间件
• Go 通用 SDK

全栈 / 前端集成

• Node.js SDK
• NestJS
• Hono
• Symfony
• Cloudflare Workers
• OpenTelemetry SDK（任意语言）
• Flutter（带会话回放）

所有集成都通过 OTLP/HTTP 传输链路、指标和日志。不需要任何专有 SDK。对于前端框架来说，会话回放功能也是开箱即用的。

Traceway 与竞品对比

对比 SigNoz

SigNoz 是最接近的开源竞品——同样基于 OTel、可自托管、功能集类似。底层都用了 ClickHouse。主要区别：SigNoz 的企业功能是专有许可（开源核心模式），而 Traceway 全部 MIT。Traceway 自带会话回放和 AI 可观测性，SigNoz 需要额外集成。

对比 Grafana 全家桶（Loki + Tempo + Mimir + Grafana）

Grafana 生态在大规模场景下久经考验，但运维复杂度是真实的——至少需要管理四个独立服务外加 OTel Collector。每个组件有自己的配置、保留策略和扩缩容行为。对于中小团队来说，Traceway 单服务部署要简单得多。

对比 Datadog / New Relic

SaaS 巨头在成熟度、集成广度和零运维上胜出。但它们败在成本——可观测性账单高得离谱已经是业内共识。对于 10-50 人的工程团队，自托管 Traceway 每月可以省下几千到几万美元，同时获得相当的可观测性能力。

对比 OpenObserve

OpenObserve 是另一个有趣的开源选项（AGPL 许可），功能类似，号称存储成本比 Elasticsearch 低很多。Traceway 的 MIT 许可在商业环境中避免 AGPL 的传染性问题，对某些团队来说是法律上的优势。

什么时候该用 Traceway

以下场景特别适合 Traceway：

• 中小工程团队（5-50 人），需要可观测性但招不起专职的 SRE
• 隐私敏感的场景——医疗、金融、国防，或者任何遥测数据不能离开自有基础设施的场景
• 创业公司和独立开发者，想省掉早期每个月几千块的 Datadog 账单
• 已经在用 OpenTelemetry 的团队——Traceway 是无缝的 OTel 后端，原生 OTLP/HTTP 接收
• Go 技术栈的团队——可以利用嵌入式模式实现超简单的部署
• AI 应用——内置的 LLM 可观测性（成本、延迟追踪）在开源工具里很少见

但它可能不适合：

• 每天处理 PB 级遥测数据的超大规模部署（Grafana 生态在大规模上经过更多考验）
• 需要完整托管 SaaS 方案和 SLA 的团队（Traceway Cloud 存在但还在早期）
• 已经在 Datadog/New Relic 生态上深度投入的团队

快速上手

最快的方式就是前面说的 Docker Compose 方案。生产环境部署时，文档建议：

• 配置 TLS 终止（通过反向代理或直接在 Traceway 容器上）
• 为 ClickHouse 和 PostgreSQL 数据配置持久化卷
• 按需配置 SSO 环境变量（Google/GitHub OAuth）
• 根据保留需求调整 ClickHouse 表的 TTL
• 通过通知面板配置告警

完整教程在 docs.tracewayapp.com。

社区和路线图

Traceway 在开放中开发，Discord 社区很活跃。团队在里面讨论功能需求、帮助解决部署和 OTel 连接问题、分享使用案例，还会提前透露即将推出的功能。

欢迎贡献代码——PR 会有人审阅和合并。项目目前还比较早期，社区的意见确实能影响路线图。缺某个框架的集成？你可以提 issue，也可以自己贡献一个。

写在最后

Traceway 的目标不是和 Datadog 正面竞争。它的目标是让可观测性变得触手可及——让那些没有企业 SaaS 预算的团队、不想维护 Grafana 全家桶的团队、以及不能把遥测数据发给第三方云的团队，也能拥有专业的可观测性能力。

MIT 许可才是这个故事的核心。在可观测性工具越来越倾向限制性许可的行业趋势下，Traceway 坚持宽松许可，消除了一类法律和运维层面的隐忧——那些你在选择工具时必须考虑的"万一以后它换许可证怎么办"的问题。

90 秒部署、没有按事件计费、云端跑的代码和你自己服务器上跑的是同一份。这个价值主张非常有说服力——也解释了为什么它能在 Hacker News 上获得 31 分。

相关链接：
GitHub 仓库 • 官方网站 • 文档 • Traceway Cloud • Discord 社区 • Hacker News 讨论