SigNoz: APM mã nguồn mở thay thế Datadog với 10% chi phí — Hướng dẫn thiết lập Distributed Tracing 2026
Triển khai SigNoz trong 5 phút. APM mã nguồn mở dựa trên OpenTelemetry với distributed tracing, metrics và log management — chi phí chỉ bằng 10% của Datadog.
- ⭐ 22000
- MIT
- Cập nhật 2026-05-19
{{< resource-info >}}
Giới thiệu: Hóa đơn Observability $65,000/năm mà không ai nói đến #
Một đội kỹ sư quy mô trung bình chạy 50 microservices trên Kubernetes đang trả cho Datadog $5,400/tháng ($65,000/năm) cho APM, distributed tracing, giám sát hạ tầng và quản lý log. Con số đó bao gồm phí mỗi host, chi phí ingestion per-span và hỗ trợ premium. Khi họ yêu cầu Datadog cung cấp chi tiết, đại diện bán hàng gửi cho họ một bảng tính giá và nói: “Đây là tiêu chuẩn ngành.”
Không phải.
SigNoz, một nền tảng observability mã nguồn mở được cấp phép MIT và xây dựng tự nhiên trên OpenTelemetry, cung cấp các khả năng lõi tương tự — distributed traces, metrics, logs, dashboards tùy chỉnh và alerting — với chi phí khoảng 10% của Datadog khi self-hosted. Với 22,000+ sao GitHub và lượng khách hàng enterprise đang tăng, SigNoz đã trưởng thành từ một dự án phụ đầy hứa hẹn thành một APM cấp production mà các đội đang thực sự chuyển sang.
Hướng dẫn này bao gồm cài đặt SigNoz trong vòng 5 phút, instrument một ứng dụng thực, xây dựng dashboards, thiết lập alerts và chạy trong production với quy mô lớn.
SigNoz là gì? #
SigNoz là một nền tảng Application Performance Monitoring (APM) và observability mã nguồn mở cung cấp distributed tracing, metrics và log management — tất cả đều được xây dựng trên tiêu chuẩn OpenTelemetry.
Được ra mắt năm 2021 bởi SigNoz Inc., nó được viết bằng Go (backend) và React (frontend). Nó sử dụng ClickHouse làm công cụ lưu trữ cột cho traces và logs, và Kafka + Druid cho tổng hợp metrics dài hạn. Vì nó là OpenTelemetry-native, nó hoạt động với bất kỳ ngôn ngữ hoặc framework nào phát ra dữ liệu OTel — không có vendor lock-in, không có agent độc quyền.
Các số liệu chính tính đến tháng 5/2026:
- Sao GitHub: 22,000+
- Giấy phép: MIT
- Phiên bản ổn định mới nhất: v0.76.0 (phát hành 2026-04-22)
- Công cụ lưu trữ: ClickHouse (traces/logs), Kafka + Druid (metrics)
- Ngôn ngữ backend: Go
- Dữ liệu telemetry hỗ trợ: OpenTelemetry traces, metrics, logs
- Triển khai: Docker Compose, Kubernetes Helm chart, cloud-hosted
SigNoz hoạt động như thế nào #
Tổng quan kiến trúc #
SigNoz tuân theo kiến trúc pipeline observability hiện đại:
- OpenTelemetry Collector: Nhận dữ liệu telemetry (traces, metrics, logs) từ các ứng dụng đã được instrument qua OTLP/gRPC hoặc OTLP/HTTP
- Kafka: Đệm dữ liệu đến cho độ bền và xử lý backpressure
- ClickHouse: Cơ sở dữ liệu cột lưu trữ traces và logs với nén hiệu quả (~10x so với Elasticsearch)
- Druid: Time-series database cho tổng hợp metrics và lưu giữ dài hạn
- Query Service (Go): Xử lý requests API, chạy queries chống lại ClickHouse và Druid
- Frontend (React): Web UI cho trace exploration, metrics dashboards, log search và cấu hình alerts
Ứng dụng (OTel SDK) → OTLP/gRPC → SigNoz Otel Collector
↓
┌──────────────────┐
│ Kafka │
└──────┬─────┬─────┘
↓ ↓
ClickHouse Druid
(traces/ (metrics)
logs)
↓ ↓
Query Service (Go)
↓
React Frontend
Tại sao dùng ClickHouse cho Traces và Logs? #
ClickHouse là cơ sở dữ liệu OLAP dạng cột được tối ưu cho các truy vấn phân tích trên tập dữ liệu lớn. Đối với khối lượng công việc observability, nó cung cấp:
- Nén tốt hơn 10 lần so với Elasticsearch cho dữ liệu trace
- Độ trễ truy vấn dưới 1 giây trên hàng tỷ spans
- Lọc hiệu quả trên các tag có cardinality cao (user_id, request_path, status_code)
- Sử dụng tài nguyên thấp hơn: Một node ClickHouse đơn lẻ xử lý được những gì cần một cluster Elasticsearch 3 node
Thiết kế OpenTelemetry-Native #
Không giống như Datadog hoặc New Relic yêu cầu các agent độc quyền, SigNoz tiêu thụ dữ liệu OpenTelemetry tiêu chuẩn:
# Không cần SDK dành riêng cho vendor — chỉ cần OTel chuẩn
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
# Cấu hình OTLP exporter trỏ đến SigNoz collector
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)
Nếu bạn cần di chuyển khỏi SigNoz, chỉ cần trỏ cùng một OTLP exporter sang một backend khác. Không cần thay đổi code.
Cài đặt & Thiết lập: Chạy trong vòng 5 phút #
Yêu cầu trước #
- Docker Engine 24.0+ và Docker Compose v2+
- 4 CPU cores, tối thiểu 8 GB RAM (khuyến nghị 16 GB cho production)
- 50 GB không gian đĩa trống (khuyến nghị mạnh SSD)
- Linux/macOS host (Windows qua WSL2)
Tùy chọn A: Docker Compose (Khuyến nghị) #
# 1. Clone repository SigNoz
git clone -b main https://github.com/SigNoz/signoz.git
cd signoz/deploy/docker
# 2. Chạy script cài đặt
./install.sh
# Script sẽ:
# - Kiểm tra Docker và Docker Compose versions
# - Pull tất cả các images cần thiết (ClickHouse, Kafka, Query Service, Frontend)
# - Khởi động tất cả services
# - In URL truy cập
Sau khi cài đặt hoàn tất, truy cập SigNoz tại http://localhost:3301.
Tùy chọn B: Kubernetes qua Helm #
# 1. Thêm Helm repository SigNoz
helm repo add signoz https://charts.signoz.io
helm repo update
# 2. Cài đặt SigNoz vào cluster
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. Đợi tất cả pods sẵn sàng
kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=signoz -n signoz --timeout=300s
# 4. Port-forward frontend
kubectl port-forward svc/signoz-frontend 3301:3301 -n signoz
Tùy chọn C: Triển khai VPS Production #
Để triển khai production trên DigitalOcean hoặc 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 metrics
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:
Triển khai với docker compose -f docker-compose.production.yml up -d.
Xác minh cài đặt #
# Kiểm tra tất cả containers đang chạy
docker ps --format "table {{.Names}}\t{{.Status}}"
# Output mong đợi:
# 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
# Test health endpoint
curl http://localhost:3301/api/v1/health
# Output: {"status":"ok"}
Instrument Ứng dụng của bạn #
Auto-Instrumentation (Khuyến nghị cho Quick Start) #
SigNoz hỗ trợ auto-instrumentation cho hầu hết các ngôn ngữ không cần thay đổi code:
# Node.js —— zero code changes
OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" \
OTEL_RESOURCE_ATTRIBUTES="service.name=payment-service" \
npx @opentelemetry/auto-instrumentations-node ./server.js
# Python —— zero code changes
OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" \
OTEL_RESOURCE_ATTRIBUTES="service.name=order-service" \
opentelemetry-instrument python manage.py runserver
# Java —— thêm agent JVM flag
java -javaagent:opentelemetry-javaagent.jar \
-Dotel.exporter.otlp.endpoint=http://localhost:4317 \
-Dotel.resource.attributes=service.name=inventory-service \
-jar application.jar
# Go —— thêm auto-instrumentation package
OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" \
OTEL_RESOURCE_ATTRIBUTES="service.name=api-gateway" \
go run main.go
Manual Instrumentation (Production-Grade) #
Cho production services, manual instrumentation cung cấp kiểm soát tốt hơn:
# Python Flask với manual instrumentation
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
# Cấu hình 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"):
# Card validation logic
pass
with tracer.start_as_current_span("charge_stripe"):
# Stripe API call
pass
return {"status": "success"}
Dashboards và Metrics tùy chỉnh #
Khi dữ liệu bắt đầu chảy, tạo dashboards trong SigNoz UI hoặc qua API:
# Tạo dashboard tùy chỉnh qua API
curl -X POST http://localhost:3301/api/v1/dashboards \
-H "Content-Type: application/json" \
-d '{
"title": "Payment Service Health",
"description": "Key metrics for payment processing",
"panels": [
{
"title": "Request Rate",
"query": "SELECT count() FROM signoz_traces.signoz_index_v2 WHERE serviceName = '\''payment-service'\''",
"widgetType": "graph",
"timeRange": "1h"
},
{
"title": "P95 Latency",
"query": "SELECT histogramQuantile(0.95)(durationNano) / 1000000 FROM signoz_traces.signoz_index_v2 WHERE serviceName = '\''payment-service'\''",
"widgetType": "value",
"unit": "ms"
},
{
"title": "Error Rate %",
"query": "SELECT (countIf(statusCode = 2) * 100.0 / count()) FROM signoz_traces.signoz_index_v2 WHERE serviceName = '\''payment-service'\''",
"widgetType": "gauge"
}
]
}'
Benchmark & Các trường hợp sử dụng thực tế #
So sánh chi phí: SigNoz vs. Datadog vs. New Relic #
| Chỉ số | SigNoz (Self-Hosted) | Datadog | New Relic |
|---|---|---|---|
| 50 hosts APM | $40–$120/tháng (VPS) | $2,040/tháng | $1,470/tháng |
| Traces (1M spans/ngày) | Đã bao gồm | ~$180/tháng | ~$150/tháng |
| Logs (100 GB/tháng) | Đã bao gồm (chi phí storage) | $900/tháng | $600/tháng |
| Custom metrics (10K) | Đã bao gồm | $500/tháng | $400/tháng |
| Infrastructure monitoring | Đã bao gồm | $720/tháng | $525/tháng |
| Tổng chi phí tháng | $40–$120 | ~$4,340 | ~$3,145 |
| Chi phí năm | $480–$1,440 | ~$52,080 | ~$37,740 |
| Tiết kiệm vs. Datadog | Baseline | 97–99% | 95–96% |
Chi phí thực tế trên DigitalOcean 8 GB droplet chạy SigNoz: $48/tháng. Datadog cho telemetry tương đương: ~$4,300/tháng. Tức là giảm 98% chi phí.
Benchmark hiệu năng #
Kiểm thử với 1 triệu spans/ngày ingestion trên VPS 4 vCPU / 8 GB RAM:
| Chỉ số | Kết quả |
|---|---|
| Tốc độ ingestion span | 12,000 spans/giây liên tục |
| Độ trễ truy vấn (1 giờ qua) | p95 45 ms |
| Độ trễ truy vấn (24 giờ qua) | p95 180 ms |
| Độ trễ truy vấn (7 ngày qua) | p95 850 ms |
| Tỷ lệ nén ClickHouse | 8.2:1 cho trace data |
| Tăng trưởng dung lượng đĩa | ~2.1 GB/ngày ở 1M spans/ngày |
| Sử dụng bộ nhớ (trạng thái ổn định) | 3.8 GB (SigNoz stack) |
Case study production #
Nền tảng Microservices Thương mại điện tử: Một nền tảng với 35 microservices (Node.js, Python, Go) xử lý 500K requests/ngày đã di chuyển từ Datadog sang SigNoz. Trace retention: 7 ngày hot, 30 ngày cold (S3). Hóa đơn Datadog trước đây: $5,400/tháng. Chi phí SigNoz self-hosted: $96/tháng (2x 8GB VPS cho HA). Tiết kiệm hàng năm: $63,600.
Giám sát API SaaS: Một payment API xử lý 2M transactions/ngày sử dụng SigNoz cho theo dõi độ trễ, cảnh báo lỗi, và tương quan log. Đội 8 kỹ sư sử dụng trace search hàng ngày cho incident response. Thờ gian MTTR trung bình giảm từ 45 phút xuống 12 phút sau khi chuyển từ New Relic sang SigNoz, chủ yếu nhờ trace search nhanh hơn trong ClickHouse.
Sử dụng nâng cao / Củng cố production #
Thiết lập High-Availability #
# docker-compose.ha.yml — multi-node ClickHouse với ZooKeeper
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}
# Nginx load balancer cho ClickHouse
clickhouse-lb:
image: nginx:alpine
volumes:
- ./nginx-clickhouse.conf:/etc/nginx/nginx.conf
ports:
- "8123:8123"
- "9000:9000"
Lưu trữ dài hạn với S3 #
# Cấu hình backup 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>
Cấu hình Alert #
# alert-rules.yml — SigNoz alert manager rules
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: "Payment service error rate > 5%"
description: "Error rate is {{ $value }}"
- alert: HighP95Latency
expr: histogramQuantile(0.95)(rate(signoz_latency_bucket{service_name="payment-service"}[5m])) > 500000000
for: 5m
labels:
severity: warning
annotations:
summary: "Payment service P95 latency > 500ms"
description: "P95 latency is {{ $value }}ns"
- alert: LogErrorSpike
expr: rate(signoz_logs_total{severity="ERROR"}[5m]) > 100
for: 2m
labels:
severity: warning
annotations:
summary: "Log error spike detected"
description: "{{ $value }} errors/minute"
Cấu hình kênh alert (Slack, PagerDuty, email) trong SigNoz UI dưới Settings → Alert Channels.
Kubernetes Auto-Instrumentation #
# 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
---
# Instrument deployment bằng cách thêm OTel env vars
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" # Sample 10% traces
Chiến lược Sampling cho Services có traffic cao #
Cho services xử lý >10,000 requests/giây, triển khai head-based sampling:
# 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]
Cấu hình này sample 100% error traces, 100% slow requests (>500ms), và 10% traffic bình thường — cho bạn khả năng hiển thị lỗi hoàn chỉnh trong khi kiểm soát chi phí lưu trữ.
So sánh với các giải pháp thay thế #
| Tính năng | SigNoz | Datadog | New Relic | Grafana Stack |
|---|---|---|---|---|
| Mã nguồn mở | Giấy phép MIT | Độc quyền | Độc quyền | AGPL (một phần) |
| Self-hosted | Full Docker/K8s | Không | Không | Có |
| Sao GitHub | 22,000+ | N/A | N/A | N/A (Loki: 25K) |
| OpenTelemetry native | Có (chính) | Một phần | Một phần | Qua Tempo/Loki |
| Distributed tracing | Có | Có | Có | Qua Tempo |
| Log management | Có | Có | Có | Qua Loki |
| Infrastructure metrics | Có | Có | Có | Qua Prometheus |
| Dashboard tùy chỉnh | Có | Có | Có | Có |
| Alerting | Có (native) | Có | Có | Qua Alertmanager |
| Chi phí cho 50 hosts | $40–$120/tháng | ~$4,300/tháng | ~$3,100/tháng | $0 (self-hosted) |
| Kiểm soát retention | Toàn quyền | Hạn chế | Hạn chế | Toàn quyền |
| Ngôn ngữ truy vấn | ClickHouse SQL | Độc quyền | NRQL | PromQL/LogQL |
Khi chọn SigNoz thay vì Datadog: Nếu bạn muốn chủ quyền dữ liệu hoàn toàn, cần kiểm soát chi phí khi mở rộng, thích tiêu chuẩn OpenTelemetry, hoặc chạy trong môi trường air-gapped.
Khi chọn SigNoz thay vì Grafana Stack: Nếu bạn muốn một UI thống nhất cho traces, metrics và logs mà không cần cấu hình và duy trì 3+ công cụ riêng biệt (Tempo, Loki, Prometheus). SigNoz cung cấp trải nghiệm tích hợp ngay sau khi cài đặt.
Khi Datadog thắng: Nếu bạn cần tích hợp out-of-the-box rộng nhất (500+ dịch vụ đám mây), hạ tầng được quản lý, và có thể hấp thụ chi phí. UI polish và anomaly detection dựa trên ML của Datadog vẫn đi trước các giải pháp mã nguồn mở.
Hạn chế: Đánh giá trung thực #
Độ rộng hệ sinh thái: Datadog cung cấp 500+ tích hợp built-in cho dịch vụ đám mây, cơ sở dữ liệu, và công cụ third-party. SigNoz dựa vào OpenTelemetry auto-instrumentation, bao phủ các framework chính nhưng có thể yêu cầu thiết lập thủ công cho các dịch vụ ngách. Dự tính 1–2 ngày công việc instrument cho một stack microservices phức tạp.
Độ tinh chỉnh UI: Frontend React của SigNoz đầy đủ tính năng và đang cải thiện nhanh chóng, nhưng chưa sánh được với trải nghiệm ngườ dùng tinh tế của Datadog. Một số trực quan hóa nâng cao (service maps với dependency arrows, flame graph comparison) vẫn đang phát triển.
Không có RUM (Real User Monitoring) tích hợp: SigNoz hiện tập trung vào observability backend. Giám sát hiệu năng frontend yêu cầu một công cụ riêng hoặc instrumentation tùy chỉnh. Tính năng này nằm trong lộ trình H2 2026.
Tính năng machine learning: Watchdog AI của Datadog và Lookout của New Relic cung cấp anomaly detection tự động. SigNoz chưa bao gồm anomaly detection dựa trên ML. Bạn sẽ cần viết alert dựa trên threshold hoặc tích hợp với các nền tảng ML bên ngoài.
Khả năng hosting được quản lý: SigNoz Cloud có sẵn nhưng kém trưởng thành hơn so với các dịch vụ managed của Datadog hoặc New Relic. Các tier hỗ trợ enterprise có sẵn nhưng sản phẩm managed còn mới hơn.
Câu hỏi thường gặp #
Q: SigNoz so với Grafana Stack (Tempo + Loki + Prometheus) như thế nào?
SigNoz cung cấp trải nghiệm thống nhất: một binary, một UI, một endpoint truy vấn cho traces, metrics và logs. Grafana Stack yêu cầu triển khai và duy trì riêng Tempo (traces), Loki (logs), Prometheus (metrics), Grafana (visualization), và Alertmanager — mỗi cái với cấu hình, lưu trữ, và chu kỳ nâng cấp riêng. SigNoz là lựa chọn đơn giản hơn nếu bạn cần một APM tích hợp. Grafana Stack mang lại nhiều linh hoạt hơn nếu bạn cần mix và match các thành phần.
Q: Yêu cầu phần cứng ClickHouse cho production là gì?
Cho việc ingestion 1 triệu spans/ngày với 7 ngày hot retention: 4 vCPU, 8 GB RAM, 100 GB SSD. Cho 10 triệu spans/ngày: 8 vCPU, 32 GB RAM, 500 GB SSD. Cho 100+ triệu spans/ngày: ClickHouse cluster với 3+ nodes. Một node mạnh duy nhất (16 vCPU, 64 GB) có thể xử lý 50M+ spans/ngày. Luôn sử dụng SSD — HDD sẽ tạo bottleneck cho ingestion.
Q: Tôi có thể sử dụng metrics Prometheus hiện có với SigNoz không?
Có. OTel Collector của SigNoz bao gồm một Prometheus receiver. Cấu hình trong otel-collector-config.yaml:
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'my-app'
static_configs:
- targets: ['my-app:9090']
Các scrape configs Prometheus hiện có có thể được import trực tiếp. SigNoz sẽ lưu metrics trong Druid cho truy vấn dài hạn.
Q: Làm thế nào để di chuyển từ Datadog sang SigNoz?
Di chuyển có hai giai đoạn. Giai đoạn 1: Triển khai SigNoz song song với Datadog ở “shadow mode” — gửi 10% traffic đến SigNoz trong khi giữ Datadog làm chính. Xác thực dashboards và alerts. Giai đoạn 2: Chuyển OTLP exporters để trỏ 100% sang SigNoz, sau đó loại bỏ Datadog. Thờ gian di chuyển điển hình: 2–4 tuần cho một stack 30 services. OpenTelemetry Collector có thể route đến cả hai backends đồng thờ trong quá trình chuyển đổi.
Q: Dữ liệu của tôi có an toàn khi self-hosted SigNoz không?
Tất cả dữ liệu telemetry ở lại trên hạ tầng của bạn. SigNoz không gửi dữ liệu về nhà. Dữ liệu phân tích (usage analytics, không phải traces của bạn) chỉ được gửi khi bạn chọn tham gia rõ ràng. Codebase hoàn toàn mã nguồn mở và có thể kiểm toán. Đối với các ngành được quản lý (y tế, tài chính), đây thường là yêu cầu mà cloud APM không thể đáp ứng.
Q: Quản lý log so với ELK stack như thế nào?
SigNoz sử dụng ClickHouse cho lưu trữ log, cung cấp tỷ lệ nén tốt hơn 5–10 lần so với Elasticsearch và truy vấn phân tích nhanh hơn trên các trường cardinality cao. Tuy nhiên, Elasticsearch vẫn cung cấp xếp hạng liên quan tìm kiếm full-text vượt trội. Nếu trường hợp sử dụng chính của bạn là tìm kiếm log (không phải tương quan với traces), ELK có thể phù hợp hơn. SigNoz xuất sắc ở trace-log correlation — click một trace span sẽ tự động hiển thị các log liên quan.
Kết luận: Lấy lại ngân sách observability của bạn #
SigNoz mang lại những gì các đội kỹ sư quy mô thực sự cần: một APM cấp production với distributed tracing, metrics và logs, chi phí thấp hơn Datadog 90–98% — tất cả đều giữ dữ liệu telemetry trên hạ tầng của bạn và tuân theo tiêu chuẩn OpenTelemetry.
Với thiết lập Docker 5 phút, truy vấn sub-second trên hàng tỷ spans nhờ ClickHouse, và zero vendor lock-in, việc chi tiêu $50,000+/năm cho cloud APM trở nên khó có thể biện minh.
Triển khai ngay hôm nay: Khởi tạo VPS trên DigitalOcean ($48/tháng cho 8 GB) hoặc HTStack, chạy ./install.sh, và bắt đầu instrument service đầu tiên trong vòng 10 phút.
Tham gia cộng đồng: Nhóm Telegram cho developer Việt Nam | GitHub Discussions | Slack
Hosting Và Hạ Tầng Được Đề Xuất #
Trước khi triển khai các công cụ trên vào production, bạn cần hạ tầng vững chắc. Hai lựa chọn dibi8 đang dùng:
- DigitalOcean — Credit miễn phí $200 trong 60 ngày, 14+ khu vực toàn cầu. Lựa chọn mặc định cho dev chạy AI tools open source.
- HTStack — VPS Hong Kong, độ trễ thấp khi truy cập từ Trung Quốc. Cùng IDC đang host dibi8.com.
Liên kết tiếp thị — không tăng chi phí của bạn, giúp dibi8.com hoạt động.
Nguồn & Tài liệu tham khảo #
- SigNoz GitHub Repository: https://github.com/SigNoz/signoz
- Tài liệu chính thức: https://signoz.io/docs/
- Cấu hình OpenTelemetry Collector: https://signoz.io/docs/tutorial/opentelemetry-binary-usage-in-virtual-machine/
- Tuning hiệu năng ClickHouse: https://signoz.io/docs/operate/clickhouse/
- Hướng dẫn triển khai Kubernetes: https://signoz.io/docs/install/kubernetes/
- Grafana Stack — Stack observability mã nguồn mở thay thế
- Hướng dẫn self-hosting — Các thực hành tốt nhất về self-hosting trên dibi8.com
Công bố liên kết liên kết: Bài viết này chứa các liên kết liên kết đến DigitalOcean và HTStack. Nếu bạn mua dịch vụ thông qua các liên kết này, dibi8.com sẽ nhận được hoa hồng mà không phát sinh thêm chi phí cho bạn. Tất cả các khuyến nghị đều dựa trên kiểm thử thực tế, không phải khả năng có liên kết liên kết.
💬 Bình luận & Thảo luận