SigNoz v0.146.0 介绍与选型指南

SigNoz v0.146.0 介绍与选型指南：开源一体化可观测平台（OpenTelemetry 原生 + ClickHouse 统一存储）的定位、六组件架构拆解与量化选型对比，覆盖与 Grafana LGTM 栈、Jaeger、Zipkin、Uptrace 的多维度对比、社区热度数据与适用场景判断，全部数据标注来源与查询日期（2026-10-20）。

SigNozSigNoz监控2026/10/20

SigNoz v0.146.0 介绍与选型指南

目标：讲清 SigNoz 是什么、由哪些组件构成、有哪些功能特性，并以量化数据给出与 Grafana LGTM 栈、Jaeger、Zipkin、Uptrace 的选型对比结论；全部数据均标注来源与查询日期（2026-10-20）。本专栏部署实录见 B2/C1/D1 三篇。

一、环境信息

本篇是「认知与选型」篇，不依赖具体实验环境，所有版本号、星数、功能描述均来自官方公开渠道的联网溯源，逐项标注来源与查询日期：

  • 溯源对象：SigNoz，官方仓库 signoz/signoz，官网 signoz.io
  • 版本取证：GitHub Releases Atom 流 https://github.com/signoz/signoz/releases.atom，查询日期 2026-10-20，最新稳定版 v0.146.0（发布于 2026-10-13），前一版本为 v0.145.0，发版节奏约每 2~4 周一个 minor 版本
  • 星数取证：shields.io 实时徽章数据，查询日期 2026-10-20，signoz/signoz 约 32k stars、约 2.5k forks
  • 许可证取证：Open Core 模式——核心（CE，仓库 signoz/signoz）为 MIT 许可，企业版（EE）模块随同一镜像分发、按许可证解锁；运行时接口返回的 "ee":"Y" 即表示镜像内含 EE 代码，未授权时仅使用 CE 能力
  • 官方文档站：signoz.io/docs；v0.146.0 起文档中安装指南已切换到 Foundry 工具链，旧的 install.sh 自 v0.130.0 起标记废弃（来源：仓库 deploy/README.md，查询日期 2026-10-20）

二、软件概述

SigNoz 是一个开源的全栈可观测性平台，把**日志、指标、链路追踪（Traces）**三类遥测数据放在同一个存储与同一个查询界面里，定位是 Datadog、New Relic 等商业 APM 的自托管（self-hosted）替代。它有两个鲜明的技术特征：

  1. OpenTelemetry 原生：数据接入层直接内建 OpenTelemetry Collector（SigNoz fork 版本 signoz-otel-collector），应用侧只需对接 OTLP 协议（gRPC 4317 / HTTP 4318），无厂商锁定。
  2. ClickHouse 作为统一存储：三类数据分别落 signoz_logs、signoz_metrics、signoz_traces 库，借助 ClickHouse 的列存与高压缩比，在单机即可支撑较大规模查询，这也是 SigNoz 敢宣称"低成本长周期留存"的底气。

项目由 Pranay Pratel 等人于 2021 年发起，SigNoz Inc. 运营。关键事实速览：

项目内容来源
当前稳定版本v0.146.0（2026-10-13）GitHub Releases，2026-10-20 查询
开源协议CE=MIT / EE 商业GitHub 仓库页，2026-10-20 查询
社区热度约 32k stars / 2.5k forksshields.io 徽章数据，2026-10-20 查询
运营方SigNoz Inc.官网 signoz.io，2026-10-20 查询
数据接入协议OTLP（gRPC 4317 / HTTP 4318）官方文档，2026-10-20 查询
统一存储ClickHouse（日志/指标/追踪分库）官方文档与 B2 实测，2026-10-20

💡 说明：SigNoz 与同属 ClickHouse 存储路线的 Uptrace 定位相近，二者差异见第七节量化对比；若核心诉求只是 Prometheus 长期存储而非全栈 APM，可参考《Thanos 0.42.4 介绍与选型指南》。

三、核心架构

v0.146.0 的单机部署由 6 类服务构成（本专栏 B2 部署实录的栈清单与之对应）：

组件镜像职责
SigNoz Server（原 query-service）signoz/signozHTTP API + Web 前端，默认监听 8080；查询构建器、告警、用户/组织管理
OpenTelemetry Collector（SigNoz fork）signoz/signoz-otel-collectorOTLP 接入（4317/4318）、批处理、span→metrics 转换、写 ClickHouse；同时承担 schema 迁移（migrate 子命令）
ClickHouse Serverclickhouse/clickhouse-server:25.12.5遥测数据存储与查询，库：signoz_logs / signoz_metrics / signoz_traces / signoz_metadata / signoz_meter
ClickHouse Keeperclickhouse/clickhouse-keeper:25.12.5分布式协调（DDL 队列、副本元数据）
PostgreSQL 16postgres:16元数据存储（用户、组织、仪表盘、告警规则等）
Migrator（一次性）复用 collector 镜像migrate ready → bootstrap → sync up → async up 建 ClickHouse schema

部署形态（来源：signoz.io/docs 部署章节与本专栏 B2 实测，查询日期 2026-10-20）：

  • 单机一体化：Foundry 工具链渲染 Compose 起 6 服务栈（ClickHouse 单机），适合验证与中小规模；
  • 集群：ClickHouse 以集群模式部署（Keeper 协调副本与 DDL），collector 按接入规模水平扩展，适合大规模长留存场景。

来源：本专栏 B2《SigNoz v0.146.0 Docker Compose 部署指南》实测容器清单（2026-10-20）；组件职责参照 signoz.io/docs 架构页。

四、功能特性

（来源：signoz.io/docs 功能说明与仓库 Release Notes，查询日期 2026-10-20；标注「实测」者为本专栏 B2/C1/D1 已验证项）

  1. 三类遥测一体接入：OTLP gRPC 4317 / HTTP 4318 统一收 logs/metrics/traces，应用侧无厂商锁定（实测：OTLP JSON 三类数据上报均返回 200）。
  2. 统一查询界面：单一界面跨三类数据互跳，日志↔追踪关联内建；指标查询支持 PromQL 与查询构建器两种方式（实测：/api/v4/query_range 的 logs/traces builder 与指标 PromQL 查询均成功）。
  3. 内建告警：指标/追踪/日志三类规则在平台内闭环，无需外部 Alertmanager。
  4. 仪表盘：查询构建器驱动的自定义仪表盘，与告警规则复用同一套查询体系。
  5. 数据处理链：fork 版 signoz-otel-collector 支持批处理、span→metrics 转换、OTTL 处理规则（实测：C1 中加 debug exporter 重启 ingester 后，collector 日志完整输出经过处理链的日志条目）。
  6. 用户与组织管理：首管理员注册 + 角色（ROOT/管理员等）体系，元数据存 PostgreSQL（实测：POST /api/v2/sessions/email_password 登录换 token、GET /api/v2/users/me 返回 ROOT 角色）。
  7. OpenAPI 全量开放：/api/v2（会话、用户）、/api/v4（查询）等（实测：D1 逐条 curl 验证）。
  8. 存储与保留：三类数据分别落 ClickHouse 的 signoz_logs/signoz_metrics/signoz_traces 库（实测：三库 distributed_* 表落库可查）。
  9. EE 企业特性：SSO、审计等企业能力随同一镜像分发、按许可证解锁（见第一节许可证取证）。

五、快速开始（最小可用示例）

按官方文档推荐路径（来源：signoz.io/docs，查询日期 2026-10-20）：v0.130.0 起 install.sh 与仓库 deploy/ 目录的 Compose 已标记废弃，当前官方正道为 Foundry 工具链——foundryctl gauge 检查环境后由 forge 渲染出 Compose 编排，再启动六服务栈。

最小验证闭环（概要示意，实测回显见部署篇）：

  1. 渲染并启动栈，等待 6 服务全部 healthy、migrator 容器执行完成；
  2. 浏览器访问 SigNoz Server 的 8080 端口，注册首管理员（密码策略要求 ≥12 位且含四类字符）；
  3. 登录后确认 Logs / Traces / Metrics 三个查询入口可用；
  4. 用 OTLP 发送一条测试数据，确认三类数据均能入库；
  5. 在查询界面检索刚发送的数据，完成接入验证。

💡 说明：本专栏已对上述路径做了端到端实测（栈 healthy、首管理员注册登录、OTLP 三类数据入库、query_range 查询全链路验证），完整步骤与真实回显见《SigNoz v0.146.0 Docker Compose 部署指南》。

六、适用场景与限制

适合：想用一个自托管平台同时收日志、指标、追踪的中小到中大规模团队；Datadog 成本压力下向 OpenTelemetry 迁移的团队；已有 ClickHouse 运维经验的数据基础设施团队。

需要再评估：只需要单一能力（纯追踪选 Jaeger、纯指标长期存储选 Thanos/Mimir）；已经深度绑定 Grafana 生态且 Loki/Tempo 运维成熟的团队；对超大规模多租户 SaaS 化有要求（SigNoz EE 才覆盖部分能力）。

七、同类选型对比

选自托管可观测平台时，最常见的四个候选路线对比如下（数据日期 2026-10-20）：

维度SigNozGrafana LGTM 栈JaegerZipkinUptrace
数据范围日志+指标+追踪一体日志(Loki)+指标(Mimir/Prometheus)+追踪(Tempo)+大日志(Elasticsearch)仅追踪仅追踪日志+指标+追踪
存储ClickHouse（单库多库表）Loki(对象存储)/Mimir(对象存储)/Tempo(对象存储) 多套Cassandra/ES/ClickHouse 等可选内存/Cassandra/ES/MySQLClickHouse
组件数（自托管最小集）3 个镜像 + 2 个存储（≈6 容器）≥4 个服务（Grafana/Loki/Tempo/Mimir）+ 采集器1~2 容器 + 存储1 容器 + 存储1~2 容器 + ClickHouse
UI 体验单一界面跨三类数据互跳（日志↔追踪关联内建）Grafana 统一前端，各数据源插件化追踪专用 UI追踪专用 UI（功能较简）单一界面
OpenTelemetry 原生内建 fork 版 Collector需自配 OTel Collector/Grafana Alloy原生支持 OTLP支持 OTLP原生支持 OTLP
告警内建（指标/追踪/日志规则）Grafana Alerting（成熟）无无内建
许可CE=MIT（EE 商业）AGPLv3（部分组件 Apache-2.0）Apache-2.0Apache-2.0AGPLv3
中文资料官方中文文档较全社区资料极多多多少
Stars（2026-10-20）32k77k（grafana）23k17k4.3k

版本节奏与社区活跃度：SigNoz 发版节奏约每 2~4 周一个 minor 版本（v0.145.0 → v0.146.0，2026-10-13），社区热度（32k stars）在"一体化自托管 APM"路线中居首；对比项 Jaeger 23k、Zipkin 17k、Uptrace 4.3k，Grafana 77k（可视化前端，非同类整栈）。来源：GitHub releases.atom 与 shields.io，查询日期 2026-10-20。

量化判断依据：

  1. "一个平台管三类数据"的集成成本：LGTM 栈要分别运维 Loki、Tempo、Mimir 三套存储与各自的保留策略；SigNoz 全部收敛到一套 ClickHouse，备份、扩容、保留期策略只有一份。以 B2 实测为证：一套 Compose 起 6 容器即得三类数据全栈。
  2. 追踪场景单独对比：如果只需要分布式追踪、已有 Grafana 展示层，Jaeger（23k stars、Apache-2.0）更轻；SigNoz 的优势在追踪/日志/指标联动与内建告警。
  3. 成本敏感的中小团队：SigNoz CE（MIT）可商用且无功能墙（EE 仅 SSO/审计等企业特性），Uptrace 与 Grafana 部分组件为 AGPLv3，商业产品化场景需评估合规。
  4. 超长周期指标降采样：若核心诉求是"Prometheus 长期存储"而非全栈 APM，Thanos 更对口（站内互链：《Thanos 0.42.4 介绍与选型指南》），SigNoz 的指标子系统定位于"APM 级指标"，不是 Prometheus 集群的替换品。

结论：SigNoz 是当前"一体化自托管 APM"路线中成熟度与社区热度平衡最好的选项（32k stars、MIT 核心、OpenTelemetry 原生、ClickHouse 单存储）。它的选型正确姿势是拿它替换"Datadog"这一整层，而不是替换生态里的某一个单件。部署路径与实测请继续阅读本专栏 B2 篇。

八、参考链接