选择 molesignal 的理由
- 希望减少后端数量、Schema 和运维手册。
- 故障调查需要持续保留上下文，而不是靠仪表盘层拼接。
- 希望用 SQL 处理跨信号问题。
- Apache 2.0 与聚焦的自托管产品符合治理要求。
产品对比 · Grafana Stack
统一数据平面，还是可组合的信号后端
两者都能自托管，也都能使用对象存储。真正的取舍是整合，还是独立组件与专用查询语言。
| 决策维度 | molesignal | Grafana Stack |
|---|---|---|
| 后端组成 | 一个应用支持 standalone 和多角色模式；日志、指标与链路共享列式数据平面。 | Grafana 负责可视化，Loki 存日志、Mimir 存指标、Tempo 存链路、Pyroscope 存 Profiles。 |
| 查询模型 | 跨列式遥测使用 SQL，指标使用公开范围的 PromQL 子集。 | 使用 LogQL、PromQL、TraceQL 与 Profile 查询等专用语言和 API。 |
| 跨信号路径 | 调查栈在下钻时保留租户、时间、服务、Trace 与 Profile 上下文。 | Grafana 通过数据源、derived fields、exemplars 与原生集成连接各后端。 |
| 持续性能分析 | Profiles 是一等产品能力，支持 pprof、Pyroscope 兼容和 OTLP Profiles 摄取。 | Grafana Pyroscope 是独立的持续性能分析数据库，并与 Grafana 及其他组件集成。 |
| 运维面 | 较小的角色集合，依赖 Postgres、对象存储与 ingester 本地 WAL。 | 每个选中的后端都有各自的部署、扩缩容、留存、升级和高可用模型。 |
| 成熟度与生态 | pre-1.0，集成集合与社区仍在增长。 | 项目历史更长，插件生态更大，社区知识也更丰富。 |
选择对比对象的理由: Grafana Stack
- 已经能稳定运维 Loki、Mimir/Prometheus、Tempo 和 Pyroscope。
- 各信号独立扩缩容与专用能力非常重要。
- 依赖 Grafana 仪表盘、插件或成熟社区。
- 更看重成熟组件，不愿承担 pre-1.0 产品风险。
迁移评估
评估整合，不必先扔掉 Grafana
开放标准让这更像一次路由测试，而不是重写埋点。
- 01
把一个服务的 OTLP 与 Prometheus 流量同时复制到 molesignal。
- 02
保留 Grafana 作为参照，复现相同的仪表盘与告警。
- 03
比较组件数量、升级路径、留存行为和跨信号故障调查。
- 04
只迁移那些“减少运维面”价值高于“失去自由组合”的工作负载。
官方来源
来源与时效
产品能力、版本与价格都会变化。在采购或生产决策前，请重新核对下方的一手来源。
- The Grafana StackGrafana Labs
- Grafana Tempo documentationGrafana Labs
- Grafana PyroscopeGrafana Labs
- Grafana Cloud pricingGrafana Labs
- molesignal product capabilitiesmolesignal
- molesignal architecturemolesignal
- molesignal Quick Startmolesignal
molesignal 与 Datadog、Grafana Labs、Elastic、SigNoz、OpenObserve 无隶属或合作关系；各产品名称归其权利人所有。
继续对比其他方案
Datadog01
molesignal vs Datadog
自托管的数据所有权与基础设施成本，对比覆盖面广的托管 SaaS 平台。
Elastic Observability02
molesignal vs Elastic Observability
聚焦的 Apache 2.0 可观测性数据平面，对比更广泛的 Elasticsearch 与 Kibana 平台。
SigNoz03
molesignal vs SigNoz
两个 OpenTelemetry 原生、自托管产品，对比不同的存储引擎、信号重点与成熟度。
OpenObserve04
molesignal vs OpenObserve
两个使用 Rust 与对象存储的可观测性系统，差异集中在许可证、Profiles、产品广度与成熟度。