¿Por qué sustituir Datadog o New Relic por SigNoz?
Las herramientas SaaS de observabilidad tienen un modelo de precios temible: gratis hasta un puñado de hosts y, después, la factura se dispara con cada servicio añadido. Para una agencia web que gestiona diez proyectos de clientes o un desarrollador independiente que escala su SaaS, la cuenta mensual supera rápidamente los 200 a 500 € sin que el valor añadido sea proporcional.
SigNoz cambia las reglas del juego. Es una plataforma de observabilidad open source (licencia Apache 2.0) que se apoya en ClickHouse para el almacenamiento de alto rendimiento de las trazas y las métricas, y en el protocolo OpenTelemetry para la instrumentación. Sus datos se quedan en su casa, usted controla la retención y solo paga el VPS que hace funcionar la stack.
Lo que SigNoz le aporta
- Trazas distribuidas: visualice el recorrido completo de una petición HTTP a través de sus microservicios, con los spans, las duraciones y los errores en cada etapa.
- Métricas compatibles con Prometheus: importe sus dashboards existentes o cree otros nuevos desde la interfaz de SigNoz.
- Logs centralizados: recopile y correlacione los logs estructurados de todas sus aplicaciones en una interfaz unificada.
- Alertas configurables: defina umbrales sobre cualquier métrica y reciba notificaciones por Slack, PagerDuty o webhook.
- Dashboards personalizables: cree vistas de negocio o técnicas en unos clics, sin necesidad obligatoria de LoQL ni PromQL.
- Interfaz moderna: UI React responsive accesible en el puerto 8080 de su VPS, sin agente propietario del lado del cliente.
Requisitos previos antes de empezar
SigNoz se apoya en ClickHouse, un motor de base de datos columnar muy exigente en memoria. El mínimo absoluto recomendado es 4 GB de RAM — por debajo, el OOM killer del kernel mata ClickHouse antes incluso de que se cargue la UI. Para un uso en producción con varias aplicaciones instrumentadas, apunte a 8 GB.
Esta es la lista completa de requisitos previos:
- Un VPS con Ubuntu 22.04 o Debian 12.
- Docker Engine ≥ 24 y Docker Compose V2 instalados.
- El puerto 8080 abierto en su cortafuegos (UI de SigNoz).
- Los puertos 4317 (OTLP/gRPC) y 4318 (OTLP/HTTP) abiertos para recibir las trazas.
- Un acceso root o sudo en el VPS.
- Al menos 20 GB de espacio libre en disco para ClickHouse y sus archivos de datos.
Instalación de SigNoz con Foundry CLI
Paso 1 — Instalar Docker en su VPS
Si Docker aún no está presente, instálelo con el script oficial:
curl -fsSL https://get.docker.com | sh systemctl enable --now docker docker --versionCompruebe que el comando
docker compose(V2, sin guion) funciona:docker compose versionPaso 2 — Instalar Foundry CLI (foundryctl)
Desde la versión v0.112.0, SigNoz adopta el Foundry CLI como método de despliegue oficial. El antiguo
install.shbasado en docker-compose está obsoleto.curl -L https://get.foundry.so/foundryctl/latest | bash export PATH="$HOME/.foundry/bin:$PATH" foundryctl --versionAñada el export PATH en su
~/.bashrco~/.profilepara hacerlo permanente.Paso 3 — Crear el archivo casting.yaml
Foundry CLI utiliza un archivo declarativo
casting.yamlpara definir la stack SigNoz:mkdir -p /opt/signoz && cd /opt/signoz cat > casting.yaml << 'EOF' apiVersion: foundry.so/v1 kind: Casting metadata: name: signoz spec: release: stable components: - name: signoz enabled: true - name: clickhouse enabled: true EOFPaso 4 — Lanzar el despliegue
Basta un solo comando para arrancar toda la stack:
foundryctl cast -f casting.yamlFoundry CLI descarga las imágenes Docker, configura los volúmenes persistentes y arranca los contenedores en el orden correcto. El arranque completo tarda entre 2 y 3 minutos. Siga los logs en tiempo real:
docker compose -f /opt/signoz/docker-compose.yaml logs -fPaso 5 — Comprobar que SigNoz está operativo
Espere a que todos los contenedores estén en estado
healthy:docker compose -f /opt/signoz/docker-compose.yaml psAbra después su navegador en
http://<IP_VPS>:8080. Cree su cuenta de administrador en la primera conexión. Nota: el antiguo puerto 3301 mencionado en tutoriales de la comunidad está obsoleto — el puerto actual es el 8080.Paso 6 — Asegurar el acceso con un reverse proxy
No deje el puerto 8080 expuesto directamente en producción. Coloque Nginx como reverse proxy con un certificado TLS:
apt install -y nginx certbot python3-certbot-nginx cat > /etc/nginx/sites-available/signoz << 'EOF' server { server_name signoz.votredomaine.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } EOF ln -s /etc/nginx/sites-available/signoz /etc/nginx/sites-enabled/ certbot --nginx -d signoz.votredomaine.com nginx -t && systemctl reload nginxCierre después el puerto 8080 en su cortafuegos.
Instrumentar su aplicación con el SDK de OpenTelemetry
SigNoz recibe las trazas mediante el protocolo OTLP. Así es como se conecta una aplicación Node.js y una aplicación Python.
Node.js (Express):
npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-nodeCree un archivo tracing.js al arrancar su app:
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const sdk = new NodeSDK({ instrumentations: [getNodeAutoInstrumentations()] });
sdk.start();Arranque su app con la variable de entorno apuntando a su VPS:
OTEL_EXPORTER_OTLP_ENDPOINT="http://<IP_VPS>:4318" \
OTEL_SERVICE_NAME="mon-api" \
node -r ./tracing.js app.jsPython (FastAPI/Flask):
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install
OTEL_EXPORTER_OTLP_ENDPOINT="http://<IP_VPS>:4318" \
OTEL_SERVICE_NAME="mon-service-python" \
opentelemetry-instrument uvicorn main:appEn ambos casos, las trazas aparecen en la interfaz de SigNoz bajo Services en los segundos siguientes a la primera llamada HTTP.
Crear dashboards y alertas
Una vez instrumentadas sus aplicaciones, SigNoz rellena automáticamente la vista Services con la latencia P50/P99, la tasa de error y el rendimiento de cada servicio.
Crear un dashboard personalizado:
1. Vaya a Dashboards → New Dashboard.
2. Añada un panel de tipo Time Series y seleccione una métrica Prometheus.
3. Aplique filtros por servicio, entorno o endpoint.
Configurar una alerta sobre la latencia P99:
1. Vaya a Alerts → New Alert Rule.
2. Elija el tipo Metric Based Alert.
3. Introduzca la condición: p99(signoz_latency_bucket{service_name="mon-api"}) > 500 (alerta si P99 > 500 ms).
4. Configure el canal de notificación: Slack, correo o webhook.
Cuidado con los OOM kills de ClickHouse
ClickHouse es el componente más exigente de la stack SigNoz. En un VPS con menos de 4 GB de RAM disponible, el kernel Linux puede matar el proceso ClickHouse con una señal exit code 137 (SIGKILL enviado por el OOM killer).
Síntoma: la interfaz de SigNoz se carga pero ya no muestra datos, o el contenedor clickhouse se reinicia en bucle. Los logs de la aplicación no mencionan nada — el error está a nivel del kernel.
Diagnóstico:
dmesg | grep -i oomVerá una línea del tipo Out of memory: Killed process XXXX (clickhouse-serv).
Remedios: añada RAM a su VPS (recomendado), o limite la memoria de ClickHouse añadiendo max_memory_usage=2000000000 (2 GB) en /etc/clickhouse-server/users.xml.
SigNoz vs Datadog vs Grafana Cloud
Desplace la tabla
| Criterio | SigNoz (self-hosted) | Datadog | Grafana Cloud |
|---|---|---|---|
| Coste mensual (5 servicios) | Solo el coste del VPS (~10-20 €) | ~75-150 $ + métricas personalizadas | Gratis hasta 10k series, luego ~8 $/1k |
| Trazas distribuidas | Sí (OpenTelemetry nativo) | Sí (agente propietario) | Sí (Tempo, vía OTLP) |
| Métricas | Sí (compatible con Prometheus) | Sí (propietario + Prometheus) | Sí (Mimir, compatible con Prometheus) |
| Logs | Sí (integrado) | Sí (coste adicional) | Sí (Loki, coste adicional) |
| Soberanía de los datos | Total — datos en su VPS | Datos en Datadog (US/UE) | Datos en Grafana Labs |
| Complejidad operativa | Media (Docker, 1 VPS) | Nula (SaaS) | Baja (SaaS) |
| Actualización | Manual (foundryctl) | Automática | Automática |
| Soporte | Comunidad + plan de pago | De pago (incluido) | Comunidad + plan de pago |
Resolver los problemas más habituales
La UI no se carga en el puerto 8080
Compruebe que el contenedor signoz-frontend está en estado running y que su cortafuegos autoriza el puerto:
docker compose ps | grep frontend
ufw status | grep 8080Las trazas no aparecen en la interfaz
Compruebe que el puerto 4318 (OTLP/HTTP) es accesible desde su aplicación:
curl -v http://<IP_VPS>:4318Una respuesta 405 Method Not Allowed confirma que el collector sí está escuchando.
El contenedor ClickHouse se reinicia en bucle
Casi con toda seguridad es un OOM kill. Consulte dmesg | grep -i oom para confirmarlo.
Error connection refused desde la app hacia el VPS
Asegúrese de que los puertos 4317 o 4318 están abiertos en el firewall del VPS de SigNoz, y de que la URL de OTEL_EXPORTER_OTLP_ENDPOINT apunta realmente a la IP pública del VPS y no a localhost.
Consejo: planifique la retención de los datos de ClickHouse
De forma predeterminada, SigNoz conserva las trazas 3 días y las métricas 30 días. En un VPS de 20 GB, un volumen de trazas moderado puede llenar el disco en unas semanas.
Ajuste la retención en la interfaz de SigNoz en Settings → Retention Period. Para una agencia que gestiona varios proyectos de clientes, 7 días de trazas y 90 días de métricas ofrecen un buen equilibrio entre visibilidad y consumo de disco.
