Przewodnik konfiguracji monitoringu bazy danych

Zanim zaczniesz

Kontrole Database nie działają z rozproszonej publicznej sieci monitoringu HostTracker tak, jak robi to kontrola Http czy Ping, więc ten formularz w ogóle nie ma sekcji Monitoring Locations. Zamiast tego każda kontrola łączy się z Twoim serwerem z własnej prywatnej infrastruktury kontrolnej HostTracker, używając dwóch stałych adresów źródłowych: 4.207.101.172 i 20.107.152.200 (Europa Północna). Zanim zapiszesz monitor, dodaj oba adresy do listy dozwolonych zapory sieciowej lub grupy bezpieczeństwa serwera bazy danych i upewnij się, że serwer akceptuje połączenia na swoim porcie z publicznego internetu, albo przynajmniej z tych dwóch adresów. Jeśli port jest nieosiągalny, każda kontrola kończy się błędem połączenia, niezależnie od tego, jak skonfigurowana jest reszta monitora.

Skonfiguruj samo konto monitorujące, zanim zaczniesz: utwórz użytkownika bazy danych dedykowanego dla kontroli, nadaj mu tylko to, czego kontrola potrzebuje (zazwyczaj samo prawo do połączenia plus SELECT na tabeli, do której odwołuje się Twoje zapytanie), i unikaj ponownego użycia konta aplikacji albo administratora. Jeśli zapytanie, które planujesz uruchamiać, zmienia dane, daj temu kontu prawo zapisu wyłącznie do konkretnej zaangażowanej tabeli, nic szerzej.

Docelowa baza danych

Trzy pola identyfikują, z czym łączy się kontrola, i znajdują się nad sekcjami zwijalnymi, ponieważ są obowiązkowe:

• Server type (Typ serwera) - lista rozwijana obsługiwanych dostawców: Microsoft SQL Server, Oracle, MySQL, PostgreSQL i Firebird.
• Server : Port (Serwer : Port) - nazwa hosta lub IP serwera bazy danych oraz jego port. Zmiana typu serwera automatycznie wstawia domyślny port zwyczajowy dla tego dostawcy (1433 dla SQL Server, 1521 dla Oracle, 3306 dla MySQL, 5432 dla PostgreSQL, 3050 dla Firebird) - musisz go nadpisać tylko wtedy, gdy Twój serwer nasłuchuje gdzie indziej.
• Database (Baza danych) (albo, dla Oracle, zamiast tego Service (Usługa) i Instance name (SID) (Nazwa instancji, SID)) - nazwa bazy danych, z którą nastąpi połączenie. Dla Oracle możesz podać nazwę usługi, SID, albo oba, w zależności od tego, jak skonfigurowany jest Twój listener.

Poniżej opcjonalne pole Name pozwala nadać monitorowi etykietę do alertów, raportów i widżetów - przydatne, gdy masz więcej niż jedną kontrolę bazy danych i musisz je odróżniać na pierwszy rzut oka.

Ustawienia główne (Main Settings)

Ta grupa zawiera harmonogram i dwa ogólne przełączniki, które ma każdy typ kontroli:

• Interval - jak często kontrola się wykonuje, dostępne wartości od 10 minut do 24 godzin (10, 15, 30, 45 minut, potem 1, 2, 4, 6, 12 i 24 godziny), plus alternatywa w postaci harmonogramu cron dla mniej regularnego rytmu. Kontrole Database nie oferują interwałów krótszych niż 10 minut, dostępnych w niektórych innych typach kontroli.
• Tags - dowolne etykiety do grupowania i filtrowania monitorów w innych miejscach panelu.
• Full Log - zapisuje każdy pojedynczy wynik kontroli zamiast tylko zgrupowanych podsumowań, przydatne, gdy trzeba zobaczyć dokładne czasy odpowiedzi albo wartości w czasie, a nie tylko historię działa/nie działa.
• Open Stats - udostępnia stronę statystyk i logu tego monitora, także osobom niezalogowanym.

Połączenie (Connection)

Skoro cel jest już ustawiony powyżej, ta sekcja opisuje, jak kontrola się uwierzytelnia i jak obsługuje nieudaną próbę połączenia:

• DB user name i DB user password - dane logowania konta monitorującego opisanego powyżej. Oba pola są opcjonalne: zostaw je puste, jeśli Twoja baza danych dopuszcza zaufane lub anonimowe połączenie z adresu z listy dozwolonych, co bywa w niektórych konfiguracjach wewnętrznych.
• Sam panel wyświetla dwa adresy źródłowe, z których wykonywane są kontrole (4.207.101.172, 20.107.152.200), z przypomnieniem, żeby dodać je do listy dozwolonych zapory Twojej bazy danych - to ten sam wymóg, o którym mowa w sekcji "Zanim zaczniesz", powtórzony tutaj, bo właśnie tu znajdują się dane logowania.
• Retry on connect fail - przełącznik, domyślnie włączony, który ponawia próbę połączenia raz, zanim oznaczy kontrolę jako nieudaną. Dotyczy wyłącznie samego kroku połączenia, nie zapytania.

Weryfikacja odpowiedzi (Response Validation)

To kluczowa decyzja w kontroli Database: czy testujesz, że połączenie działa, czy że konkretne zapytanie wciąż zachowuje się zgodnie z oczekiwaniami.

• Query - zostaw to pole puste, a kontrola przetestuje tylko połączenie: otwiera się, zamyka, i to cała kontrola. Wpisz dowolny SQL, który Twoje konto monitorujące ma prawo wykonać - SELECT albo instrukcję zmieniającą dane, taką jak UPDATE, DELETE czy INSERT - a kontrola będzie go wykonywać przy każdym odpytaniu i będzie mogła ocenić wynik.
• Query result (pokazuje się dopiero po wpisaniu zapytania) - wybierz Scalar value, żeby odczytać to, co jest w pierwszej kolumnie pierwszego zwróconego wiersza (naturalny wybór dla SELECT, albo dla UPDATE/INSERT używającego klauzuli OUTPUT), albo Row count, żeby odczytać, ile wierszy zostało zmienionych (naturalny wybór dla zwykłego UPDATE, DELETE czy INSERT bez własnego zestawu wyników).
• Result verification - porównanie stosowane do tej wartości: No verification (zapytanie ma po prostu wykonać się bez błędu), Equal to, Not equal to, Greater than, Less than, In range albo Out of range. Opcje większe/mniejsze niż oraz zakres dodają jedno lub dwa pola liczbowe, z przełącznikiem włącznie/wyłącznie na każdej granicy zakresu.
• Retry query on error - przełącznik, domyślnie włączony, który ponawia wykonanie zapytania raz w razie niepowodzenia, niezależnie od ponowienia na poziomie połączenia opisanego wyżej.

Wybierz opcję samego połączenia, jeśli chcesz po prostu wiedzieć, że baza danych jest osiągalna i akceptuje połączenia - to wyłapuje jawne awarie. Wybierz zapytanie z weryfikacją wyniku, gdy sama osiągalność nie wykryłaby prawdziwego problemu: tabeli, która przestała otrzymywać nowe wiersze, zapisanej liczby wykraczającej poza normalny zakres, albo konkretnych danych, które zawsze powinny być obecne.

Subskrypcje alertów (Alert Subscriptions)

Wybierz, które kontakty mają się dowiadywać o tym monitorze i dla jakich zdarzeń - Up, Down i Repeat (powtarzane przypomnienie, dopóki kontrola pozostaje w stanie Down). Jeden przełącznik subskrybuje wszystkie kontakty naraz na Up/Down, albo możesz wybrać poszczególne kontakty i zdarzenia w tabeli poniżej.

Subskrypcje raportów (Report Subscriptions)

Niezależnie od alertów wybierz, kto otrzymuje okresowe raporty o uptime i wydajności tego monitora - dziennie, tygodniowo czy miesięcznie - pocztą e-mail.

Przykład zastosowania

Obserwacja produkcyjnej bazy PostgreSQL, od której zależy aplikacja: Server type PostgreSQL, Server : Port db.example.com:5432, Database myapp_prod. W sekcji Connection wpisane jest dedykowane konto tylko do odczytu, a oba adresy źródłowe są wcześniej dodane do grupy bezpieczeństwa bazy danych. Pole Query zawiera SELECT COUNT(*) FROM orders WHERE created_at > now() - interval '1 hour', Query result to Scalar value, a Result verification to Greater than z limitem 0 - jeśli w ciągu ostatniej godziny nie zapisano żadnego zamówienia, coś wyżej w łańcuchu przestało pisać, i kontrola przechodzi w Down, mimo że baza danych jest osiągalna. Interval to 15 minut, oba przełączniki Retry pozostają włączone, żeby chwilowe zakłócenie nie wywołało fałszywego alertu, alerty trafiają do całego zespołu przez subskrypcję Up/Down, a cotygodniowy raport trafia do właściciela konta.

Rozwiązywanie problemów

• Każda kontrola kończy się błędem połączenia. Najczęstszą przyczyną jest zapora sieciowa, która nie została otwarta dla dwóch adresów źródłowych HostTracker - upewnij się, że 4.207.101.172 i 20.107.152.200 są na liście dozwolonych i że sam port jest dla nich otwarty.
• Połączenie się udaje, ale uwierzytelnianie zawodzi. Sprawdź, czy nazwa użytkownika i hasło DB są poprawne i czy konto ma uprawnienia do połączenia z konkretną nazwaną bazą danych, a nie tylko z serwerem.
• Zapytanie, które świetnie działa w narzędziu klienckim, tutaj nic nie zwraca. Zwykłe UPDATE, DELETE czy INSERT bez klauzuli OUTPUT nie ma zestawu wyników do odczytania jako Scalar value - przełącz Query result na Row count albo dodaj klauzulę OUTPUT, jeśli potrzebujesz odzyskać dane wiersza.
• Result verification nigdy się nie uruchamia. Upewnij się, że porównanie i pola liczbowe odpowiadają oczekiwanemu zakresowi: granica ustawiona jako wyłączona zamiast włączonej to łatwy sposób, żeby limit nigdy się nie zadziałał.
• Sporadyczne pojedyncze awarie, które podejrzewasz o chwilowość. Oba przełączniki ponawiania są domyślnie włączone i już ponawiają próbę raz, zanim kontrola zostanie oznaczona jako nieudana - jeśli awarie wciąż są częste, problem jest raczej rzeczywisty, związany z połączeniem lub zapytaniem, a nie szumem.

Powiązane

• Monitoring zapytań do bazy danych - strona produktu dla tego typu kontroli.
• Przewodnik po monitoringu CPU, RAM i dysku - kolejna kontrola działająca z prywatnej infrastruktury HostTracker, a nie z sieci publicznej, przydatna razem z kontrolą bazy danych na tym samym serwerze.
• Przewodnik po monitoringu SNMP - do odczytu wartości bezpośrednio ze sprzętu sieciowego zamiast z bazy danych.
• Tryb assertów i reguły weryfikacji odpowiedzi - język reguł weryfikacji odpowiedzi używany też w innych typach kontroli HostTracker.
• Wszystkie funkcje monitoringu HostTracker - zobacz wszystkie typy kontroli obok siebie.
• 503 Service Unavailable - status, który strona zwraca, gdy stojąca za nią baza danych przestaje odpowiadać.
• Wszystkie przewodniki po monitoringu - przewodnik konfiguracji dla każdego innego typu kontroli.