SigNoz: Thay thế Datadog bằng open-source, liệu có đáng?

Nếu bạn đang chạy microservices và mỗi tháng nhìn hóa đơn Datadog mà muốn khóc, thì bạn không đơn độc đâu. Mình đã từng ở vị trí đó team nhỏ, budget hạn chế, nhưng hệ thống thì ngày càng phình to. Logs bay khắp nơi, trace thì mỗi service một kiểu, metrics thì nằm rải rác trên Grafana, Prometheus, rồi thêm cả ELK nữa. Đống tool chồng chéo lên nhau mà debug một cái request đi qua 5 services vẫn mất cả buổi.

Rồi mình tình cờ gặp SigNoz. Nói thật là ban đầu mình cũng hoài nghi open-source mà claim thay thế được Datadog thì nghe hơi "to" nhưng sau khi dành thời gian đào sâu vào codebase, deploy thử, và chạy production nhỏ, mình thấy project này đáng để anh em nghiêm túc xem xét.

Gom logs, traces, metrics vào đúng một chỗ và tại sao điều đó thay đổi cách bạn debug

Cái pain point lớn nhất khi dùng nhiều tool riêng lẻ là context switching. Bạn thấy error rate tăng trên Grafana, nhảy sang Kibana tìm log, rồi lại mở Jaeger để trace request. Mỗi tool một giao diện, một query language, một cách filter khác nhau. Đến lúc tìm ra root cause thì đã mất 30 phút.

SigNoz giải quyết chuyện này bằng cách đưa cả ba pillars of observability logs, traces, và metrics vào chung một application. Nghe thì đơn giản, nhưng cái hay nằm ở chỗ chúng được correlate với nhau. Bạn đang xem một trace, click vào một span chậm, và ngay lập tức xem được logs của service đó trong khoảng thời gian đó. Hoặc bạn đang xem dashboard metrics, thấy p99 latency tăng đột biến, click vào là nhảy thẳng sang traces để xem chuyện gì đang xảy ra.

Theo kinh nghiệm của mình, chỉ riêng việc có correlated data trong một UI đã tiết kiệm được rất nhiều thời gian debug. Không phải mở 3-4 tab, không phải copy-paste trace ID từ tool này sang tool khác.

OpenTelemetry-native đây mới là điểm bán hàng thực sự

Nhiều tool observability hỗ trợ OpenTelemetry kiểu "à, chúng tôi cũng accept OTLP protocol". Nhưng SigNoz thì khác nó được build native trên OpenTelemetry từ đầu. Tức là toàn bộ data pipeline, data model, và instrumentation đều xoay quanh OTel standards.

Tại sao chuyện này quan trọng? Vì OpenTelemetry đang trở thành chuẩn de facto cho observability. Nếu bạn instrument code bằng OTel SDK hôm nay, mai mốt muốn đổi backend sang Datadog, Grafana, hay bất kỳ vendor nào khác bạn chỉ cần đổi exporter config, không cần sửa một dòng code nào trong application. Vendor lock-in gần như bằng 0.

Mình thấy cái này hay ở chỗ: nhiều team Việt Nam đang bắt đầu adopt OpenTelemetry nhưng chưa biết gửi data đi đâu. SigNoz cho bạn một backend sẵn sàng, self-hosted, không tốn tiền license, và hoàn toàn compatible với OTel collector. Bạn chỉ cần config OTel collector trỏ về SigNoz là xong.

Kiến trúc bên trong ClickHouse là trái tim

Đào vào codebase, mình thấy SigNoz dùng kiến trúc khá thú vị. Backend viết bằng Go, frontend bằng React/TypeScript, và phần storage dùng ClickHouse làm datastore chính cho cả logs, traces, lẫn metrics.

Việc chọn ClickHouse là một quyết định kiến trúc rất có chủ đích. ClickHouse là columnar database, cực kỳ mạnh cho analytical queries kiểu như "cho tôi xem p99 latency của service X trong 7 ngày qua, group by endpoint". Những query kiểu này trên traditional database sẽ chậm kinh khủng khi data lớn, nhưng ClickHouse xử lý rất nhanh.

So với ELK stack dùng Elasticsearch cho logs, ClickHouse có compression ratio tốt hơn đáng kể. Theo benchmark mà team SigNoz publish, storage cost có thể giảm tới 50-80% so với Elasticsearch cho cùng một lượng log data. Mình chưa verify con số chính xác, nhưng trong thực tế khi chạy thử, mình thấy ClickHouse thực sự ngốn ít disk hơn nhiều so với Elasticsearch cluster mình đang dùng.

Cấu trúc repo cũng khá clean:

• cmd/ entry points cho các services
• pkg/ shared packages
• ee/ enterprise edition features (phần trả phí)
• frontend/ React app
• deploy/ Docker Compose, Kubernetes manifests
• conf/ default configurations

Anh em lưu ý folder ee/ SigNoz theo mô hình open-core, tức là core features thì free, còn một số advanced features như SSO, RBAC nâng cao thì nằm trong enterprise edition. Mình sẽ nói kỹ hơn phần này ở dưới.

So sánh thẳng với các giải pháp khác

Để anh em dễ hình dung, mình tổng hợp lại so sánh giữa SigNoz và các tool phổ biến:

Điểm mình muốn highlight: nếu so với Grafana stack, SigNoz có lợi thế rõ ràng về simplicity. Grafana stack yêu cầu bạn setup Loki cho logs, Tempo cho traces, Mimir (hoặc Prometheus) cho metrics mỗi cái một config, một cách scale riêng. SigNoz gom hết vào một application duy nhất, dùng chung một ClickHouse backend. Ít moving parts hơn đồng nghĩa với ít thứ có thể break.

Còn so với Datadog, obviously bạn trade-off giữa tiền và effort. Datadog là SaaS, bạn không cần lo infra, nhưng bill có thể lên rất nhanh khi scale. SigNoz self-hosted thì bạn phải tự manage, nhưng cost chỉ là tiền server.

Developer experience setup và sử dụng thực tế

Mình thử deploy SigNoz bằng Docker Compose trên một con EC2 t3.large (2 vCPU, 8GB RAM). Quá trình setup khá straightforward:

1git clone -b main https://github.com/SigNoz/signoz.git && cd signoz/deploy/
2docker compose up -d

Chờ khoảng 2-3 phút cho tất cả containers pull và start, rồi truy cập http://localhost:3301. Đơn giản vậy thôi. Lần đầu vào sẽ được yêu cầu tạo admin account.

UI của SigNoz khá modern và intuitive. Mình không phải đọc docs nhiều để biết cách navigate. Phần APM dashboard hiện sẵn các metrics quan trọng: p50/p90/p99 latency, error rate, request rate, Apdex score. Bạn click vào bất kỳ service nào là thấy ngay breakdown theo endpoint.

Phần Traces có filter khá mạnh filter theo service, operation, status code, duration, rồi kết quả hiện dạng timeline. Click vào một trace thì thấy flamegraph và Gantt chart, giống Jaeger nhưng mình thấy UI đẹp hơn và responsive hơn.

Phần Logs thì có query builder visual, không cần viết raw query. Nhưng nếu bạn thích viết query thì cũng có chế độ raw ClickHouse SQL. Mình thích cái này vì ClickHouse SQL rất powerful cho aggregation queries.

Một điểm mình đánh giá cao là phần Alerts. Bạn có thể tạo alert dựa trên bất kỳ metric, log pattern, hay trace condition nào. Alert channels hỗ trợ Slack, PagerDuty, webhook, email. Đủ dùng cho hầu hết team.

Những điểm cần cân nhắc không phải màu hồng hết đâu

Nói công bằng, SigNoz cũng có những điểm mình thấy cần improve:

ClickHouse operations: Nếu team bạn chưa có kinh nghiệm vận hành ClickHouse, đây sẽ là learning curve đáng kể. ClickHouse mạnh nhưng không phải dễ tune. Khi data lớn lên (hàng trăm GB logs/ngày), bạn cần hiểu về partitioning, TTL, merge behavior, memory settings. Đây không phải lỗi của SigNoz, nhưng là trade-off khi self-host.

Community size: Với 27k+ stars trên GitHub, SigNoz có community khá lớn. Nhưng so với Grafana ecosystem hay ELK, nó vẫn nhỏ hơn nhiều. Điều này có nghĩa là khi bạn gặp edge case, khả năng tìm được câu trả lời trên StackOverflow thấp hơn. Bù lại, Slack community của họ khá active, team core respond nhanh.

Enterprise features: Một số feature như SSO (SAML), advanced RBAC, query-based access control nằm trong enterprise edition. Nếu team bạn cần những thứ này, bạn sẽ phải trả phí hoặc tự implement. Mình thấy đây là điều hợp lý cho một open-core business model, nhưng anh em cần biết trước.

High availability: Deploy production-grade ClickHouse cluster với replication không phải chuyện đơn giản. SigNoz có docs cho Kubernetes deployment với ClickHouse operator, nhưng mình thấy phần này vẫn cần nhiều kinh nghiệm DevOps.

Instrument ứng dụng thực ra không khó

Vì SigNoz dùng OpenTelemetry, nên việc instrument application khá chuẩn. Ví dụ với một Node.js app, bạn chỉ cần:

1npm install @opentelemetry/auto-instrumentations-node

Rồi chạy app với:

1OTEL_EXPORTER_OTLP_ENDPOINT=http://signoz-host:4318 \
2OTEL_SERVICE_NAME=my-service \
3node --require @opentelemetry/auto-instrumentations-node/register app.js

Với Java thì còn đơn giản hơn dùng OTel Java agent, không cần sửa code:

1java -javaagent:opentelemetry-javaagent.jar \
2  -Dotel.exporter.otlp.endpoint=http://signoz-host:4318 \
3  -Dotel.service.name=my-service \
4  -jar myapp.jar

Auto-instrumentation sẽ tự capture HTTP requests, database calls, external API calls, và tạo traces tương ứng. Bạn không cần viết thêm code gì cả cho basic observability. Khi cần custom spans hay business metrics, bạn mới cần dùng OTel SDK manual instrumentation.

Ai nên dùng SigNoz?

Dựa trên trải nghiệm thực tế, mình recommend SigNoz cho:

• Team đang dùng nhiều tool rời rạc (Prometheus + Grafana + ELK + Jaeger) và muốn consolidate lại. SigNoz giảm đáng kể operational overhead.
• Startup và team nhỏ cần observability nghiêm túc nhưng không có budget cho Datadog. Với một con server tầm 4-8 CPU, 16-32GB RAM, bạn có thể chạy SigNoz cho hệ thống vài chục services thoải mái.
• Team đang hoặc sẽ adopt OpenTelemetry. SigNoz là backend tự nhiên nhất cho OTel data.

Ngược lại, mình không recommend SigNoz nếu:

• Team bạn không có ai rành DevOps/infra để vận hành ClickHouse và các component liên quan. Lúc đó dùng SaaS như Datadog hay SigNoz Cloud (hosted version) sẽ hợp lý hơn.
• Bạn cần APM rất advanced với features như continuous profiling, real user monitoring (RUM), synthetic monitoring. SigNoz đang phát triển những feature này nhưng chưa mature bằng Datadog.

Nhìn vào trajectory của project

Mình xem commit history và thấy project rất active hơn 6,200 commits, release đều đặn. Repo có 1,200+ issues mở, 256 PRs dấu hiệu của một project sống và đang phát triển nhanh. Team core có vẻ khá focused, roadmap rõ ràng.

Điều mình thấy đáng chú ý là họ vừa thêm folder .claude/agents trong repo cho thấy team đang experiment với AI-assisted development. Nhỏ thôi nhưng nó cho thấy mindset của team khá cập nhật.

Nếu bạn đang tìm một giải pháp observability self-hosted, nghiêm túc, và không muốn bị vendor lock-in, SigNoz xứng đáng nằm trong shortlist. Cứ dành một buổi chiều setup thử bằng Docker Compose, instrument một vài services, rồi tự đánh giá. Mình nghĩ bạn sẽ bất ngờ với những gì một open-source project có thể làm được ở thời điểm này.