2 min de leitura ·

Pitch: Criei o unTelemetry: telemetria rápida com Node.js, Redis e ClickHouse (requests, SQL queries, logs e tracing)

Nos últimos meses eu estava procurando uma solução de telemetria/observabilidade para projetos com alto volume de eventos.

E o cenário era sempre parecido:

plataformas muito boas, mas com custo que cresce rápido demais
opções open source poderosas, mas com setup e operação mais chatos
várias ferramentas dependiam de SDK próprio, e eu perdia liberdade para decidir com clareza o que subir ou não, com personalizações básicas

Foi daí que nasceu o unTelemetry:
https://untelemetry.unledu.com.br

A proposta do projeto é simples:
Receber eventos em massa, processar muito rápido e entregar métricas úteis sem virar um monstro de configuração.

Stack que usei:

Node.js (ingestão e APIs)
Redis (buffer/fila/cache para absorver picos)
ClickHouse (armazenamento analítico e consulta rápida em alto volume)

Um ponto importante:
o unTelemetry é agnóstico de linguagem.
Se a linguagem/plataforma suporta OpenTelemetry, o unTelemetry consegue receber os dados.
Ou seja: onde o OpenTelemetry roda, o unTelemetry integra.

E essa escolha foi central no projeto:
em vez de prender o usuário a SDK proprietário, eu aproveito o ecossistema OpenTelemetry.
Com isso, ganho toda a personalização que o OpenTelemetry já oferece, com mais controle sobre o que coletar, o que enviar e como modelar a telemetria.

Hoje eu já consigo gerar e visualizar:

métricas de requests
métricas de queries SQL (sql only)
recebimento e consulta de logs
tracing completo (distribuído)

Arquitetura (visão resumida):

ingestão de telemetria via OpenTelemetry
desacoplamento com Redis para segurar picos
persistência e agregações no ClickHouse
leitura rápida para dashboards/insights operacionais

Motivação principal:
eu queria fugir de dois extremos:

soluções enterprise excelentes, mas caras para muitos projetos
soluções abertas que exigem uma carga operacional alta logo no começo

Também deixei o projeto com plano free:
dá para testar 100% grátis antes de qualquer decisão.

Se alguém quiser trocar ideia, eu gostaria de feedback sobre:

melhorias de arquitetura
estratégias de retenção e particionamento no ClickHouse
práticas para manter baixa latência com crescimento de volume
trade-offs entre custo x granularidade das métricas

Projeto:
https://untelemetry.unledu.com.br

Plano grátis (100% free para teste):
https://untelemetry.unledu.com.br

pedrovisk

Acho legal ter uma alternativa dessa nativa do BR, de fato New Relic, DataDog sao bem caros e em dolar.
Mas me procupa alguns pontos nesse projeto, tenho contato com essas ferramentas a um bom tempo e o ponto mais critico que vejo é a LGPD, os usuarios podem acabar logando dados sensiveis, seu sistema é seguro de fato? Clickhouse é excelente para esse tipo de problema, mas voce esta trabalhando com a mesma estrutura/infra para todos usuarios? e se houver alguma vunerabilidade seja permitido visualizar dados de outros usuarios?
O ponto que talvez eu pensaria: porque devo confiar na sua ferramenta e o que ela apresenta que me dar essa confiança?
Tem mais alguns pontos, por exemplo, se sua infra cair, ha redundancia? se nao informacoes dos clientes serao perdidas... em fim, nao me leve a mal, continue firme na ideia, mas nao deixe que os detalhes importantes nao seja revisto.
abç!

Militao36

Autor

Muito obrigado pelo comentário, respondendo alguams coisas.

1 - Se usuários logar ao sensivel (senhas e tokens) atualmente estou removendo (más penso em talvez deixar se usuário quer então deixo)
2 - Atualmente estou em uma mesma estrutura/infra, com isso tenho um unico banco clickhouse para várias empresas/usuários, porém penso em talvez ter banco dividos por empresa.
3 - Atualmente tenho algumas seguranças tais como sql injections, para tratar
4 - Atualmente estou migrando para utilizar o API Gateway da AWS, que consigo ter uma balanceador de carga para vários servidores, conseguigando um bom uptime. E tenho apps desacopladas, uma é de "injestão de dados" e outra de processamento e a terceira para o front consumir a API e ter acesso aos filtros.

Más obrigado pelo compentário me fez pensar em muitas coisas, a principio fiz o projeto para usar em meus projetos pessoais, então tem muito que evoluir, para ser algo comercial