Guía completa de observabilidad: cómo monitorear servidores Linux, aplicaciones y contenedores

Idea clave: monitoreo te dice que algo falló; observabilidad te ayuda a entender por qué falló, dónde ocurrió y qué debes corregir.

Ejemplo práctico: si un sitio web está lento, el monitoreo puede decirte que la latencia subió. La observabilidad debe ayudarte a descubrir si la causa está en Nginx, la base de datos, el contenedor, el DNS, la red, una consulta pesada o una dependencia externa.

Preguntas iniciales

• ¿Qué servidores son críticos?
• ¿Qué aplicaciones deben estar siempre disponibles?
• ¿Qué contenedores procesan servicios importantes?
• ¿Qué bases de datos o APIs son sensibles a latencia?
• ¿Qué indicadores afectan directamente al usuario final?
• ¿Qué eventos deben generar alerta inmediata?
• ¿Quién recibe las alertas y cómo se responde?

sudo apt update
sudo apt upgrade -y

sudo apt install -y curl wget git htop ufw docker.io docker-compose-plugin

sudo systemctl enable --now docker
docker --version
docker compose version

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Consejo: no expongas Prometheus, Grafana, Loki o exporters directamente a Internet. Usa red interna, VPN, proxy inverso con HTTPS y autenticación.

mkdir observabilidad-linux
cd observabilidad-linux
mkdir prometheus grafana

cat > prometheus/prometheus.yml <<'EOF'
global:
  scrape_interval: 15s

scrape_configs:

* job_name: "prometheus"
  static_configs:

  * targets: ["prometheus:9090"]

* job_name: "node-exporter"
  static_configs:

  * targets: ["node-exporter:9100"]

* job_name: "cadvisor"
  static_configs:

  * targets: ["cadvisor:8080"]
    EOF

cat > docker-compose.yml <<'EOF'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: unless-stopped
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus_data:/prometheus

grafana:
image: grafana/grafana-oss:latest
container_name: grafana
restart: unless-stopped
ports:
- "3000:3000"
volumes:
- grafana_data:/var/lib/grafana

node-exporter:
image: prom/node-exporter:latest
container_name: node-exporter
restart: unless-stopped
pid: host
network_mode: host
command:
- "--path.rootfs=/host"
volumes:
- "/:/host:ro,rslave"

cadvisor:
image: gcr.io/cadvisor/cadvisor:latest
container_name: cadvisor
restart: unless-stopped
ports:
- "8080:8080"
volumes:
- "/:/rootfs:ro"
- "/var/run:/var/run:ro"
- "/sys:/sys:ro"
- "/var/lib/docker/:/var/lib/docker:ro"
- "/dev/disk/:/dev/disk:ro"

volumes:
prometheus_data:
grafana_data:
EOF

docker compose up -d
docker ps

http://IP_DEL_SERVIDOR:3000

1. Ingresa a Grafana.
2. Ve a Connections o Data sources.
3. Selecciona Prometheus.
4. Usa la URL interna: http://prometheus:9090.
5. Guarda y prueba la conexión.

100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100

100 - ((node_filesystem_avail_bytes{mountpoint="/"} * 100) / node_filesystem_size_bytes{mountpoint="/"})

rate(container_cpu_usage_seconds_total[5m])

Métricas recomendadas en aplicaciones

• Tiempo de respuesta promedio y percentiles.
• Tasa de errores HTTP 4xx y 5xx.
• Número de solicitudes por segundo.
• Uso de conexiones a base de datos.
• Latencia de consultas SQL.
• Colas pendientes.
• Errores por dependencia externa.
• Tiempo de inicio y reinicios inesperados.

Logs que conviene centralizar

• Logs de sistema: journalctl, syslog, auth.log.
• Logs de aplicaciones web.
• Logs de contenedores.
• Logs de proxy inverso, Nginx o Apache.
• Logs de bases de datos.
• Eventos de seguridad y autenticación.

sudo journalctl -p warning..alert -S today
sudo journalctl -u docker -S "1 hour ago"
sudo tail -f /var/log/auth.log

Las trazas ayudan cuando:

• Una API llama a otra API.
• Un frontend consume un backend.
• La aplicación consulta base de datos, cache y servicios externos.
• Hay microservicios o colas de mensajes.
• El problema ocurre solo en ciertas rutas o usuarios.
• La latencia no se explica con CPU o memoria.

Buena práctica: cada alerta debe tener dueño, severidad, canal de notificación y procedimiento de respuesta. Una alerta sin responsable es ruido.

Dashboards mínimos

• Servidor Linux: CPU, memoria, disco, red, carga, procesos.
• Contenedores: CPU, RAM, reinicios, red, I/O por contenedor.
• Aplicación web: latencia, errores, solicitudes, endpoints lentos.
• Base de datos: conexiones, consultas lentas, locks, uso de disco.
• Logs críticos: errores, autenticación, fallos repetidos, eventos recientes.
• Disponibilidad: uptime, endpoints, certificados, respuesta externa.

Señales que merecen investigación

• Intentos SSH fallidos repetidos.
• Servicios nuevos escuchando en puertos no autorizados.
• Uso de CPU alto sin explicación.
• Contenedores que se reinician constantemente.
• Errores 500 después de un despliegue.
• Logs borrados, incompletos o rotación anormal.
• Aumento inesperado de tráfico saliente.

Checklist recomendado

• Empieza con servidores críticos y aplicaciones principales.
• Define métricas de negocio y métricas técnicas.
• Instala Node Exporter en servidores Linux.
• Usa cAdvisor para contenedores.
• Centraliza logs con etiquetas claras.
• Instrumenta aplicaciones con OpenTelemetry cuando sea posible.
• Crea dashboards por rol, no uno gigante para todo.
• Configura alertas con umbrales realistas.
• Protege el acceso a Grafana y Prometheus.
• Documenta procedimientos de respuesta.
• Revisa alertas falsas y ajusta reglas.
• Incluye observabilidad en cada nuevo despliegue.

Evita estos errores

• Instalar herramientas sin objetivos claros.
• Medir demasiadas cosas sin priorizar.
• No proteger el acceso a dashboards.
• Crear alertas que nadie atiende.
• No monitorear contenedores individualmente.
• Guardar logs sin retención ni política de privacidad.
• No revisar consumo de almacenamiento de métricas y logs.
• No documentar qué significa cada dashboard.
• No probar alertas antes de producción.
• No correlacionar métricas, logs y trazas.

¿Qué debo instalar primero para observar servidores Linux?

Empieza con Prometheus, Grafana y Node Exporter. Con eso tendrás métricas básicas de CPU, memoria, disco, red y estado general del servidor.

¿Cómo monitoreo contenedores Docker?

Una forma práctica es usar cAdvisor para exponer métricas de contenedores y Prometheus para recolectarlas. Luego puedes visualizarlas en Grafana.

¿Prometheus guarda logs?

No es su función principal. Prometheus está orientado a métricas. Para logs puedes usar Loki, Fluent Bit u otra solución de centralización.

¿Cuándo necesito trazas?

Las trazas son útiles cuando tienes aplicaciones distribuidas, microservicios, APIs encadenadas o problemas de latencia difíciles de explicar solo con métricas.

¿Grafana reemplaza a Prometheus?

No. Grafana visualiza datos. Prometheus recolecta y almacena métricas. Normalmente trabajan juntos.

¿Debo monitorear todo?

No. Debes observar lo que permite tomar decisiones. Medir demasiado sin estrategia puede generar ruido, consumo innecesario y alertas inútiles.

¿La observabilidad ayuda a la seguridad?

Sí. Logs, métricas y alertas pueden revelar comportamientos anómalos, servicios inesperados, accesos sospechosos o degradación causada por incidentes.

• Cómo implementar monitoreo y observabilidad en infraestructuras Linux empresariales
• Las mejores herramientas de monitoreo para servidores Linux y entornos empresariales
• Qué es DevOps y cómo Linux se convierte en la base de la automatización moderna
• Cómo optimizar el rendimiento de un servidor Linux paso a paso

Conclusión editorial

Linux, contenedores y aplicaciones modernas necesitan visibilidad permanente. Una buena observabilidad reduce tiempos de diagnóstico, mejora la disponibilidad, fortalece la seguridad y permite que los equipos de TI pasen de reaccionar tarde a operar con evidencia.