Pozwolę sobie omówić temat, który nie jest z natury specyficzny dla PostgreSQL, ale który regularnie napotykam podczas badania problemów z systemami klientów, oceny „obsługiwania” tych systemów itp. Ważne jest posiadanie rozwiązania do monitorowania metryk systemowych, rozsądna konfiguracja i dlaczego sar jest nadal moim ulubionym narzędziem (przynajmniej w Linuksie).
O znaczeniu monitorowania
Po pierwsze, niezwykle ważne jest monitorowanie podstawowych wskaźników systemowych (procesor, I/O, pamięć). To trochę dziwne, że musi to wskazywać w dyskusjach z innymi inżynierami, ale powiedziałbym, że 1 na 10 inżynierów uważa, że tak naprawdę nie potrzebują monitorowania. Rozumowanie zwykle przebiega w następujący sposób:
To prawda, że monitorowanie zwiększa koszty, nie ma co do tego wątpliwości. Ale prawdopodobnie jest to znikome w porównaniu z tym, co robi aplikacja. Właściwie sar tak naprawdę nie dodaje żadnego dodatkowego oprzyrządowania, po prostu odczytuje liczniki z nernela, oblicza delty i zapisuje je na dysku. Może potrzebować trochę miejsca na dysku i we/wy (w zależności od liczby procesorów i dysków), ale to wszystko.
Na przykład zbieranie statystyk na sekundę na maszynie z 32 rdzeniami i wieloma dyskami wygeneruje ~5 GB surowych danych dziennie, ale kompresja jest bardzo dobra, często do ~5-10%). I jest ledwo widoczne w top . Rozdzielczość na sekundę jest nieco ekstremalna, a użycie 5 lub 10 sekund jeszcze bardziej zmniejszy obciążenie.
Więc nie, okazuje się, że narzut w rzeczywistości nie jest uzasadnionym powodem, aby nie włączać monitorowania.
Koszty a korzyści
Co ważniejsze jednak, „Ile kosztów ogólnych mam wyeliminować, nie włączając monitorowania?” to złe pytanie. Zamiast tego powinieneś zapytać:„Jakie korzyści odnoszę z monitorowania? Czy korzyści przewyższają koszty?”
Wiemy już, że koszty (narzuty) są dość małe lub całkowicie znikome. Jakie są korzyści? Z mojego doświadczenia wynika, że posiadanie danych z monitoringu jest bezcenne.
Po pierwsze, pozwala badać problemy – patrzenie na kilka wykresów i szukanie nagłych zmian jest zaskakująco skuteczne i często prowadzi bezpośrednio do właściwego problemu. Podobnie porównywanie bieżących danych (zebranych podczas problemu) z wartościami bazowymi (zebranymi, gdy wszystko jest w porządku) jest bardzo przydatne i niemożliwe, jeśli włączysz monitorowanie tylko wtedy, gdy coś się zepsuje.
Po drugie, pozwala oceniać trendy i identyfikować potencjalne problemy, zanim one faktycznie do Ciebie trafią. Ile procesora używasz? Czy zużycie procesora rośnie z biegiem czasu? Czy istnieją podejrzane wzorce wykorzystania pamięci? Możesz odpowiedzieć na te pytania tylko wtedy, gdy masz monitoring.
Dlaczego sar to moje ulubione narzędzie
Załóżmy, że przekonałem Cię, że monitorowanie jest ważne i zdecydowanie powinieneś to robić. Ale dlaczego sar nasze ulubione narzędzie, gdy istnieją różne wymyślne alternatywy, zarówno lokalne, jak i oparte na chmurze?
- Jest zawarty we wszystkich dystrybucjach, a jego instalacja/konfiguracja jest trywialna. To sprawia, że przekonanie ludzi do włączenia tej funkcji jest dość proste.
- Jest bezpośrednio na maszynie. Więc jeśli SSH do maszyny, możesz również uzyskać dane monitorowania.
- Wykorzystuje proste wyjście tekstowe. Trywialne przetwarzanie danych – zaimportuj je do bazy danych, przeanalizuj, dołącz do zgłoszenia do pomocy technicznej. Jest to dość trudne w przypadku innych narzędzi, które generalnie nie pozwalają na łatwe eksportowanie danych, pokazują tylko wykresy i/lub znacznie ograniczają analizę, którą możesz wykonać itp.
Przyznaję, że część z tego wynika z faktu, że pracuję dla firmy świadczącej usługi PostgreSQL dla innych firm (czy to wsparcie 24×7, czy Remote DBA. Więc zazwyczaj otrzymujemy bardzo ograniczony dostęp do systemów klientów (głównie tylko serwery baz danych i nic więcej). Oznacza to, że posiadanie wszystkich ważnych danych na samym serwerze bazy danych, dostępnych przez zwykły SSH, jest niezwykle wygodne i eliminuje niepotrzebne podróże w obie strony tylko po to, aby zażądać kolejnej porcji danych z innego systemu. Co oszczędza czas i zdrowie psychiczne po obu stronach.
Jeśli masz wiele systemów do zarządzania, prawdopodobnie wolisz rozwiązanie monitorujące, które zbiera dane z wielu maszyn w jednym miejscu. Ale dla mnie sar nadal wygrywa.
Więc jak to skonfigurować?
Wspomniałem o instalacji i włączeniu sar (a raczej sysstat , czyli pakiet zawierający sar ) jest bardzo prosta. Niestety domyślna konfiguracja jest trochę zła. Po zainstalowaniu sysstat , znajdziesz coś takiego w /etc/cron.d/sysstat (lub gdziekolwiek Twoja dystrybucja przechowuje cron konfiguracja):
*/10 * * * * root /usr/lib64/sa/sa1 1 1
To skutecznie mówi sa1 komenda będzie wykonywana co 10 minut i zbierze pojedynczą próbkę w ciągu 1 sekundy. Tutaj są dwie kwestie. Po pierwsze, 10 minut to dość niska rozdzielczość. Po drugie, próbka obejmuje tylko 1 sekundę z 600, więc pozostałe 9:59 tak naprawdę nie są w niej uwzględnione. Jest to trochę w porządku w przypadku trendów długoterminowych, gdzie wystarczy losowe próbkowanie o niskiej rozdzielczości. W innych celach prawdopodobnie będziesz musiał zrobić coś takiego:
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Który zbiera jedną próbkę na minutę, a każda próbka obejmuje jedną minutę. -S XALL oznacza, że wszystkie statystyki powinny być gromadzone, w tym przerwania, poszczególne urządzenia blokowe i partycje itp. Zobacz man sadc po więcej szczegółów.
Podsumowanie
Podsumowując ten post w kilku prostych punktach:
- Powinieneś mieć monitoring, nawet jeśli uważasz, że go nie potrzebujesz. Gdy napotkasz problemy, jest już za późno.
- Koszty monitorowania są prawdopodobnie znikome, ale z pewnością znacznie niższe niż korzyści z posiadania danych z monitorowania.
sarjest wygodny i bardzo wydajny. Może w przyszłości użyjesz czegoś innego, ale to dobry pierwszy krok.- Domyślna konfiguracja nie jest szczególnie dobra (niska rozdzielczość, 1-sekundowe próbki). Rozważ zwiększenie rozdzielczości.
Jedną rzeczą, o której nie wspomniałem, jest to, że sar zajmuje się tylko metrykami systemowymi – CPU, dyskami, pamięcią, procesami, a nie statystykami PostgreSQL. Oczywiście powinieneś również monitorować tę część stosu.
