Saltar a contenido

Dashboards y Alertas

Acceder a la UI

Acceso URL
Público (Cloudflare + TLS) https://signoz.histrix.com.ar
Interno (red ZeroTier) http://IP_ZEROTIER_CENTRAL:8080

El día a día se usa la URL pública. La interna por ZeroTier sirve para diagnóstico cuando el proxy público no está disponible.

Puerto :8080, no :3301

El stack nativo (systemd) sirve la UI y la API en el puerto 8080. El :3301 era el frontend de la versión vieja sobre Docker y ya no se usa.

Métricas del host

Una vez que el agente está enviando datos (~60 segundos), los servidores aparecen en Infrastructure en el menú lateral.

Dos familias de métricas

Cada agente envía las métricas del host por dos vías, así que vas a ver nombres distintos para lo mismo:

Familia Origen Prefijo Uso
OTel hostmetrics receiver hostmetrics del otelcol-contrib system.* Canónica — es la que usan nuestros dashboards y alertas
Prometheus node_exporter binario node_exporter scrapeado por el agente node_* Disponible como alternativa / compatibilidad con dashboards de la comunidad

Usá system.* para paneles y alertas nuevas

Todo lo que armamos internamente está sobre system.*. Reservá node_* solo si importás un dashboard de la comunidad que ya viene escrito con esos nombres.

Métricas system.* más usadas:

Métrica Qué muestra
system.cpu.utilization Uso de CPU por core y modo (0–1)
system.cpu.load_average.1m / .5m / .15m Load average
system.memory.usage / system.memory.utilization RAM usada (bytes / %)
system.filesystem.usage Uso de disco en bytes (atributo state = used / free)
system.filesystem.inodes.usage Inodos usados
system.paging.usage Swap en uso
system.network.io Bytes de red transmitidos/recibidos
system.disk.io Bytes de disco leídos/escritos

Dashboards existentes

Ya hay un set de dashboards armado en Dashboards del menú lateral. Se dividen en dos grupos.

Operativos (técnicos)

Dashboard Para qué
Host Metrics CPU, memoria, disco, red y filesystem por servidor (basado en hostmetrics)
Container Metrics Métricas de los contenedores Docker (docker_stats)
🐳 Docker / Contenedores Estado y consumo de contenedores Docker por host (CPU, memoria, red)
📈 Capacidad / Tendencias Tendencia de disco, swap, inodos, load y red por servidor para planificar capacidad
📜 Logs & Seguridad Volumen y errores de logs por servidor, accesos SSH y bloqueos de firewall
🛡️ Seguridad — Actividad Eventos de seguridad desde los logs (accesos SSH, fallos, altas de usuario)
IngestionV2 Volumen de métricas, logs y trazas que se están ingiriendo (para controlar costos de almacenamiento)

Gerencia (negocio)

Dashboard Para qué
Gerencia — Infraestructura Vista ejecutiva de un vistazo: salud de los servidores (CPU, RAM, disco) con semáforos y detalle por servidor

Container IDs como hosts

En los filtros por host.name vas a ver, además de los nombres de servidor, algunos IDs cortos en hexadecimal (ej. 85496e1c87b6). Son contenedores Docker que reportan su ID como hostname. Para la vista de servidores reales, filtrá por los nombres que pusiste en --server-name.

Importar más dashboards

Para sumar dashboards de la comunidad:

  1. Ir a Dashboards → New Dashboard → Import JSON
  2. Tomar el JSON de la galería oficial de SigNoz
  3. Si el dashboard usa métricas node_* (Prometheus), funciona directo porque también las recolectamos

Logs

  1. Ir a Logs en el menú lateral
  2. Filtrar por host.name = nombre-del-servidor (el nombre que pusiste en --server-name)
  3. Filtrar por log.file.path para separar syslog, auth.log, logs de containers, etc.

Alertas

Alertas configuradas

Hay un set de alertas ya cargado. Todas notifican al canal Gerencia Email y se agrupan por host.name (un aviso por servidor afectado).

Alerta Tipo Qué detecta Umbral Severidad Equipo
Disco por encima del 85% Métrica usado / total de un filesystem > 85% (recupera en 82%) critical infra
Servidor caído (sin datos) Métrica (ausencia) Un servidor dejó de reportar métricas sin datos > 10 min critical infra
CPU por encima del 90% Métrica Uso de CPU sostenido > 90% critical infra
RAM por encima del 90% Métrica Uso de memoria > 90% critical infra
Swap en uso por encima del 50% Métrica Presión de memoria (swap) > 50% warning infra
Inodos por encima del 85% Métrica Inodos usados de un filesystem > 85% critical infra
OOM killer detectado Logs El kernel mató un proceso por falta de memoria aparición en logs critical infra
Posible brute-force SSH Logs Oleada de accesos SSH rechazados umbral de intentos warning seguridad
Posible escaneo web (oleada de 4xx) Logs Oleada de HTTP 4xx desde IPs externas umbral de 4xx warning seguridad

Renotificación

Las alertas vuelven a avisar mientras siguen activas (cada 6 h las de disco, cada 1 h la de servidor caído). La de servidor caído también notifica en estado nodata.

Crear una alerta nueva

El patrón que usamos (ejemplo real: la alerta de disco) es builder query con fórmula, no PromQL:

  1. Alerts → New Alert Rule → Metrics
  2. Query A: métrica system.filesystem.usage, filtro state = 'used', agregación avg + sum, agrupado por host.name
  3. Query B: la misma métrica system.filesystem.usage sin filtro, agrupada por host.name
  4. Fórmula F1: A/B (fracción usada del disco)
  5. Umbral: > 0.85 (unidad percentunit), severidad critical, label team: infra
  6. Canal de notificación: Gerencia Email

Para una alerta basada en logs (ej. brute-force SSH u OOM), elegir Logs en vez de Metrics y definir el filtro de log + un umbral de cantidad de coincidencias en la ventana.

Canales de notificación

Configurados en Settings → Notification Channels.

Canal Tipo Uso
Gerencia Email email Destino actual de todas las alertas

SigNoz también soporta Slack, PagerDuty, OpsGenie, MS Teams y webhook genérico si más adelante se quiere separar por equipo (infra / seguridad).