加载失败
Traceway 是一个 MIT 授权的自托管 observability stack，主打大约 90 秒就能部署起来，讨论焦点其实是它要替代谁，以及是否真能省掉现有观测系统的运维成本。可观测性通常同时覆盖 metrics、logs 和 traces，所以评论里频繁比较 Prometheus（指标系统）、Grafana（仪表盘工具）、Loki（日志系统）以及 OTEL（OpenTelemetry，遥测标准）。另一条主线是 ClickHouse（列式数据库）生态的自托管平台，如 Signoz、ClickStack 和 OpenObserve，它们被认为更适合统一处理大量遥测数据，但也更重。更深的背景是，很多团队正在试图摆脱 Datadog、Splunk 等高价 SaaS，并在“本地能跑”和“生产能稳”之间寻找平衡。
不少人觉得这类产品最大的问题不是能不能自托管，而是又在重造一套 observability stack。评论里把 KubeCon 上满场的观测厂商和“我们更好”“用 Rust 写的”式卖点联系起来，追问 Traceway 相比 Prometheus + Thanos、Grafana、OTEL、VictoriaMetrics、Jaeger/Tempo、Loki 等成熟组合到底有什么明确优势。有人也直接抛出场景分界：如果只是本地跑跑当然无所谓，但一旦进入大规模生产，已有方案的权衡已经很多。还有观点认为 OTEL 已经把互操作性问题缓解了，所以更该做的是整合现有工具，而不是再造一个轮子。
另一条主线是成本压力，尤其是想摆脱 Datadog 和云观测账单。有人把这波热潮归因于 post-covid 便宜资金时代结束，企业开始清理 2023/2024 年在观测平台上的高额支出。评论里也提到和 Datadog 销售谈判的痛苦体验，以及对 Datadog、Splunk 定价的不满，认为与其持续喂给 SaaS 巨兽，不如养一小队工程师维护一套更理性的开源栈。这个视角下，Traceway 的价值不在“新奇”，而在能否把成本和运维压力压到可接受范围。
有人直说 Grafana、Loki、Prometheus、Alloy 这一套并不是真正的 plug-and-play。一个人用 VPS 自建时折腾了几个月，感觉文档总在暗示“别自托管，直接买托管版”，而且界面太粗糙，连伙伴都不愿意用它来排障。另一个人则给出相反经验：在 NixOS 或家用环境里，Prometheus + Grafana + Loki 其实不算难，真正费时的是学习新的领域概念。整体上看，难度很大程度取决于部署方式、熟悉程度和对 UX 的要求。
关于 Prometheus 是否适合生产，争论非常激烈。批评者强调“能跑起来”和“能上生产”是两回事，Prometheus 假设太多 happy path，单节点时序库在磁盘故障、scraper 超时、数据空洞等情况下可能出现灾难性后果，还拿 Google 最终转向 Monarch 作为大规模可靠性的反例。支持者则认为这些都是正常系统故障，超时重试本来就会发生，而且对普通业务来说 Prometheus 已经够用；真要扩展可以上 Thanos 或 Mimir，只是没有任何方案是完全无 bug 的。这个分歧本质上是“指标丢失能不能接受”的边界问题。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
另一组讨论把焦点放在 ClickHouse 生态的自托管观测平台上。有人指出更相关的开源候选其实是 Signoz 和 ClickStack，它们都以 ClickHouse 为底层数据库，且更偏 OTEL-native，而不是单纯的日志平台。实战反馈是用 docker compose 把 metrics、tracing、logging 一起拉起来并不算太难，几 GB 就能跑，但它是否值得，取决于团队是否真的会用查询能力和 dashboard。OpenObserve 被评价为价格和性能不错，但 UI 和 mobile experience 还不够精致；Elastic stack 则被认为查询能力强，但常常过度工程化，最后只是数据仓库或审计存档。
还有一个很细但很典型的产品文案争议：README 里写着没有 per-language vendor SDK，却又链接了一堆 per-language client SDK。回复者解释说，这两类 SDK 不是同一回事，前者是把数据送进平台的厂商 SDK，后者是把数据导出的可选客户端 SDK。这个插曲说明观测产品在采集、导出、agent、SDK 这些词上很容易混用。
OTEL（OpenTelemetry）: 统一采集和传输 metrics、logs、traces 的开放标准。
Prometheus: 以 metrics 和告警为核心的时序数据系统，常作为观测栈基础。
Thanos: 为 Prometheus 提供长期存储、水平扩展和全局查询的组件。
Mimir: Grafana Labs 的可水平扩展 Prometheus 后端，用于大规模 metrics 存储。
ClickHouse: 列式分析数据库，常被新一代观测平台用来承载高吞吐遥测查询。
Loki: Grafana 体系里的日志聚合与检索系统，强调按标签存储日志。