博客 / 工程

SigNoz：基于 OpenTelemetry 原生的开源指标、追踪和日志，集中于单一面板

Pranay Prateek @ Signoz

2023年6月8日 - 7 分钟阅读

当我们在 2021 年初开始时，没有一款工具能够提供完整的应用程序性能监控 (APM) 体验。我们从应用程序性能指标开始，主要关注开箱即用的指标，例如 RED 指标和应用程序的第 99 百分位延迟。

Prometheus 等工具已经存在，但这些工具主要用于基础设施指标。虽然如果您想监控 Kubernetes 指标，Prometheus 本身是默认选择，但计算应用程序指标（如 API 的 p99 延迟）需要付出巨大的努力。

与此同时，Elasticsearch、Logstash 和 Kibana 栈专门用于日志收集，对指标的支持有限。Prometheus 和 ELK 生态系统提供的功能与 Datadog 等闭源产品提供的体验之间存在巨大差距。

作为开发人员，我们更喜欢开源模式，社区可以在其中支持和贡献项目，我们可以从中学习。这促使我们开发和发布了 Signoz，这是一个由 ClickHouse 驱动的开源 APM 解决方案。

当我们在 2021 年 2 月发布 Signoz 的初始版本时，我们开始使用 Druid 作为数据存储。了解到可观测性只是另一种分析用例，我们知道列式 OLAP 数据存储将是最合适的数据存储。

我们评估了 Druid、Pinot 和 ClickHouse。当时，Pinot 仍然很新，Druid 被 Lyft 等许多大公司使用，而 ClickHouse 则介于两者之间。

根据当时的市场采用情况，我们从 Druid 开始。

我们在 HN 帖子中收到了许多评论，称 Druid 可能难以运行。我们还开始看到开源社区中的用户在运行 Druid 时遇到问题，尤其是对于单机或单节点部署。

我们意识到，人们希望在他们的笔记本电脑或单节点机器上尝试新的开源产品，一旦他们对体验感到满意，就会逐渐转向配置更大的集群的痛苦。

因此，我们开始寻找即使在低 RAM 和 CPU 下也能运行，但也能很好地扩展以适应更高工作负载的数据存储。在查看 ClickHouse 后，我们发现它很容易上手，而且在规模上表现良好。

因此，我们开始使用 ClickHouse 作为我们的主要数据存储。

当我们在 2021 年初开始研究 SigNoz 时，OpenTelemetry 仍然是一个新兴的项目。只有追踪规范和 SDK 是稳定的，而日志和指标仍在开发中。两年后，可观测性的所有关键信号 - 指标、追踪和日志都已声明为稳定。

尽管该项目仍处于起步阶段，但对我们来说，很明显它代表了可观测性数据收集的未来。对于 SDK 具有通用检测层，其他产品可以消费它来可视化和展示洞察，这对我们来说是直观的。此外，它将允许使用 OpenTelemetry 的公司不会被供应商锁定。这是公司在采用闭源遥测工具时面临的一个大问题。

因此，我们早期押注了 OpenTelemetry。

如今，OpenTelemetry 无处不在。它现在是 CNCF 生态系统中第二活跃的项目，仅次于 Kubernetes。许多像 eBay 这样的大公司已将其可观测性堆栈转移到 OpenTelemetry ^[2]

我们认为 OpenTelemetry 实现的遥测数据格式的标准化将创建一个更大的工具生态系统。我们期望新的框架和语言支持 OpenTelemetry 作为数据发出的默认格式出现，例如 ClickHouse 以 OpenTelemetry 格式发出数据和 Traefik 添加 Otel 支持。鉴于这些越来越多的 OpenTelemetry 格式数据，我们希望 SigNoz 作为一个开源后端，将对社区开始使用有所帮助。

到目前为止，可观测性生态系统中的大多数开源工具都专注于特定的用例，例如，Prometheus 专注于指标，Jaeger 仅专注于追踪，而 Elastic 主要用于日志记录。

虽然这些工具本身都很棒，但我们认为将可观测性的所有三个关键信号 - 指标、追踪和日志整合在单个面板中有很多价值。这使得信号之间的关联更容易，并且由于指标、追踪和日志功能是单个应用程序的一部分，因此运行和管理起来更容易得多。与 Grafana 等堆栈相比，架构要简单得多，在 Grafana 中，您必须为每种数据类型运行不同的系统并将它们组合在一起。

SigNoz 还带有一个用户界面和可视化层，它是为可观测性定制构建的。用户界面使点击浏览和更深入的向下钻取更快，允许用户有效地识别问题的根本原因。

SigNoz 中的开箱即用服务列表页面

此外，由于 SigNoz 使用 ClickHouse 作为主要数据存储，我们可以为高基数数据提供卓越的性能。我们认为可观测性主要是一个分析用例，您希望从遥测数据中提出许多问题，以获得对问题潜在原因的洞察。基数的限制，或需要将其视为扩展维度来考虑，让人感觉不必要、复杂且具有限制性。

最近，像 Uber 和 Cloudflare 这样的人也转向 ClickHouse 用于他们的日志分析用例，进一步支持 ClickHouse 成为这种数据类型的最佳存储。

开始使用 SigNoz 非常简单。您可以从单节点或 Kubernetes 集群开始。

默认的 SigNoz 安装会自动部署 ClickHouse 实例，以获得简单的入门体验。

但是，如果您已经运行了 ClickHouse，您可以按照此处的说明设置 SigNoz 并重用您的集群。

如果您在 Kubernetes 集群中运行 SigNoz，可以使用以下步骤

在 Kubernetes 中，我们将更新 override-values.yaml 文件以使用外部 ClickHouse。首先，我们将通过将 clickhouse.enabled 设置为 false 来禁用默认的 ClickHouse 实例。然后，我们将外部 ClickHouse 信息包含在 externalClickhouse 部分中。

override-values.yaml