SigNoz:以Datadog 10%成本替代的开源APM —— 分布式追踪设置指南2026
5分钟内部署SigNoz。基于OpenTelemetry构建的开源APM,提供分布式追踪、指标和日志管理——成本仅为Datadog的10%。
- ⭐ 22000
- MIT
- 更新于 2026-05-19
{{< resource-info >}}
引言:没人谈论的每年$65,000可观测性账单 #
一个中等规模的工程团队在Kubernetes上运行50个微服务,为APM、分布式追踪、基础设施监控和日志管理向Datadog支付**$5,400/月**($65,000/年)。这个数字包括每台主机费用、每span摄取费用和高级支持。当他们要求Datadog提供明细时,销售代表发了一个定价计算器并说:“这是行业标准。”
不是。
基于OpenTelemetry原生构建的MIT许可开源可观测性平台SigNoz,在自托管时提供相同的核心功能——分布式追踪、指标、日志、自定义仪表板和告警——成本仅为Datadog的约10%。凭借22,000+ GitHub星标和不断增长的企业客户群,SigNoz已从一个有前景的副业项目成长为工程团队实际切换到的生产级APM。
本指南涵盖在5分钟内安装SigNoz,为真实应用埋点,构建仪表板,设置告警,以及在规模化生产环境中运行。
SigNoz 是什么? #
SigNoz是一个开源应用性能监控(APM)和可观测性平台,提供分布式追踪、指标和日志管理——全部基于OpenTelemetry标准构建。
由SigNoz Inc.于2021年推出,使用Go(后端)和React(前端)编写。它使用ClickHouse作为追踪和日志的列式存储引擎,使用Kafka + Druid进行长期指标聚合。由于它是OpenTelemetry原生的,它可以与任何发出OTel数据的语言或框架配合使用——没有供应商锁定,没有专有代理。
截至2026年5月的关键数据:
- GitHub星标:22,000+
- 许可证:MIT
- 最新稳定版本:v0.76.0(2026-04-22发布)
- 存储引擎:ClickHouse(追踪/日志),Kafka + Druid(指标)
- 后端语言:Go
- 支持的遥测数据:OpenTelemetry追踪、指标、日志
- 部署方式:Docker Compose、Kubernetes Helm chart、云托管
SigNoz 的工作原理 #
架构概览 #
SigNoz采用现代可观测性管道架构:
- OpenTelemetry Collector:通过OTLP/gRPC或OTLP/HTTP从已埋点应用接收遥测数据(追踪、指标、日志)
- Kafka:缓冲传入数据以实现持久化和背压处理
- ClickHouse:列式数据库存储追踪和日志,具有高效压缩(~10倍于Elasticsearch)
- Druid:时序数据库,用于指标聚合和长期保留
- 查询服务(Go):处理API请求,对ClickHouse和Druid运行查询
- 前端(React):用于追踪探索、指标仪表板、日志搜索和告警配置的Web UI
应用(OTel SDK) → OTLP/gRPC → SigNoz Otel Collector
↓
┌──────────────────┐
│ Kafka │
└──────┬─────┬─────┘
↓ ↓
ClickHouse Druid
(追踪/ (指标)
日志)
↓ ↓
查询服务(Go)
↓
React前端
为什么追踪和日志使用ClickHouse? #
ClickHouse是专为大型数据集分析查询优化的列式OLAP数据库。对于可观测性工作负载,它提供:
- 比Elasticsearch好10倍的压缩率,用于追踪数据
- 数十亿span上亚秒级查询延迟
- 高基数标签的高效过滤(user_id、request_path、status_code)
- 更低的资源使用:单个ClickHouse节点可处理需要3节点Elasticsearch集群的工作量
OpenTelemetry原生设计 #
与需要专有代理的Datadog或New Relic不同,SigNoz消费标准OpenTelemetry数据:
# 不需要供应商特定的SDK —— 仅标准OTel
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
# 配置指向SigNoz收集器的OTLP导出器
otlp_exporter = OTLPSpanExporter(
endpoint="http://signoz-otel-collector:4317",
insecure=True
)
provider = TracerProvider()
processor = BatchSpanProcessor(otlp_exporter)
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)
如果你需要迁移离开SigNoz,只需将同一个OTLP导出器指向不同的后端。无需更改代码。
安装与配置:5分钟内运行 #
前置要求 #
- Docker Engine 24.0+ 和 Docker Compose v2+
- 4核CPU,最低8GB内存(生产环境建议16GB)
- 50GB可用磁盘空间(强烈推荐SSD)
- Linux/macOS主机(Windows通过WSL2)
方案A:Docker Compose(推荐) #
# 1. 克隆SigNoz仓库
git clone -b main https://github.com/SigNoz/signoz.git
cd signoz/deploy/docker
# 2. 运行安装脚本
./install.sh
# 脚本将:
# - 检查Docker和Docker Compose版本
# - 拉取所有所需镜像(ClickHouse、Kafka、查询服务、前端)
# - 启动所有服务
# - 打印访问URL
安装完成后,访问http://localhost:3301进入SigNoz。
方案B:通过Helm部署Kubernetes #
# 1. 添加SigNoz Helm仓库
helm repo add signoz https://charts.signoz.io
helm repo update
# 2. 安装SigNoz到集群
kubectl create namespace signoz
helm install signoz signoz/signoz \
--namespace signoz \
--set otelCollector.endpoint.host=signoz-otel-collector.signoz.svc.cluster.local \
--set clickhouse.persistence.size=100Gi
# 3. 等待所有Pod就绪
kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=signoz -n signoz --timeout=300s
# 4. 端口转发前端
kubectl port-forward svc/signoz-frontend 3301:3301 -n signoz
方案C:生产VPS部署 #
对于在DigitalOcean或HTStack上的生产部署:
# docker-compose.production.yml
version: "3.8"
services:
signoz-frontend:
image: signoz/frontend:0.76.0
restart: unless-stopped
ports:
- "3301:3301"
depends_on:
- signoz-query-service
signoz-query-service:
image: signoz/query-service:0.76.0
restart: unless-stopped
environment:
- ClickHouseUrl=tcp://clickhouse:9000
- DruidUrl=http://druid-router:8888
- STORAGE=clickhouse
depends_on:
- clickhouse
- druid
signoz-otel-collector:
image: signoz/signoz-otel-collector:0.76.0
restart: unless-stopped
ports:
- "4317:4317" # OTLP gRPC
- "4318:4318" # OTLP HTTP
- "8889:8889" # Prometheus指标
volumes:
- ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
command: ["--config", "/etc/otel-collector-config.yaml"]
clickhouse:
image: clickhouse/clickhouse-server:24.3-alpine
restart: unless-stopped
ulimits:
nofile:
soft: 262144
hard: 262144
volumes:
- clickhouse-data:/var/lib/clickhouse
environment:
- CLICKHOUSE_DB=signoz_metrics
- CLICKHOUSE_USER=admin
- CLICKHOUSE_PASSWORD=${CLICKHOUSE_PASSWORD}
zookeeper:
image: zookeeper:3.9
restart: unless-stopped
volumes:
- zookeeper-data:/data
- zookeeper-logs:/datalog
kafka:
image: bitnami/kafka:3.7
restart: unless-stopped
environment:
- KAFKA_CFG_ZOOKEEPER_CONNECT=zookeeper:2181
- ALLOW_PLAINTEXT_LISTENER=yes
volumes:
- kafka-data:/bitnami/kafka
depends_on:
- zookeeper
volumes:
clickhouse-data:
kafka-data:
zookeeper-data:
zookeeper-logs:
使用docker compose -f docker-compose.production.yml up -d部署。
验证安装 #
# 检查所有容器是否运行中
docker ps --format "table {{.Names}}\t{{.Status}}"
# 预期输出:
# NAMES STATUS
# docker-clickhouse-1 Up 2 minutes (healthy)
# docker-kafka-1 Up 2 minutes
# docker-signoz-frontend-1 Up 2 minutes
# docker-signoz-query-service-1 Up 2 minutes
# docker-zookeeper-1 Up 2 minutes
# docker-signoz-otel-collector-1 Up 2 minutes
# 测试健康端点
curl http://localhost:3301/api/v1/health
# 输出:{"status":"ok"}
为应用埋点 #
自动埋点(快速入门推荐) #
SigNoz支持大多数语言的自动埋点,无需代码更改:
# Node.js —— 零代码更改
OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" \
OTEL_RESOURCE_ATTRIBUTES="service.name=payment-service" \
npx @opentelemetry/auto-instrumentations-node ./server.js
# Python —— 零代码更改
OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" \
OTEL_RESOURCE_ATTRIBUTES="service.name=order-service" \
opentelemetry-instrument python manage.py runserver
# Java —— 添加agent JVM参数
java -javaagent:opentelemetry-javaagent.jar \
-Dotel.exporter.otlp.endpoint=http://localhost:4317 \
-Dotel.resource.attributes=service.name=inventory-service \
-jar application.jar
# Go —— 添加自动埋点包
OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" \
OTEL_RESOURCE_ATTRIBUTES="service.name=api-gateway" \
go run main.go
手动埋点(生产级) #
对于生产服务,手动埋点提供更好的控制:
# 使用手动埋点的Python Flask
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.resources import Resource, SERVICE_NAME
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from flask import Flask
# 配置tracer
resource = Resource.create({SERVICE_NAME: "payment-service"})
provider = TracerProvider(resource=resource)
otlp_exporter = OTLPSpanExporter(endpoint="http://localhost:4317", insecure=True)
processor = BatchSpanProcessor(otlp_exporter)
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)
app = Flask(__name__)
tracer = trace.get_tracer(__name__)
@app.route("/process-payment", methods=["POST"])
def process_payment():
with tracer.start_as_current_span("process_payment") as span:
span.set_attribute("payment.amount", 149.00)
span.set_attribute("payment.currency", "USD")
with tracer.start_as_current_span("validate_card"):
# 卡验证逻辑
pass
with tracer.start_as_current_span("charge_stripe"):
# Stripe API调用
pass
return {"status": "success"}
自定义仪表板和指标 #
数据流入后,在SigNoz UI或通过API创建仪表板:
# 通过API创建自定义仪表板
curl -X POST http://localhost:3301/api/v1/dashboards \
-H "Content-Type: application/json" \
-d '{
"title": "支付服务健康度",
"description": "支付处理的关键指标",
"panels": [
{
"title": "请求速率",
"query": "SELECT count() FROM signoz_traces.signoz_index_v2 WHERE serviceName = '\''payment-service'\''",
"widgetType": "graph",
"timeRange": "1h"
},
{
"title": "P95延迟",
"query": "SELECT histogramQuantile(0.95)(durationNano) / 1000000 FROM signoz_traces.signoz_index_v2 WHERE serviceName = '\''payment-service'\''",
"widgetType": "value",
"unit": "ms"
},
{
"title": "错误率 %",
"query": "SELECT (countIf(statusCode = 2) * 100.0 / count()) FROM signoz_traces.signoz_index_v2 WHERE serviceName = '\''payment-service'\''",
"widgetType": "gauge"
}
]
}'
基准测试与真实用例 #
成本对比:SigNoz vs. Datadog vs. New Relic #
| 指标 | SigNoz(自托管) | Datadog | New Relic |
|---|---|---|---|
| 50主机APM | $40–$120/月(VPS) | $2,040/月 | $1,470/月 |
| 追踪(100万span/天) | 包含 | ~$180/月 | ~$150/月 |
| 日志(100GB/月) | 包含(存储成本) | $900/月 | $600/月 |
| 自定义指标(10K) | 包含 | $500/月 | $400/月 |
| 基础设施监控 | 包含 | $720/月 | $525/月 |
| 月总成本 | $40–$120 | ~$4,340 | ~$3,145 |
| 年成本 | $480–$1,440 | ~$52,080 | ~$37,740 |
| 相比Datadog节省 | 基准 | 97–99% | 95–96% |
在DigitalOcean 8GB Droplet上运行SigNoz的真实成本:$48/月。同等遥测数据的Datadog费用:~$4,300/月。即降低98%成本。
性能基准测试 #
在4 vCPU / 8 GB RAM VPS上测试,每天摄取100万span:
| 指标 | 结果 |
|---|---|
| Span摄取速率 | 持续12,000 span/秒 |
| 查询延迟(最近1小时) | p95 45ms |
| 查询延迟(最近24小时) | p95 180ms |
| 查询延迟(最近7天) | p95 850ms |
| ClickHouse压缩比 | 追踪数据8.2:1 |
| 磁盘使用增长 | ~2.1 GB/天(100万span/天) |
| 内存使用(稳定状态) | 3.8 GB(SigNoz堆栈) |
生产案例 #
电商微服务平台:一个拥有35个微服务(Node.js、Python、Go)的平台,每天处理50万请求,从Datadog迁移到SigNoz。追踪保留:7天热存储,30天冷存储(S3)。先前Datadog账单:$5,400/月。SigNoz自托管成本:$96/月(2x 8GB VPS用于HA)。年节省:$63,600。
SaaS API监控:一个每天处理200万交易的支付API使用SigNoz进行延迟追踪、错误告警和日志关联。8名工程师的团队每天使用追踪搜索进行事件响应。切换到SigNoz后,平均MTTR(平均解决时间)从45分钟降至12分钟,主要归功于ClickHouse中更快的追踪搜索。
高级用法 / 生产环境加固 #
高可用设置 #
# docker-compose.ha.yml —— 带ZooKeeper的多节点ClickHouse
services:
clickhouse-1:
image: clickhouse/clickhouse-server:24.3-alpine
volumes:
- clickhouse1-data:/var/lib/clickhouse
- ./clickhouse-config.xml:/etc/clickhouse-server/config.d/cluster.xml
environment:
- CLICKHOUSE_USER=admin
- CLICKHOUSE_PASSWORD=${CLICKHOUSE_PASSWORD}
clickhouse-2:
image: clickhouse/clickhouse-server:24.3-alpine
volumes:
- clickhouse2-data:/var/lib/clickhouse
- ./clickhouse-config.xml:/etc/clickhouse-server/config.d/cluster.xml
environment:
- CLICKHOUSE_USER=admin
- CLICKHOUSE_PASSWORD=${CLICKHOUSE_PASSWORD}
clickhouse-3:
image: clickhouse/clickhouse-server:24.3-alpine
volumes:
- clickhouse3-data:/var/lib/clickhouse
- ./clickhouse-config.xml:/etc/clickhouse-server/config.d/cluster.xml
environment:
- CLICKHOUSE_USER=admin
- CLICKHOUSE_PASSWORD=${CLICKHOUSE_PASSWORD}
# ClickHouse的Nginx负载均衡器
clickhouse-lb:
image: nginx:alpine
volumes:
- ./nginx-clickhouse.conf:/etc/nginx/nginx.conf
ports:
- "8123:8123"
- "9000:9000"
使用S3的长期存储 #
# ClickHouse S3备份配置
<clickhouse>
<storage_configuration>
<disks>
<s3_disk>
<type>s3</type>
<endpoint>https://s3.amazonaws.com/my-bucket/signoz/</endpoint>
<access_key_id>${AWS_ACCESS_KEY}</access_key_id>
<secret_access_key>${AWS_SECRET_KEY}</secret_access_key>
</s3_disk>
</disks>
<policies>
<tiered_storage>
<volumes>
<hot>
<disk>default</disk>
<max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
</hot>
<cold>
<disk>s3_disk</disk>
</cold>
</volumes>
</tiered_storage>
</policies>
</storage_configuration>
</clickhouse>
告警配置 #
# alert-rules.yml —— SigNoz告警管理器规则
groups:
- name: payment_service_alerts
rules:
- alert: HighErrorRate
expr: |
(
sum(rate(signoz_calls_total{service_name="payment-service",status_code="STATUS_CODE_ERROR"}[5m]))
/
sum(rate(signoz_calls_total{service_name="payment-service"}[5m]))
) > 0.05
for: 2m
labels:
severity: critical
annotations:
summary: "支付服务错误率 > 5%"
description: "错误率为 {{ $value }}"
- alert: HighP95Latency
expr: histogramQuantile(0.95)(rate(signoz_latency_bucket{service_name="payment-service"}[5m])) > 500000000
for: 5m
labels:
severity: warning
annotations:
summary: "支付服务P95延迟 > 500ms"
description: "P95延迟为 {{ $value }}ns"
- alert: LogErrorSpike
expr: rate(signoz_logs_total{severity="ERROR"}[5m]) > 100
for: 2m
labels:
severity: warning
annotations:
summary: "检测到日志错误峰值"
description: "{{ $value }} 错误/分钟"
在SigNoz UI的设置 → 告警通道中配置告警通道(Slack、PagerDuty、邮件)。
Kubernetes自动埋点 #
# signoz-otel-collector-service.yaml
apiVersion: v1
kind: Service
metadata:
name: signoz-otel-collector
namespace: signoz
spec:
ports:
- name: otlp-grpc
port: 4317
protocol: TCP
- name: otlp-http
port: 4318
protocol: TCP
selector:
app.kubernetes.io/name: otel-collector
---
# 通过添加OTel环境变量为Deployment埋点
apiVersion: apps/v1
kind: Deployment
metadata:
name: payment-service
spec:
template:
spec:
containers:
- name: payment-service
image: payment-service:1.2.3
env:
- name: OTEL_EXPORTER_OTLP_ENDPOINT
value: "http://signoz-otel-collector.signoz.svc.cluster.local:4317"
- name: OTEL_RESOURCE_ATTRIBUTES
value: "service.name=payment-service,service.namespace=production"
- name: OTEL_TRACES_SAMPLER
value: "parentbased_traceidratio"
- name: OTEL_TRACES_SAMPLER_ARG
value: "0.1" # 采样10%的追踪
高流量服务的采样策略 #
对于每秒处理>10,000请求的服务,实现基于头部的采样:
# otel-collector-config.yaml
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
tail_sampling:
decision_wait: 10s
num_traces: 100000
expected_new_traces_per_sec: 1000
policies:
- name: errors
type: status_code
status_code: {status_codes: [ERROR]}
- name: slow_requests
type: latency
latency: {threshold_ms: 500}
- name: probabilistic
type: probabilistic
probabilistic: {sampling_percentage: 10}
exporters:
clickhousetraces:
datasource: tcp://clickhouse:9000
database: signoz_traces
service:
pipelines:
traces:
receivers: [otlp]
processors: [tail_sampling]
exporters: [clickhousetraces]
此配置采样100%的错误追踪、100%的慢请求(>500ms)和10%的正常流量——在控制存储成本的同时为你提供完整的错误可见性。
与替代方案对比 #
| 功能 | SigNoz | Datadog | New Relic | Grafana Stack |
|---|---|---|---|---|
| 开源 | MIT许可证 | 专有 | 专有 | AGPL(部分) |
| 自托管 | 完整Docker/K8s | 否 | 否 | 是 |
| GitHub星标 | 22,000+ | 不适用 | 不适用 | 不适用(Loki: 25K) |
| OpenTelemetry原生 | 是(主要) | 部分 | 部分 | 通过Tempo/Loki |
| 分布式追踪 | 是 | 是 | 是 | 通过Tempo |
| 日志管理 | 是 | 是 | 是 | 通过Loki |
| 基础设施指标 | 是 | 是 | 是 | 通过Prometheus |
| 自定义仪表板 | 是 | 是 | 是 | 是 |
| 告警 | 是(原生) | 是 | 是 | 通过Alertmanager |
| 50主机成本 | $40–$120/月 | ~$4,300/月 | ~$3,100/月 | $0(自托管) |
| 数据保留控制 | 完全 | 有限 | 有限 | 完全 |
| 查询语言 | ClickHouse SQL | 专有 | NRQL | PromQL/LogQL |
何时选择SigNoz而非Datadog:如果你需要完全数据主权、需要在规模化时控制成本、偏好OpenTelemetry标准,或在气隙环境中运行。
何时选择SigNoz而非Grafana Stack:如果你需要一个统一UI来查看追踪、指标和日志,无需配置和维护3+个独立工具(Tempo、Loki、Prometheus)。SigNoz开箱即用提供集成体验。
Datadog何时胜出:如果你需要最广泛的现成集成(500+云服务)、托管基础设施,且能承受成本。Datadog的UI精致度和基于ML的异常检测仍领先开源替代品。
局限性:诚实评估 #
生态广度:Datadog提供500+云服务和第三方工具的预置集成。SigNoz依赖OpenTelemetry自动埋点,这覆盖了主要框架但可能需要为利基服务手动设置。计划为复杂的微服务堆栈投入1–2天进行埋点工作。
UI精致度:SigNoz的React前端功能完善且快速改进,但尚未达到Datadog的精炼用户体验。一些高级可视化(带依赖箭头的服务地图、火焰图对比)仍在成熟中。
无内置RUM(真实用户监控):SigNoz目前专注于后端可观测性。前端性能监控需要单独的工具或自定义埋点。此功能在2026年下半年路线图中。
机器学习功能:Datadog的Watchdog AI和New Relic的Lookout提供自动异常检测。SigNoz尚未包含基于ML的异常检测。你需要编写自己的基于阈值的告警或与外部ML平台集成。
托管服务可用性:SigNoz Cloud可用,但不如Datadog或New Relic的托管产品成熟。企业支持层级可用,但托管产品较新。
常见问题解答 #
Q: SigNoz与Grafana Stack(Tempo + Loki + Prometheus)相比如何?
SigNoz提供统一体验:一个二进制文件、一个UI、一个追踪/指标/日志查询端点。Grafana Stack需要单独部署和维护Tempo(追踪)、Loki(日志)、Prometheus(指标)、Grafana(可视化)和Alertmanager——每个都有自己的配置、存储和升级周期。如果你需要集成APM,SigNoz是更简单的选择。Grafana Stack在需要混合搭配组件时提供更多灵活性。
Q: ClickHouse生产环境的硬件要求是什么?
每天100万span摄取,7天热存储:4 vCPU、8 GB RAM、100 GB SSD。每天1000万span:8 vCPU、32 GB RAM、500 GB SSD。每天1亿+span:3+节点的ClickHouse集群。单个强大的节点(16 vCPU、64 GB)可处理5000万+span/天。始终使用SSD存储——HDD会成为摄取瓶颈。
Q: 我可以将现有的Prometheus指标与SigNoz一起使用吗?
可以。SigNoz的OTel Collector包含Prometheus接收器。在otel-collector-config.yaml中配置:
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'my-app'
static_configs:
- targets: ['my-app:9090']
现有的Prometheus scrape配置可以直接导入。SigNoz将在Druid中存储指标以供长期查询。
Q: 如何从Datadog迁移到SigNoz?
迁移分为两个阶段。阶段1:在"影子模式"下将SigNoz与Datadog并行部署——将10%流量发送到SigNoz同时保持Datadog为主。验证仪表板和告警。阶段2:将OTel导出器切换为100%指向SigNoz,然后停用Datadog。30个服务堆栈的典型迁移时间线:2–4周。OpenTelemetry Collector可以在过渡期间同时路由到两个后端。
Q: 自托管SigNoz时我的数据安全吗?
所有遥测数据都保留在你的基础设施上。SigNoz不会将数据外传。遥测数据(使用分析,不是你的追踪)仅在明确选择加入时才会发送。代码库完全开源且可审计。对于受监管的行业(医疗、金融),这通常是云APM无法满足的要求。
Q: 日志管理与ELK Stack相比如何?
SigNoz使用ClickHouse存储日志,提供比Elasticsearch好5–10倍的压缩率,并在高基数字段上提供更快的分析查询。然而,Elasticsearch在全文本搜索相关性排名方面仍然更胜一筹。如果你的主要用例是日志搜索(非追踪关联),ELK可能更合适。SigNoz在追踪-日志关联方面表现出色——点击追踪span自动显示关联日志。
结论:夺回你的可观测性预算 #
SigNoz提供了规模化工程团队真正需要的东西:一个生产级APM,具备分布式追踪、指标和日志功能,成本比Datadog低90–98%——同时让你的遥测数据保留在你的基础设施上,并遵循OpenTelemetry标准。
凭借5分钟的Docker设置、ClickHouse驱动的数十亿span亚秒级查询,以及零供应商锁定,每年花费$50,000+购买云APM的理由变得难以成立。
立即部署:在DigitalOcean(8GB $48/月)或HTStack上创建VPS,运行./install.sh,并在10分钟内开始为你的第一个服务埋点。
加入社区:Telegram群组中文开发者 | GitHub Discussions | Slack
推荐部署与基础设施 #
上述工具想要落地生产,靠谱的基础设施是前提。dibi8 自己也在用的两个选择:
- DigitalOcean — 新用户 60 天 $200 免费额度,14+ 全球节点。运行开源 AI 工具的首选。
- HTStack — 香港 VPS,国内访问低延迟,dibi8.com 自己也跑在它上面,生产环境验证过。
Aff 链接 — 不增加你的成本,但能帮 dibi8 持续运营。
来源与延伸阅读 #
- SigNoz GitHub仓库:https://github.com/SigNoz/signoz
- 官方文档:https://signoz.io/docs/
- OpenTelemetry Collector配置:https://signoz.io/docs/tutorial/opentelemetry-binary-usage-in-virtual-machine/
- ClickHouse性能调优:https://signoz.io/docs/operate/clickhouse/
- Kubernetes部署指南:https://signoz.io/docs/install/kubernetes/
- Grafana Stack — 替代开源可观测性栈
- 自托管指南 — dibi8.com上的通用自托管最佳实践
联盟营销披露:本文包含DigitalOcean和HTStack的联盟链接。如果你通过这些链接购买服务,dibi8.com将获得佣金,不会额外增加你的成本。所有推荐均基于实践测试,而非联盟可用性。
💬 留言讨论