Verfolgen Sie eine langsame Anfrage vor der Größenanpassung

Wählen Sie eine Anfrage mit einem klaren erwarteten Ergebnis

Erfassen Sie für einen beispielhaften Report-Endpunkt das Routenmuster, die ungefähre Datengröße, den Authentifizierungskontext und ob er Hintergrundarbeit erzeugt. Verwenden Sie ein Testkonto und repräsentative bereinigte Daten. Kopieren Sie keine Tokens, Kundenkennungen oder vollständige Anfragetexte in eine Vorfallnotiz.

Trennen Sie die Startkosten der ersten Anfrage vom wiederholten Verhalten im eingeschwungenen Zustand. Erfassen Sie das UTC-Zeitfenster und die Release-Revision. Stellen Sie fest, ob alle Routen langsam sind, nur große Reports betroffen sind oder die Verzögerung einer externen Abhängigkeit folgt. Diese Unterscheidungen machen die nächste Messung nützlicher als eine breite Sammlung unzusammenhängender Metriken.

Erstellen Sie eine Zeitachse ohne Doppelzählung

OpenTelemetry-Traces verbinden zusammengehörige Spans durch propagierten Kontext über Dienstgrenzen hinweg. Übereinstimmende Zeitstempel allein reichen nicht aus. Verschachtelte synchrone Spans und parallele Aufrufe können sich überlappen. Asynchrone Kinder können ihre Eltern überleben, sodass das Addieren aller Span-Dauern die verstrichene Zeit doppelt zählen kann. Folgen Sie den Operationen, die bestimmen, wann die Anfrage abgeschlossen ist.

Technische Referenz: OpenTelemetry-Traces · Endverhalten von OpenTelemetry-Spans.

Das größte Intervall deutet darauf hin, wo untersucht werden sollte, nicht auf die Grundursache. Ein in der API gemessenes Datenbankintervall kann das Warten auf eine Verbindung einschließen, bevor eine Abfrage die Datenbank erreicht. Fehlende Telemetrie beweist ebenfalls nicht, dass keine Arbeit stattgefunden hat; prüfen Sie Sampling und Instrumentierungsabdeckung.

Korrelieren Sie Anwendungs- und Host-Beobachtungen

Sammeln Sie Anfragezeiten, Fehler, Datenbankverbindungsnutzung, Queue-Alter, CPU-, Speicher- und Datenträgerdruck für dasselbe Zeitfenster. Notieren Sie gleichzeitige Backups, Migrationen oder Releases. Ein einzelner Auslastungs-Screenshot kann den Burst verfehlen, der die Anfrage beeinträchtigt hat.

Verwenden Sie Korrelations-IDs und Zeitstempel in redigierten Protokollen mit angemessener Aufbewahrung und Zugriffskontrollen. Vermeiden Sie rohe Geheimnisse, Kunden-Payloads und unbegrenzte Metrik-Labels. Instrumentieren Sie die für die Hypothese erforderliche Grenze und prüfen Sie den Overhead. Ein neuer Tracing-Agent ist selbst eine Änderung, die es wert ist, beobachtet zu werden.

Untersuchen Sie die Abfrage, ohne einen weiteren Vorfall auszulösen

Identifizieren Sie zuerst die Abfrageform, die Eingabegrößenmerkmale und Verbindungs- oder Sperrwartezeiten. PostgreSQL EXPLAIN beschreibt einen Plan; EXPLAIN ANALYZE führt die Anweisung tatsächlich aus und fügt Instrumentierungs-Overhead hinzu. Ein Schreibvorgang kann Daten ändern, während ein teurer Lesevorgang dennoch Last erzeugt. Verwenden Sie für die erste Untersuchung eine isolierte repräsentative Datenbank.

Planner-Kosten sind nicht verstrichene Millisekunden. Eine winzige Testtabelle kann einen anderen Plan ergeben als der größere Datensatz der Anwendung. Überprüfen Sie Statistiken, Indizes und Verteilung und vergleichen Sie dieselbe Abfrageform nach der Änderung. Fügen Sie niemals einen unbekannten Schreibvorgang nur zur Zeitmessung in einen Analysebefehl in der Produktion ein.

Technische Referenz: PostgreSQL EXPLAIN.

Sagen Sie voraus, was eine Änderung verbessern sollte

Wenn Pool-Warten dominiert, untersuchen Sie Worker-Verbindungen oder Anfragen, die eine Verbindung unnötig halten. Wenn die Abfrageausführung dominiert, untersuchen Sie den Plan und die angeforderten Zeilen. Wenn eine externe API dominiert, überprüfen Sie Timeouts, Wiederholungsversuche und ob die Arbeit synchron sein muss. CPU-Sättigung während der Serialisierung deutet auf ein anderes Experiment hin.

Schreiben Sie eine Vorhersage: Reduzierung der Export-Parallelität sollte das Warten auf den API-Pool verringern, während Exporte länger dauern. Dies legt den Trade-off offen. Wiederholen Sie denselben Anforderungsmix, vergleichen Sie Latenz und Fehler und prüfen Sie, ob die Verbesserung den Fehler nicht einfach in eine ständig wachsende Warteschlange verlagert hat.

Behalten Sie das Ergebnis und seine Unsicherheit

Dokumentieren Sie die ursprüngliche Beobachtung, die getestete Änderung, die Vergleichsmethode und die verbleibende Unsicherheit. Wenn Beweise der Hypothese widersprechen, machen Sie die isolierte Änderung gegebenenfalls rückgängig und untersuchen Sie eine andere Grenze. Vermeiden Sie die Anhäufung dauerhafter Tuning-Änderungen ohne Erklärung.

Ändern Sie die Größe, wenn Messungen eine Ressourcenbeschränkung identifizieren, die durch zusätzliche Zuweisung behoben werden könnte. Verwenden Sie das Workload-Budget und erfassen Sie eine Release-Regression im Incident-Brief. Das Ergebnis ist eine begründete Diagnose, kein versprochenes Latenz- oder Anbieter-Benchmark.