Prześledź jedno wolne żądanie przed zmianą rozmiaru

Wybierz żądanie o jasnym oczekiwanym wyniku

Dla przykładowego punktu końcowego raportu zapisz wzorzec trasy, przybliżony rozmiar danych, kontekst uwierzytelniania i to, czy tworzy pracę w tle. Użyj konta testowego i reprezentatywnych zsanityzowanych danych. Nie kopiuj tokenów, identyfikatorów klientów ani pełnych treści żądań do notatki o incydencie.

Oddziel koszt startu pierwszego żądania od powtarzalnego zachowania w stanie ustalonym. Zapisz okno UTC i wersję wydania. Ustal, czy wszystkie trasy są wolne, czy dotyczy to tylko dużych raportów, albo czy opóźnienie wynika z jednej zależności zewnętrznej. Te rozróżnienia czynią następny pomiar użyteczniejszym niż szeroki zbiór niepowiązanych metryk.

Zbuduj os czasu bez podwójnego liczenia

Ślady OpenTelemetry łączą powiązane spany poprzez propagowany kontekst przez granice usług. Same zgodne znaczniki czasu nie wystarczą. Zagnieżdżone synchroniczne spany i równoległe wywołania mogą się nakładać. Asynchroniczne dzieci mogą żyć dłużej niż rodzic, więc dodawanie czasu trwania każdego spanu może podwójnie liczyć czas, który upłynął. Śledź operacje, które decydują o zakończeniu żądania.

Dokumentacja techniczna: Ślady OpenTelemetry · Zachowanie końca spanu OpenTelemetry.

Największy interwał sugeruje, gdzie sprawdzić, a nie przyczynę źródłową. Interwał bazy danych mierzony w API może obejmować oczekiwanie na połączenie, zanim zapytanie dotrze do bazy danych. Brak telemetrii również nie dowodzi, że nie wykonano żadnej pracy; sprawdź próbkowanie i pokrycie instrumentacji.

Skoreluj obserwacje aplikacji i hosta

Zbierz czasy żądań, błędy, użycie połączeń do bazy danych, wiek kolejki, obciążenie CPU, pamięci i dysku dla tego samego okna. Zanotuj równoczesne kopie zapasowe, migracje lub wydania. Pojedynczy zrzut wykorzystania może pominąć skok, który wpłynął na żądanie.

Używaj identyfikatorów korelacji i znaczników czasu w zredagowanych logach z odpowiednim okresem przechowywania i kontrolą dostępu. Unikaj surowych sekretów, ładunków klientów i nieograniczonych etykiet metryk. Instrumentuj granicę potrzebną dla hipotezy i sprawdź narzut. Nowy agent śledzenia sam w sobie jest zmianą wartą obserwacji.

Sprawdź zapytanie bez wywoływania kolejnego incydentu

Najpierw zidentyfikuj kształt zapytania, charakterystykę rozmiaru danych wejściowych oraz oczekiwanie na połączenie lub blokadę. PostgreSQL EXPLAIN opisuje plan; EXPLAIN ANALYZE faktycznie wykonuje instrukcję i dodaje narzut instrumentacji. Zapis może zmienić dane, podczas gdy kosztowny odczyt nadal tworzy obciążenie. Do wstępnego badania użyj odizolowanej reprezentatywnej bazy danych.

Koszt planisty to nie milisekundy, które upłynęły. Malutka tabela testowa może dać inny plan niż większy zbiór danych aplikacji. Sprawdź statystyki, indeksy i rozkład, a następnie porównaj ten sam kształt zapytania po zmianie. Nigdy nie wklejaj nieznanego zapisu do polecenia analizy na produkcji tylko po to, aby uzyskać czas.

Dokumentacja techniczna: PostgreSQL EXPLAIN.

Przewidź, co powinna poprawić jedna zmiana

Jeśli dominuje oczekiwanie na pulę, sprawdź połączenia workerów lub żądania, które niepotrzebnie trzymają połączenie. Jeśli dominuje wykonanie zapytania, sprawdź plan i żądane wiersze. Jeśli dominuje zewnętrzne API, sprawdź limity czasu, ponowienia i to, czy praca musi być synchroniczna. Nasycenie CPU podczas serializacji wskazuje na inny eksperyment.

Zapisz przewidywanie: zmniejszenie współbieżności eksportu powinno zmniejszyć oczekiwanie na pulę API, a eksporty potrwają dłużej. Ujawnia to kompromis. Powtórz ten sam zestaw żądań, porównaj opóźnienia i błędy oraz sprawdź, czy poprawa nie przeniosła po prostu awarii do stale rosnącej kolejki.

Zachowaj wynik i jego niepewność

Zapisz pierwotną obserwację, przetestowaną zmianę, metodę porównania i pozostałą niepewność. Jeśli dowody przeczą hipotezie, cofnij odizolowaną zmianę, gdy to właściwe, i zbadaj inną granicę. Unikaj gromadzenia trwałych zmian strojenia bez wyjaśnienia.

Zmień rozmiar, gdy pomiary zidentyfikują ograniczenie zasobów, które dodatkowa alokacja mogłaby rozwiązać. Użyj budżet obciążenia i uchwyć regresję wydania w krótka notatka o incydencie. Wynikiem jest uzasadniona diagnoza, nie obiecane opóźnienie ani benchmark dostawcy.