Alerting w SQL Server: kiedy reagować i co automatyzować

Dlaczego monitoring bez alertingu nie ma sensu

Przez lata pracy jako DBA widziałem dziesiątki środowisk, w których ktoś skrupulatnie zbierał metryki wydajnościowe, logi i statystyki. Piękne dashboardy, gigabajty danych historycznych. Problem polegał na tym, że nikt tych danych nie analizował na bieżąco. O problemach dowiadywano się od użytkowników, którzy dzwonili z pytaniem, dlaczego system nie działa.

Monitoring ma wartość tylko wtedy, gdy przekłada się na akcję. A akcja wymaga informacji dostarczonej w odpowiednim momencie do odpowiedniej osoby. To właśnie rola alertingu.

SQL Server oferuje wbudowane mechanizmy, które przy właściwej konfiguracji potrafią wykryć problem na minuty lub nawet godziny przed tym, zanim wpłynie on na użytkowników końcowych. Kluczem jest jednak umiejętne ich wykorzystanie.

Fundament techniczny: SQL Server Agent i Database Mail

Zanim przejdziemy do strategii alertingu, warto zrozumieć narzędzia, którymi dysponujemy. SQL Server Agent to silnik automatyzacji wbudowany w SQL Server. Pozwala definiować zadania (Jobs), harmonogramy ich wykonania oraz alerty reagujące na konkretne zdarzenia systemowe.

Database Mail to z kolei podsystem pocztowy, który umożliwia wysyłanie wiadomości e-mail bezpośrednio z poziomu SQL Server. Konfiguracja obejmuje profile pocztowe, konta SMTP oraz kolejkę wiadomości zarządzaną przez Service Broker.

Konfiguracja Database Mail krok po kroku

Podstawowa konfiguracja wymaga utworzenia profilu i konta pocztowego:

Najpierw włączamy Database Mail poprzez sp_configure, ustawiając opcję 'Database Mail XPs' na 1. Następnie tworzymy profil za pomocą sysmail_add_profile_sp, dodajemy konto przez sysmail_add_account_sp (podając serwer SMTP, port, ewentualnie dane uwierzytelniające) i łączymy profil z kontem używając sysmail_add_profileaccount_sp.

Warto pamiętać o kilku rzeczach: używaj dedykowanego konta SMTP dla alertów SQL Server, skonfiguruj odpowiednie limity rozmiaru załączników i liczby wiadomości, oraz regularnie monitoruj kolejkę msdb.dbo.sysmail_mailitems pod kątem nieudanych wysyłek.

Kiedy reagować: sztuka definiowania progów

To najtrudniejszy aspekt alertingu. Zbyt niskie progi generują fałszywe alarmy i prowadzą do alert fatigue. Zbyt wysokie powodują, że dowiadujemy się o problemach zbyt późno.

Po dwudziestu latach w branży nauczyłem się jednej rzeczy: idealne progi alertów nie istnieją. Istnieje natomiast proces ciągłego dostrajania oparty na znajomości konkretnego środowiska i jego specyfiki.

Progi dla przestrzeni dyskowej

Klasyczny błąd to ustawienie alertu na 10% wolnego miejsca. W środowisku z dyskami 2TB to oznacza 200GB, co może wystarczyć na tygodnie pracy. Natomiast przy dyskach 100GB to tylko 10GB, które przy intensywnym wzroście logów transakcyjnych może zniknąć w ciągu godzin.

Rekomenduję podejście wielopoziomowe: ostrzeżenie przy 20% wolnego miejsca (lub 50GB, w zależności co jest mniejsze), alert krytyczny przy 10% (lub 20GB), oraz alarm natychmiastowy przy 5% (lub 10GB). Dodatkowo warto monitorować tempo wzrostu zajętości i alertować, gdy projekcja wskazuje na wyczerpanie miejsca w ciągu najbliższych 24 godzin.

Progi dla wydajności IO

Latency dysków to jeden z najważniejszych wskaźników zdrowia SQL Server. Dla dysków SSD akceptowalne wartości to poniżej 5ms dla odczytu i poniżej 10ms dla zapisu. Dla tradycyjnych dysków HDD te wartości mogą być wyższe, ale przekroczenie 20ms dla odczytu powinno już budzić niepokój.

Do monitorowania używam zapytania do sys.dm_io_virtual_file_stats, obliczając średnie latency jako iloraz io_stall_read_ms przez num_of_reads. Kluczowe jest jednak porównywanie z wartościami bazowymi dla konkretnego środowiska, nie z ogólnymi benchmarkami.

Deadlocki i blokady

Każdy deadlock powinien generować alert, ponieważ oznacza problem w logice aplikacji lub strukturze bazy. SQL Server Agent ma wbudowany alert dla błędu 1205 (deadlock victim), który warto aktywować.

Blokady to bardziej złożony temat. Krótkotrwałe blokady są normalne i nie powinny generować alertów. Problematyczne są blokady trwające dłużej niż ustalony próg. W większości środowisk produkcyjnych alertuję przy blokadach przekraczających 30 sekund, a alarm krytyczny wysyłam przy blokadach powyżej 2 minut.

Co automatyzować: reakcje bez udziału człowieka

Nie każdy alert wymaga natychmiastowej reakcji administratora. Wiele typowych sytuacji można obsłużyć automatycznie, rezerwując czas DBA na rzeczywiście skomplikowane przypadki.

Automatyczne czyszczenie przestrzeni

Gdy alert wykryje niski poziom wolnego miejsca, Job może automatycznie wykonać szereg działań: usunąć stare backupy zgodnie z polityką retencji, wyczyścić folder tymczasowy SQL Server, skompresować lub usunąć stare pliki logów Agent Jobs, oraz wykonać DBCC SHRINKFILE na logach transakcyjnych (tylko w uzasadnionych przypadkach, gdy log rozrósł się jednorazowo).

Automatyczna diagnostyka

Przy wykryciu problemów wydajnościowych warto automatycznie zbierać informacje diagnostyczne: aktualnie wykonywane zapytania z sys.dm_exec_requests, statystyki wait types, plan cache dla problematycznych zapytań, oraz snapshot blokad i sesji. Te dane, zapisane do tabeli lub wysłane mailem, są bezcenne podczas późniejszej analizy.

Restart usług i procesów

To kontrowersyjny temat. Automatyczny restart może zamaskować głębszy problem. Jednak w przypadku niektórych znanych błędów SQL Server (szczególnie w starszych wersjach) automatyczny restart określonych komponentów bywa jedynym praktycznym rozwiązaniem. Kluczowe jest logowanie każdego takiego zdarzenia i regularna analiza przyczyn.

Grupowanie i korelacja: walka z szumem informacyjnym

Pojedynczy incydent może wygenerować dziesiątki alertów. Pełny dysk spowoduje błędy backupów, problemy z logami transakcyjnymi, błędy zapisu do tempdb i wiele innych. Administrator nie powinien otrzymać 47 maili; powinien otrzymać jeden, wskazujący na przyczynę źródłową.

Techniki grupowania

Najprostszym podejściem jest okno czasowe: jeśli ten sam alert wystąpił w ciągu ostatnich 15 minut, nie wysyłaj kolejnego maila, tylko inkrementuj licznik. Po upływie okna wyślij podsumowanie.

Bardziej zaawansowane podejście to budowanie hierarchii zależności. Alert o błędzie backupu sprawdza najpierw, czy nie ma aktywnego alertu o braku miejsca na dysku. Jeśli jest, nie generuje osobnego powiadomienia, tylko dodaje się jako skutek do istniejącego incydentu.

Eskalacja

Warto zbudować mechanizm eskalacji: pierwszy alert idzie tylko do systemu ticketowego, po 30 minutach bez reakcji wysyłany jest mail do DBA, po godzinie SMS, po dwóch godzinach powiadomienie do managera. SQL Server Agent w połączeniu z prostymi skryptami PowerShell pozwala zbudować taki system bez zewnętrznych narzędzi.

Praktyczna implementacja: przykład kompleksowego alertu

Pokażę przykład alertu monitorującego wzrost logów transakcyjnych. Job uruchamiany co 15 minut sprawdza rozmiar logów względem poprzedniego pomiaru. Jeśli wzrost przekracza 500MB w ciągu 15 minut, zbiera diagnostykę (aktywne transakcje, najdłużej trwające zapytania, status backupu logu), zapisuje do tabeli audytowej i wysyła mail z podsumowaniem. Jeśli wzrost przekracza 2GB, dodatkowo wykonuje backup logu (o ile jest skonfigurowany model odzyskiwania FULL) i eskaluje alert.

Taki wielopoziomowy alert dostarcza kontekst, wykonuje podstawową automatyzację i eskaluje tylko gdy sytuacja tego wymaga.