Niezbędne monitorowanie PostgreSQL — część 1

Jakie metryki wdrożenia PostgreSQL należy monitorować? Ta seria postów na blogu ma na celu zapewnienie minimalnego, początkowego zestawu podstawowych działań monitorujących, które należy wdrożyć, aby zapewnić kondycję i stabilność serwerów Postgres.

Pierwsza część obejmuje parametry na poziomie klastra.

Część 1:Poziom klastra

W żargonie Postgres:klaster to zestaw baz danych zarządzanych przez pojedynczą instancję serwera Postgres. Funkcje takie jak replikacja i archiwizacja WAL na poziomie klastra.

1. Zakres identyfikatorów transakcji

Z perspektywy normalnego klienta pliki danych klastra PostgreSQL będą wydawały się zawierać migawkę danych zmodyfikowanych przez ostatnią zatwierdzoną transakcję. Jednak ze względu na architekturę MVCC Postgresa, fizyczne pliki zawierają nie tylko dane dla ostatniej transakcji, ale także dla szeregu transakcji kończących się na ostatniej. (Regularne odkurzanie usuwa dane dotyczące starszych transakcji.)

Każda transakcja ma unikalny 32-bitowy identyfikator w postaci liczby całkowitej, zwany identyfikatorem transakcji . Z różnych powodów różnica między identyfikatorami pierwszej i ostatniej transakcji powinna wynosić mniej niż 2, czyli około 2 miliardów.Utrzymywanie zakresu znacznie poniżej tego limitu jest konieczne – przeczytaj tę prawdziwą historię o tym, co dzieje się inaczej.

Działanie:stale monitoruj zakres identyfikatorów transakcji, ostrzegaj, jeśli wartość przekroczy ustawiony próg.

Jak to zrobić:

-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
       regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
  FROM pg_control_checkpoint();

-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
  FROM pg_database;

2. Liczba backendów

Każdy backend reprezentuje albo klienta podłączonego do serwera, albo proces systemowy backend (np. pracownik automatycznego odkurzania, zapisujący w tle itp.). Każdy backend jest również procesem systemu operacyjnego, który zużywa zasoby systemu operacyjnego, takie jak pamięć, otwarte deskryptory plików itp. Zbyt wiele backendów, zwykle z powodu zbyt wielu klientów lub zbyt wielu długotrwałych zapytań, może wywierać presję na zasoby systemu operacyjnego i spowolnić czasy odpowiedzi na zapytania dla każdego klienta.

Działanie:monitoruj maksymalną liczbę backendów każdego dnia/tygodnia, badaj rosnące trendy.

Jak to zrobić:

-- returns the count of currently running backends
SELECT count(*)
  FROM pg_stat_activity;

3. Nieaktywne gniazda replikacji

Gniazda replikacji są oznaczane jako „nieaktywne”, gdy klient replikacji podłączony do gniazda rozłącza się. Nieaktywne gniazda replikacji powodują, że pliki WAL są zachowywane, ponieważ będą musiały zostać wysłane do klienta po ponownym połączeniu się, a gniazda staną się aktywne. Rzeczywiście, pierwszą rzeczą, którą należy sprawdzić, czy liczba plików WAL nie spada, jest sprawdzenie, czy masz nieaktywne gniazda replikacji.

Często nieaktywne gniazda replikacji są wynikiem usunięcia klienta kopii zapasowej, odłączenia urządzenia podrzędnego, promocji, przełączeń awaryjnych i tym podobnych.

Działanie:stale sprawdzaj, czy nie ma nieaktywnych przedziałów replikacji, ostrzegaj, jeśli takie istnieją.

Jak to zrobić:

-- returns the count of inactive replication slots
SELECT count(*)
  FROM pg_replication_slots
 WHERE NOT active;

4. Backendy czekają na blokady

Instrukcje SQL mogą jawnie lub niejawnie powodować oczekiwanie innych instrukcji SQL. Na przykład uruchomienie „SELECT .. FOR UPDATE” jawnie deklaruje blokadę dla wybranych wierszy, a uruchomienie „UPDATE” umieszcza niejawne blokady wyłączne dla wierszy.Inne instrukcje SQL, gdy napotkanie blokady będzie musiało poczekać, aż pierwsza instrukcja zrezygnuje z blokady, przed kontynuowaniem jej wykonywania.

Może to objawiać się niską wydajnością aplikacji podczas cotygodniowych uruchomień raportów, przekroczeniem limitu czasu transakcji/stron internetowych i tym podobnych.

Chociaż nie da się uniknąć pewnej liczby blokad, rosnący trend backendów oczekujących na blokady zazwyczaj wymaga zmiany struktury zapytań lub logiki aplikacji.

Działanie:monitoruj maksymalną liczbę backendów oczekujących na blokady każdego dnia/tygodnia, badaj rosnące trendy.

Jak to zrobić:

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE wait_event = 'Lock';

5. Backendy bezczynne w transakcji

Długotrwałe transakcje nie są zbyt przyjemne w świecie PostgreSQL. Mogą powodować gromadzenie się plików WAL, zapobiegać automatycznemu i ręcznemu odkurzaniu oraz zużywać zasoby. Niewiele można zrobić w przypadku prawdziwych transakcji, których ukończenie zajmuje dużo czasu, ale zdarzają się przypadki, takie jak nieprawidłowe działanie aplikacji/skryptów i okazjonalny klient psql, który rozpoczyna transakcje, ale ich nie zamyka. Backendy, które obsługują takich klientów, pojawiają się jako „bezczynne w transakcji”.

Backendy, które są bezczynne w transakcji, powinny zostać wykryte i zamknięte, zanim zaczną wpływać na stabilność systemu.

Działanie:stale monitoruj liczbę backendów nieaktywnych w transakcji, sprawdzaj, czy jakieś zostały znalezione.

Jak to zrobić:

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE state = 'idle in transaction';

6. Opóźnienie replikacji dla aktywnych połączeń

Gdy istnieją aktywne klienty replikacji strumieniowej (takie jak hot-standby) lub aktywne klienty replikacji logicznej, Postgres uruchamia backend systemu o nazwie WAL sender dla każdego aktywnego (podłączonego) klienta. Nadawca WAL jest odpowiedzialny za wysyłanie danych rekordu WAL, których potrzebuje klient.

Klienci replikacji zazwyczaj starają się jak najwięcej nadążać za podstawową. Czasami jednak szybkość generowania WAL po stronie pierwotnej może być wyższa niż szybkość, z jaką klient jest w stanie je wykorzystać. Powoduje to opóźnienie replikacji dla każdego połączenia replikacji.

PostgreSQL zapewnia mechanizm zapytań o opóźnienie zapisu (liczba bajtów wysłanych, ale niezapisanych na dysk klienta), opóźnienie opróżnienia (liczba bajtów zapisanych, ale nie wyczyszczonych na dysk klienta) i opóźnienie powtórzenia (liczba bajtów usuniętych, ale nieodtworzonych na dysku klienta). bazy danych) dla każdego aktywnego nadawcy WAL.

Działanie:stale monitoruj opóźnienia replikacji dla aktywnych połączeń, ostrzegaj, jeśli wartości przekraczają ustawione progi.

Jak to zrobić:

-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
       flush_lsn - write_lsn AS flush_lag,
       replay_lsn - flush_lsn AS replay_lag
  FROM pg_stat_replication;

7. Opóźnienie replikacji dla gniazd replikacji

Klienci mogą nie tylko pozostawać w tyle, ale mogą też całkowicie zniknąć z powodu awarii, zmian topologii lub błędów ludzkich. Może to być również zgodne z projektem, w którym klienci nie zawsze są online.

Jeśli klient jest wspierany przez gniazdo replikacji, wszystkie pliki WAL niezbędne do wznowienia przez klienta od momentu, w którym zostało przerwane, są zachowywane przez PostgreSQL. Pliki WAL będą przechowywane przez czas nieokreślony – nie ma możliwości ustalenia limitu. Gdy klient ponownie się połączy, wszystkie zachowane dane muszą być najpierw przesłane strumieniowo do klienta, co może wiązać się z dużym obciążeniem dysku i ruchem sieciowym na serwerze podstawowym. Z tych powodów powinieneś monitorować opóźnienie również na poziomie boksu.

(Uwaga:proces nadawcy WAL działa tylko wtedy, gdy klient jest podłączony i kończy działanie, gdy klient się rozłączy. Metoda WAL sender mierząca odległość od klienta nie działa, gdy klient jest rozłączony.)

Działanie:stale monitoruj opóźnienia replikacji dla logicznych przedziałów replikacji, ostrzegaj, gdy wartości przekraczają ustawiony próg.

Jak to zrobić:

-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
  FROM pg_replication_slots;

8. Liczba plików WAL

Zarządzanie plikami WAL może być irytującym zadaniem, zwłaszcza jeśli masz klientów WALarchiving lub streaming replikacji. Liczba plików WAL może zacząć rosnąć bez wyraźnego powodu, proces archiwizacji WAL może nie nadążać za szybkością generowania WAL, a całkowity rozmiar pliku WAL może osiągnąć terabajty.

Musisz przynajmniej monitorować liczbę plików WAL obecnych w katalogu bazy danych i upewnić się, że liczba ta wygląda na rozsądną dla twojego wdrożenia.

Działanie:stale monitoruj liczbę plików WAL, ostrzegaj, jeśli wartość przekroczy ustawiony próg.

Jak to zrobić:

-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
  FROM pg_ls_waldir();

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';

-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'

9. Liczba gotowych do archiwizacji plików WAL

Gdy archiwizacja WAL jest włączona, PostgreSQL wywołuje skrypt użytkownika za każdym razem, gdy generowany jest nowy plik WAL. Skrypt ma „zarchiwizować” pojedynczy plik WAL, dla którego został wywołany (zwykle kopiuje go na inny serwer lub do zasobnika S3). Jeśli skrypt wykonuje swoje zadanie zbyt długo lub nie powiedzie się, zestaw plików WAL do być archiwizowane w stosach.

Działanie:stale monitoruj liczbę plików gotowych do archiwizacji WAL, ostrzegaj, jeśli wartość przekroczy ustawiony próg.

Jak to zrobić:

-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
  FROM pg_ls_archive_statusdir()
 WHERE name ~ '^[0-9A-F]{24}.ready$';

-- same, for v10+
SELECT count(*)
  FROM pg_ls_dir('pg_wal/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .ready

Zbieranie tych danych

Powyższe sekcje zawierają instrukcje SQL umożliwiające wyodrębnienie potrzebnych metryk z działającego serwera Postgres. Jeśli wolisz nie pisać skryptów samodzielnie, sprawdź narzędzie open source pgmetrics. Może zbierać powyższe dane i nie tylko oraz raportować je w formatach tekstowych i JSON.

Możesz bezpośrednio wysyłać raporty pgmetrics do naszej oferty handlowej,pgDash, która przechowuje i przetwarza te raporty w celu wyświetlania wykresów i wykonywania alertów.

Dalej

Dalsze części tej serii będą obejmować metryki na poziomie bazy danych, tabeli, indeksu i systemu. Bądź na bieżąco!