SigNoz号称自己是开源领域的Datadog,基于OpenTelemetry做了一套可观测性方案。夜莺从V6版本开始,也希望做全栈可观测性方案,巧了,大家目标一致,今天我们一起来对SigNoz做个初步了解,看看其产品设计如何,也帮大家未来选型做参考。
核心要点摘要
- SigNoz 的自我定位是开源应用性能监控工具,基于 OpenTelemetry 获取可观测数据,底层使用 ClickHouse 存储。
- 从作者当时体验看,SigNoz 更像是以 Trace 为中心展开的可观测性产品:Services、Traces、拓扑和火焰图能力相对更核心。
- Logs、Dashboards、Alerts 和权限模型也有覆盖,但文章认为这些能力仍较初级,尤其日志分析体验、数据权限和告警分组能力还需要继续打磨。
- 对生产选型来说,SigNoz 可以作为 Trace/APM 方向的候选工具尝试;如果做日志方案,文章认为 ELK 仍更成熟;Metrics 方向则更建议 Prometheus、InfluxDB、VictoriaMetrics 等成熟方案。
- 本文是一次初探,结论基于当时 Docker Compose 本地体验,不等同于完整生产评测。
先说评估边界
这篇文章不是 SigNoz 的完整压测,也不是生产级选型报告。作者主要基于官网介绍、架构图和本地 Docker Compose 体验,观察 SigNoz 的产品设计。文中的评价适合作为初步参考,真正选型还需要结合团队的数据规模、保留周期、权限模型、告警流程和运维能力继续验证。
1. SigNoz介绍
SigNoz is an open-source application performance monitoring tool that helps you monitor your applications and troubleshoot problems. SigNoz uses distributed tracing to gain visibility into your software stack.
SigNoz是一个开源的应用性能监控工具,帮助您监控应用程序并解决问题。SigNoz使用分布式跟踪来获得对软件堆栈的可见性。
点评:上面这个英文介绍是从其官网摘录的,从这个介绍中,我第一感受是SigNoz更侧重分布式链路追踪。
With SigNoz, you can do the following:
- Monitor application metrics such as latency, requests per second, error rates
- Monitor infrastructure metrics such as CPU utilization or memory usage
- Track user requests across services
- Set alerts on metrics
- Find the root cause of the problem by going to the exact traces which are causing the problem
- See detailed flame graphs of individual request traces
使用SigNoz,您可以做下面这些事情:
- 监控应用程序指标,如延迟、每秒请求、错误率
- 监控基础设施指标,比如CPU利用率或内存使用率
- 在多个服务之间追踪用户请求
- 在指标上设置警报
- 通过转到出问题的trace来找到问题的根本原因
- 查看单个请求trace的详细火焰图
点评:上面的介绍是SigNoz声称自己可以做到的事情,但是程度如何还未可知,不同的可观测性产品通常都说自己可以观测到软件的健康状况、可以定位根因,但真正用起来就会发现,要么数据不全,要么做得太浅,基本都只是把可观测性三大支柱的数据简单筒仓式罗列,真正好用的没几个。所以这样的宣传语看看就好,具体好不好用,还是要真正的去用一下才知道。
2. SigNoz架构

这个架构很清晰,SigNoz自身不提供采集器,完全复用 OpenTelemetry 的能力,不过 Otel Collector 这块它在架构图里冠以 SigNoz,不知道是否对社区的 Collector 做了二次开发,存储使用 ClickHouse,SigNoz 自己用 Go 开发了 Query Service 组件和 Alert Manager 组件,前端使用 React 开发。
从数据流上来讲,应用程序埋点推送监控数据给 Otel Collector,Otel Collector 对数据做初步处理,之后直接写入 ClickHouse,写入链路就算完事了。前端和 Alert Manager 对 ClickHouse 的查询会统一发给 Query Service,Query Service 会把 HTTP 请求转换为 ClickHouse 的 TCP 查询语句。
点评:链路追踪的 Span 数据存入 ClickHouse 这种列存存储,是越来越多公司的做法,长期数据扔到 S3 节省成本,也没毛病。对于日志数据,也有越来越多公司尝试存入 ClickHouse,SigNoz 显然也是把日志存入了 ClickHouse。不过,指标也存入 ClickHouse 的做法未必妥当,指标的标签是不固定的,但是 ClickHouse 是固定 Schema 的,难道直接扔到 Map 字段了?开源社区里指标的存储,笔者还是觉得 VictoriaMetrics、Thanos 是更好的选择。
3. SigNoz安装
最简单的安装方式是 Docker compose:
git clone -b main https://github.com/SigNoz/signoz.git && cd signoz/deploy/
docker-compose -f docker/clickhouse-setup/docker-compose.yaml up -d
笔者是 Macbook M1,可以正常运行:

我这只是初步测试尝试,所以直接使用 Docker compose 在笔记本运行了,生产环境运行的话,重点要关注 ClickHouse 的部署。
之后浏览器访问:http://localhost:3301/就可以看到 SigNoz 的登录页面了,随便输入用户名密码就可以登录了。第一个用户默认进来就是Admin。
4. SigNoz功能初体验

左侧菜单可以看出 SigNoz 的核心功能,我们挨个看一下。首先是 Services,即服务列表,即接入链路追踪系统的那些微服务,会展示每个服务的 P99 延迟、错误率、每秒请求数,显然是符合 RED 方法论的。上图截图就是这个页面。
Traces 菜单,是展示近期所有 Span,可以通过 Service Name、Operation、Status、Duration 等做筛选,如图:

点击某个 Span,可以跳转到相关的那个 Trace 的瀑布流图:

点评:以上功能其实都是 Trace 功能,相关竞品有 Skywalking、Zipkin、Jaeger 等。看起来 SigNoz 主打的也是 Trace,后面还有一个拓扑图的菜单,也是 Trace 相关的。只是简单看这些页面,感觉也基本够用。能够检索链路信息,也能根据 Trace 数据生成基本的 Metrics 数据,如果再能够从日志里跳转到 Trace,那就更好了(没有看到这个打通)。
Logs 菜单,是展示日志。当前效果图如下:

点击某个日志行,可以看到日志详情,日志体没有做字段拆解,可能还是需要引入 logstash 之类的组件才可以:

点评:初步体验下来,没有 ELK 的体验好,比如 Kibana 页面可以看到不同维度信息的 Top 视图,这才是可观测性产品应该提供的能力。只是提供基础数据还远远不够,把数据的特征展示出来,进而帮助用户建立观点洞察,最终形成 actionable insights,才是可观测性产品的核心价值所在。我看 SigNoz 也提供了 Cloud 产品,不知道是否做的更多一些,一些更牛的功能放到 Cloud 也是不错的商业决策。毕竟,全职研发人员有收入了才能反哺开源社区。
其他功能,比如 Dashboards、Alerts,在笔者看来还非常初级,Dashboards 还是 Grafana 做得更好一些,Alerts 这块则是 Nightingale 做得更好一些。
权限这块,SigNoz 分为 Admin、Editor、Viewer 三种角色,分别对应不同的权限,比如 Viewer 就只能看,不能操作,Editor 则可以做日常操作,Admin 则是最高权限,可以做所有操作。这块没有看到数据权限的控制,比如告警规则,没有更多分组划分,比如云平台的告警规则我想单独分组,单独一拨人管理,电商业务的告警规则单独分组,单独一拨人管理,目前看 SigNoz 是做不到的。
5. 总结
本文对 SigNoz 做了初探,不深入,导致有些评价可能有所偏颇,仅供参考。整体来看,如果使用 SigNoz 做 Trace,是可以尝试的,如果做日志方案,还是 ELK 方案更成熟,不过 ElasticSearch 日志存储成本比较高,如果只是存近期数据用于排障,ElasticSearch 是很好的选择,如果想存很久的数据,SigNoz 用 ClickHouse 存储,成本会低很多。Metrics 方面,不建议使用 SigNoz,Metrics 的成熟方案太多了,比如 Prometheus、InfluxDB、VictoriaMetrics 等,SigNoz 这块还是太初级了。不管大家用什么监控系统,最终的告警降噪、值班OnCall还是希望在一个平台解决,这块笔者还是推荐 Flashduty。
今天就到这里,感谢大家阅读,欢迎大家留言评论,如果有公司把 SigNoz 用起来了,也欢迎分享使用感受,一起学习,交流进步。
FAQ
Q1:SigNoz 更适合从哪个方向切入试用? A:从本文体验看,SigNoz 更适合作为 Trace/APM 方向的候选工具试用。Services、Traces、瀑布图和拓扑相关能力是它更突出的部分。
Q2:SigNoz 可以替代 ELK 做日志平台吗? A:文章没有给出替代结论。作者认为当时日志体验不如 ELK 成熟,如果只是存近期日志用于排障,ELK 仍是成熟选择;如果考虑更长周期存储,ClickHouse 路线值得评估。
Q3:为什么作者不建议优先用 SigNoz 做 Metrics? A:文章认为 Metrics 领域已经有 Prometheus、InfluxDB、VictoriaMetrics 等成熟方案,而当时 SigNoz 的 Metrics 能力还较初级。
Q4:SigNoz 的架构有什么特点? A:它复用 OpenTelemetry 采集能力,使用 ClickHouse 存储数据,自己实现 Query Service 和 Alert Manager,前端使用 React。
Q5:生产环境试用 SigNoz 应重点验证什么? A:需要验证 ClickHouse 部署和容量、Trace 与日志是否能打通、日志字段解析能力、告警规则和通知流程、数据权限控制,以及和现有 OnCall/告警平台的集成方式。
