En tancar la lliçó anterior va quedar plantejada una pregunta que les mètriques no poden respondre. Quan ApiReservesTaxaErrorAlta dispara a les 03:14, sabem que el 7 % de les peticions falla, en quina ruta i amb quina latència. El que no sabem és per què: l'excepció concreta, el missatge que va retornar PostgreSQL, la línia de codi que va petar. Això no viu en una mètrica. Viu en els logs.

I avui, a Rutas Norte, els logs són un desastre organitzat: estan repartits pels nodes, es perden quan un pod es recrea, no hi ha manera de buscar entre components i desapareixen del tot si el node mor. En aquesta lliçó muntem la pila completa que vam anunciar a 06-02 en desplegar el recol·lector com a DaemonSet: Elasticsearch, Fluentd i Kibana. Veurem com funciona el registre a Kubernetes per sota, com es recullen i s'enriqueixen els logs, per què el JSON estructurat és la decisió que més millora tot el sistema, i —crític per a una plataforma que desa el DNI i el telèfon dels seus clients— què no ha d'acabar mai escrit en un log.

1. Per què kubectl logs no basta
2. Com funciona el registre a Kubernetes per sota
3. kubectl logs a fons: l'eina de primera línia i els seus límits
4. L'arquitectura del patró de recol·lecció per node
5. Fluentd davant de Fluent Bit
6. La configuració real del recol·lector
7. Elasticsearch: índexs, plantilles i cicle de vida
8. Kibana: patró d'índex, KQL i quadre de comandament d'errors
9. Logs estructurats en JSON: la decisió que més rendibilitat dóna
10. Correlació entre logs i mètriques
11. Què NO s'ha de registrar mai
12. Alternatives més lleugeres i el cost real d'una pila de registre
13. Errors comuns i consells
14. Exercicis

kubectl logs és la primera eina que vam aprendre a 01-05 i continua sent utilíssima. Però té quatre límits estructurals que la fan insuficient tan bon punt la plataforma creix.

Es perd en recrear el pod. Els logs d'un contenidor viuen al sistema de fitxers del node, associats al pod. Quan el pod s'esborra —un desplegament, un desallotjament, un escalat— els fitxers s'esborren amb ell. Si api-reserves va entrar en CrashLoopBackOff a les 03:14 i a les 08:00 algú ja l'havia reiniciat a mà, l'evidència ha desaparegut.

No busca entre components. Un client reporta que la seva compra va fallar. La petició va passar per botiga-web, després per api-reserves, que va consultar redis-cache i postgres-reserves, va cridar la passarel·la externa i va encuar un missatge per a worker-notificacions. Això són sis kubectl logs diferents, en pods diferents, cadascun amb el seu propi format i sense cap manera de saber quina línia d'un correspon a quina línia de l'altre.

No correlaciona. Encara que obris les sis terminals, hauràs de quadrar marques de temps a ull. Amb sis rèpliques d'api-reserves ni tan sols saps en quina va caure la petició.

Desapareix amb el node. Si rutas-norte-worker-2 mor, tots els seus logs moren amb ell. I precisament quan un node mor és quan més falta fan.

A aquests quatre se n'hi suma un de governança: no hi ha retenció definida ni control d'accés granular. Qualsevol amb permís pods/log veu tot el que escriuen les aplicacions, inclosos els que no haurien de ser-hi. Hi tornarem a l'apartat 11.

Abans de recollir res cal entendre on són físicament els logs. Sense això, la configuració del recol·lector és màgia.

Kubernetes no defineix cap API de logs per a les aplicacions. El contracte és el de Docker i el dels dotze factors:

L'aplicació escriu els seus logs a la sortida estàndard (stdout) i a la d'error (stderr). No gestiona fitxers, ni rotació, ni destinacions.

Una aplicació que escriu a /var/log/laplicacio.log dins del contenidor ho està fent malament: aquell fitxer és invisible per a Kubernetes, creix sense control dins del contenidor i desapareix en reiniciar-se.

1. El procés escriu una línia a stdout.
2. El runtime de contenidors (containerd o CRI-O) captura aquella sortida.
3. El runtime l'escriu en un fitxer del node, en format CRI.
4. El kubelet gestiona aquell fitxer: el rota i crea enllaços simbòlics amb nom parlant.
5. kubectl logs demana al kubelet que llegeixi aquell fitxer i el retorna.

Entrem en un node del nostre minikube a mirar-los:

El nom del fitxer és la clau de tot. La seva estructura és:

D'aquí el recol·lector extreu, sense consultar ningú, el pod, el namespace i el contenidor de cada línia. És el que fa possible l'enriquiment de l'apartat 6.

Fixa't també que postgres-reserves-0 té dos fitxers: un pel contenidor postgres i un altre pel sidecar exportador-pg que vam afegir a 06-04. Cada contenidor té el seu propi flux de logs.

Cada línia té quatre camps separats per espais:

L'etiqueta P apareix quan una línia supera els 16 KB: el runtime la parteix. Un recol·lector mal configurat tractarà cada tros com una línia diferent. Fluentd i Fluent Bit saben reassemblar-les, però cal activar-ho.

Sense rotació, un contenidor xerraire ompliria el disc del node i provocaria desallotjaments de pods. El kubelet la gestiona amb dos paràmetres de la seva configuració:

Amb els valors per defecte, cada contenidor conserva com a màxim 50 MB de logs al node. api-reserves sota càrrega genera uns 200 MB al dia per rèplica: això significa que conserva menys de sis hores d'història.

Conseqüència directa i molt concreta: si l'incident va passar a les 03:14 i ho mires a les 11:00, els logs ja s'han rotat i ja no existeixen, encara que el pod no s'hagi reiniciat. És una raó addicional, juntament amb les quatre de l'apartat 1, per centralitzar.

Encara que muntem EFK, kubectl logs continua sent el primer que s'executa davant d'un problema. Val la pena dominar-lo.

El flag --prefix anteposa el nom del pod a cada línia, imprescindible en fer servir -l:

Combinacions útils al dia a dia:

Regla d'ús: kubectl logs per al que està passant ara; la pila centralitzada per al que va passar.

Hi ha tres maneres de recollir logs a Kubernetes. Només una és la bona per al cas general.

Triem el primer, i ja el tenim desplegat: a 06-02, en estudiar DaemonSets, vam desplegar un recol·lector de logs amb un pod per node, tolerations per al pla de control i un hostPath muntat sobre /var/log/containers, anunciant que la pila completa es muntaria aquí. Ha arribat el moment.

Les quatre responsabilitats del recol·lector:

1. Llegir els fitxers de /var/log/containers/, seguint les escriptures noves i recordant per on anava després d'un reinici.
2. Parsejar el format CRI i, si el contingut és JSON, expandir-lo en camps.
3. Enriquir amb les metadades de Kubernetes: namespace, pod, contenidor, node, etiquetes i anotacions del pod. Aquestes no són al fitxer: s'obtenen consultant l'API a partir del nom del fitxer.
4. Enviar al magatzem, amb buffer i reintents per no perdre res si la destinació cau.

L'enriquiment és el que converteix una línia de text en un document consultable:

Ara sí que es pot buscar "tots els errors d'api-reserves a pro entre les 03:00 i les 04:00", que és el que necessitàvem.

Hem posat un agregador entre els agents i Elasticsearch. No és obligatori, però en producció es justifica:

• Els agents de node (Fluent Bit) es queden lleugeríssims: només llegir i reenviar.
• El parseig pesat, l'emmascarament de dades sensibles i l'encaminament es fan en un sol lloc, més fàcil d'auditar i de canviar.
• Elasticsearch rep connexions de 3 agregadors en lloc de 30 agents, cosa que redueix molt la pressió.
• L'agregador fa d'amortidor: si Elasticsearch cau mitja hora, el buffer de l'agregador reté les dades.

Tots dos són projectes de la CNCF i de la mateixa família. La confusió sobre quin fer servir és constant.

La regla pràctica que segueix la indústria:

Fluent Bit com a agent a cada node (DaemonSet): consumeix gairebé res, i multiplicat per 30 nodes aquesta diferència importa molt.

Fluentd com a agregador central (Deployment): on cal la flexibilitat dels mil plugins, l'encaminament complex i les transformacions cares.

Per a Rutas Norte amb tres nodes, honestament, Fluent Bit sol n'hi hauria prou. Muntem els dos nivells perquè l'emmascarament de dades personals de l'apartat 11 es beneficia molt de centralitzar-se, i perquè és l'arquitectura que trobaràs en qualsevol clúster seriós.

Comparació de cost al nostre clúster:

Recuperem i completem el DaemonSet de 06-02:

Nota de seguretat, que reprendrem al mòdul 8. Aquest DaemonSet munta hostPath sobre el sistema de fitxers del node. Encara que sigui en només lectura, qualsevol que pugui executar un exec en aquest pod pot llegir els logs de tots els contenidors del node, inclosos els d'altres namespaces. El recol·lector és un objectiu d'alt valor: ha de tenir el seu propi namespace, RBAC mínim i accés molt restringit.

Aquest és el detall que més frustració causa i que més s'agraeix resoldre.

Una excepció de Node.js arriba al log així:

Per al runtime són cinc línies independents. Sense el filtre multilínia, Elasticsearch rep cinc documents:

• Un amb Error: connection pool exhausted, sense cap traça.
• Quatre amb fragments de traça, sense cap context de quin error els va produir.

I a Kibana, ordenats per data entre els logs d'altres cinc pods, resulta impossible reconstruir l'excepció. Amb vint línies de traça, el problema es multiplica.

El filtre multiline reconeix que les línies que comencen per espais i at són continuació de l'anterior i les uneix en un sol document amb la traça completa en un camp. És la diferència entre poder depurar i no poder.

El paràmetre retry_forever true en producció i false fora d'ella és una decisió de disseny conscient: perdre logs de rutas-norte-dev durant una caiguda d'Elasticsearch és acceptable; perdre els de producció, no.

El recol·lector és infraestructura crítica: si falla en silenci, et quedes sense logs sense assabentar-te'n.

I l'alerta corresponent, amb el criteri de 07-04:

Elasticsearch és un motor de cerca distribuït que indexa documents JSON. Per al nostre cas, cada línia de log enriquida és un document.

Els logs són dades temporals que envelleixen: els d'avui es consulten constantment, els de fa tres setmanes gairebé mai, i els de fa un any probablement mai. Per això no es desen tots en un índex, sinó en índexs per dia:

Avantatges decisius d'aquesta divisió:

• Esborrar és instantani. Eliminar un índex sencer és una operació de metadades. Esborrar documents solts dins d'un índex gran és lentíssim i costós.
• Les consultes per data només toquen els índexs necessaris. Buscar a les últimes 24 hores no recorre 30 dies de dades.
• Cada índex pot tenir configuració diferent: els recents en discos ràpids, els antics comprimits.

Una plantilla defineix com es configura qualsevol índex nou que coincideixi amb un patró. Sense ella, Elasticsearch endevina els tipus de cada camp, i endevina malament.

La distinció entre keyword i text és fonamental i confon tothom:

Si nivell fos text, no podries fer una agregació "quants logs per nivell", que és exactament el que vols en un quadre de comandament. Si missatge fos keyword, no podries buscar "pool" dins de "connection pool exhausted".

refresh_interval: 30s és un ajust de rendiment important: per defecte és 1 segon, cosa que obliga Elasticsearch a fer visible cada document gairebé a l'instant, a un cost alt. Per a logs, 30 segons de retard és perfectament acceptable i multiplica el rendiment d'escriptura.

La gestió del cicle de vida d'índexs automatitza l'envelliment. Sense ella, algú ha de recordar-se d'esborrar índexs antics, i ningú se'n recorda fins que el disc s'omple.

El punt crític: la fase d'esborrat. Els 30 dies no són un número tècnic, és una decisió de negoci i de compliment normatiu. Si els logs contenen dades personals (que no haurien, però és el que passa a la pràctica), la retenció s'ha d'ajustar al que exigeixi la normativa aplicable i al que hagi definit el responsable de protecció de dades de l'empresa. Hi tornem a l'apartat 11.

Aquesta és la part que se subestima sempre.

I el mínim de recursos de còmput:

Elasticsearch necessita tres nodes, no un. Amb un sol node no hi ha tolerància a errors i la pila de logs cau sencera quan aquell pod es reinicia. Amb dos hi ha risc de cervell dividit (split-brain). Tres és el mínim real.

Regla d'or del heap: assigna com a màxim el 50 % de la memòria del contenidor i mai més de 31 GB (per sobre d'aquest llindar la JVM perd la compressió de punters i rendeix pitjor amb més memòria).

Total aproximat: 24 GB de RAM i 300 GB de disc ràpid només per poder llegir logs. Aquesta xifra és la que cal posar sobre la taula abans de decidir, i la que motiva l'apartat 12.

Abans de buscar res cal dir-li a Kibana quins índexs consultar. A Stack Management → Data Views → Create data view:

El camp de temps és el que permet el selector de rang temporal i els histogrames. Sense ell, Kibana no pot ordenar cronològicament.

KQL (Kibana Query Language) és el llenguatge de la barra de cerca. És molt més simple que PromQL i s'aprèn en deu minuts.

Comparació ràpida amb el que ja sabem:

Tornem a l'escenari de l'apartat 1: l'alerta ApiReservesTaxaErrorAlta dispara a les 03:14.

Pas 1 — Acotar en el temps. Selector de rang: 2026-08-06 03:00 a 2026-08-06 04:00.

Pas 2 — Veure la forma del problema. Consulta àmplia i mirar l'histograma:

L'histograma mostra d'un cop d'ull si els errors van començar de cop (un desplegament, una caiguda) o van créixer progressivament (esgotament d'un recurs).

Pas 3 — Identificar el component. Al panell de camps, fer clic a kubernetes.labels.app per veure la distribució:

Pas 4 — Trobar el missatge dominant. Clic a missatge.keyword:

Pas 5 — Obrir un document i llegir la traça completa. Gràcies al filtre multilínia de l'apartat 6, l'excepció és sencera en un sol document.

Pas 6 — Correlacionar cap enrere. Què va passar just abans del primer error? Treure el filtre de nivell i mirar els cinc minuts anteriors:

Allà sol aparèixer la causa: un desplegament, un CronJob que va arrencar, una consulta lenta de PostgreSQL.

Diagnòstic complet en cinc minuts. Amb kubectl logs en sis pods, això hauria portat una hora, i probablement els logs ja no existirien.

A Dashboards → Create dashboard, amb aquestes visualitzacions:

El mapa de calor per pod és especialment revelador: si els errors es concentren en un sol pod de sis, el problema és d'aquell pod (un node amb problemes, una rèplica amb estat corrupte). Si estan repartits uniformement, el problema és sistèmic (la base de dades, una dependència externa). Aquesta distinció, que a kubectl logs és gairebé impossible de veure, aquí salta a la vista en un segon.

Tot l'anterior funciona moltíssim millor si les aplicacions escriuen JSON en lloc de text lliure. És, de llarg, el canvi de menor cost i major impacte de tota la lliçó.

Problemes d'aquesta línia, que sembla perfectament raonable:

• Per filtrar per nivell cal buscar la subcadena [ERROR], cosa que també troba un missatge que digui "l'usuari va veure un [ERROR] a la pantalla".
• La durada 4821ms és text: no es pot consultar duracio_ms > 1000 ni calcular percentils.
• L'identificador d'usuari està incrustat a la frase: no es pot filtrar per ell.
• No hi ha identificador de traça: no es pot seguir aquesta petició pels altres components.
• Si demà algú canvia el format del missatge, tots els filtres desats deixen de funcionar.

Ara sí:

I agregacions: la durada mitjana de les peticions fallides, els deu trajectes amb més errors, l'evolució d'error_tipus en el temps.

Nota crítica sobre el que no és en aquell JSON: no hi apareix el nom del client, ni el seu DNI, ni el seu telèfon, ni el seu correu. Hi apareix traca_id, que és un identificador opac. Si cal saber quin client era, es creua el traca_id amb la base de dades, en un sistema amb control d'accés. És una decisió deliberada, i l'apartat 11 explica per què és obligatòria.

Tot component de la plataforma ha d'emetre aquests camps:

Regla sobre missatge: ha de ser constant per al mateix tipus d'esdeveniment, amb els valors variables en camps a part. "Error en crear reserva" amb duracio_ms: 4821 és molt més útil que "Error en crear reserva després de 4821ms", perquè permet agregar per missatge.

I el seu ús, amb l'identificador de traça propagat:

Fixa't en l'últim detall: retornem el traca_id al client al cos de l'error. Quan algú truqui al servei d'atenció dient "no he pogut comprar", amb aquell identificador es localitza a Kibana la petició exacta i tot el seu recorregut:

Sense filtrar per component: tots els logs de tots els components que van participar en aquella petició, en ordre. Això és correlació de debò.

A 06-04 vam afegir a worker-notificacions un contenidor adaptador que converteix el seu log propietari a JSON. Aquí és on s'explica del tot per què.

worker-notificacions fa servir una biblioteca antiga d'enviament de correu que escriu així, i no es pot modificar sense reescriure el component:

Dos problemes: no és JSON, i conté l'adreça de correu d'un client, que és una dada personal.

L'adaptador, un sidecar que llegeix aquell log i emet JSON net:

La seva sortida:

Dues transformacions clau: el format passa a JSON consultable, i l'adreça de correu se substitueix per un hash. El hash permet respondre a "quants correus han fallat per al mateix destinatari?" sense que l'adreça aparegui en cap índex.

Els logs i les mètriques són dues vistes del mateix sistema, i el seu valor es multiplica quan es poden creuar. La clau és fer servir les mateixes etiquetes en tots dos.

Amb aquesta correspondència, el flux d'investigació és directe:

Tres maneres pràctiques d'enllaçar tots dos mons:

1. Enllaç des del panell de Grafana. A les opcions del panell, un Data link que obre Kibana amb els filtres ja aplicats:

Amb això, un clic al pic del gràfic porta als logs d'aquell pod en aquella finestra exacta. Estalvia moltíssim temps sota pressió.

2. Mètriques derivades de logs. Fluentd pot comptar esdeveniments i exposar-los a Prometheus, cosa que permet alertar sobre patrons de log:

Compte amb la cardinalitat, exactament igual que a 07-03: no facis servir mai el missatge complet com a etiqueta.

3. Grafana com a visor unificat. Grafana pot afegir Elasticsearch com a font de dades addicional i mostrar al mateix quadre de comandament un panell de mètriques i un altre de logs. Amb la font Loki (apartat 12) la integració és encara més estreta.

El que falta per tancar el cercle del tot són les traces distribuïdes (OpenTelemetry, Jaeger, Tempo): la tercera pota de l'observabilitat, que registra el recorregut complet d'una petició amb els temps de cada salt. El nostre traca_id és una versió artesanal i molt útil d'aquesta idea, però les traces queden fora de l'abast d'aquest curs.

Aquest apartat és el més important de la lliçó, i el que més conseqüències té fora de l'àmbit tècnic.

postgres-reserves desa dades personals dels clients de Rutas Norte: nom, DNI, telèfon i correu electrònic. I tan bon punt muntes una pila de registre centralitzat, tot el que les aplicacions escriguin es copia, s'indexa i es conserva durant 30 dies en un sistema al qual accedeix molta més gent que a la base de dades.

Aquest és el risc real, i és fàcil de subestimar. Un log tan innocent com aquest:

acaba de convertir el teu sistema de logs en un fitxer de dades personals amb totes les obligacions que això comporta.

Un cas que s'escapa sempre: els logs d'accés de l'Ingress i de botiga-web. Registren la URL completa de cada petició. Si alguna ruta porta dades a la cadena de consulta, queden registrades sense que l'aplicació hi intervingui. Solució: no posar dades sensibles a les URL, mai.

Cap no és suficient per si sola. S'apliquen totes.

Capa 1 — Al codi (la més eficaç). Que la dada no s'escrigui mai. És l'única defensa que no té fuites, perquè si mai surt del procés no hi ha res a filtrar. Requereix revisió a les peticions de canvi.

Capa 2 — Redacció a la llibreria de logging. Com el redact de pino de l'apartat 9: una xarxa de seguretat per als descuits.

Capa 3 — Emmascarament al recol·lector. L'última defensa tècnica abans que la dada es persisteixi.

Aquest camp _emmascarat és més valuós del que sembla. Amb una consulta a Kibana:

i agregant per component, obtens la llista de components que estan escrivint dades personals i que cal corregir al codi. Converteix una mesura defensiva en una eina de millora.

Advertiment honest sobre les expressions regulars: no són fiables. Un DNI escrit com 12.345.678-Z no el detecta el patró anterior. Un nom i cognoms no té cap patró detectable. L'única defensa real és la capa 1.

Capa 4 — Control d'accés i retenció. Encara que no hi hagi fuites, restringeix qui pot veure els logs de producció, amb índexs separats per entorn (com vam fer a l'agregador) i rols d'Elasticsearch que només donin accés al necessari.

La retenció de 30 dies de l'apartat 7 és una decisió que combina tres criteris:

I una regla que sovint sorprèn: si els logs contenen dades personals, conservar-los "per si de cas" no és acceptable. La normativa de protecció de dades exigeix que les dades personals es conservin només el temps necessari per a la finalitat que va justificar la seva recollida, i "per si algun dia cal depurar" no sol ser una finalitat vàlida.

Aquest és un punt que no es pot resoldre només amb criteri tècnic.

La configuració d'aquesta lliçó —què es registra, quant de temps es conserva, qui ho pot consultar i des d'on— ha de ser revisada i aprovada pel responsable de compliment normatiu i protecció de dades de l'organització abans de posar-se en producció.

Rutas Norte tracta dades personals dels seus clients (nom, DNI, telèfon i correu electrònic), cosa que situa la plataforma dins de l'àmbit d'aplicació del RGPD i de la normativa nacional de protecció de dades. Un sistema de registre centralitzat que capturi, encara que sigui accidentalment, aquestes dades, té conseqüències concretes:

• Passa a ser un tractament de dades personals que ha de figurar al registre d'activitats de tractament, amb la seva base legal i la seva finalitat documentades.
• Exigeix un termini de conservació justificat i aplicat tècnicament, no una retenció indefinida "per si de cas".
• Obliga a controlar i registrar els accessos: qui consulta els logs de producció i amb quina finalitat.
• Pot requerir una avaluació d'impacte si el volum o la naturalesa del tractament ho justifiquen.
• Complica notablement l'exercici dels drets de supressió i d'accés: si el DNI d'un client apareix en vint índexs distribuïts, atendre una sol·licitud de supressió es torna tècnicament molt costós.
• Si Elasticsearch està allotjat fora de l'Espai Econòmic Europeu, activa les obligacions sobre transferències internacionals de dades.

Què fer, a la pràctica:

1. Documentar per escrit quins camps es registren de cada component i presentar-ho a la persona responsable de compliment.
2. Acordar amb ella el termini de retenció de cada índex, i aplicar-lo a la política ILM.
3. Definir qui té accés als índexs de producció, i revisar-ho periòdicament.
4. Auditar amb la consulta _emmascarat: true quins components continuen emetent dades sensibles i corregir-los al codi.
5. Incloure la revisió de logs a la llista de comprovació de qualsevol funcionalitat nova que tracti dades de clients.

L'equip tècnic proporciona els mecanismes —emmascarament, retenció, control d'accés, separació per entorns—, però la decisió sobre què és acceptable registrar i durant quant de temps no és una decisió tècnica.

Recapitulant l'apartat 7, la pila EFK mínima per a Rutas Norte:

Més el cost humà: algú ha de mantenir Elasticsearch, dimensionar els fragments, vigilar l'estat del clúster, gestionar les actualitzacions i respondre quan es posa en vermell. Elasticsearch no és un component que s'instal·li i s'oblidi.

Per a una plataforma amb sis components i tres nodes, és un cost considerable. Val la pena preguntar-se si hi ha alguna cosa més lleugera.

Loki és el sistema de logs de Grafana Labs, amb una idea de disseny radicalment diferent:

Loki no indexa el contingut dels logs. Només indexa les etiquetes.

És "Prometheus per a logs": el mateix model d'etiquetes, el mateix llenguatge de consulta (LogQL, molt semblant a PromQL) i emmagatzematge en objectes barats (S3) en lloc de discos ràpids.

Quan triar cadascun:

Recomanació honesta per a Rutas Norte: amb sis components, tres nodes i un equip petit, Loki seria l'elecció més sensata. Hem muntat EFK perquè és el que trobaràs a la majoria d'empreses establertes i perquè ensenya els conceptes (índexs, plantilles, ILM, mapatges) que després s'apliquen en qualsevol sistema. Però si demà comencessis de zero, comença per Loki.

La tercera via és no operar res:

Avantatge: zero operació. Inconvenients: cost per GB ingerit que es dispara amb el volum, i —important per a l'apartat 11— les dades surten de la teva infraestructura, cosa que cal revisar amb el responsable de compliment normatiu, especialment si el proveïdor emmagatzema fora de l'EEE.

Abans de dimensionar res, redueix el volum. És gratis i sempre funciona:

Mesures complementàries:

• Nivell info en producció, debug només a rutas-norte-dev.
• access_log off; per a l'endpoint de salut d'nginx, com ja vam fer a 07-01.
• Retenció més curta per a dev i pre (7 dies) que per a pro (30 dies).
• Revisar periòdicament quin component genera més volum:

1. L'aplicació escriu a fitxer en lloc de a stdout. Trenca el contracte de Kubernetes: el recol·lector no ho veu, el fitxer creix dins del contenidor i desapareix en reiniciar-se. Si no pots canviar l'aplicació, fes servir un sidecar adaptador com el de worker-notificacions.

2. No configurar el reassemblatge multilínia. Cada traça d'excepció es converteix en vint documents inconnexos, justament el que més falta fa llegir sencer durant un incident.

3. El recol·lector llegeix els seus propis logs. Bucle infinit: cada log generat produeix un altre log. L'Exclude_Path de l'apartat 6 no és opcional.

4. Elasticsearch amb un sol node. Sense quòrum, sense tolerància a errors, i la pila de logs sencera cau quan aquell pod es reinicia. Tres nodes és el mínim real.

5. Heap d'Elasticsearch mal dimensionat. Màxim el 50 % de la memòria del contenidor, i mai més de 31 GB. Per sobre d'aquest llindar la JVM perd la compressió de punters i rendeix pitjor amb més memòria.

6. Sense política ILM. Els índexs s'acumulen fins a omplir el disc. Quan això passa, Elasticsearch passa a només lectura i deixes de rebre logs justament quan més falta fan.

7. Mapar com a text el que hauria de ser keyword. Sense keyword no pots agregar per aquell camp, i les agregacions són la meitat del valor de Kibana.

8. Registrar dades personals. L'error amb més conseqüències fora del terreny tècnic. Aplica les quatre capes de defensa i, sobretot, no ho escriguis al codi.

9. No definir un estàndard de camps. Si cada component fa servir level, severity i nivell per al mateix, no hi ha cap consulta que funcioni per a tots. Acorda l'estàndard abans d'instrumentar.

10. No propagar el traca_id. Sense ell, correlacionar una petició entre sis components és impossible per molta pila de logs que tinguis.

11. Sense buffer al recol·lector. Si Elasticsearch cau deu minuts i no hi ha buffer, es perden deu minuts de logs de producció, probablement els més interessants.

12. No monitorar la pila de logs. El recol·lector pot estar descartant registres en silenci. Fes servir el PodMonitor i l'alerta de l'apartat 6: aplica el que has après a 07-03 i 07-04 a la mateixa infraestructura d'observabilitat.

13. Registrar massa. El nivell debug en producció multiplica per deu el volum i el cost, i fa més difícil trobar l'important entre el soroll.

botiga-web (nginx) genera logs d'accés en format combinat:

1. Enumera tots els problemes d'aquesta línia, inclosos els de protecció de dades.
2. Escriu la configuració d'nginx que emeti el mateix esdeveniment en JSON, d'acord amb l'estàndard de camps de Rutas Norte.
3. Escriu el parser de Fluent Bit necessari si no poguessis canviar la configuració d'nginx.
4. Què faries amb el paràmetre dni de la URL?

Una auditoria interna revela que l'índex rutasnorte-pro-2026.08.* conté 47 000 documents amb adreces de correu de clients en text clar. Els logs provenen de worker-notificacions i d'api-reserves.

1. Escriu la consulta KQL que localitza els documents afectats.
2. Enumera, per ordre de prioritat, les accions a prendre en les properes 24 hores.
3. Escriu el filtre d'emmascarament que evita que torni a passar, i explica per què no és suficient.
4. Quin paper té el responsable de compliment normatiu en aquest incident i en quin moment cal involucrar-l'hi?

Rutas Norte s'expandeix: passa de 3 a 12 nodes, de 6 a 15 components, i el volum de logs es multiplica per 5 respecte a l'estimació de l'apartat 7. El pressupost d'infraestructura no es multiplica per 5.

1. Recalcula el volum diari i l'emmagatzematge necessari per a 30 dies.
2. Proposa tres mesures per reduir el volum sense perdre capacitat de diagnòstic, amb una estimació de l'estalvi de cadascuna.
3. Compara EFK i Loki per a aquest escenari concret, amb números.
4. Recomana una arquitectura final i justifica-la.

Solució 1

1. Problemes de la línia.

De format:

• No és JSON: cada camp s'ha d'extreure amb expressions regulars, fràgils davant de qualsevol canvi.
• La data fa servir format nginx (06/Aug/2026:03:14:22 +0000), no ISO 8601: requereix un parser específic.
• La durada 4.821 està en segons, no en mil·lisegons, i incompleix l'estàndard de Rutas Norte (duracio_ms).
• No hi ha traca_id: impossible correlacionar aquesta petició amb la d'api-reserves.
• No hi ha component ni nivell: no es pot filtrar per severitat.

De protecció de dades (els greus):

• La URL conté un DNI: ?dni=12345678Z. Queda registrat al log d'nginx, al de l'Ingress i a qualsevol proxy intermedi. Aquest és el problema més greu.
• La IP del client (83.45.12.99) és una dada personal segons el RGPD. S'ha de tractar com a tal: anonimitzar-la o justificar-ne la conservació.
• L'User-Agent contribueix a l'empremta digital del navegador i, combinat amb altres dades, pot ser identificatiu.

2. Configuració d'nginx en JSON.

Punts clau d'aquesta configuració:

• $uri en lloc de $request: $uri és la ruta sense la cadena de consulta, així que el ?dni=... no arriba mai al log. És la solució al problema més greu.
• escape=json és obligatori: sense ell, un User-Agent amb cometes trenca el JSON i Fluent Bit no el pot parsejar.
• access_log off a la sonda de salut, coherent amb el que vam fer a 07-01.

3. Parser si no es pot canviar nginx.

I un filtre Lua que normalitzi a l'estàndard i netegi la cadena de consulta:

4. Què fer amb el dni de la URL.

La resposta correcta té tres nivells, i només el primer resol el problema d'arrel:

Nivell 1 (la solució real): canviar l'aplicació. Un DNI no ha de viatjar mai a la cadena de consulta d'una URL. Les URL queden registrades al navegador, a l'historial, al Referer que s'envia a tercers, als logs d'nginx, de l'Ingress i de qualsevol proxy. La consulta ha de ser POST amb la dada al cos, o fer servir un identificador opac.

Nivell 2 (mitigació immediata): no registrar la cadena de consulta. Fer servir $uri en lloc de $request, com a la solució 2. S'implementa en minuts i talla la fuita cap als logs.

Nivell 3 (xarxa de seguretat): emmascarar al recol·lector. El filtre Lua de l'apartat 11 detecta el patró de DNI i el substitueix. És l'última defensa, i no és fiable per si sola: un DNI escrit com 12.345.678-Z se li escapa.

Aplicar els tres. I molt important: els logs que ja contenen el DNI continuen allà. Cal esborrar-los, i això ens porta a l'exercici següent.

Solució 2

1. Consulta KQL per localitzar els documents.

Més precisa, aprofitant el marcador de l'emmascarament:

I per quantificar i localitzar l'origen, una agregació a Elasticsearch:

Aquesta agregació et dóna exactament quin component, quants documents i des de quin dia: les tres dades que necessites per a l'informe.

2. Accions en 24 hores, per prioritat.

Hora 0-1 — Contenir i notificar.

1. Notificar al responsable de compliment normatiu immediatament. No és una decisió tècnica que es pugui diferir: els terminis de notificació de bretxes són curts i el rellotge comença a córrer des que se'n té coneixement.
2. Restringir l'accés als índexs afectats només a l'equip que gestiona l'incident, mitjançant rols d'Elasticsearch.
3. Documentar l'abast: quins components, quins camps, quants documents, des de quina data, qui ha accedit a aquells índexs (els logs d'auditoria d'Elasticsearch).

Hora 1-4 — Tallar la fuita.

4. Desplegar el filtre d'emmascarament a Fluent Bit (punt 3) perquè deixin d'entrar documents nous. És ràpid i no requereix tocar les aplicacions.
5. Verificar que els documents nous ja arriben emmascarats, comprovant l'índex del dia.

Hora 4-12 — Corregir l'origen.

6. Localitzar al codi les crides al logger que emeten el correu. A worker-notificacions és al log SMTP heretat; a api-reserves, probablement en un log.info(reserva) que bolca l'objecte sencer.
7. Corregir el codi: substituir l'adreça per un hash, com fa l'adaptador de l'apartat 9.
8. Afegir redact a la configuració del logger com a xarxa de seguretat de capa 2.
9. Desplegar a pre i després a pro.

Hora 12-24 — Sanejar i prevenir.

10. Eliminar o depurar els documents afectats, segons el que decideixi el responsable de compliment:

Advertiment: _delete_by_query sobre 47 000 documents és una operació pesada. Si els índexs són diaris i estan molt contaminats, esborrar l'índex sencer és molt més ràpid i més segur, al cost de perdre també els logs nets d'aquell dia.

11. Afegir una comprovació automàtica a la integració contínua que rebutgi una petició de canvi si detecta patrons de dades personals en crides al logger.
12. Escriure un informe per al responsable de compliment amb cronologia, abast, causa arrel i mesures.

3. El filtre d'emmascarament i per què no basta.

Per què no és suficient, en quatre raons:

1. Les expressions regulars s'escapen. marta.ruiz [arrova] ejemplo.example, un correu partit entre dos camps, o un amb caràcters poc habituals no coincideixen amb el patró. L'emmascarament dóna una falsa sensació de seguretat.
2. Només cobreix el que ja saps buscar. Un nom i cognoms no té patró detectable. Una adreça postal tampoc. El filtre protegeix contra correus, DNI i targetes; contra la resta, res.
3. La dada existeix fins al filtre. Surt del procés, s'escriu al fitxer del node, viatja fins al recol·lector. Qualsevol amb accés al node (o al pod del recol·lector, que munta hostPath) la veu sense emmascarar.
4. És una capa de mitigació, no de prevenció. L'única defensa real és que la dada no s'escrigui mai. Tota la resta són xarxes que atrapen el que s'escapa.

Per això el pas 7 (corregir el codi) és l'important, i el filtre només compra temps mentre es desplega.

4. El paper del responsable de compliment normatiu.

Quan involucrar-l'hi: a la primera hora, abans de prendre cap acció de sanejament. És un error freqüent "arreglar-ho primer i avisar després": esborrar els documents abans que ell documenti l'abast pot destruir l'evidència que necessita per avaluar la bretxa, i els terminis de notificació corren des que es té coneixement del fet, no des que s'acaba d'arreglar.

Les seves responsabilitats en aquest incident:

• Qualificar l'incident: determinar si constitueix una violació de seguretat de dades personals segons el RGPD.
• Decidir sobre la notificació: si escau notificar a l'autoritat de control (a Espanya, l'AEPD) en el termini legal de 72 hores, i si escau comunicar-ho als afectats.
• Avaluar el risc per als drets i llibertats de les persones afectades, tenint en compte el volum, la naturalesa de la dada i qui hi ha pogut accedir.
• Decidir el sanejament: què s'esborra, què es conserva com a evidència i durant quant de temps.
• Registrar l'incident al registre intern de violacions de seguretat, obligatori fins i tot quan no escau notificar.
• Aprovar les mesures correctores i verificar que s'han implantat.

I cap endavant, el seu paper és preventiu: revisar i aprovar quins camps es registren, els terminis de retenció i la política d'accés, tal com estableix l'advertiment de l'apartat 11. L'equip tècnic proporciona els mecanismes; la decisió sobre què és acceptable registrar no és tècnica.

Solució 3

1. Recàlcul del volum.

Un increment d'aproximadament tres vegades el cost original, a més d'un salt qualitatiu en complexitat operativa: amb 5 nodes de dades cal gestionar fragments, reequilibrat i actualitzacions contínues.

2. Tres mesures de reducció.

Mesura A — Mostreig de logs d'èxit. Estalvi estimat: 45 %.

El 90 % dels logs són peticions que van anar bé i que ningú mirarà mai. Conservar-ne el 10 % és estadísticament suficient per veure tendències, i el 100 % dels errors.

El camp _mostrejat permet multiplicar per 10 els recomptes en fer agregacions i obtenir xifres correctes.

Mesura B — Retenció esglaonada per entorn i per nivell. Estalvi estimat: 30 %.

S'implementa amb dos fluxos de dades diferents, encaminats a l'agregador Fluentd pel camp nivell, cadascun amb la seva política ILM.

Mesura C — Descartar soroll a l'origen. Estalvi estimat: 20 %.

Efecte combinat (les mesures no són purament additives perquè se solapen):

I l'important: sense perdre capacitat de diagnòstic, perquè es conserva el 100 % dels errors, el 100 % del que és lent i el 100 % del que toca reserves.

3. Comparació EFK davant de Loki amb números.

Sobre el volum ja optimitzat de 15,8 GB/dia:

La dada decisiva és a la comparació de les dues files de cerca: Loki és lent en cerques de text lliure sobre tot l'històric, però igual de ràpid en el cas que representa el 95 % de l'ús real, que és "logs d'aquest component, en aquesta finestra de temps, filtrant per nivell". I això és exactament com s'investiga un incident: mai busques una cadena en 30 dies de tots els components; sempre acotes per component i per finestra, perquè l'alerta ja te'ls va donar tots dos.

4. Arquitectura recomanada.

Recomanació: migrar a Loki, amb les tres mesures de reducció aplicades.

Justificació, en cinc punts:

1. Cost: 190 € davant de 750 € al mes. La diferència (6 700 € l'any) és difícil de justificar quan el cas d'ús predominant rendeix igual en tots dos.
2. Complexitat operativa. Elasticsearch amb 5 nodes de dades requereix algú que sàpiga gestionar fragments, reequilibrats i actualitzacions. Loki, molt menys. Amb un equip petit, aquell temps val més que la diferència de cost.
3. Integració amb el que ja tenim. Grafana ja està desplegada des de 07-04. Loki apareix com una font de dades més, i el mateix quadre de comandament pot tenir un panell de mètriques a sobre i un de logs a sota, amb la mateixa finestra temporal. Aquell salt de context estalviat en un incident val molt.
4. El model d'etiquetes és el que ja coneixem. LogQL és tan semblant a PromQL que l'equip l'aprèn en una tarda, mentre que KQL i les agregacions d'Elasticsearch són un cos de coneixement a part.
5. Es conserva l'arquitectura de recol·lecció. Fluent Bit continua sent l'agent per node, amb la mateixa configuració de parseig, multilínia i emmascarament. La migració només canvia la destinació de la sortida, cosa que la fa de baix risc.

Quan NO seguir aquesta recomanació:

• Si l'equip ja opera Elasticsearch per a altres coses (cercador del web, anàlisi), el cost marginal d'afegir-hi logs és molt menor.
• Si hi ha requisits d'auditoria que exigeixen cerca de text lliure en tot l'històric amb temps de resposta garantits.
• Si es necessiten agregacions complexes sobre camps de log de manera habitual.

Pla de migració de baix risc:

1. Desplegar Loki en paral·lel, sense tocar EFK.
2. Configurar Fluent Bit amb dues sortides simultànies durant dues setmanes.
3. Reconstruir a Grafana els quadres de comandament d'errors que eren a Kibana.
4. Validar amb un incident real que Loki respon a les preguntes necessàries.
5. Retirar EFK, conservant una còpia dels índexs de producció fins a esgotar la retenció acordada amb el responsable de compliment normatiu.

Aquest últim punt no és un detall: no es pot esborrar EFK abans d'hora si la seva retenció està compromesa amb compliment.

Rutas Norte ja no perd la seva història. En aquesta lliçó hem:

• Entès per què kubectl logs no basta: es perd en recrear el pod, no busca entre components, no correlaciona i desapareix amb el node. I hem vist un límit addicional poc conegut: amb la rotació per defecte del kubelet, un component verbós conserva menys de sis hores de logs al node.
• Vist com funciona el registre per sota: l'aplicació escriu a stdout, el runtime ho desa a /var/log/containers/ amb un nom parlant del qual s'extreuen pod, namespace i contenidor, i el kubelet el rota.
• Dominat kubectl logs com a eina de primera línia, amb --previous com el flag decisiu davant d'un CrashLoopBackOff.
• Muntat l'arquitectura de recol·lecció per node sobre el DaemonSet que vam desplegar a 06-02: Fluent Bit com a agent lleuger a cada node i Fluentd com a agregador central, amb el filtre kubernetes que enriqueix cada línia i el reassemblatge multilínia que evita que una excepció es converteixi en vint documents inconnexos.
• Configurat Elasticsearch amb índexs per dia, plantilles que distingeixen keyword de text, i una política ILM amb fases calenta, tèbia, freda i esborrat; i hem dimensionat la pila amb números realistes: uns 24 GB de RAM i 300 GB de disc només per poder llegir logs.
• Fet servir Kibana amb KQL per passar d'una alerta a la causa arrel en cinc minuts, seguint un flux de treball concret: acotar, veure la forma, identificar el component, trobar el missatge dominant, llegir la traça i correlacionar cap enrere.
• Adoptat els logs estructurats en JSON com la decisió de major rendibilitat, amb l'estàndard de camps de Rutas Norte i el traca_id que permet seguir una petició pels sis components; i hem tancat el cercle de l'adaptador de logs de worker-notificacions que vam introduir a 06-04.
• I, sobretot, hem establert què no s'ha de registrar mai: credencials, dades de pagament i dades personals dels clients. Amb quatre capes de defensa —el codi, la llibreria, el recol·lector i el control d'accés— sabent que només la primera és realment fiable, i amb l'advertiment exprés que la configuració de registre ha de ser revisada i aprovada pel responsable de compliment normatiu abans d'arribar a producció.
• Comparat el cost real d'EFK amb les alternatives més lleugeres, amb la conclusió honesta que per a una plataforma de la mida de Rutas Norte, Loki seria avui l'elecció més sensata.

Ja tenim les tres senyals: les sondes diuen si un component està sa, les mètriques diuen quant i com funciona, i els logs diuen exactament què va passar. El que encara no tenim és un mètode per fer-les servir juntes.

Perquè quan a les 03:14 la botiga web retorna 502 i sona el telèfon, saber fer servir Grafana i Kibana no basta: cal un procediment que vagi del símptoma a la causa sense donar voltes, saber que els esdeveniments de Kubernetes caduquen en una hora i cal capturar-los abans, i conèixer una taula mental de símptoma → causa probable → ordre que ho confirma. A 07-06, l'última lliçó del mòdul, construirem aquesta metodologia i l'aplicarem, pas a pas, a un incident real de Rutas Norte.