info-sistema.sh responia preguntes sobre un instant. Els registres responen preguntes sobre el temps: què va passar, quan va començar, quant va durar i si torna a passar. A Veloz Envíos hi ha dos fitxers que ningú no mira fins que alguna cosa falla —/var/log/veloz/acces.log i /var/log/veloz/app.log— i llavors algú obre un tail -f i endevina. Aquest projecte substitueix l'endevinació per analitza-logs.sh, l'eina més ambiciosa del curs en processament de text: agrega, dibuixa, detecta anomalies i emet un informe en text o JSON, sobre fitxers vius, rotats i comprimits.

1. Les preguntes que ha de respondre
2. Requisits i decisions de disseny
3. Llegir qualsevol registre: la funció obre_log
4. Versió 1: comptar codis de resposta
5. Per què awk per a acces.log i BASH_REMATCH per a app.log
6. Filtres per data i per nivell
7. Les agregacions en una sola passada
8. L'histograma per hores
9. Detecció d'anomalies
10. L'informe: text i JSON
11. Rendiment sobre un milió de línies
12. Anonimitzar abans de compartir

Un analitzador de registres no es dissenya llistant funcions, sinó escrivint les preguntes que algú farà a les tres de la matinada:

Requisits derivats: una sola passada per fitxer, suport de .1 i .2.gz, filtres per rang de dates i per nivell, sortida en text i JSON, i capacitat d'anonimitzar IP.

Tres decisions marquen tot l'script:

1. Una passada, no sis. La versió ingènua fa un grep per cada mètrica: sis lectures del fitxer. Amb awk i arrays associatius (06-01) es calcula tot en una. A 08-02 vam mesurar per què: sobre un registre gran, la diferència és d'un ordre de magnitud, i no per awk en si, sinó per llegir el disc una vegada en lloc de sis.
2. La lectura s'abstreu. La resta de l'script no ha de saber si el fitxer està comprimit: una funció obre_log retorna el flux i llestos.
3. Recollida i presentació separades, igual que a 09-01: awk produeix línies metrica<TAB>clau<TAB>valor, i els formatadors les converteixen en informe de text o en JSON.

Els registres rotats són acces.log, acces.log.1 i acces.log.2.gz. Tractar-los per separat duplicaria el codi; la solució és decidir el lector per l'extensió (05-01):

El case sobre el nom és la tècnica de 04-05 i evita executar file. Els -- protegeixen davant de noms que comencin per guionet (08-03). L'ordre d'expandeix_logs no és casual —de més antic a més nou, perquè l'informe surti cronològic sense haver d'ordenar després—. I es fa servir done < <(...) i no expandeix_logs | while per la raó de 05-05: en una canonada, el while corre en una subshell i qualsevol comptador que incrementi es perd en acabar.

La primera versió útil cap en una línia i ja respon a mitja pregunta: $9 és el codi de resposta en el format combinat. A partir d'aquí, cada millora afegeix una mètrica al mateix awk en lloc d'afegir un grep nou; aquest és tot el mètode de construcció d'aquesta lliçó.

Els dos fitxers tenen formats molt diferents i mereixen eines diferents:

acces.log és posicional: camps separats per espais, sempre el mateix nombre, la ruta a $7, el codi a $9, els bytes a $10. Això és exactament per al que existeix awk (06-01): partir per camps és gratis i el volum és alt.

app.log és semiestructurat: la part fixa és la data, l'hora i el nivell; la resta és prosa on el component apareix abans dels dos punts, però no sempre. Aquí convé una expressió regular amb captura (05-04):

La regla pràctica: awk quan el format és tabular i el volum alt; =~ amb BASH_REMATCH quan cal capturar trossos d'una línia irregular i decidir coses diferents segons el que s'ha capturat. I un advertiment mesurat a 08-02: aquest bucle processa unes 50.000 línies per segon, mentre que awk supera el milió. Per a app.log (milers de línies al dia) va de sobres; si creixés a milions, caldria portar el patró dins de l'awk.

Les opcions segueixen el patró de 09-01, amb una validació explícita de la data abans de fer-la servir:

Dues comprovacions perquè calen totes dues: la regex descarta 03/08/2026 i date -d descarta 2026-02-31, que té la forma correcta i no existeix. Filtrar per data amb comparació de cadenes ([[ $data < $DES_DE ]]) funciona només perquè el format AAAA-MM-DD ordena igual com a text que com a data; és la raó per la qual aquest format es va triar a 07-04 i una de les millors decisions que pot prendre qui dissenya un registre. A acces.log, en canvi, la data ve com a 03/Aug/2026, així que l'awk la normalitza amb una taula de mesos:

split amb una classe de caràcters com a separador (06-01) parteix [03/Aug/2026:10:15:22 d'una tacada, sense sed previ ni canonades addicionals.

El nucli del projecte viu a libexec/acces.awk, no en una cadena encastada entre cometes: així és més llegible, shellcheck no s'hi barallarà i es pot provar per separat.

Tota la feina passa en una sola lectura. sub(/\?.*/, "", ruta) agrupa la cadena de consulta, perquè si no /envios?ciudad=Valencia i /envios?ciudad=Madrid compten com a rutes diferents i el top-N s'omple de soroll. substr($9,1,1) "xx" converteix 503 en 5xx amb una operació de cadena en lloc d'una cascada d'if. I la sortida és el format intern de tres columnes: metrica, clau, valor, que en Bash es recull amb mapfile o es filtra amb awk -F'\t' '$1=="ruta"'.

Ordenar el top-N es fa fora, on és barat i amb les eines adequades: top_n() { awk -F'\t' -v m="$1" '$1 == m {print $3 "\t" $2}' "$CRU" | sort -rn | head -n "$2"; }.

Un número per hora s'entén malament; una barra s'entén d'un cop d'ull. La tècnica és escalar el valor màxim a una amplada fixa:

${f%%$'\t'*} i ${f##*$'\t'} parteixen la línia pel tabulador sense llançar cut (04-04, i l'estalvi de processos de 08-02). L'aritmètica entera val * amplada / max es fa multiplicant abans de dividir: a l'inrevés, val / max seria 0 per a tot i totes les barres sortirien buides, un dels errors clàssics de 04-06. I el max ? ... : 0 evita la divisió per zero quan el rang filtrat no té dades.

Tres deteccions simples cobreixen la majoria dels incidents reals de Veloz Envíos:

Comparar contra la mediana i no contra un número fix és el que fa que la detecció continuï sent vàlida quan el trànsit es dupliqui: un llindar absolut de «1000 peticions» s'ha de reajustar cada trimestre; «vint vegades la mediana» s'ajusta tot sol.

La tercera detecció, ràfega d'errors, es fa sobre app.log convertint l'hora a segons (04-06) i comprovant quants ERROR caben en una finestra:

mktime de GNU awk converteix 2026 08 03 10 15 22 a segons des de l'època, i gensub prepara aquest format substituint guionets i dos punts per espais (06-01). Restar posicions separades n-1 a l'array és la finestra lliscant més barata possible.

L'informe de text compon les peces ja construïdes; el JSON surt del mateix fitxer intermedi:

jq -Rn amb inputs llegeix línies crues (06-05), group_by agrupa per mètrica i from_entries converteix cada grup en un objecte. El tonumber? // .valor manté els números com a números i deixa les cadenes intactes —el ? evita que jq avorti davant d'un valor no numèric—. Que el JSON surti del mateix fitxer intermedi que el text garanteix que tots dos informes diguin el mateix, que és el motiu d'haver separat recollida i presentació en els dos projectes.

Amb un registre real generat per a la prova, les xifres de 08-02 es confirmen:

Un export LC_ALL=C a dalt de l'script gairebé divideix per dos el temps i no canvia cap resultat, perquè les IP, les dates i els codis són ASCII. Mesurar abans d'optimitzar continua sent la regla: aquí la mesura diu que el coll d'ampolla era el nombre de passades, no el llenguatge.

Una IP és una dada personal, i un informe que surt del servidor —a un tiquet, a un proveïdor, a un canal de xat— no n'ha de portar (08-03). lib/comu.sh ja té la peça:

Emmascara l'últim octet (06-02): es conserva la xarxa, que és el que serveix per detectar l'escaneig, i es perd l'identificador de l'individu. L'script ho aplica amb --anonimitza, i el runbook diu que qualsevol informe que surti de la infraestructura passa per aquesta opció. Compte amb l'ordre: s'anonimitza en presentar, no en recollir, perquè agrupar per IP truncada ajuntaria equips diferents.

• Un grep per mètrica. És la causa número u de lentitud. Si l'script recorre el fitxer més d'una vegada, hi ha una agregació que hauria d'estar dins de l'awk.
• Ordenar dins de l'awk. awk no garanteix l'ordre de for (k in array). Ordena fora amb sort -rn, o fes servir asorti si t'hi lligues a GNU awk.
• Oblidar els rotats. Una anàlisi dels «últims set dies» que només llegeix acces.log menteix així que hi hagi rotació diària. expandeix_logs no és cap luxe.
• Dividir abans de multiplicar a l'escala de l'histograma: totes les barres surten a zero (04-06). I no comparis dates ISO com a números: 2026-08-03 en aritmètica no és una data, compara-la com a cadena.
• Consell: desa el fitxer intermedi de tres columnes en un temporal amb mktemp i trap EXIT (05-02). Permet recalcular vistes diferents sense rellegir el registre i és el que fa possible que text i JSON coincideixin.

1. Top d'agents d'usuari. El format combinat porta el User-Agent a l'últim camp entre cometes. Afegeix la mètrica agent a l'awk agrupant per família (Chrome, Firefox, curl, bot) en lloc de per cadena completa.
2. Mode --segueix. Afegeix un mode que analitzi en temps real amb tail -f, mostrant cada 10 segons les peticions de l'últim minut i avisant si la taxa de 5xx supera el llindar.
3. Primera i última aparició. Afegeix --patro REGEX que informi de quantes vegades apareix el patró, amb la seva primera i última marca de temps.

1. Dins de l'awk, l'agent és l'últim camp compost; s'extreu amb una regex sobre $0 i es classifica amb una cascada:

Agrupar per família és el que fa útil el top: sense agrupar, cada versió menor de Chrome seria una fila diferent.

2. El mode segueix no pot fer servir l'awk amb END, perquè END no arriba mai. Es processa per finestres:

Es fa servir tail -F (majúscula) i no -f: segueix el fitxer pel nom, així que sobreviu a la rotació de logrotate, exactament l'escenari de 07-04.

3. --patro es resol amb un awk de tres línies: $0 ~ p { n++; if (pri=="") pri = marca; ult = marca } END { print n, pri, ult }, passant el patró amb -v p="$PATRO" i mai interpolant-lo dins del programa, que seria la injecció de 08-03 aplicada a awk.

analitza-logs.sh ja respon les sis preguntes de l'apartat 1 sobre fitxers vius, rotats i comprimits, amb filtres per data i nivell, histograma, tres deteccions d'anomalia i informe en text i JSON. Les lliçons del projecte són quatre. Una sola passada: el cost és en rellegir el fitxer, no en el llenguatge, i la mesura de 08-02 ho va confirmar amb un factor de deu. Cada eina en el seu format: awk per al que és tabular i voluminós, BASH_REMATCH per capturar de línies irregulars on cal decidir. Un format intermedi explícit (metrica<TAB>clau<TAB>valor) que permet que l'informe de text i el JSON no puguin contradir-se. I anonimitzar en presentar, no en recollir, per no perdre la informació que fa falta per detectar l'atac. Pel camí s'han fet servir zcat i comodins de rotats (05-01), done < <(...) (05-05), expansions de cadena en lloc de cut (04-04), aritmètica entera amb cura de l'ordre (04-06), jq -Rn amb group_by (06-05) i sed -E per a l'emmascarament (06-02).

A 09-03 canvia el risc. Un informe equivocat es corregeix; una còpia de seguretat equivocada es descobreix el dia que cal restaurar i ja no hi ha res a fer. Portarem copia.sh —l'esbós de 07-03— a un sistema complet amb perfils configurables, manifest i verificació, retenció amb promoció, còpia remota, xifratge i una prova de restauració automàtica setmanal, sota el principi que una còpia de seguretat no verificada no existeix.