info-sistema.sh respondía preguntas sobre un instante. Los logs responden preguntas sobre el tiempo: qué pasó, cuándo empezó, cuánto duró y si vuelve a pasar. En Veloz Envíos hay dos ficheros que nadie mira hasta que algo falla —/var/log/veloz/acceso.log y /var/log/veloz/app.log— y entonces alguien abre un tail -f y adivina. Este proyecto sustituye la adivinación por analiza-logs.sh, la herramienta más ambiciosa del curso en procesamiento de texto: agrega, dibuja, detecta anomalías y emite un informe en texto o JSON, sobre ficheros vivos, rotados y comprimidos.

1. Las preguntas que debe responder
2. Requisitos y decisiones de diseño
3. Leer cualquier log: la función abre_log
4. Versión 1: contar códigos de respuesta
5. Por qué awk para acceso.log y BASH_REMATCH para app.log
6. Filtros por fecha y por nivel
7. Las agregaciones en una sola pasada
8. El histograma por horas
9. Detección de anomalías
10. El informe: texto y JSON
11. Rendimiento sobre un millón de líneas
12. Anonimizar antes de compartir

Un analizador de logs no se diseña listando funciones, sino escribiendo las preguntas que alguien hará a las tres de la mañana:

Requisitos derivados: una sola pasada por fichero, soporte de .1 y .2.gz, filtros por rango de fechas y por nivel, salida en texto y JSON, y capacidad de anonimizar IPs.

Tres decisiones marcan todo el script:

1. Una pasada, no seis. La versión ingenua hace un grep por cada métrica: seis lecturas del fichero. Con awk y arrays asociativos (06-01) se calcula todo en una. En 08-02 medimos por qué: sobre un log grande, la diferencia es de un orden de magnitud, y no por awk en sí, sino por leer el disco una vez en lugar de seis.
2. La lectura se abstrae. El resto del script no debe saber si el fichero está comprimido: una función abre_log devuelve el flujo y ya está.
3. Recolección y presentación separadas, igual que en 09-01: awk produce líneas metrica<TAB>clave<TAB>valor, y los formateadores las convierten en informe de texto o en JSON.

Los logs rotados son acceso.log, acceso.log.1 y acceso.log.2.gz. Tratarlos por separado duplicaría el código; la solución es decidir el lector por la extensión (05-01):

El case sobre el nombre es la técnica de 04-05 y evita ejecutar file. Los -- protegen ante nombres que empiecen por guion (08-03). El orden de expande_logs no es casual —de más antiguo a más nuevo, para que el informe salga cronológico sin ordenar después—. Y se usa done < <(...) y no expande_logs | while por la razón de 05-05: en una tubería, el while corre en una subshell y cualquier contador que incremente se pierde al terminar.

La primera versión útil cabe en una línea y ya responde a media pregunta: $9 es el código de respuesta en el formato combinado. A partir de aquí, cada mejora añade una métrica al mismo awk en lugar de añadir un grep nuevo; ese es todo el método de construcción de esta lección.

Los dos ficheros tienen formatos muy distintos y merecen herramientas distintas:

acceso.log es posicional: campos separados por espacios, siempre el mismo número, la ruta en $7, el código en $9, los bytes en $10. Eso es exactamente para lo que existe awk (06-01): partir por campos es gratis y el volumen es alto.

app.log es semiestructurado: la parte fija es la fecha, la hora y el nivel; el resto es prosa donde el componente aparece antes de los dos puntos, pero no siempre. Aquí conviene una expresión regular con captura (05-04):

La regla práctica: awk cuando el formato es tabular y el volumen alto; =~ con BASH_REMATCH cuando hay que capturar trozos de una línea irregular y decidir cosas distintas según lo capturado. Y una advertencia medida en 08-02: este bucle procesa unas 50.000 líneas por segundo, mientras awk supera el millón. Para app.log (miles de líneas al día) sobra; si creciera a millones, habría que llevar el patrón dentro de awk.

Las opciones siguen el patrón de 09-01, con una validación explícita de la fecha antes de usarla:

Dos comprobaciones porque hacen falta las dos: la regex descarta 03/08/2026 y date -d descarta 2026-02-31, que tiene forma correcta y no existe. Filtrar por fecha con comparación de cadenas ([[ $fecha < $DESDE ]]) funciona solo porque el formato AAAA-MM-DD ordena igual como texto que como fecha; es la razón por la que ese formato se eligió en 07-04 y una de las mejores decisiones que puede tomar quien diseña un log. En acceso.log, en cambio, la fecha viene como 03/Aug/2026, así que el awk la normaliza con una tabla de meses:

split con una clase de caracteres como separador (06-01) parte [03/Aug/2026:10:15:22 de una vez, sin sed previo ni tuberías adicionales.

El núcleo del proyecto vive en libexec/acceso.awk, no en una cadena embebida entre comillas: así es más legible, shellcheck no se pelea con él y se puede probar por separado.

Todo el trabajo ocurre en una lectura. sub(/\?.*/, "", ruta) agrupa la cadena de consulta, porque si no /envios?ciudad=Valencia y /envios?ciudad=Madrid cuentan como rutas distintas y el top-N se llena de ruido. substr($9,1,1) "xx" convierte 503 en 5xx con una operación de cadena en lugar de una cascada de if. Y la salida es el formato interno de tres columnas: metrica, clave, valor, que en Bash se recoge con mapfile o se filtra con awk -F'\t' '$1=="ruta"'.

Ordenar el top-N se hace fuera, donde es barato y con las herramientas adecuadas: top_n() { awk -F'\t' -v m="$1" '$1 == m {print $3 "\t" $2}' "$CRUDO" | sort -rn | head -n "$2"; }.

Un número por hora se entiende mal; una barra se entiende de un vistazo. La técnica es escalar el valor máximo a un ancho fijo:

${f%%$'\t'*} y ${f##*$'\t'} parten la línea por el tabulador sin lanzar cut (04-04, y el ahorro de procesos de 08-02). La aritmética entera val * ancho / max se hace multiplicando antes de dividir: al revés, val / max sería 0 para todo y todas las barras saldrían vacías, uno de los errores clásicos de 04-06. Y el max ? ... : 0 evita la división por cero cuando el rango filtrado no tiene datos.

Tres detecciones simples cubren la mayoría de los incidentes reales de Veloz Envíos:

Comparar contra la mediana y no contra un número fijo es lo que hace que la detección siga siendo válida cuando el tráfico se duplique: un umbral absoluto de «1000 peticiones» hay que reajustarlo cada trimestre; «veinte veces la mediana» se ajusta solo.

La tercera detección, ráfaga de errores, se hace sobre app.log convirtiendo la hora a segundos (04-06) y comprobando cuántos ERROR caben en una ventana:

mktime de GNU awk convierte 2026 08 03 10 15 22 a segundos desde época, y gensub prepara ese formato sustituyendo guiones y dos puntos por espacios (06-01). Restar posiciones separadas n-1 en el array es la ventana deslizante más barata posible.

El informe de texto compone las piezas ya construidas; el JSON sale del mismo fichero intermedio:

jq -Rn con inputs lee líneas crudas (06-05), group_by agrupa por métrica y from_entries convierte cada grupo en un objeto. El tonumber? // .valor mantiene los números como números y deja las cadenas intactas —el ? evita que jq aborte ante un valor no numérico—. Que el JSON salga del mismo fichero intermedio que el texto garantiza que ambos informes digan lo mismo, que es el motivo de haber separado recolección y presentación en los dos proyectos.

Con un log real generado para la prueba, las cifras de 08-02 se confirman:

Un export LC_ALL=C arriba del script casi divide por dos el tiempo y no cambia ningún resultado, porque las IPs, las fechas y los códigos son ASCII. Medir antes de optimizar sigue siendo la regla: aquí la medición dice que el cuello de botella era el número de pasadas, no el lenguaje.

Una IP es un dato personal, y un informe que sale del servidor —a un ticket, a un proveedor, a un canal de chat— no debe llevarlas (08-03). lib/comun.sh ya tiene la pieza:

Enmascara el último octeto (06-02): se conserva la red, que es lo que sirve para detectar el escaneo, y se pierde el identificador del individuo. El script lo aplica con --anonimizar, y el runbook dice que cualquier informe que salga de la infraestructura pasa por esa opción. Ojo con el orden: se anonimiza al presentar, no al recolectar, porque agrupar por IP truncada juntaría equipos distintos.

• Un grep por métrica. Es la causa número uno de lentitud. Si el script recorre el fichero más de una vez, hay una agregación que debería estar dentro del awk.
• Ordenar dentro de awk. awk no garantiza el orden de for (k in array). Ordena fuera con sort -rn, o usa asorti si te atas a GNU awk.
• Olvidar los rotados. Un análisis de «los últimos siete días» que solo lee acceso.log miente en cuanto haya rotación diaria. expande_logs no es un lujo.
• Dividir antes de multiplicar en la escala del histograma: todas las barras salen a cero (04-06). Y no compares fechas ISO como números: 2026-08-03 en aritmética no es una fecha, compárala como cadena.
• Consejo: guarda el fichero intermedio de tres columnas en un temporal con mktemp y trap EXIT (05-02). Permite recalcular vistas distintas sin releer el log y es lo que hace posible que texto y JSON coincidan.

1. Top de agentes de usuario. El formato combinado lleva el User-Agent en el último campo entre comillas. Añade la métrica agente al awk agrupando por familia (Chrome, Firefox, curl, bot) en lugar de por cadena completa.
2. Modo --seguir. Añade un modo que analice en tiempo real con tail -f, mostrando cada 10 segundos las peticiones del último minuto y avisando si la tasa de 5xx supera el umbral.
3. Primera y última aparición. Añade --patron REGEX que informe de cuántas veces aparece el patrón, con su primera y última marca de tiempo.

1. Dentro del awk, el agente es el último campo compuesto; se extrae con una regex sobre $0 y se clasifica con una cascada:

Agrupar por familia es lo que hace útil el top: sin agrupar, cada versión menor de Chrome sería una fila distinta.

2. El modo seguir no puede usar el awk con END, porque END nunca llega. Se procesa por ventanas:

Se usa tail -F (mayúscula) y no -f: sigue el fichero por nombre, así que sobrevive a la rotación de logrotate, exactamente el escenario de 07-04.

3. --patron se resuelve con un awk de tres líneas: $0 ~ p { n++; if (pri=="") pri = marca; ult = marca } END { print n, pri, ult }, pasando el patrón con -v p="$PATRON" y nunca interpolándolo en el programa, que sería la inyección de 08-03 aplicada a awk.

analiza-logs.sh responde ya las seis preguntas del apartado 1 sobre ficheros vivos, rotados y comprimidos, con filtros por fecha y nivel, histograma, tres detecciones de anomalía e informe en texto y JSON. Las lecciones del proyecto son cuatro. Una sola pasada: el coste está en releer el fichero, no en el lenguaje, y la medición de 08-02 lo confirmó con un factor de diez. Cada herramienta en su formato: awk para lo tabular y voluminoso, BASH_REMATCH para capturar de líneas irregulares donde hay que decidir. Un formato intermedio explícito (metrica<TAB>clave<TAB>valor) que permite que el informe de texto y el JSON no puedan contradecirse. Y anonimizar al presentar, no al recolectar, para no perder la información que hace falta para detectar el ataque. Por el camino se han usado zcat y globbing de rotados (05-01), done < <(...) (05-05), expansiones de cadena en lugar de cut (04-04), aritmética entera con cuidado del orden (04-06), jq -Rn con group_by (06-05) y sed -E para el enmascarado (06-02).

En 09-03 cambia el riesgo. Un informe equivocado se corrige; un respaldo equivocado se descubre el día que hay que restaurar y ya no hay nada que hacer. Llevaremos respaldo.sh —el esbozo de 07-03— a un sistema completo con perfiles configurables, manifiesto y verificación, retención con promoción, copia remota, cifrado y una prueba de restauración automática semanal, bajo el principio de que un respaldo no verificado no existe.