0Pricing
Linux Command Line & Bash Scripting Mastery · Lección

Seguimiento de registros en tiempo real y alertas en streaming

Siga y filtre flujos de registros en directo para activar alertas en cuanto aparezcan patrones de error.

Seguimiento de registros en tiempo real y alertas en streaming es una lección gratuita de Linux Command Line & Bash Scripting Mastery en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Linux Command Line & Bash Scripting Mastery, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Linux Command Line & Bash Scripting Mastery incluye 4 lecciones en total.

Por qué es importante seguir los registros en tiempo real

En los sistemas de producción, los archivos de registro crecen continuamente. Esperar a que se notifique un problema antes de examinar los registros significa que el tiempo de inactividad ya le ha costado recursos. El seguimiento de registros en tiempo real le permite observar los eventos en el momento en que se escriben, lo que posibilita responder de inmediato a fallos, eventos de seguridad y degradaciones del rendimiento.

  • Los servidores web escriben una línea por solicitud; los errores aparecen al instante
  • Los daemons de aplicaciones registran los stack traces en el momento en que se produce una excepción
  • Los sistemas de autenticación registran los intentos fallidos de inicio de sesión en tiempo real

La herramienta Unix fundamental para esto es tail -f, combinada con utilidades de filtrado y alertas para convertir los flujos de registros sin procesar en señales útiles.

tail -f: seguimiento de un registro en directo

tail -f (follow) mantiene abierto el archivo e imprime las líneas nuevas a medida que se añaden. Es la herramienta de registros en tiempo real más sencilla y disponible de forma más universal.

Patrones de uso habituales:

  • tail -f /var/log/syslog — seguir el registro del sistema
  • tail -n 50 -f app.log — mostrar las últimas 50 líneas y seguir después
  • tail -f /var/log/nginx/access.log — seguir en directo las solicitudes de nginx

Pulse Ctrl+C para detenerlo. El proceso permanece conectado hasta que lo cancela o se cierra el terminal.

#!/usr/bin/env bash
# Simulate a live log and follow it
LOGFILE='/tmp/demo_app.log'

# Write a header
echo '[INFO] Application started' >> "$LOGFILE"

# In a real scenario you would run:
# tail -f "$LOGFILE"
# Below we demonstrate tail showing the last 3 lines then exit
tail -n 3 "$LOGFILE"

tail -F: sobrevivir a la rotación de registros

Muchos sistemas rotan los archivos de registro a medianoche o cuando alcanzan un límite de tamaño. Cuando esto sucede, se cambia el nombre del archivo original (por ejemplo, app.log.1) y se crea un nuevo app.log. Con tail -f, seguirá leyendo silenciosamente el archivo antiguo con el nuevo nombre y no verá ninguna salida nueva.

tail -F (F mayúscula) resuelve este problema al vigilar el nombre del archivo, no el descriptor de archivo. Cuando el archivo desaparece y vuelve a aparecer, tail -F lo abre de nuevo automáticamente y continúa siguiéndolo.

  • Prefiera siempre tail -F a tail -f en los scripts de producción
  • Funciona con logrotate, newsyslog y los controladores de registros de Docker que rotan archivos
# Follow nginx access log, surviving log rotation
tail -F /var/log/nginx/access.log

# Follow multiple files simultaneously
tail -F /var/log/nginx/access.log /var/log/nginx/error.log

Filtrar el flujo con grep

Seguir un registro activo sin filtrar resulta abrumador: un servidor web con mucha actividad puede escribir cientos de líneas por segundo. Envíe la salida de tail -F a grep para aislar únicamente los patrones que le interesan.

Opciones principales de grep para flujos:

  • --line-buffered — vacía cada línea coincidente inmediatamente en lugar de almacenarla en un búfer; es obligatorio en las canalizaciones, ya que, de lo contrario, la salida se retrasará o se perderá
  • -i — coincidencia sin distinguir mayúsculas de minúsculas
  • -E — expresión regular extendida para alternancia (error|warn|crit)
  • -v — invierte la coincidencia (excluye líneas)
# Show only ERROR and WARN lines from a live application log
tail -F /var/log/myapp/app.log | grep --line-buffered -Ei 'error|warn|critical'

# Follow nginx and exclude health-check requests
tail -F /var/log/nginx/access.log | grep --line-buffered -v '/health'

Añadir marcas de tiempo y contexto con awk

A veces, las líneas de registro carecen del contexto necesario para ayudar en la clasificación inicial del incidente. Puede enriquecer el flujo en tiempo real con awk: añadir una marca de tiempo local, extraer campos o reformatear la salida para facilitar su lectura.

awk también se ejecuta en modo de streaming (con búfer por línea) cuando se utiliza en una tubería, por lo que es seguro emplearlo en canalizaciones activas sin opciones adicionales.

# Prepend a reception timestamp to every ERROR line
tail -F /var/log/myapp/app.log | \
  grep --line-buffered -i 'error' | \
  awk '{ print strftime("[%Y-%m-%d %H:%M:%S]"), $0; fflush() }'

# Extract HTTP status code (field 9) and URL (field 7) from nginx combined log
tail -F /var/log/nginx/access.log | \
  awk '{ print $9, $7; fflush() }' | \
  grep --line-buffered '^5'

Enviar alertas con Slack Webhooks

Filtrar solo es la mitad del trabajo: cuando detecta un patrón de error, necesita notificar a alguien. Un webhook entrante de Slack le permite enviar un mensaje a un canal mediante una única llamada a curl, sin necesitar el SDK de Slack ni credenciales adicionales aparte de la URL del webhook.

El patrón es el siguiente: filtrar el flujo y enviar una solicitud HTTP POST por cada línea coincidente.

#!/usr/bin/env bash
# Real-time alert: send every ERROR line to a Slack channel
LOGFILE='/var/log/myapp/app.log'
WEBHOOK_URL='https://hooks.slack.com/services/T000/B000/XXXX'

tail -F "$LOGFILE" | grep --line-buffered -i 'error' | while IFS= read -r line; do
  payload=$(printf '{"text":"*[ERROR ALERT]*\n%s"}' "$line")
  curl -s -o /dev/null -X POST -H 'Content-Type: application/json' \
    -d "$payload" "$WEBHOOK_URL"
done

Limitar la frecuencia de las alertas para evitar ruido

Una avalancha de registros puede generar miles de líneas de error por minuto. Enviar un mensaje de Slack por cada línea inundará el canal y provocará fatiga por alertas. Necesita un límite de frecuencia: active la alerta y suprima las notificaciones posteriores durante un periodo de enfriamiento.

Esto se consigue con un archivo de marca de tiempo sencillo: registre cuándo se envió la última alerta y omita el envío si aún no ha transcurrido el periodo de enfriamiento.

#!/usr/bin/env bash
# Alert on ERROR lines but no more than once every 60 seconds
LOGFILE='/var/log/myapp/app.log'
WEBHOOK_URL='https://hooks.slack.com/services/T000/B000/XXXX'
COOLDOWN=60
LAST_ALERT_FILE='/tmp/last_alert_ts'

tail -F "$LOGFILE" | grep --line-buffered -i 'error' | while IFS= read -r line; do
  now=$(date +%s)
  last=0
  [ -f "$LAST_ALERT_FILE" ] && last=$(cat "$LAST_ALERT_FILE")

  if (( now - last >= COOLDOWN )); then
    echo "$now" > "$LAST_ALERT_FILE"
    payload=$(printf '{"text":"*[ERROR ALERT]*\n%s"}' "$line")
    curl -s -o /dev/null -X POST -H 'Content-Type: application/json' \
      -d "$payload" "$WEBHOOK_URL"
    echo "[$(date)] Alert sent: $line"
  else
    echo "[$(date)] Suppressed (cooldown): $line"
  fi
done

Contar ráfagas de errores con una ventana deslizante

A veces, una sola línea de error no es significativa, pero 20 errores en 30 segundos sí constituyen un problema grave. Un contador de ventana deslizante permite activar alertas únicamente cuando se supera un umbral de tasa de errores, reduciendo los falsos positivos.

La técnica guarda la marca de tiempo epoch de cada evento coincidente en un archivo temporal y, antes de decidir si debe enviar una alerta, cuenta cuántos eventos se encuentran dentro de la ventana.

#!/usr/bin/env bash
# Alert when more than 10 errors occur within any 60-second window
LOGFILE='/var/log/myapp/app.log'
WINDOW=60
THRESHOLD=10
TS_FILE='/tmp/error_timestamps'
WEBHOOK_URL='https://hooks.slack.com/services/T000/B000/XXXX'

tail -F "$LOGFILE" | grep --line-buffered -i 'error' | while IFS= read -r line; do
  now=$(date +%s)
  echo "$now" >> "$TS_FILE"

  # Keep only timestamps within the window
  cutoff=$(( now - WINDOW ))
  tmp=$(mktemp)
  awk -v c="$cutoff" '$1 > c' "$TS_FILE" > "$tmp" && mv "$tmp" "$TS_FILE"

  count=$(wc -l < "$TS_FILE")
  if (( count > THRESHOLD )); then
    msg="*[BURST ALERT]* ${count} errors in ${WINDOW}s — last: ${line}"
    curl -s -o /dev/null -X POST -H 'Content-Type: application/json' \
      -d "{\"text\":\"$msg\"}" "$WEBHOOK_URL"
    # Clear to avoid re-alerting until next burst
    > "$TS_FILE"
  fi
done

journalctl -f: seguimiento de los journals de systemd

En los sistemas Linux modernos (RHEL, Ubuntu 20.04+, Debian 10+), los servicios escriben en el journal de systemd en lugar de hacerlo en archivos de texto sin formato. journalctl -f es el equivalente de tail -F para el journal.

Opciones útiles:

  • -u myapp.service — seguir únicamente una unidad específica
  • -p err — filtrar por prioridad (emerg, alert, crit, err, warning, notice, info, debug)
  • --since '5 min ago' — comenzar desde un momento relativo
  • -o json — mostrar JSON estructurado para el procesamiento automático
# Follow only error-and-above entries for nginx
journalctl -f -u nginx.service -p err

# Stream journal as JSON and extract MESSAGE field with jq
journalctl -f -u myapp.service -o json | \
  jq --unbuffered -r 'select(.PRIORITY <= "3") | .MESSAGE'

multitail y supervisión multifuente con códigos de color

Cuando necesita observar varias fuentes de registros simultáneamente, multitail divide el terminal en paneles —cada uno sigue un archivo o comando diferente— y permite aplicar colores según el patrón.

Si multitail no está instalado, una alternativa ligera de BASH puro consiste en anteponer a cada flujo el nombre de su fuente y combinarlos en una sola vista.

# multitail: watch nginx access + error + app log in split panes
# (requires: apt install multitail  or  brew install multitail)
multitail /var/log/nginx/access.log /var/log/nginx/error.log /var/log/myapp/app.log

# Pure-Bash alternative — merge three streams with labeled prefixes
(
  tail -F /var/log/nginx/access.log | sed --unbuffered 's/^/[nginx-access] /' &
  tail -F /var/log/nginx/error.log  | sed --unbuffered 's/^/[nginx-error]  /' &
  tail -F /var/log/myapp/app.log    | sed --unbuffered 's/^/[myapp]        /' &
  wait
)

Crear un daemon de alertas autónomo

Al reunir todo lo aprendido en esta lección, un daemon de alertas preparado para producción debería:

  • Seguir el archivo de registro de forma robusta con tail -F
  • Filtrar patrones críticos con grep con búfer
  • Limitar la frecuencia de las notificaciones para evitar la fatiga por alertas
  • Registrar su propia actividad para que pueda auditar lo que se envió
  • Ejecutarse como proceso en segundo plano gestionado por systemd o un supervisor

El script siguiente es un daemon mínimo pero completo que puede colocar en /usr/local/bin/ y gestionar con systemd.

#!/usr/bin/env bash
# log_alert_daemon.sh — tail a log and fire Slack alerts with cooldown
set -euo pipefail

LOGFILE=${1:-'/var/log/myapp/app.log'}
PATTERN=${2:-'error|critical|fatal'}
WEBHOOK_URL=${SLACK_WEBHOOK_URL:?'Set SLACK_WEBHOOK_URL env var'}
COOLDOWN=${ALERT_COOLDOWN:-120}
DAEMON_LOG='/var/log/log_alert_daemon.log'
LAST_SENT_FILE='/tmp/log_alert_last_sent'

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$DAEMON_LOG"; }

log "Starting alert daemon: watching $LOGFILE for pattern: $PATTERN"

tail -F "$LOGFILE" | grep --line-buffered -Ei "$PATTERN" | while IFS= read -r line; do
  now=$(date +%s)
  last=0
  [ -f "$LAST_SENT_FILE" ] && last=$(cat "$LAST_SENT_FILE")

  if (( now - last >= COOLDOWN )); then
    echo "$now" > "$LAST_SENT_FILE"
    msg=$(printf '{"text":"*[ALERT]* %s\n%s"}' "$(hostname)" "$line")
    if curl -s -o /dev/null -w '%{http_code}' -X POST \
         -H 'Content-Type: application/json' -d "$msg" "$WEBHOOK_URL" | grep -q '^200$'; then
      log "Alert sent: $line"
    else
      log "Alert FAILED to send: $line"
    fi
  else
    log "Suppressed (cooldown ${COOLDOWN}s): $line"
  fi
done

Comprobación de conocimientos: canalizaciones de registros en streaming

Compruebe su comprensión del seguimiento de registros en tiempo real y las alertas en streaming.

Una canalización de Bash sigue un archivo de registro y envía una alerta de Slack por cada línea coincidente. Durante una avalancha de registros, se escriben 3.000 líneas de error en 10 segundos. ¿Qué cambio único evita mejor que el script inunde el canal de Slack con 3.000 mensajes?

Resumen de la lección: seguimiento de registros en tiempo real y alertas en streaming

En esta lección ha creado desde cero una canalización completa de observabilidad de registros en tiempo real:

  • tail -F sigue un archivo de registro por su nombre y sobrevive a la rotación de registros; prefiera siempre esta opción a tail -f en producción
  • grep --line-buffered filtra el flujo en directo sin introducir latencia; añada siempre esta opción en los comandos de grep usados en tuberías
  • awk con fflush() enriquece cada línea con marcas de tiempo o campos extraídos de forma segura para el streaming
  • Webhooks de Slack mediante curl envían alertas con una única solicitud HTTP POST, sin necesidad de un SDK
  • Los archivos de enfriamiento evitan la fatiga por alertas durante las avalanchas de registros al imponer un intervalo mínimo entre notificaciones
  • Los contadores de ventana deslizante detectan ráfagas de errores (alertas basadas en la tasa) en lugar de reaccionar a cada línea individual
  • journalctl -f es el equivalente nativo de systemd a tail -F, con filtrado de prioridades y salida JSON integrados
  • Un script daemon de alertas autónomo combina todos estos patrones y puede gestionarse mediante systemd para ofrecer fiabilidad en producción

Estas primitivas se combinan para formar la base de cualquier canalización de observabilidad personalizada, sin necesidad de un agente de terceros.

Preguntas frecuentes

¿La lección «Seguimiento de registros en tiempo real y alertas en streaming» es gratis?

Sí — el texto completo de «Seguimiento de registros en tiempo real y alertas en streaming» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Linux Command Line & Bash Scripting Mastery, actualiza a CoddyKit PRO. El curso de Linux Command Line & Bash Scripting Mastery incluye 4 lecciones en total.

¿Qué aprenderé en «Seguimiento de registros en tiempo real y alertas en streaming»?

Siga y filtre flujos de registros en directo para activar alertas en cuanto aparezcan patrones de error. Practicas Linux Command Line & Bash Scripting Mastery con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Linux Command Line & Bash Scripting Mastery?

No se requiere experiencia previa. Linux Command Line & Bash Scripting Mastery en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «Seguimiento de registros en tiempo real y alertas en streaming»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Linux Command Line & Bash Scripting Mastery?

Sí. Cada lección de Linux Command Line & Bash Scripting Mastery incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Análisis de registros web y de aplicaciones a gran escala
  2. Seguimiento de registros en tiempo real y alertas en streaming
  3. Consulta de journald con journalctl en scripts
  4. Cálculo de métricas e histogramas a partir de flujos de registros
← Volver a Linux Command Line & Bash Scripting Mastery