Saps què va passar a les tres de la matinada: quinze db_timeout amb les 200 connexions esgotades. El que no saps és per què. I ara la Marta hi afegeix llenya: «Diversos comercials diuen que el web va lent al matí, cap a les nou. És cosa nostra?». «Va lent» no és una dada, és una sensació; convertir-la en un número, trobar el recurs culpable i demostrar que el canvi ha servit és justament la feina d'aquesta lliçó. Aprendràs un mètode reproduïble en lloc d'una col·lecció d'ordres soltes, a interpretar de debò el que diuen uptime, free o iostat, i a establir una línia base de srv-tramontana sense la qual cap mesura no significa res.

1. Monitorar, diagnosticar i el mètode USE
2. CPU: càrrega mitjana, vmstat, mpstat i el steal
3. Memòria: què significa «usada», intercanvi i l'OOM killer
4. Disc: iostat -xz, latència enfront de cabal
5. Xarxa: sar -n DEV, ss -s i les retransmissions
6. Eines de conjunt i la història amb sar
7. Mètriques contínues i els quatre golden signals
8. Procediment per a «el servidor va lent»
9. Ajustos a l'abast d'un administrador
10. La línia base de srv-tramontana
11. Cas Tramontana: «el web va lent al matí»

Són dues activitats diferents i es confonen constantment:

• Monitorar és saber com està el sistema de manera contínua i sense que ningú miri: mètriques cada quinze segons, guardades, amb alertes. Respon a «va bé?» abans que truqui el client.
• Diagnosticar és esbrinar per què va malament en un moment concret, amb eines interactives i una hipòtesi que es confirma o es descarta.

Un humà mirant top no és monitoratge: és diagnòstic manual, ocasional i sense memòria. Necessites totes dues, i la primera fa possible la segona, perquè una mesura sense punt de comparació no diu res: una càrrega de 3,5 pot ser normal o catastròfica, i només ho saps si coneixes la d'ahir.

El mètode USE (de Brendan Gregg) dona l'ordre en què es mira. Per a cada recurs —CPU, memòria, disc, xarxa— es comproven tres coses:

La seva utilitat pràctica és que evita perdre temps: en cinc minuts recorres els quatre recursos amb tres preguntes cadascun i en surts sabent quin és el coll d'ampolla.

Els tres números són la mitjana de processos en estat executable (R) o en espera ininterrompible (D) durant 1, 5 i 15 minuts. Dues regles que ho canvien tot. Primera: cal normalitzar pel nombre de nuclis; amb nproc = 2, una càrrega de 3,42 són 1,71 processos per nucli i el sistema està saturat, mentre que el mateix 3,42 en una màquina de 16 nuclis seria un 21 % d'ocupació, és a dir, res. Segona: l'estat D compta, i aquest és el matís que gairebé ningú no coneix, perquè a Linux la càrrega inclou els processos bloquejats esperant disc; per això pots veure una càrrega de 8 amb la CPU al 5 %.

La tendència també informa: 3,42 2,10 1,08 és una càrrega pujant (el problema comença ara); 1,08 2,10 3,42 és una que ja s'està resolent.

La primera línia de vmstat és la mitjana des de l'arrencada: ignora-la sempre i mira de la segona endavant. A l'exemple, wa en 56–68 % amb r en 4–5 i bo disparat diu a crits que el coll d'ampolla és el disc, no la CPU.

L'st mereix un apunt: en una VM és temps que l'hipervisor va donar a una altra màquina, així que un st del 20 % significa que cap optimització teva no arreglarà res, perquè el problema és a l'amfitrió o al proveïdor.

I el desglossament per nucli i per procés:

mpstat -P ALL revela un cas molt comú: la mitjana global sembla raonable però un sol nucli està al 100 % perquè l'aplicació no paral·lelitza. pidstat reparteix el consum per procés, i la seva columna %wait —temps esperant que li donin CPU— és or pur per detectar contenció.

«Lliure: 208 Mi» no és un problema. És exactament el contrari: la RAM lliure és RAM desaprofitada, i el nucli la fa servir com a memòria cau de pàgina per no haver de tornar a llegir del disc. Les columnes que importen:

used és la memòria de processos sense memòria cau ni memòries intermèdies; buff/cache és memòria cau de pàgina i metadades, que el nucli allibera a l'instant si cal; i available és la xifra que cal mirar: quanta memòria pot obtenir una aplicació nova sense fer intercanvi. Amb 2,4 GiB disponibles de 3,8, srv-tramontana va sobrat; l'alarma seria available caient cap a zero, no free.

Tres xifres que es confonen a diari: VSZ és tot l'espai d'adreces reservat —biblioteques compartides i memòria demanada però mai tocada incloses—, gairebé sempre enorme i irrellevant; RSS són les pàgines realment a la RAM, útil però compta sencera cada biblioteca compartida a cada procés, així que sumar els RSS dona molt més que la RAM total; i PSS reparteix cada pàgina compartida entre els qui la fan servir, i és l'única que suma bé (es veu amb smem -k o a /proc/PID/smaps_rollup).

Tenir intercanvi ocupat no és dolent per si sol: el nucli descarrega pàgines que ningú no toca. El greu és el tràfec constant, que es veu a si/so de vmstat. Si aquelles columnes estan actives de manera sostinguda, el sistema passa més temps movent pàgines que treballant: això és thrashing, i es percep com una lentitud brutal amb la CPU gairebé ociosa.

Quan no queda memòria ni intercanvi, el nucli tria una víctima i la mata. Saber que ha actuat és fonamental, perquè el símptoma que arriba és «el servei s'ha reiniciat sol»:

Tria per oom_score, que premia matar el procés que més memòria allibera, ponderat per oom_score_adj (de −1000 a 1000). Es consulta a /proc/PID/oom_score i s'ajusta en calent amb sudo choom -p 1284 -n -500. Encara que en un servei de systemd el correcte és declarar-ho a la unitat (OOMScoreAdjust=-500) i, sobretot, posar MemoryMax com vas veure a 05-05: així l'OOM actua dins del cgroup del servei i no s'endú per davant la base de dades.

La distinció crítica és latència enfront de cabal: un disc pot moure 200 MB/s tan tranquil amb una tasca seqüencial (cabal alt, latència baixa) i ofegar-se amb 5 MB/s d'escriptures aleatòries petites (cabal ridícul, latència terrible). A l'usuari li fa mal la latència, no el cabal.

I qui està escrivint:

Aquella última ordre és un avançament del cas d'avui: dues-centes connexions establertes contra el port de la base de dades, exactament el max_connexions d'app.conf.

Per veure el trànsit en directe, nload (per interfície) o iftop (per conversa) són immediats.

I l'indicador de salut de TCP que cal conèixer, nstat -az | grep TcpRetransSegs: les retransmissions són segments que es van haver de reenviar perquè no va arribar confirmació. Un percentatge petit és normal; una taxa creixent indica pèrdua de paquets —cable, saturació d'un enllaç o un dispositiu intermedi descartant trànsit—. El diagnòstic complet de xarxa, amb mtr i les capes, ja el tens de 03-08.

El punt que més vegades es passa per alt: la foto d'ara no serveix sense la d'ahir. Si la Marta es queixa a les 09:10 d'alguna cosa que va passar a les 09:00, top ja no diu res; sar sí:

Activar sysstat costa un minut i és el que converteix «em sembla que anava lent» en «a les 09:04 el %iowait va pujar al 61 %».

Per a més d'un servidor, o per alertar sense que ningú miri, l'estàndard d'avui és Prometheus (base de dades temporal que consulta els objectius), node_exporter (exposa les mètriques del sistema a /metrics), Grafana (taulers) i Alertmanager (avisos). No els muntem aquí: és matèria del Mòdul 8. El que sí que t'has d'emportar és què mesurar, els quatre golden signals:

I una regla sobre alertes: una alerta que sona a diari deixa de llegir-se. Alerta sobre símptomes que fan mal a l'usuari (latència p95, taxa d'errors), no sobre cada pic de CPU. És la mateixa disciplina del «silenci si tot va bé» dels teus scripts.

Aquest és el procediment numerat que pots aplicar tal qual, en aquest ordre, sense saltar-te passos:

1. Tradueix la queixa a un número mesurable. Quina operació, a quina hora, quant triga ara i quant abans? Sense això no pots saber si has arreglat res.
2. Foto de 60 segons. uptime, vmstat 1 5, free -h, iostat -xz 1 3, ss -s, systemctl --failed. Amb sis ordres saps si el problema és CPU, memòria, disc o xarxa.
3. Compara amb la línia base. És anormal, o sempre ha estat així i el que ha canviat és l'expectativa?
4. Identifica el recurs amb USE i tria'n un, descartant els altres explícitament.
5. Localitza el culpable dins d'aquell recurs amb pidstat, iotop, ss o top -H: nom i PID.
6. Formula una hipòtesi falsable. «La còpia de les 04:20 satura el disc i per això les consultes caduquen» es pot confirmar o descartar; «va lent» no.
7. Revisa què va canviar: journalctl --since, /var/log/apt/history.log, git log dels teus scripts, l'HISTORIAL. El 80 % dels problemes nous vénen d'un canvi recent.
8. Mesura abans de tocar res i guarda les xifres en un fitxer amb data.
9. Canvia UNA sola cosa i documenta què i per què.
10. Mesura després, en les mateixes condicions, i compara. Si no millora, reverteix abans de provar una altra cosa.
11. Anota el resultat a l'HISTORIAL, fins i tot —sobretot— si el canvi no va servir.

Els passos 8, 9 i 10 són innegociables. Canviar tres paràmetres alhora i veure que millora no t'ensenya res: no saps quin va servir, i arrossegaràs dos ajustos inútils per sempre.

Els paràmetres del nucli via sysctl són matèria de 07-03 i el perfilatge amb perf i eBPF és de 07-02. El que sí que és a les teves mans avui:

Límits de fitxers oberts. Un servidor amb moltes connexions esgota el límit per procés i rebutja peticions amb Too many open files:

En un servei de systemd no es toca /etc/security/limits.conf —que només s'aplica a sessions d'accés via PAM—, sinó la unitat:

Límits de recursos del servei: MemoryMax i CPUQuota de 05-05, que a més de protegir serveixen per mesurar, perquè systemd-cgtop mostra si el servei arriba al sostre. I noatime a fstab (05-04), que evita una escriptura per cada lectura i es nota en un servidor amb molts fitxers petits.

Perfilatge somer de fils: top -H -p 1284 desglossa el consum fil a fil quan un procés multifil va carregat i no saps quina part. perf top donaria el desglossament per funció, però això és 07-02.

Els paràmetres de l'aplicació mateixa, que solen rendir més que qualsevol ajust del sistema: a Tramontana, max_connexions i timeout_consulta d'/etc/tramontana/app.conf.

Una línia base és una foto del comportament normal, presa quan tot va bé, per comparar quan no. Es guarda al costat de la de referència del Mòdul 1:

Valors normals mesurats a srv-tramontana un dimarts a les 11:00, amb l'aplicació en marxa:

Aquella taula, i no la intuïció, és el que converteix una mesura en un diagnòstic.

Pas 1 — Traduir la queixa. Preguntem i mesurem: la cerca de disponibilitat, que normalment respon en 180 ms, triga entre 4 i 9 segons entre les 08:50 i les 09:15. Ja és un número.

Pas 2-3 — Foto i comparació amb la línia base. Com que l'incident és recurrent, mesurem a les 09:00 de l'endemà:

Càrrega 3,42 amb 2 vCPU (línia base: 0,15–0,40) i wa al 68 % (base: 0–3 %) amb id al 8 %. No falta CPU: falta disc. Memòria i intercanvi, normals. Recurs identificat: E/S.

Pas 4-5 — El culpable.

w_await de 22,85 ms davant dels 0,8–2,5 de la base, %util al 97,6 %, i qui escriu és la còpia de seguretat, que en teoria es llança a les 04:20: la del dia 17 va trigar 1 h 42 min i la del 18 encara no havia acabat a les 09:04. El conjunt de dades ha crescut i la còpia se solapa amb l'hora punta.

Pas 6 — Hipòtesi falsable. «La còpia de seguretat satura l'E/S del disc fins passades les 09:00; això allarga les consultes a la base de dades, que arriben al timeout_consulta de 30 s i esgoten les 200 connexions de max_connexions, que és el que provoca els db_timeout dels registres.»

Comprovació de la segona meitat:

Dues-centes connexions exactes —el sostre— i onze errors en quatre minuts. Hipòtesi confirmada: el mateix mecanisme que va causar els db_timeout de les 03:00 de la lliçó anterior.

Pas 7-9 — Què va canviar, mesurar i canviar UNA cosa. L'HISTORIAL ho diu: el volum de còpies es va migrar el 18 i el conjunt de dades ha crescut. La causa arrel és la durada de la còpia, no les connexions. El canvi mínim i reversible:

Pas 10 — Mesurar després, a la mateixa hora i amb les mateixes ordres.

Pas 11 — Documentar. I l'informe per a la Marta, amb l'estructura de sempre: «La lentitud dels matins la causava la còpia de seguretat, que havia crescut fins a trigar més de quatre hores i continuava escrivint en hora punta; en saturar el disc, les consultes caducaven i s'esgotaven les 200 connexions a la base de dades. Hem avançat la còpia a les 02:30 i li hem posat un límit de 3 hores i menor prioritat d'E/S. Mesurat a les 09:04: la cerca torna a 190 ms i no hi ha errors. Què protegeix això: que la còpia interfereixi amb l'horari laboral. Què no protegeix: si el conjunt de dades continua creixent, hi tornarem a xocar; cal passar a còpies incrementals, i això ho abordem ara mateix. Tampoc no resol que 200 connexions sigui un límit ajustat si creix el nombre d'usuaris.»

• Llegir la càrrega mitjana sense dividir per nproc. Un 3,42 no significa res fins que no saps quants nuclis hi ha.
• Espantar-se per «poca memòria lliure». La xifra que importa és available; la memòria cau és memòria ben emprada.
• Fiar-se de la primera línia de vmstat o iostat. És la mitjana des de l'arrencada, no el moment actual.
• Mirar %util en un SSD com si fos un disc mecànic. Amb cues paral·leles, un NVMe pot marcar 100 % i no estar saturat. Mira await i aqu-sz.
• Diagnosticar sense línia base. Sense saber què és normal, qualsevol número sembla alarmant o tranquil·litzador segons l'ànim. I no canviïs diverses coses alhora: no sabràs quina va funcionar, i arrossegaràs ajustos inútils durant anys.
• No tenir història. Instal·la sysstat el primer dia: quan algú pregunti per les 09:00, ja serà tard per activar-lo.
• Confondre un símptoma amb la causa. Les 200 connexions eren el símptoma; la còpia era la causa. Pujar max_connexions hauria amagat el problema.
• Consell: guarda cada mesura en un fitxer amb data, al costat de l'HISTORIAL. D'aquí a sis mesos, aquella carpeta valdrà més que la teva memòria.

1. Llegir una foto. Un servidor amb 4 vCPU mostra load average: 7,80, 7,20, 6,90, vmstat amb us=6 sy=3 id=4 wa=87 st=0, r=1, b=6, i free -h amb 5,1 GiB disponibles de 8. Quin és el recurs saturat, quin no ho és, i quines són les dues ordres següents?
2. Un servei que mor de matinada. tramontana.service apareix reiniciat cada nit cap a les 03:40 sense que ningú el toqui. Dona les ordres per confirmar si va ser l'OOM killer i, si ho va ser, dues maneres d'evitar que s'endugui per davant la base de dades.
3. Demostrar una millora. Dissenya el protocol exacte —ordres, moments i criteri d'èxit— per demostrar que activar noatime a /srv/tramontana/backups escurça la còpia nocturna, de manera que el resultat convenci algú escèptic.

1. El recurs saturat és el disc. La prova: wa=87 % amb id=4 % significa que la CPU està aturada esperant E/S, i b=6 són sis processos bloquejats en estat D, que a més són els que inflen la càrrega fins a 7,80 tot i que només hi ha r=1 esperant CPU. Normalitzat, 7,80 entre 4 nuclis serien 1,95, però aquell número és enganyós aquí precisament perquè el componen processos en D, no en R. El que no està saturat: la CPU (us+sy = 9 %) ni la memòria (5,1 GiB disponibles de 8, sense intercanvi en moviment). Les dues ordres següents:

2.

status=9/KILL sense que ningú hagi executat un kill és la signatura de l'OOM killer, i el missatge del nucli ho confirma. Fixa't en la coincidència horària amb la còpia nocturna: la memòria cau de pàgina que genera la còpia pressiona la memòria disponible.

Dues maneres de protegir la base de dades:

La primera és la bona, perquè acota el problema al seu origen: quan Tramontana es passi de memòria morirà Tramontana, i systemd l'aixecarà, sense que el nucli triï víctima a tota la màquina. La segona és un complement defensiu: esbiaixa l'elecció, però no impedeix que la màquina es quedi sense memòria.

3. El protocol, que és el mètode de la secció 8 aplicat:

Criteri d'èxit, fixat abans de mesurar: reducció de la mediana de durada superior al 10 % sense augment d'errors a journalctl -u tramontana-copia.service -p err. Tres nits a cada costat perquè una sola mesura no distingeix una millora d'una nit fluixa. I si no es compleix el criteri, es reverteix amb el .bak i s'anota a l'HISTORIAL que no va servir: un experiment negatiu documentat estalvia que algú el repeteixi d'aquí a un any.

Ja no depens que algú «noti» que el servidor va lent. Distingeixes monitorar de diagnosticar i apliques el mètode USE —utilització, saturació, errors— als quatre recursos. Llegeixes la càrrega mitjana normalitzada per nproc sabent que inclou els processos en estat D, i interpretes vmstat 1 columna a columna: r i b, si/so, us/sy/id/wa i el st que delata l'hipervisor. Reparteixes el consum amb mpstat -P ALL i pidstat.

En memòria saps que «lliure» és una xifra enganyosa i que la bona és available, distingeixes VSZ, RSS i PSS, reconeixes el thrashing a si/so, i saps demostrar que va actuar l'OOM killer amb journalctl -k i com evitar que s'endugui el veí amb MemoryMax i OOMScoreAdjust. En disc manegues iostat -xz amb %util, await i aqu-sz, tens clara la diferència entre latència i cabal, i localitzes el culpable amb iotop i lsof. En xarxa fas servir sar -n DEV, ss -s i les retransmissions. Coneixes htop, atop, glances i dstat, i —el més important— has activat sysstat per tenir la història sense la qual la foto d'avui no significa res. Saps què són els quatre golden signals i per què una alerta que sona a diari deixa de llegir-se.

Tens un procediment d'onze passos per a «el servidor va lent», amb les tres regles innegociables: mesurar abans, canviar una sola cosa, mesurar després. Tens una línia base de srv-tramontana amb llindars escrits. I has resolt el cas: la lentitud matinal era la còpia de seguretat saturant l'E/S fins passades les 09:00, provocant els db_timeout i l'esgotament de les 200 connexions; avançar-la i limitar-la va tornar la cerca de 4–9 s a 190 ms, amb les xifres d'abans i després escrites a l'HISTORIAL.

Però l'informe per a la Marta acabava amb un cap solt que no pot esperar: la còpia completa continuarà creixent, i amb ella el problema. I hi ha una cosa molt pitjor que ningú no ha comprovat encara: ningú no ha restaurat mai aquella còpia. A Còpies de Seguretat i Restauració, l'última lliçó del mòdul, veuràs per què no existeixen les còpies de seguretat sinó només les restauracions provades: fixaràs RPO i RTO per a Tramontana, aplicaràs la regla 3-2-1 i la retenció per generacions, resoldràs la coherència amb instantànies LVM de 05-04, faràs servir tar --listed-incremental, rsync --link-dest i una eina moderna amb deduplicació i xifratge, i escriuràs el procediment de restauració pas a pas per als tres escenaris que et poden passar de debò.