Al Mòdul 5 vas aprendre a mesurar. El mètode USE, vmstat, iostat, free, sar i pidstat et diuen quant: la CPU està al 80 %, el disc té 22 ms de latència d'escriptura, queden 300 MB de memòria disponible. Amb allò vas resoldre l'incident del web lent als matins, perquè els comptadors assenyalaven l'E/S i l'E/S tenia un culpable identificable.

Però hi ha una classe de problema per a la qual els comptadors no serveixen: quan tots són en verd i el servei va malament igualment. La CPU ociosa, el disc tranquil, la memòria de sobres, i l'aplicació trigant deu vegades més del que hauria. En aquell punt la pregunta deixa de ser quant i passa a ser què està fent exactament aquest procés, i per respondre-la calen eines que no mesurin agregats, sinó que observin esdeveniments individuals.

Aquesta lliçó te'n dona tres, en ordre creixent de sofisticació i decreixent de cost: strace per veure les crides al sistema una per una, perf per perfilar on es consumeixen els cicles de debò, i eBPF per instrumentar el nucli en producció sense penalització apreciable. I et trobaràs de cara amb una conseqüència de la teva pròpia feina del Mòdul 6.

1. Quan els comptadors no basten
2. strace: les crides al sistema una per una
3. L'obstacle que tu mateix vas posar: ptrace_scope
4. ltrace i el nivell de les biblioteques
5. perf: perfilat per mostreig
6. Gràfics de flama
7. eBPF: instrumentar el nucli en producció
8. Les eines de bpfcc i quina pregunta respon cadascuna
9. Taula de decisió: quina eina per a quina pregunta
10. Cas Tramontana: de 400 ms a 40 ms

La diferència entre les dues famílies d'eines és la unitat d'observació:

Aquell últim punt és important i ordena tota la lliçó: les eines de traçat no substitueixen els comptadors, els continuen. Es fan servir quan ja tens una hipòtesi que vols confirmar o refutar. Llançar strace sobre un procés sense saber què busques produeix cent mil línies il·legibles i alenteix el servei.

La metodologia, doncs, té tres passos i l'ordre no és negociable:

1. Símptoma mesurat. «L'aplicació triga 400 ms a respondre; la línia base diu 40 ms.» No «va lenta».
2. Hipòtesis descartades amb comptadors. CPU? Disc? Memòria? Xarxa? És gratis i elimina la majoria dels casos.
3. Mesura dirigida amb l'eina adequada. Una hipòtesi concreta, una eina, una resposta.

Recorda les capes del Mòdul 1: maquinari → nucli → crides al sistema → shell i biblioteques → aplicacions. Una crida al sistema és l'única manera que té un programa de demanar alguna cosa al nucli: obrir un fitxer, llegir d'un sòcol, reservar memòria, esperar. Tot el que un procés fa de cara a l'exterior hi passa.

strace intercepta aquelles crides i les imprimeix. És literalment veure la conversa entre el programa i el nucli.

Cada línia té la mateixa estructura: nom de la crida, arguments entre parèntesis, i el valor retornat després de l'=. Si el valor és negatiu, apareix el nom simbòlic de l'error (ENOENT, EACCES, EAGAIN) i la seva descripció. Aquella tercera part és on sol ser la resposta.

Fixa't en la línia de /etc/ld.so.preload: retorna ENOENT. No és un error, és normal —aquell fitxer rarament existeix—, i això il·lustra una cosa que cal interioritzar: strace mostra moltíssims errors esperats. Saber quins són normals és la meitat de l'ofici.

Els grups de -e trace= estalvien memoritzar noms:

Això és el primer pas de qualsevol diagnòstic amb strace, i per una raó pràctica: cap en una pantalla i diu immediatament on se'n va el temps. Aquí el 89 % del temps és a connect, amb 300 crides a 8 ms cadascuna. Això és una pista enorme: el procés està obrint connexions noves constantment i cadascuna costa 8 mil·lisegons.

Les columnes: % time és la proporció del temps total dins de crides al sistema (no del temps total del procés: si el programa crema CPU al seu propi codi, aquí no es veu); usecs/call és la mitjana per crida; errors compta els retorns amb error.

L'ús més rendible d'strace, i el que cal tenir memoritzat. Un programa falla dient que no troba un fitxer, i tu estàs segur que el fitxer existeix:

El fitxer hi és. La pregunta és què està buscant el programa realment:

Aquí està, i no era el que semblava. El fitxer de configuració s'obre bé; el .local que no existeix és opcional. L'error real és EACCES sobre el fitxer de la credencial: el programa el busca a /etc/tramontana/secrets/db_password, però des de 06-05 la credencial l'entrega systemd a $CREDENTIALS_DIRECTORY, i executat a mà aquella variable no existeix. El programa funciona correctament sota systemd i falla executat directament.

Aquell és el patró general i per això val la pena memoritzar-lo:

strace funciona amb ptrace, que atura el procés a cada crida al sistema, transfereix el control al traçador, i el reprèn. Això significa dos canvis de context per crida.

Un procés que fa 50.000 crides per segon pot tornar-se cent vegades més lent. Les conseqüències operatives:

• Mai strace sense -e trace= ni -c sobre un procés de producció amb càrrega. Si ho has de fer, fes-ho amb un límit de temps: timeout 5 strace -f -c -p PID.
• Un procés al qual estàs adjuntat i mates strace amb SIGKILL pot quedar aturat. Surt sempre amb Ctrl+C, que fa un detach net.
• Per a producció, perf trace i eBPF fan el mateix amb un cost un o dos ordres de magnitud menor. És la raó que existeixin.

Intenta adjuntar-te al procés de l'aplicació com el teu usuari:

No és una fallada. És el kernel.yama.ptrace_scope = 1 que vas posar a /etc/sysctl.d/60-enfortiment.conf a 06-06, i que aquell dia venia amb un avís escrit al costat precisament per això:

Els quatre valors possibles:

I per què la mesura és correcta, que és la part que cal entendre i no només esquivar: amb ptrace_scope = 0, un procés compromès pot llegir tota la memòria de qualsevol altre procés del mateix usuari. Això inclou la credencial de la base de dades que tanta feina va costar xifrar a 06-05: és en clar a la memòria del procés que la fa servir. Un atacant que aconsegueixi executar codi com a svc-tramontana en un procés qualsevol podria extreure-la del procés de l'aplicació sense tocar cap fitxer. El valor 1 tanca exactament aquella via.

Les dues sortides legítimes:

Per a la sortida B, la forma disciplinada és un script amb trap, aplicant el de 04-06, perquè un Ctrl+C a mitges deixaria el sistema amb la protecció desactivada:

A la pràctica, la sortida A —sudo— és la correcta el 95 % de les vegades. La sortida B només té sentit amb eines que no funcionen bé sota sudo, i en un servidor de producció la resposta honesta és que no s'abaixa ptrace_scope: es fa servir eBPF, que no necessita ptrace en absolut. És un altre argument a favor de la tercera secció d'aquesta lliçó.

strace veu la frontera entre el programa i el nucli. N'hi ha una altra, de frontera, un nivell més amunt: entre el programa i les biblioteques compartides que fa servir.

És útil per entendre el comportament d'un programa propi —fuites de memòria, ús d'una biblioteca criptogràfica, crides a libcurl— però té dos límits seriosos: només veu crides a biblioteques dinàmiques (un binari estàtic és opac), i el seu cost és encara més gran que el d'strace. A la pràctica es fa servir poc, i en un servidor gairebé mai. strace per a la frontera amb el nucli, perf per a l'interior del procés.

perf és l'eina de rendiment del nucli de Linux mateix, i opera amb un model radicalment diferent:

La diferència clau és la penúltima fila. strace no et pot dir res d'un procés que crema CPU al seu propi bucle, perquè allà no hi ha crides al sistema. perf sí.

En una VM, alguns comptadors de maquinari no estan disponibles perquè l'hipervisor no els exposa. Els esdeveniments de programari (task-clock, context-switches, page-faults) sí que funcionen sempre.

Com llegir això, línia per línia, perquè cadascuna respon a una pregunta diferent:

I la conclusió d'aquesta mesura concreta: 0,128 CPU utilitzades. El procés no està treballant, està esperant. Els 3.412 canvis de context en 10 segons ho confirmen: entra i surt de la CPU constantment perquè es bloqueja. Amb això queda descartada la CPU com a causa del problema de latència, que era l'objectiu del pas 2 de la metodologia.

L'IPC de 0,61 i el 39 % de fallades de memòria cau són mediocres, però irrellevants aquí: amb el procés al 12,8 % d'un nucli, millorar la seva eficiència de CPU no canviaria la latència.

-F 99 fixa la freqüència de mostreig en 99 Hz. És una convenció amb motiu: fer servir 100 Hz corre el risc de sincronitzar-se amb esdeveniments periòdics del sistema que també són de 100 Hz, i esbiaixar la mostra. Un nombre primer proper ho evita.

Les marques [k] i [.] distingeixen l'espai de nucli del d'usuari. Aquí el 82 % del temps de CPU és a connect i tcp_v4_connect, tots dos al nucli, i tramontana_db_connectar apareix a l'espai d'usuari. Tres eines diferents apuntant al mateix lloc: el procés es passa la vida obrint connexions.

Un perf report amb piles de crides és difícil de llegir perquè la informació és jeràrquica i la sortida és plana. El gràfic de flama (flame graph) ho resol visualment, i s'ha convertit en l'estàndard de l'àrea.

Com es llegeix, que és el que cal aprendre:

• L'eix horitzontal NO és temps. És l'agrupació alfabètica de les piles. L'amplada d'un bloc és la proporció de mostres en què aquella funció era a la pila.
• L'eix vertical és la profunditat de la pila. A baix el punt d'entrada, a dalt la funció que s'estava executant en aquell instant.
• El que busques són altiplans amples, especialment a la part alta: una funció ampla a dalt és una funció on el procés passa molt de temps realment executant. Una funció ampla a baix amb moltes torres fines a sobre és només un punt de pas.

El resultat és un SVG interactiu: s'obre en un navegador, es pot fer clic per ampliar una branca i cercar per nom de funció.

Existeix una variant molt útil que gairebé ningú no coneix: el gràfic de flama fora de CPU (off-CPU). El normal mostra on es consumeix CPU; el de fora de CPU mostra on el procés està bloquejat esperant. Per a un problema de latència com el nostre —procés al 12 % de CPU— el segon és molt més informatiu, i es construeix amb eBPF en lloc de amb perf:

I perf trace, que mereix una menció perquè resol el problema de cost d'strace:

Mateixa informació que strace -T, amb un cost molt menor perquè fa servir la infraestructura d'esdeveniments del nucli en lloc de ptrace — i, de passada, no l'afecta ptrace_scope.

eBPF és el canvi més important en l'observabilitat de Linux de l'última dècada. La idea: permetre carregar programes propis dins del nucli, que s'executen quan es produeix un esdeveniment, amb tres garanties que el fan segur:

1. Un verificador analitza el programa abans de carregar-lo i rebutja tot allò que pugui penjar el nucli: bucles no acotats, accessos a memòria arbitrària, crides no permeses.
2. Es compila a codi natiu amb un JIT, així que s'executa a velocitat de nucli.
3. No pot bloquejar ni modificar el flux del nucli; només observar i agregar.

Per què això ho canvia tot: abans, per saber la latència de cada operació de disc havies de triar entre un comptador agregat (iostat, que dona la mitjana i amaga la cua) o traçar-ho tot (strace, prohibitiu). Amb eBPF pots calcular l'histograma complet dins del nucli i treure'n només el resultat. El cost és de fraccions de percentatge.

I aquí apareix el segon sysctl de 06-06 amb conseqüències:

Això impedeix que un usuari sense privilegis carregui programes eBPF, i és correcte: el subsistema BPF ha tingut vulnerabilitats d'escalada de privilegis, i la seva superfície és gran. La conseqüència pràctica és que totes les eines d'aquesta secció s'executen amb sudo, que és exactament el que vols en un servidor.

bpftrace és un llenguatge d'una línia per a eBPF, amb sintaxi inspirada en awk —que ja coneixes del Mòdul 3—: esdeveniment { acció }.

L'histograma de l'exemple 2 és la classe d'informació que cap altra eina no dona fàcilment: 300 crides a connect, amb la massa entre 4 i 16 microsegons... espera. Aquell histograma diu microsegons, i strace -c deia 8 mil·lisegons per crida. La discrepància és la pista: la crida connect al nucli és ràpida; el temps se'n va en una altra part del procés de connexió. Hi tornarem al cas pràctic.

Fixa't en la mecànica de l'exemple 2, perquè és el patró de mesura de latència amb eBPF: guardar nsecs en un mapa indexat per tid a l'entrada, restar a la sortida, i agregar amb hist(). El càlcul sencer passa dins del nucli; l'única cosa que surt a l'espai d'usuari és l'histograma final.

bpfcc-tools instal·la unes cent cinquanta eines ja escrites. Aquestes són les que es fan servir de debò:

Dues d'elles mereixen un comentari pel que aporten sobre els comptadors clàssics:

Aquells tres esdeveniments de 256-511 ms no apareixen en cap mitjana. Si coincideixen amb les peticions lentes, són la causa.

La taula que resumeix la lliçó i a la qual tornar quan tinguis un problema al davant:

I la regla d'ordre: comptadors → perf stat → eBPF → strace. De menor a major cost, i strace en últim lloc precisament perquè és el més car. La intuïció contrària —començar per strace perquè és el més conegut— és la que produeix diagnòstics que degraden el servei que intenten arreglar.

Una nota sobre abocaments: si el problema és una caiguda, no una lentitud, l'eina és una altra. Recorda que a 06-06 vas posar * hard core 0 a limits.conf perquè els abocaments no exposessin secrets; per depurar una caiguda caldria revertir-ho temporalment, i coredumpctl de systemd és la via moderna.

revisio_salut.sh comença a retornar 1. La línia base de 05-07 diu que l'aplicació respon en 40 ms; ara triga 400.

Confirmat i reproduïble: ~400 ms, no un pic aïllat.

CPU al 95 % ociosa, disc al 0,4 % d'utilització, 2,4 GB de memòria disponible. Cap recurs no està saturat. Aquest és exactament l'escenari que anunciava el tancament de 07-01: els comptadors en verd i el servei malament.

12,8 % d'un nucli i 3.412 canvis de context. El procés es bloqueja constantment. La hipòtesi passa a ser: està esperant alguna cosa externa. Els candidats són disc (descartat per iostat) i xarxa — és a dir, PostgreSQL.

Amb sudo, pel ptrace_scope, i amb límit de temps pel cost:

300 crides a connect en 10 segons, a 8 ms cadascuna. Amb ~75 peticions en aquell interval, en surten unes 4 connexions noves per petició. Una aplicació amb un grup de connexions no n'hauria d'obrir cap.

Aquí és on la discrepància que vam deixar pendent es resol:

Tres-centes connexions a PostgreSQL, cadascuna de 8 ms de vida i uns pocs KB. S'obren, fan una consulta i es tanquen. Això és un grup de connexions que no funciona.

I l'histograma explica els 8 ms, que la crida connect sola no justificava:

La crida al sistema triga microsegons. Els 8 mil·lisegons que veia strace inclouen tot el que envolta la connexió: l'establiment TCP, i sobretot l'autenticació i l'arrencada de sessió de PostgreSQL. perf report ja ho insinuava amb SSL_connect a la pila.

18,4 de 20 segons bloquejat dins de db_connectar. Confirmat des d'una quarta eina independent.

La peça que faltava és una dada que ja tenies. Recorda l'incident de 05-07: errors.log amb connexions_actives=200 i db_timeout. Aleshores es va resoldre la saturació d'E/S, però el max_connexions=200 va quedar allà:

Aquí està la causa arrel, i és de configuració, no de codi: l'aplicació es pensa que pot tenir 200 connexions, PostgreSQL només n'accepta 100. Quan el grup intenta créixer més enllà de 100, les connexions noves són rebutjades, l'aplicació desisteix del grup i obre connexions directes per petició, i cadascuna costa 8 ms d'establiment i autenticació.

De 400 ms a 40 ms. De 300 connexions cada 10 segons a 80 en total, que és la mida del grup establint-se una sola vegada. I revisio_salut.sh torna a 0.

El que fa vàlid aquest diagnòstic no és cap eina en particular, sinó la convergència de cinc mesures independents —perf stat, strace -c, tcplife, bpftrace i offcputime— assenyalant el mateix punt, més una hipòtesi final verificada per comparació abans/després. I la nota per al manual d'operació: canviar un límit en un costat d'una relació client-servidor sense comprovar l'altre costat és l'error que va provocar això, i va passar fa tres mòduls.

• Començar per strace. És l'eina més coneguda i la més cara. L'ordre és comptadors → perf stat → eBPF → strace.
• strace sense -e trace= ni -c en producció. Cent mil línies il·legibles i un servei cent vegades més lent. Si has de traçar en producció, timeout 5 strace -f -c -p PID.
• Oblidar -f. Sense seguir fills i fils, en una aplicació multifil en perds gairebé tot.
• Confondre el temps d'strace -c amb el temps total del procés. % time és la proporció dins de crides al sistema. Si el programa crema CPU al seu codi, allà no apareix: per a això hi ha perf.
• Matar strace amb SIGKILL. Pot deixar el procés traçat aturat. Surt amb Ctrl+C.
• Interpretar tots els ENOENT com a errors. Una arrencada normal en genera desenes buscant biblioteques i locales. Filtra el soroll abans de concloure.
• Abaixar ptrace_scope i oblidar restaurar-lo. Deixa oberta la lectura de memòria entre processos del mateix usuari, i amb ella els secrets. Fes servir sudo, o un script amb trap.
• Refiar-se de la mitjana de latència. iostat pot donar 1 ms de mitjana mentre l'1 % de les operacions triga 500 ms. biolatency-bpfcc mostra la distribució, i la cua és el que l'usuari nota.
• Mostrejar a 100 Hz. Es pot sincronitzar amb esdeveniments periòdics del sistema i esbiaixar la mostra. Fes servir un primer proper: -F 99.
• Buscar el problema de latència en un gràfic de flama normal. El de CPU mostra on es consumeix; per a un procés que espera necessites el de fora de CPU (offcputime-bpfcc).
• Concloure amb una sola eina. Aquest cas es va resoldre amb cinc mesures convergents. Una de sola hauria donat una resposta plausible i probablement incompleta.
• Consell de mètode. Guarda les mesures del diagnòstic al costat de la línia base de 05-07: què mesuraves, amb quina ordre, i el valor normal. La propera vegada, el pas 2 són trenta segons en lloc de vint minuts.

copia_tramontana.sh trigava 40 minuts i ara triga 3 hores, cosa que fa que la còpia de les 02:30 no acabi abans del pic del matí — l'incident de 05-07 una altra vegada. iostat mostra el disc al 45 % d'utilització, molt lluny de la saturació. Dissenya el procediment de diagnòstic indicant quina eina faries servir a cada pas i per què, sabent que la còpia fa servir restic sobre un volum xifrat amb LUKS.

Escriu un script diagnostic_latencia.sh que, donat el nom d'un servei de systemd, executi automàticament els passos 2, 3 i 4 de la metodologia —comptadors, perf stat i strace -c— i produeixi un informe llegible. Ha de respectar les convencions del curs, gestionar el ptrace_scope de forma segura, i no deixar residus.

Un company proposa posar kernel.yama.ptrace_scope = 0 de forma permanent «perquè així podem diagnosticar sense sudo». Redacta la resposta tècnica: què s'hi guanya, què s'hi perd exactament, i quina alternativa proposes.

Solució 1

La clau de l'enunciat és «45 % d'utilització», que descarta la saturació però no descarta la latència: són dues coses diferents i confondre-les és l'error habitual. Un disc al 45 % pot tenir una cua de peticions lentes.

Amb w_await de 38 ms i %util del 45 %, ja hi ha una anomalia: hi ha latència sense saturació, cosa que apunta a operacions individualment lentes o a un coll d'ampolla en algun punt de la pila.

I aquí està el raonament específic de l'exercici: /srv/tramontana/backups és un volum LUKS sobre LVM sobre sda. Són tres capes, i la latència cal atribuir-la a una:

La interpretació, que és el que es demana:

• CPUs utilized a prop d'1,00 i profile-bpfcc mostrant funcions d'AES: el coll és el xifratge per programari. Causes possibles: la VM no exposa AES-NI a l'hoste, o la CPU no el té. Es comprova amb /proc/cpuinfo i es resol activant host-passthrough a la configuració de la VM (ho veuràs a 07-04) o canviant el xifratge de LUKS.
• CPUs utilized baix i offcputime mostrant espera en E/S: el coll és el disc. Aleshores biolatency -D diu si la latència ja ve de sda, i el pas següent és ext4slower-bpfcc per veure quines operacions concretes triguen.
• Canvis de context molt alts amb tots dos baixos: contenció entre restic i un altre procés. runqlat-bpfcc ho confirmaria.

I dues hipòtesis alternatives que cal descartar abans de tocar res, perquè són més probables que un problema de maquinari:

Un repositori de restic sense forget --prune acumula dades i alenteix cada operació. Si la retenció GFS 14/8/12 va deixar d'executar-se, aquella és l'explicació més simple — i comprovar-ho és gratis. Abans de diagnosticar el maquinari, descarta l'avorrit.

Nota final de mètode: l'ionice que es va posar a 05-07 continua aplicant-se i és correcte que el procés cedeixi E/S. Però si la còpia ja no cap a la seva finestra, ionice deixa de ser suficient i cal atacar la causa, no el símptoma.

Solució 2

Les decisions de disseny que fan que aquest script sigui utilitzable en producció i no un perill:

1. MainPID en lloc de pgrep. systemctl show -p MainPID dona el procés que systemd considera principal. pgrep -f tramontana podria agafar el mateix script, un grep, o un procés d'un altre release.
2. L'ordre dels passos és el de cost creixent, i strace va l'últim. Si el problema es veu al pas 2, ja tens la resposta abans de pagar res.
3. sudo per a strace, mai tocar ptrace_scope. És la sortida A de la lliçó, i és l'única acceptable en un script que pot executar qualsevol.
4. timeout obligatori a strace, amb || true perquè el codi 124 de timeout és el resultat esperat, no una fallada. Sense això, set -e avortaria l'script just abans d'escriure les conclusions.
5. Degradació elegant. Si perf o eBPF no hi són, l'informe ho diu i continua. Un script de diagnòstic que falla perquè falta una eina opcional és inútil precisament quan més el necessites.
6. Un mktemp -d amb trap, segons 04-06: no deixa residus ni en interrompre's.
7. La secció final orienta el pas següent. L'script automatitza els passos mecànics; la interpretació continua sent humana, i donar a l'operador l'arbre de decisió és més útil que intentar concloure automàticament.

Solució 3

Resposta tècnica: proposta de fixar kernel.yama.ptrace_scope = 0

Què s'hi guanya. Poder executar strace, gdb i perf contra processos del mateix usuari sense sudo. A la pràctica això estalvia escriure quatre caràcters, perquè a srv-tramontana l'aplicació corre com a svc-tramontana i nosaltres com a operador: amb ptrace_scope = 0 continuaríem necessitant sudo, ja que el valor 0 només permet traçar processos del propi usuari. El benefici real de la proposta, en el nostre cas concret, és zero.

Què s'hi perd, exactament. ptrace permet llegir i escriure tota la memòria d'un altre procés. La memòria del procés de l'aplicació conté, en clar i necessàriament:

• La contrasenya de la base de dades, que a 06-05 vam treure d'app.conf i vam xifrar amb systemd-creds precisament perquè no fos llegible.
• La clau privada TLS, si el procés la carrega.
• Les dades personals d'hostes de les peticions en curs.

Amb ptrace_scope = 0, qualsevol procés compromès que s'executi com el mateix usuari pot extreure tot allò sense tocar cap fitxer: sense escriptures que AIDE detecti, sense accessos que auditd registri a les rutes que vigilem, i sense deixar rastre als registres. És a dir, anul·laria a la pràctica la feina de dues lliçons senceres del mòdul anterior.

Concretant sobre el nostre model d'amenaces de 06-06: la segona amenaça per probabilitat és la credencial filtrada, i la quarta l'abús d'accés legítim. Aquesta proposta obre una via directa per a totes dues i no en tanca cap.

Alternatives, en ordre de preferència.

1. Fer servir sudo. És la resposta correcta el 95 % de les vegades. CAP_SYS_PTRACE ignora la restricció de Yama, queda registrat a auth.log —cosa que és un avantatge, no un inconvenient— i no canvia la postura del sistema. Cost: cinc caràcters.
2. Fer servir eBPF, que és millor eina. perf trace, tcplife-bpfcc, biolatency-bpfcc, offcputime-bpfcc i bpftrace no fan servir ptrace en absolut, així que ptrace_scope no els afecta. I són entre deu i cent vegades més barates, cosa que les fa les úniques realment aptes per a producció. Si la motivació de fons és «diagnosticar amb comoditat», aquesta és la resposta tècnica, no abaixar una protecció.
3. Si de debò cal traçar sense privilegis, hi ha una via intermèdia: donar CAP_SYS_PTRACE únicament al binari de diagnòstic, en lloc d'obrir el sistema sencer:

   $ sudo setcap cap_sys_ptrace+ep /usr/bin/strace
   

   Reprenent les capabilities de 05-02. Continua sent un augment de superfície —qualsevol que pugui executar strace podrà traçar—, però acotat a un binari en lloc de a tot el sistema. Tot i així no ho recomano aquí: no resol el nostre cas real (usuaris diferents) i afegeix un binari privilegiat per auditar.
4. Abaixar-lo temporalment, només durant una sessió de diagnòstic, amb restauració garantida per trap (~/scripts/tracar_temporal.sh). Acceptable al laboratori; en producció és innecessari atès el punt 2.

Recomanació. Mantenir kernel.yama.ptrace_scope = 1. La proposta no aporta cap benefici a la nostra configuració —continuaríem necessitant sudo— i obre una via d'extracció de credencials i dades personals que no deixa rastre. Si el problema de fons és la fricció en diagnosticar, la solució és instal·lar i aprendre bpfcc-tools i bpftrace, que a més ens permetran diagnosticar en producció i amb càrrega, cosa que strace no permet en cap cas.

Hi afegeixo dues notes per al manual d'operació: el valor 1 està documentat a /etc/sysctl.d/60-enfortiment.conf amb un comentari que ja advertia d'aquest efecte secundari; i convé registrar aquí que el diagnòstic de l'incident de latència d'aquesta setmana es va resoldre íntegrament amb eBPF i sudo strace, sense necessitat de tocar el paràmetre.

Ja saps mirar dins d'un procés en marxa. Tens tres famílies d'eines i —el més important— el criteri per triar entre elles: els comptadors del Mòdul 5 responen a quant i són gratis, perf stat diu si un procés treballa o espera amb un cost menyspreable, eBPF instrumenta el nucli en producció amb histogrames que revelen les cues que les mitjanes amaguen, i strace dona la resposta exacta a costa d'alentir el procés fins a cent vegades. L'ordre comptadors → perf stat → eBPF → strace és la lliçó pràctica que cal endur-se, juntament amb la línia que resol la meitat dels misteris de configuració: strace -e trace=%file | grep ENOENT.

Has resolt un cas complet seguint la metodologia: símptoma mesurat i reproduïble, hipòtesis descartades amb comptadors gratuïts, i cinc mesures independents convergint en la mateixa causa —un max_connexions=200 contra un max_connections=100, un desajust que feia tres mòduls que hi era— amb la correcció verificada de 400 ms a 40 ms. I t'has topat amb la conseqüència del teu propi enfortiment: el ptrace_scope = 1 que impedeix traçar sense privilegis, que resulta que està bé perquè la memòria d'un procés conté en clar exactament els secrets que tanta feina va costar xifrar. Que la solució correcta a aquella fricció sigui fer servir eBPF, i no abaixar la protecció, és la classe de decisió que distingeix un administrador d'algú que segueix receptes.

Fixa't en un detall d'aquest diagnòstic que orienta el que ve: la causa era un valor de configuració, i el vas trobar comparant dos costats d'una mateixa relació. Aquell és el terreny de la lliçó següent, amb una diferència important: aquí el valor era a l'aplicació, i ara tocaràs els del nucli. A la lliçó 07-03: Optimització del Nucli de Linux aprendràs a ajustar sysctl per rendiment —no per seguretat, que ja ho vas fer a 06-06—: la memòria virtual amb swappiness i els llindars de pàgines brutes, la xarxa amb somaxconn i el control de congestió BBR, els límits de fitxers i processos, el planificador d'E/S i per què un NVMe vol none, i les pàgines enormes transparents que tota base de dades demana desactivar. Veuràs també els mòduls del nucli, dkms, i una resposta honesta a si compilar el nucli té sentit en un servidor de producció. I ho faràs amb la regla que governa tot l'assumpte i que aquesta lliçó ja t'ha ensenyat a aplicar: no s'ajusta el que no s'ha mesurat, un sol canvi cada vegada, i mesurar abans i després. Recorda que el somaxconn per defecte continua allà, i que aquell errors.log amb connexions_actives=200 tenia més d'una causa.