Urmăriți o cerere lentă înainte de redimensionare

Alegeți o solicitare cu un rezultat așteptat clar

Pentru un endpoint de raport ilustrativ, înregistrați modelul rutei, dimensiunea aproximativă a datelor, contextul de autentificare și dacă creează activitate în fundal. Folosiți un cont de test și date reprezentative sanitizate. Nu copiați token-uri, identificatori de client sau corpuri complete de cerere într-o notă de incident.

Separați costul de pornire al primei cereri de comportamentul repetat în regim staționar. Înregistrați fereastra UTC și revizia versiunii. Determinați dacă toate rutele sunt lente, doar rapoartele mari sunt afectate sau întârzierea urmează o singură dependență externă. Aceste distincții fac următoarea măsurătoare mai utilă decât o colecție largă de metrici fără legătură.

Construiți o cronologie fără dublă numărare

Urmăririle OpenTelemetry conectează span-uri asociate prin context propagat peste granițele serviciilor. Doar potrivirea marcajelor de timp nu este suficientă. Span-urile sincrone imbricate și apelurile paralele se pot suprapune. Copiii asincroni pot supraviețui părintelui, astfel încât adăugarea fiecărei durate de span poate dubla timpul scurs. Urmăriți operațiunile care determină când se finalizează cererea.

Referință tehnică: Urmăriri OpenTelemetry · Comportamentul de încheiere a span-urilor OpenTelemetry.

Cel mai mare interval sugerează unde să inspectați, nu cauza rădăcină. Un interval de bază de date măsurat în API poate include așteptarea unei conexiuni înainte ca o interogare să ajungă la baza de date. Telemetria lipsă, de asemenea, nu dovedește că nu s-a produs nicio activitate; inspectați eșantionarea și acoperirea instrumentării.

Corelați observațiile aplicației cu cele ale host-ului

Colectați temporizări ale cererilor, erori, utilizarea conexiunilor la baza de date, vechimea cozii, CPU, memorie și presiunea pe disc pentru aceeași fereastră. Notați backup-urile, migrările sau lansările concurente. O singură captură de utilizare poate rata explozia care a afectat cererea.

Folosiți ID-uri de corelare și marcaje de timp în jurnalele redactate cu retenție și controale de acces adecvate. Evitați secretele brute, payload-urile clienților și etichetele de metrici nemărginite. Instrumentați granița necesară pentru ipoteză și revizuiți overhead-ul. Un nou agent de urmărire este el însuși o schimbare demnă de observat.

Inspectați interogarea fără a provoca un alt incident

Identificați mai întâi forma interogării, caracteristicile dimensiunii de intrare și așteptările de conexiune sau blocare. PostgreSQL EXPLAIN descrie un plan; EXPLAIN ANALYZE execută efectiv instrucțiunea și adaugă overhead de instrumentare. O scriere poate modifica date, în timp ce o citire costisitoare creează totuși încărcare. Folosiți o bază de date reprezentativă izolată pentru investigarea inițială.

Costul planificatorului nu este milisecunde scurse. Un tabel de test minuscul poate produce un plan diferit de setul de date mai mare al aplicației. Revizuiți statisticile, indexurile și distribuția și comparați aceeași formă de interogare după modificare. Nu lipiți niciodată o scriere necunoscută într-o comandă de analiză pe producție doar pentru a obține temporizarea.

Referință tehnică: PostgreSQL EXPLAIN.

Preziceți ce ar trebui să îmbunătățească o singură modificare

Dacă așteptarea pool-ului domină, inspectați conexiunile lucrătorilor sau cererile care dețin o conexiune inutil. Dacă execuția interogării domină, inspectați planul și rândurile solicitate. Dacă un API extern domină, revizuiți timeout-urile, reîncercările și dacă munca trebuie să fie sincronă. Saturația CPU în timpul serializării indică un alt experiment.

Scrieți o predicție: reducerea concurenței la export ar trebui să reducă așteptarea pool-ului API, în timp ce exporturile durează mai mult. Aceasta expune compromisul. Repetați același mix de cereri, comparați latența și erorile și verificați că îmbunătățirea nu a mutat pur și simplu eșecul într-o coadă în creștere continuă.

Păstrați rezultatul și incertitudinea lui

Înregistrați observația originală, modificarea testată, metoda de comparație și incertitudinea rămasă. Dacă dovezile contrazic ipoteza, anulați modificarea izolată acolo unde este cazul și investigați o altă graniță. Evitați acumularea de modificări permanente de reglaj fără explicație.

Redimensionați când măsurătorile identifică o constrângere de resurse pe care o alocare suplimentară ar putea-o adresa. Folosiți bugetul de încărcare și capturați o regresie de lansare în rezumatul incidentului. Rezultatul este un diagnostic argumentat, nu o latență promisă sau un benchmark al furnizorului.