Ampliando la Monitorización de Servicios Web

Después de integrar con éxito la monitorización de nuestra infraestructura core (servidores, redes, etc.), era el momento de elevar el juego. En esta ocasión, la misión era llevar la observabilidad al siguiente nivel, centrándonos en los servicios críticos de nuestra aplicación web. El objetivo: unificar métricas, logs y trazas en un solo lugar. Así, en lugar de saltar entre herramientas cuando un servicio falla, tenemos un «centro de mando» que no solo nos avisa, sino que nos explica el porqué del problema.

—

Objetivo: El «cuadro de mandos» perfecto

Al igual que hicimos con la infraestructura, definimos una serie de objetivos claros para este proyecto. Como técnicos de sistemas, queríamos visualizar en un mismo panel de Grafana:

• Métricas clave: Latencia, códigos de estado HTTP y disponibilidad de cada servicio.
• Logs en vivo: Correlacionar errores y eventos del sistema en tiempo real.
• Flexibilidad total: Dashboards clonables y etiquetados de forma consistente con host, service y role.
• Retención: Un mínimo de 30 días de datos en InfluxDB y Loki.
• Robustez: Contenedores de monitorización que se recuperan automáticamente tras un fallo o reinicio.

—

Naming conventions: La clave para no volverse loco

Para asegurar que nuestros dashboards fueran consistentes y fáciles de gestionar, establecimos una serie de reglas de etiquetado (o «naming conventions») desde el principio. Al igual que en la entrada sobre infraestructura, estas etiquetas actúan como variables que podemos usar para filtrar y buscar la información que necesitamos en segundos. Estas son las que utilizamos:

• host: El nombre del servidor o máquina virtual (ej. web-01, db-prod-02).
• service: El nombre de la aplicación o microservicio (ej. myapp, crm-api).
• role: La función del componente (ej. httpd, database, api-gateway).
• job: El trabajo o proceso de recolección de datos (ej. web_access, system_metrics).

Seguir estas reglas es fundamental para poder crear dashboards que, con un par de clics, se adapten para mostrar los datos de cualquier servicio o máquina, sin tener que editarlos manualmente.

—

Integrando los logs con Promtail y Loki

Para poder tener los logs en vivo dentro de Grafana, el primer paso fue instalar Promtail en nuestros servidores. Promtail es un agente ligero que lee los logs de los archivos y los envía a Loki, el agregador de logs de Grafana.

La instalación es muy sencilla. Primero, descargamos el binario y lo movemos a la ruta correcta. Después, creamos un usuario dedicado y un servicio de systemd para que se ejecute en segundo plano y se reinicie solo en caso de fallo.

# Descargamos, instalamos el binario y lo hacemos ejecutable
curl -L -o promtail-linux-amd64.zip https://github.com/grafana/loki/releases/download/v2.X.X/promtail-linux-amd64.zip
unzip promtail-linux-amd64.zip
chmod +x promtail-linux-amd64
mv promtail-linux-amd64 /usr/local/bin/promtail

# Creamos un usuario de sistema para Promtail
useradd --system --no-create-home --shell /usr/sbin/nologin promtail

# Configuramos el servicio en systemd para que arranque solo
cat < /etc/systemd/system/promtail.service
[Unit]
Description=Promtail service
After=network.target

[Service]
User=promtail
ExecStart=/usr/local/bin/promtail --config.file=/etc/promtail/config.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

# Activamos el servicio
systemctl daemon-reload
systemctl enable --now promtail

Una vez que el servicio estaba corriendo, solo teníamos que configurar el archivo /etc/promtail/config.yaml para que supiera a dónde enviar los logs (nuestra instancia de Loki) y cómo etiquetar cada línea con las naming conventions que habíamos definido.

Con esto, cada línea de log de nuestros servidores se etiqueta con la información del servicio, el host y el rol, lo que nos permite filtrarla de forma increíblemente rápida y precisa desde Grafana.

—

El resultado: Dashboards que hablan por sí solos

Con todos los datos fluyendo, la parte final fue montar los dashboards. Creamos paneles que combinaban las métricas de respuesta HTTP con un panel de logs en tiempo real. Así, si vemos un pico de errores 500, podemos ver al mismo tiempo las líneas de log que lo causaron. Es una forma de pasar de la simple notificación a la comprensión del problema.

¿Te ha gustado este enfoque? Si quieres llevar la observabilidad de tus servicios al siguiente nivel, no dudes en contactarnos. Juntos, podemos construir un sistema de monitorización que te dé el control total sobre tu infraestructura y tus aplicaciones.