核心问题: 将三种遥测信号合并到单一 ClickHouse 平台后，减少的运维开销是否足以抵消迁移和容量规划带来的成本？
RepoDaily 采用评分
RepoDaily 将该项目的采用分评为 91/100（强）：分数来自文章来源、安装路径、生产风险、差异化、许可证清晰度以及 AI/Agent 适配度。
包含 5 个来源、覆盖 3 类来源；如有 RepoDaily 独有模块，会进一步提高证据分。
检测到 6 个工作流步骤、5 个下一步动作，以及 3 个命令/安装信号。
趋势热度为 +425 stars；如内容中有 release、issue 或维护信号，会提高维护可信度。
采纳风险标记为 medium，并包含 6 条安全说明与 4 条跳过条件。
3 个机会视角、4 个替代方案，以及 4 个类型化模块支撑差异化判断。
文章中包含许可证来源或许可证表述。
文章正文和元数据中检测到 6 个 AI/Agent 相关信号。
项目概览
SigNoz 是一个基于 OpenTelemetry 构建的开源可观测平台，将应用性能监控（APM）、分布式追踪、日志管理、指标、仪表盘、异常管理和告警整合在一个工具中。README 明确将其定位为碎片化监控栈以及 DataDog、New Relic 等商业产品的企业级替代方案。
社区版可通过 Docker、Kubernetes 或 Linux 在自有基础设施上运行。仓库的 LICENSE 文件划清了许可边界：`ee/` 和 `cmd/enterprise/` 目录之外的代码采用 MIT Expat 许可证发布，而企业版专属代码由独立的 `ee/LICENSE` 约束。这意味着自部署社区版包含核心遥测管道和 UI，无需依赖专有运行时。
从 `go.mod` 可以看出平台的技术骨架：ClickHouse 作为主分析存储（`github.com/ClickHouse/clickhouse-go/v2`）、SigNoz 维护的 OpenTelemetry Collector（`github.com/SigNoz/signoz-otel-collector v0.144.3`）、Redis 用于缓存与协调、Prometheus 库用于指标、Alertmanager 用于告警、OpenFGA 用于细粒度授权。前端基于 TypeScript，后端服务使用 Go 编写。
README 描述中还提到了一个新方向：原生 Agent 工作流。README 中的截图展示了 "Noz" 界面和基于 MCP 的 Agent 流程，表明 SigNoz 正在统一遥测数据之上构建 AI 辅助排查能力。
为什么现在变热
- 本期获得 425 颗星，趋势排名第 4，主要得益于 OpenTelemetry 原生定位和 README 中新增的 Agent 原生工作流。
- 将通常需要三个独立工具——指标（Prometheus/Grafana）、追踪（Jaeger/Tempo）、日志（Loki/Elastic）——合并到一个基于 ClickHouse 的平台，减少了以 OTel 为标准的团队的集成胶水代码。
- 使用 `signoz-otel-collector v0.144.3`，这是 SigNoz 维护的上游 OpenTelemetry Collector 分支，与 OTel Collector `v0.144.0` 对齐，插桩保持厂商中立且可移植。
- 社区版在 MIT Expat 许可下免费，提供 DataDog 级别的功能面——APM、日志搜索、追踪漏斗、仪表盘——且不按主机收取 SaaS 费用。
解决什么问题
- 分别运行 Prometheus、Loki 和 Jaeger 会产生碎片化的排查路径：Grafana 中的错误率飙升、Jaeger 中的链路、Loki 中的日志行需要手动关联。
- DataDog 和 New Relic 等商业 APM 工具按主机、容器或摄入量收费，随着可观测覆盖范围扩大，预算压力不断上升。
- OpenTelemetry 已成为事实上的插桩标准，但许多平台仍通过专有网关接收 OTLP，或对原生 OTLP 支持额外收费。
- 基于 Agent 的排障工作流（让 LLM 分析某个 span 或日志聚类）正在兴起，但大多数可观测工具在设计时并未考虑 Agent 原生接口。
工作原理
- 插桩：应用使用 OpenTelemetry SDK 以 OTLP 格式发出遥测数据。SigNoz 直接接收 OTLP 追踪、指标和日志，无需单独的厂商网关。
- 采集：`signoz-otel-collector` 接收 OTLP 数据，处理后写入 ClickHouse 进行长期存储和高基数查询。
- 存储与查询：ClickHouse 作为唯一的分析后端。指标仪表盘支持三种查询模式：可视化 Query Builder、PromQL 和原生 ClickHouse SQL。
- 排查：UI 在同一视图中关联追踪、日志和指标。追踪漏斗等功能可视化请求在服务边界处的丢弃情况。
- 告警：Alertmanager（`github.com/prometheus/alertmanager v0.31.1`）处理通知路由。平台支持基于指标、日志或追踪衍生信号的阈值告警和异常检测告警。
- 访问控制：OpenFGA（`github.com/openfga/api/proto`）和 SAML2/OIDC 集成（`russellhaering/gosaml2`、`coreos/go-oidc/v3`）在企业版中提供 RBAC 和 SSO。
产品演示与界面预览
架构解读：依赖图揭示的运行时真相
`go.mod`（`module github.com/SigNoz/signoz`，`go 1.25.7`）是理解 SigNoz 运行时架构信息量最大的来源。ClickHouse 客户端 `github.com/ClickHouse/clickhouse-go/v2 v2.44.0` 和 SQL 解析器 `github.com/AfterShip/clickhouse-sql-parser v0.4.16` 证实 ClickHouse 不是可选的——它是三种信号的唯一主分析存储。
遥测管道通过 `github.com/SigNoz/signoz-otel-collector v0.144.3` 运行，该组件基于 `go.opentelemetry.io/collector/otelcol v0.144.0` 构建。这意味着 SigNoz 致力于紧跟上游 OTel Collector 发版，而非从零重写采集层。
授权由 OpenFGA（`github.com/openfga/api/proto` 和 `github.com/openfga/language/pkg/go`）处理，这是一种基于关系的访问控制系统，也被 Auth0 和 Twitch 使用。结合 SAML2（`russellhaering/gosaml2 v0.11.0`）和 OIDC（`coreos/go-oidc/v3 v3.17.0`），平台支持企业级身份联合。
其他值得关注的依赖包括 Redis（`github.com/redis/go-redis/v9`）用于缓存和瞬态状态、Prometheus 库（`prometheus/prometheus v0.311.3`、`prometheus/client_golang`）用于指标处理、Gin Web 框架（`github.com/gin-gonic/gin v1.11.0`）用于 HTTP API 层。
试用路径：从克隆到第一条追踪
- 自部署安装文档从 README 链接到 `https://signoz.io/docs/install/self-host/`，涵盖 Docker Compose、Kubernetes Helm 和 Linux systemd 部署路径。
- `CONTRIBUTING.md` 指向 `docs/contributing/development.md` 用于本地开发环境搭建，以及 `docs/otel-demo-docs.md` 用于在 SigNoz 旁部署 OpenTelemetry Demo Application 生成示例追踪和指标。
- 为获得最快的首次体验，README 推荐 SigNoz Cloud 提供 30 天免费试用，无需信用卡，按用量计费从 $49 起——适合在投入自部署基础设施前进行评估。
- 社区 Slack 频道 `#contributing` 和 `#contributing-frontend`（CONTRIBUTING.md 中有链接）是自部署部署的主要支持渠道。
部署须知：许可边界与版本选择
- `LICENSE` 文件划定了清晰边界：`ee/` 和 `cmd/enterprise/` 下的代码由 `ee/LICENSE`（专有）管辖，其余代码均为 MIT Expat。这是标准的开放核心模式。
- 企业版增加 RBAC、摄入控制、自定义留存策略、数据驻留和区域选择。这些功能存在于仓库中但受企业版许可证约束。
- BYOC（自带云）作为介于完全 SaaS 和完全自部署之间的企业版部署模式提供，让团队控制数据面而由 SigNoz 管理控制面。
- `SECURITY.md` 策略要求研究人员通过 `security@signoz.io` 而非公开 GitHub issue 报告漏洞，并承诺每封邮件一个问题以便分类处理。
替代方案对比：SigNoz 与相邻可观测工具
- 对比 Grafana + Tempo + Loki + Prometheus：SigNoz 用一个 ClickHouse 后端的平台替代四个独立组件，降低集成复杂度但增加了对单一存储的集中风险。
- 对比 Jaeger：Jaeger 仅处理分布式追踪。SigNoz 覆盖追踪外加日志和指标，并提供 Jaeger 原生不具备的追踪漏斗可视化。
- 对比 Datadog：Datadog 仅提供 SaaS，按主机和摄入量计费。SigNoz 社区版可自部署且免费；SigNoz Cloud 按用量计费从 $49/月起。
- 对比单独的 Prometheus：Prometheus 仅支持指标和 PromQL。SigNoz 同时支持 PromQL、ClickHouse SQL 和可视化 Query Builder，并增加了 Prometheus 无法存储的日志和追踪。
谁适合关注
适合关注
- 已经以 OpenTelemetry SDK 和 OTLP 导出为标准的团队。
- 出于合规原因需要将遥测数据保留在自有 VPC 或本地数据面中的组织。
- 厌倦了维护四个独立 OSS 遥测存储（Prometheus、Loki、Tempo、Alertmanager）及其之间胶水代码的平台工程组。
- 正在评估 AI 辅助事件排查，希望拥有一个具备新兴 Agent 原生界面的可观测后端的工程团队。
可以先跳过
- 已有成熟 Grafana 技术栈且无意将存储后端迁移至 ClickHouse 的团队。
- 仅需日志聚合且没有分布式追踪或 APM 需求的项目。
- 需要完全托管 SaaS、零基础设施运维的组织——建议使用 SigNoz Cloud 而非自部署。
- 遥测数据量足够小，单个 Prometheus 实例已能覆盖所有需求的团队。
风险与注意事项
SigNoz 是一个成熟且架构清晰的平台，但生产环境自部署需要 ClickHouse 容量规划、持续维护 SigNoz 专有的 OTel Collector 分支，以及对开放核心许可边界的接受。
- ClickHouse 是三种信号的唯一分析后端。低估高基数追踪数据的存储和计算需求会导致查询性能下降。
- 平台使用 `signoz-otel-collector v0.144.3`，这是 SigNoz 维护的分支。团队需要跟踪 SigNoz 的发布节奏而非直接使用上游 OTel Collector，在破坏性变更期间可能会出现滞后。
- 企业功能（通过 OpenFGA 的 RBAC、通过 SAML2/OIDC 的 SSO、自定义留存、数据驻留）受 `ee/` 目录约束并需要商业许可证，可能会让期望社区版功能完全对等的团队感到意外。
- README 和文档链接指向 `signoz.io` 获取安装说明，意味着标准的自部署文档位于仓库之外。气隙环境中的团队需要镜像或缓存这些文档。
- `SECURITY.md` 策略要求通过 `security@signoz.io` 报告漏洞，而非公开 GitHub issue，并承诺每封邮件一个问题以便分类处理。
- `LICENSE` 文件清晰区分 MIT Expat 代码和企业代码（`ee/LICENSE`），减少了关于哪些代码可再分发的歧义。
- `go.mod` 引入 `golang.org/x/crypto v0.52.0` 和 `golang-jwt/jwt/v5 v5.3.1` 用于认证和加密操作。
- 企业版部署支持 OIDC（`coreos/go-oidc/v3 v3.17.0`）和 SAML2（`russellhaering/gosaml2 v0.11.0`）身份提供商集成。
- OpenFGA 提供基于关系的访问控制，支持超越简单角色分配的细粒度 RBAC。
- 策略建议始终运行最新版本以获得安全更新，暗示旧版本可能不会获得回溯修复。
替代方案比较
| 方案 | 适用场景 | 代价 |
|---|---|---|
Grafana + Loki + Tempo + Prometheus | 你倾向于模块化技术栈，每种信号类型都有独立且经受过考验的组件，且已在运营 Grafana。 | OSS 免费；Grafana Cloud 提供托管服务，按用量计费。 |
Jaeger | 你只需要分布式追踪，日志和指标已有其他工具处理。 | OSS 免费（CNCF 毕业项目）。 |
Datadog | 你需要完全托管的 SaaS，零基础设施运维，且开箱即用拥有广泛的第三方集成。 | 商业 SaaS，按主机和摄入量计费。 |
Prometheus | 你只需要指标采集和基于 PromQL 的告警，追踪和日志在其他地方处理。 | OSS 免费。 |
这个趋势说明了什么
ClickHouse SQL 作为统一查询面
由于三种信号都存储在 ClickHouse 中，团队可以在仪表盘构建器中使用原生 ClickHouse SQL 关联指标、日志和追踪。这开启了在碎片化的 Prometheus + Loki + Tempo 技术栈中难以或无法实现的跨信号分析查询。
README 明确将 ClickHouse SQL 与 PromQL 和 Query Builder 并列为支持的指标查询模式。
Agent 原生可观测工作流
README 提到的 Agent 原生工作流和基于 MCP 的 "Noz" 界面表明 SigNoz 正在构建 LLM 辅助的事件排查能力。已在收集 OTLP 数据的团队可以利用这一界面实现自动化的根因建议，无需将数据导出到第三方 AI 厂商。
仓库描述提到面向'你的团队和他们的 AI 代理'的可观测性，README 截图展示了 Noz 界面旁边的 MCP Agent 工作流。
开放核心的企业功能升级路径
清晰的 `ee/` 目录边界创造了可预测的升级路径。团队可以从免费的 MIT 社区版开始，在出现 RBAC、SSO 或数据驻留需求时再迁移到企业版，无需更改底层数据面或查询层。
`LICENSE` 文件指定 `ee/` 和 `cmd/enterprise/` 下的内容由 `ee/LICENSE` 管辖，其余均为 MIT Expat。
RepoDaily 判断
SigNoz 在 OpenTelemetry 原生、ClickHouse 后端的架构上提供了真正的统一可观测体验。开放核心的许可边界清晰，依赖图透明，功能面——APM、日志管理、支持 PromQL 和 ClickHouse SQL 的指标、追踪漏斗、新兴 Agent 原生工作流——覆盖了大多数团队过去需要从四个独立工具拼装的完整三信号面。自部署采用存在中等风险，主要来自 ClickHouse 容量规划和 SigNoz 专有的 Collector 分支，但对于已决定使用 OTLP 插桩的团队来说，SigNoz 是 2026 年商业 APM 平台最完整的开源替代方案之一。