Zanim zaczniesz przyglądać się narzędziu do monitorowania serwera SQL, pomyśl o swoim konkretnym środowisku:
- Ile instancji chcesz monitorować?
- Czy są one w jednym miejscu, czy są rozproszone?
- Czy musisz monitorować system operacyjny i/lub hipernadzorcę?
- Ile historii potrzebujesz, aby uzyskać dokładny obraz granic działania Twojej instancji?
- Czy wszystkie są dostępne lokalnie, czy niektóre w chmurze?
- Czy Twoje zespoły są rozproszone?
- Czy kupujesz oprogramowanie w ramach budżetu wydatków kapitałowych lub wydatków operacyjnych?
- Czy możesz sobie pozwolić na zainwestowanie ryczałtu z góry na infrastrukturę i licencję, czy wolisz rozłożyć koszty w czasie?
- Czy masz dostępną infrastrukturę i instancje baz danych, które możesz poświęcić narzędziu monitorującemu?
- Czy masz czas na zbudowanie infrastruktury monitorowania?
- Czy masz niezmiennie wysoką wiedzę specjalistyczną w swoim zespole?
- Czy korzystasz z młodszych zasobów do wstępnej selekcji, czy we wszystkim polegasz na swoich ekspertach?
- Czy masz czas lub zasoby wewnętrzne na utrzymanie infrastruktury monitorowania?
Czy powinienem rzucić swoje?
Tutaj mogę zadeklarować naszą stronniczość. Quest Software buduje narzędzia do monitorowania wydajności przez ostatnie 20 lat. Jest doskonały powód, dla którego my i wielu innych, takich jak my, pozostajemy w tym segmencie od tak dawna i dlaczego mamy rosnącą bazę klientów. Dobrze wykonane monitorowanie wydajności nie jest łatwe!
Rzeczywiście istnieje kilka świetnych sposobów zbierania metryk z SQL Server za pomocą PerfMon, śladów, DMV i XEvents, żeby wymienić tylko kilka. Robienie tego jednorazowo dla jednego problemu jest dobre i dobre — jeśli masz czas, aby zainwestować w zbadanie, gdzie i jak gromadzić dane dotyczące tego problemu. Gdy problemy zaczną narastać, a liczba instancji wzrośnie, szybko stanie się to nieskalowalne.
Dostępnych jest kilkaset metryk, które warto śledzić, aby uzyskać pełny obraz kondycji wydajności serwera SQL Server. Oprócz tego istnieje uruchamiany kod SQL i plany zapytań związane z każdym wykonaniem tego samego. Niektóre metryki powinny być zbierane co sekundę, niektóre co godzinę, a niektóre na podstawie czasu wykonania kodu. Niektóre metody gromadzenia danych mogą mieć wpływ na monitorowaną instancję i należy ich unikać.
Każda metryka będzie miała inne progi, które określałyby jej status. Poszczególne instancje mogą mieć niestandardowe poziomy. Następnie musisz to wszystko przechowywać. Ilość danych sumuje się BARDZO szybko. Będziesz musiał wprowadzić strategię, aby regularnie usuwać szczegółowe dane, a następnie, jeśli jest to wymagane w przypadku trendów, agregować te dane do raportowania.
To DUŻO pracy… i oczywiście za każdym razem, gdy pojawia się nowa wersja SQL Server, musisz sobie poradzić z regresją. O ile nie chcesz sprzedawać narzędzia do monitorowania, zdecydowanie odradzałbym rozwijanie własnego, chyba że liczba problemów jest niewielka, a problemy, które musisz rozwiązać, są bardzo konkretne.
A co z bezpłatnymi narzędziami?
Często warto rozważyć darmowe narzędzia, zwłaszcza w przypadku mniejszych zespołów z mniej krytycznymi instancjami. Pomyśl o tym jako o kolejnym kroku na drabinie skalowalności po „wyrzuceniu własnego”. Wiele komercyjnych narzędzi do monitorowania serwerów SQL klasy podstawowej powinno uwzględniać podobne względy. Rozważ następujące kwestie:
- Czy narzędzie obejmuje wystarczającą ilość danych, aby zapewnić odpowiednie pokrycie wszystkich przypadków użycia w monitorowanych instancjach? Wiele darmowych narzędzi daje pewien rodzaj „dostosowania”, aby dodać własne metryki. Kiedy „dostosowywanie” jest używane do wypełniania luk w funkcjonalności, szybko zauważysz, że Twój zespół kończy „samodzielnie” z wymaganym rozproszeniem i bólem głowy.
- Czy narzędzie obsługuje alerty? Czy jest wstępnie skonfigurowany? Konfiguracja alertów może być bardzo czasochłonna. Gotowe alerty są koniecznością, aby zapobiec utracie wielu roboczogodzin podczas konfigurowania czyjegoś narzędzia. Powinno to również ułatwić dostosowywanie alertów dla skrajnych przypadków, które nie są zgodne z wartościami domyślnymi.
- Jak i gdzie przechowywane są dane? Większość darmowych narzędzi pozostawia Ci zarządzanie przechowywaniem danych dotyczących wydajności. Uważaj na „bezpłatne” monitorowanie od dostawców chmury. Pobierają opłaty za przechowywanie, a to może szybko stać się duże i drogie!
Tak więc, za wszelką cenę, korzystaj z bezpłatnych narzędzi, które są tam dostępne. Po prostu bądź świadomy ich ograniczeń i szukaj klasycznych antywzorców w swoim zespole, takich jak:
- Więcej czasu spędzonego na naprawie lub utrzymaniu narzędzia niż używanie go do rozwiązywania problemów
- Więcej pieniędzy wydanych na infrastrukturę i pamięć masową
- Dużo danych, ale brak spostrzeżeń
- Niewystarczająca dogłębna diagnostyka, aby rozwiązać problemy
- Niewystarczająco skalowalne, aby spełnić Twoje potrzeby
Jeśli zauważysz którekolwiek z powyższych, powinno to wskazywać na potrzebę uaktualnienia do bardziej niezawodnego rozwiązania.
Typowa architektura systemu monitorowania serwera SQL
Rozważając, czy wybrać tradycyjne rozwiązanie lokalne, czy oprogramowanie hostowane jako usługa (SaaS), warto rozważyć architekturę aplikacji monitorującej. Oto podsumowanie kluczowych elementów architektonicznych.
Kluczowe odchylenie między SaaS a lokalnymi dotyczy miejsca przechowywania danych o wydajności i tego, kto zarządza tym repozytorium. W przypadku rozwiązania lokalnego jest to odpowiedzialność użytkownika końcowego. Te repozytoria mogą szybko się rozrastać, dlatego należy nimi starannie zarządzać. Infrastrukturę należy zaplanować i zaplanować (więcej poniżej).
W rozwiązaniu SaaS do monitorowania serwerów SQL te kluczowe komponenty infrastruktury są hostowane i zarządzane za Ciebie.
| Tradycyjne rozwiązanie lokalne | Rozwiązanie SaaS |
|
|
Więcej informacji znajdziesz na naszym blogu Architektura systemu monitorowania baz danych.
