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采用现代可观测性管道架构:

  1. OpenTelemetry Collector:通过OTLP/gRPC或OTLP/HTTP从已埋点应用接收遥测数据(追踪、指标、日志)
  2. Kafka:缓冲传入数据以实现持久化和背压处理
  3. ClickHouse:列式数据库存储追踪和日志,具有高效压缩(~10倍于Elasticsearch)
  4. Druid:时序数据库,用于指标聚合和长期保留
  5. 查询服务(Go):处理API请求,对ClickHouse和Druid运行查询
  6. 前端(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部署 #

对于在DigitalOceanHTStack上的生产部署:

# 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(自托管)DatadogNew 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%的正常流量——在控制存储成本的同时为你提供完整的错误可见性。

与替代方案对比 #

功能SigNozDatadogNew RelicGrafana 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专有NRQLPromQL/LogQL

何时选择SigNoz而非Datadog:如果你需要完全数据主权、需要在规模化时控制成本、偏好OpenTelemetry标准,或在气隙环境中运行。

何时选择SigNoz而非Grafana Stack:如果你需要一个统一UI来查看追踪、指标和日志,无需配置和维护3+个独立工具(Tempo、Loki、Prometheus)。SigNoz开箱即用提供集成体验。

Datadog何时胜出:如果你需要最广泛的现成集成(500+云服务)、托管基础设施,且能承受成本。Datadog的UI精致度和基于ML的异常检测仍领先开源替代品。

局限性:诚实评估 #

  1. 生态广度:Datadog提供500+云服务和第三方工具的预置集成。SigNoz依赖OpenTelemetry自动埋点,这覆盖了主要框架但可能需要为利基服务手动设置。计划为复杂的微服务堆栈投入1–2天进行埋点工作。

  2. UI精致度:SigNoz的React前端功能完善且快速改进,但尚未达到Datadog的精炼用户体验。一些高级可视化(带依赖箭头的服务地图、火焰图对比)仍在成熟中。

  3. 无内置RUM(真实用户监控):SigNoz目前专注于后端可观测性。前端性能监控需要单独的工具或自定义埋点。此功能在2026年下半年路线图中。

  4. 机器学习功能:Datadog的Watchdog AI和New Relic的Lookout提供自动异常检测。SigNoz尚未包含基于ML的异常检测。你需要编写自己的基于阈值的告警或与外部ML平台集成。

  5. 托管服务可用性: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将获得佣金,不会额外增加你的成本。所有推荐均基于实践测试,而非联盟可用性。

💬 留言讨论