Dziś kolejna dawka wiedzy na temat Zabbixa. Dzisiejszy temat to 7 najczęstszych błędów podczas wdrożenia monitoringu!
Poniżej znajdziesz nagranie video i formę tekstową. Wybierz tą, która pasuje Ci bardziej 😊 Aczkolwiek od razu dodam, że na video jest dodatkowo, krótka część praktyczna z Zabbixa. A tam… magia triggerów.
Oczywiście, jeżeli jesteś totalnie początkujący w temacie monitoringu IT to warto najpierw zrozumieć Co to jest Zabbix?
Sprawdź, czego nauczysz się dzięki kursowi Grafany!
Udostępniamy darmowo ponad godzinny materiał z kursu. Przekonaj się, że jest idealny dla Ciebie!
Chcesz wziąć udział w kursie? Kliknij w link i obejrzyj co Cię czeka: https://asdevops.pl/demo-grafana/
Wersja Video
Wersja Tekstowa
Dzisiaj opowiemy sobie o dwóch rzeczach. Przede wszystkim na początek w ramach wstępu 7 błędów przy wdrożeniu monitoringu. Natomiast w drugiej części praktycznej pokażę ci jak działają jak funkcjonują Tigery oraz pokaże Ci jak tworzyć wykresy. Nie przedłużając lecimy do siedmiu błędów.
7 błędów wdrożenia monitoringu:
Najczęstszy błąd numer jeden. Powiem szczerze, osobiście jestem fanem minimalizm nie tylko w życiu ale również w monitoringu. Uważam że lepiej mieć mniej triggerów i mniej powiadomień niż całą masę różnych komunikatów, które ostatecznie kończą się tym, że pracownicy IT zaczynają je ignorować.
Monitoring ma pomagać, a nie utrudniać. Dla przykładu powiem ciz że w jednej firmie której dostałem zadanie uporządkowania monitoringu pracownicy dostawali dziennie ponad 10 tysięcy komunikatów. Nie da się nad czymś takim zapanować. Najważniejsze to zrobić inwentaryzację wtyczek komunikatów i alarmów, a następnie uporządkować je i zredukować do absolutnego minimum.
Błąd numer dwa. Brak archiwizacji wykresów i danych analitycznych. O ile w przypadku triggerów jestem fanem minimalizm to jednak w przypadku wykresów zawsze będę twierdził, że należy zbierać dane najdłużej jak się da. Oczywiście w ramach możliwości własnej infrastruktury. Jeżeli nie masz zasobów do przechowania tych danych to naturalnym jest, że będziesz chciał to ograniczyć do minimum.
Niestety niechlubnym standardem jest często w firmach jest to, że przechowuje się dane z wykresów w okresie dwóch lub trzech miesięcy. Jeżeli chcemy się odwołać do dalszego okresu niż te trzy miesiące to nie mamy wtedy danych. Osobiście jestem fanem tego, by posiadać dane z wykresów na okres przynajmniej rok wstecz. Dzięki temu posiadam odpowiednie źródło wiedzy do analizowania i poprawiania infrastruktury. A przede wszystkim, mam możliwość sprawdzenia co się działo w przyszłości. Gdzie mieliśmy wąskie gardła? Gdzie mieliśmy problemy? Rok to jest dobry okres na podstawie, którego można coś konkretnego wywnioskować. Oczywiście wykresy przydają się również do zarządzania zasobami. Ale o tym na blogu już wkrótce.
Zatem, jeżeli nie chcesz przegapić to zapisz się na mój newsletter, a poinformuję Cię o nowym materiale.
Niestety często mamy do czynienia z przypadkami gdy firmy nie robią backupu. Prędzej czy później, następuje awaria. Choćby dysku twardego, na którym jest utrzymywany Zabbix. W takim przypadku cała historia przepada.
Komunikacja
Błąd numer 3. Brak podjęcia tematu. W większości systemów do monitorowania mamy coś takiego jak Acknowledge. Jest to pewnego rodzaju oznaczenie, że ktoś już się zajmuje tematem. Prosta informacja dla innych pracujących w IT, że tematem już ktoś się zajął i coś trwa praca nad rozwiązaniem problemu. Jeżeli Trigger został odpalony i mamy alarm to w pierwszej kolejności osoba, która jest obecnie na dyżurze powinna kliknąć Acknowledge i tym samym poinformować innych że już się danym tematem zajmuje.
A skoro już jesteśmy przy temacie Acknowledge to czwarty punkt to brak odpowiedzialności. Co z tego, że ktoś zaznaczy Acknowledge jeżeli nikt się nie zajmie problemem? W dobrze zaprojektowanym środowisku informatycznym funkcjonują odpowiednie praktyki korzystania z monitoringu. Mamy konkretną odpowiedzialność. Mamy przypisane osoby do konkretnego zasobu informatycznego. Bez względu na to jaki jest problem. Nie działa serwer aplikacji. Jest problem z siecią. Czy może co innego…
Ważne jest, by do każdego zasobu dodanego do Zabbixa była przypisana konkretna osoba lub dział IT. Tak, by w razie problemów, później można było ścigać te osoby o to dlaczego ten czas SLA został przekroczony. I wyciągnąć konsekwencje… Naturalnie. Idąc dalej, skoro mówimy o braku odpowiedzialności to z tym wiąże się punkt piąty. Jest to brak procedur eskalacji problemu z monitoringiem. Często bardzo mocno łączy się systemem obsługi zgłoszeń Service Desk.
Zadaniem Service jest jak najszybsze rozwiązywanie problemów. Aczkolwiek, jeżeli nie ma stworzonej procedury, która wyjaśnia nam:
– kto się zajmuje danym zgłoszeniem?
– jak należy daną rzecz eskalować?
to niestety, gdzieś cały proces rozwiązywania problemów zawiedzie. Przykładowo jeżeli osoba która obecnie dyżuruje otrzyma komunikat z monitoringu, że coś niedobrego dzieje lecz nic z tym nie zrobi to monitoring sam magicznie nie rozwiąże problemu.
Monitoring jest narzędziem, które ma pomóc i usprawnić pracę. Dlatego też ważne jest, by opracować procedurę lub instrukcję, która wyjaśni osobie dyżurującej co należy z danym zgłoszeniem zrobić.
Przykładowo, mamy zgłoszenie z monitoringu dotyczący danego serwera. Niech to będzie serwer bazy danych. Człowiek odbierający taki komunikat z monitoringu powinien wiedzieć gdzie go eskalować. Na przykład, do osób zajmujących się bazą danych.
Własny system
Punkt szósty, czyli odkrywanie koła na nowo. Co mam na myśli? Już tłumaczę. Budowanie własnego systemu monitoringu. Niektórzy są na tyle ambitni, że chcieliby stworzyć swój własny system monitoringu, projektując go od zera zaprogramować.
Na rynku jest już wiele gotowych rozwiązań, które się w tym specjalizują i w zupełności się sprawdzają. Jaki jest zatem cel wymyślać coś na nowo? Jednego jestem pewien. Jeżeli postanowisz stworzyć swój własny system monitoringu to na 100% nie unikniesz błędów. Stracisz całą masę czasu i pieniędzy. Do tego zapewne zrobisz to gorzej. Chyba że twoją ambicją jest zrobienie czegoś lepszego od Zabbixa. Wydać nowy system monitoringu i udostępnić światu. Wtedy będę Ci kibicował.
I teraz rzecz, która niejako jest powiązana z punktem szóstym czyli nasz ostatni błąd.
Rozproszenie
Błąd numer 7 to korzystanie z kilku narzędzi do monitoringu. Zdaję sobie sprawę, że jest wiele rozwiazań tego typu. Na tym blogu opisujemy chociażby Hyperion odpowiedzialne za monitorowanie maszyn wirtualnych. Mimo wszystko twierdzę, że jeżeli już korzystamy z monitoringu to dobrze jest wszystko uporządkować. Zgodnie z tym co omówiliśmy w punkcie pierwszym. Jeżeli dział IT będzie otrzymywał masę różnych, dziwnych powiadomień to niestety, nic dobrego z tego nie wyjdzie. Również, jeżeli działy IT będą otrzymywały powiadomienia z kilku różnych systemów do monitorowania to też w pewnym momencie zacznie się robić bałagan. Postaraj się tego uniknąć.
Skup się na jednym narzędziu. To co polecam to co oczywiście często omawiany na blogu Zabbix. Ten system to kompleksowe rozwiązanie do monitoringu infrastruktury IT i gwarantuję Ci, że spełni Twoje wymagania.
Jak widzisz, nie jest to aż tak straszne jak się wydaje. Jeżeli masz jakieś pytania to zapraszam. Postaram się pomóc.
Miłego dnia!
Arek
