Introdução ao SigNoz como alternativa open source ao Datadog

1. Por que considerar uma alternativa open source ao Datadog?

Empresas que escalam suas operações rapidamente enfrentam um desafio comum: os custos de observabilidade disparam à medida que o volume de dados cresce. O Datadog, embora seja uma plataforma madura e rica em funcionalidades, adota um modelo de precificação por host e por log que pode se tornar proibitivo. Em ambientes com centenas de microsserviços, a fatura mensal frequentemente ultrapassa dezenas de milhares de dólares.

Além dos custos, há questões de compliance e soberania de dados. Com regulamentações como a LGPD no Brasil e a GDPR na Europa, muitas organizações precisam garantir que dados sensíveis permaneçam em infraestrutura controlada. Soluções open source eliminam o lock-in de fornecedor e permitem auditoria completa do código.

O SigNoz se destaca nesse cenário por ser construído sobre o OpenTelemetry, o padrão emergente para instrumentação de sistemas distribuídos. Enquanto o Datadog usa agentes proprietários, o SigNoz adota uma abordagem aberta, facilitando a portabilidade e evitando dependências de vendor.

2. Visão geral do SigNoz: arquitetura e componentes principais

O SigNoz é composto por três camadas principais:

  • ClickHouse: banco de dados colunar de alto desempenho para armazenamento de traces, métricas e logs. Suporta consultas analíticas complexas em tempo real.
  • SigNoz Query Service: backend em Go que processa requisições da interface e gerencia a ingestão de dados via gRPC e HTTP.
  • Frontend: aplicação React/TypeScript que fornece dashboards, visualização de traces e configuração de alertas.

O pipeline de ingestão segue este fluxo:

Aplicação Instrumentada → OpenTelemetry Collector → SigNoz Query Service → ClickHouse

O OpenTelemetry Collector atua como gateway, recebendo dados em formato OTLP (OpenTelemetry Protocol) e encaminhando para o SigNoz. Ele também pode fazer sampling, transformação e roteamento antes do armazenamento.

3. Instalação e primeiros passos com SigNoz

Para ambientes de desenvolvimento, a maneira mais rápida de começar é usando Docker Compose. Crie um arquivo docker-compose.yml com a configuração mínima:

version: "3.8"
services:
  clickhouse:
    image: clickhouse/clickhouse-server:23.8-alpine
    ports:
      - "9000:9000"
      - "8123:8123"
    volumes:
      - ./data/clickhouse:/var/lib/clickhouse

  query-service:
    image: signoz/query-service:latest
    ports:
      - "8080:8080"
      - "8081:8081"
    environment:
      - STORAGE=clickhouse
      - CLICKHOUSE_HOST=clickhouse
    depends_on:
      - clickhouse

  frontend:
    image: signoz/frontend:latest
    ports:
      - "3000:3000"
    environment:
      - SIGNOZ_API_ENDPOINT=http://query-service:8080
    depends_on:
      - query-service

Execute com docker-compose up -d e acesse http://localhost:3000. A interface solicitará a criação de uma conta local. Após o login, você poderá configurar seu primeiro serviço monitorado.

Para produção, o SigNoz oferece charts Helm para Kubernetes, com suporte a réplicas, persistência e escalabilidade horizontal.

4. Ingestão de dados de observabilidade com OpenTelemetry

Vamos instrumentar uma aplicação Node.js simples. Primeiro, instale as dependências:

npm install @opentelemetry/api @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-grpc

Crie um arquivo instrumentation.js:

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-grpc');

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'http://localhost:4317',
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Execute sua aplicação com node -r ./instrumentation.js app.js. Agora, cada requisição HTTP gerará traces que serão enviados para o SigNoz via OTLP.

Para logs estruturados, configure o OpenTelemetry Collector com um pipeline de logs:

receivers:
  filelog:
    include: [ /var/log/app/*.log ]
    start_at: beginning
processors:
  batch:
exporters:
  otlp:
    endpoint: "query-service:4317"
service:
  pipelines:
    logs:
      receivers: [filelog]
      processors: [batch]
      exporters: [otlp]

5. Navegando na interface: dashboards, traces e métricas

Ao acessar o SigNoz, o menu principal oferece três áreas:

  • Traces: exibe uma lista de todas as requisições com duração, status e serviço. Ao clicar em um trace, você vê o flamegraph completo com spans detalhados, incluindo parâmetros, exceções e tempo gasto em cada operação.

  • Metrics: dashboards pré-construídos mostram latência (p50, p95, p99), taxa de erro e throughput por serviço. É possível criar dashboards customizados usando consultas SQL sobre o ClickHouse. Exemplo:

SELECT toStartOfMinute(timestamp) as minute,
       count() as total_requests,
       quantile(0.99)(duration) as p99_latency
FROM signoz_traces.signoz_index_v2
WHERE serviceName = 'meu-servico'
  AND timestamp > now() - INTERVAL 1 HOUR
GROUP BY minute
ORDER BY minute
  • Alerts: configure regras como "se p99 latency > 500ms por 5 minutos, notificar no Slack". O SigNoz suporta webhooks, PagerDuty e e-mail.

6. Comparação prática: SigNoz vs Datadog em cenários comuns

Funcionalidade Datadog SigNoz
APM (Traces) Completo com correlação automática Completo via OpenTelemetry
Métricas de infraestrutura Agente proprietário OpenTelemetry Collector + kube-state-metrics
Logs Gerenciamento centralizado Suporte via pipeline OTLP
RUM (Real User Monitoring) Nativo Não disponível nativamente
Alertas Baseados em métricas e logs Baseados em queries ClickHouse

A maior diferença está no RUM: enquanto o Datadog oferece monitoramento de usuários reais no frontend, o SigNoz ainda depende de integrações externas ou do OpenTelemetry para JavaScript.

Em contrapartida, o SigNoz oferece correlação nativa entre traces e logs através de atributos comuns como traceId e spanId, funcionalidade que no Datadog exige plano Enterprise.

7. Estratégias de redução de custo com SigNoz

O modelo self-hosted do SigNoz permite controle total sobre custos de armazenamento. Algumas estratégias práticas:

Retenção seletiva com TTL no ClickHouse:

ALTER TABLE signoz_traces.signoz_index_v2
  MODIFY TTL timestamp + INTERVAL 30 DAY;

ALTER TABLE signoz_logs.logs
  MODIFY TTL timestamp + INTERVAL 7 DAY;

Sampling adaptativo no OpenTelemetry Collector:

processors:
  probabilistic_sampler:
    hash_seed: 42
    sampling_percentage: 10

Com sampling de 10%, você reduz em 90% o volume de dados armazenados, mantendo representatividade estatística.

Comparação de custos: para um cluster com 50 hosts gerando 500 GB de logs por mês, o Datadog cobraria aproximadamente $15.000/mês. Com SigNoz em cloud própria (AWS EC2 + EBS), o custo de infraestrutura fica em torno de $500/mês, uma economia de 97%.

8. Próximos passos e considerações finais

Migrar do Datadog para o SigNoz requer planejamento, mas é viável com uma abordagem gradual:

  1. Paralelo inicial: instrumente novos serviços com OpenTelemetry e envie tanto para Datadog quanto para SigNoz.
  2. Validação: compare métricas e traces entre as plataformas por 2-4 semanas.
  3. Corte: desative o agente Datadog nos serviços validados e monitore os dashboards do SigNoz.
  4. Expansão: migre logs e métricas de infraestrutura usando o OpenTelemetry Collector.

A comunidade do SigNoz é ativa no GitHub e Slack, com contribuições frequentes. Integrações oficiais incluem Slack, PagerDuty, Grafana e webhooks genéricos.

Para ambientes de produção, recomenda-se:
- Múltiplas réplicas do Query Service com balanceamento de carga
- Cluster ClickHouse com replicação e sharding
- Monitoramento do próprio SigNoz com métricas de saúde

O SigNoz não é apenas uma alternativa de baixo custo: é uma plataforma moderna, alinhada aos padrões abertos da indústria e que coloca o controle dos dados nas mãos do usuário.

Referências