Miłego piątku wszystkim! Kochani, dzisiaj kontynuujemy cykl publikacji poświęconych kursowi , gdyż zajęcia w nowej grupie na kurs rozpoczną się pod koniec przyszłego tygodnia. A więc zaczynajmy!
Monitorowanie jest po prostu. Jest to znany fakt. Uruchom Nagios, uruchom NRPE na zdalnym systemie, skonfiguruj Nagios na porcie NRPE TCP 5666 i masz monitorowanie.
To jest tak proste, że nie jest interesujące. Teraz masz podstawowe wskaźniki czasu procesora, podsystemu dysku, pamięci RAM, dostarczane domyślnie do Nagios i NRPE. Ale w rzeczywistości nie jest to „monitorowanie” jako takie. To dopiero początek.
(Zwykle instalują PNP4Nagios, RRDtool i Thruk, konfigurują powiadomienia w Slacku i od razu przechodzą do nagiosexchange, ale zostawmy to na razie).
Dobre monitorowanie jest w rzeczywistości dość skomplikowany, naprawdę musisz znać wewnętrzne elementy monitorowanej aplikacji.
Czy monitorowanie jest trudne?
Każdy serwer, czy to Linux, czy Windows, z definicji będzie służył czemuś celowi. Apache, Samba, Tomcat, przechowywanie plików, LDAP - wszystkie te usługi są mniej lub bardziej wyjątkowe pod jednym lub kilkoma względami. Każdy ma swoją funkcję, swoje własne cechy. Istnieją różne sposoby uzyskiwania wskaźników KPI (kluczowych wskaźników wydajności), które są dla Ciebie interesujące, gdy serwer jest obciążony.
Autor zdjęcia na
(Chciałbym, żeby moje deski rozdzielcze były neonowoniebieskie - wzdycham marzycielsko -... hmm...)
Każde oprogramowanie świadczące usługi musi mieć mechanizm zbierania metryk. Apache ma moduł mod-status, wyświetlając stronę stanu serwera. Nginx ma - stub_status. Tomcat ma JMX lub niestandardowe aplikacje internetowe, które pokazują kluczowe wskaźniki. MySQL ma polecenie „pokaż status globalny” itp.
Dlaczego więc programiści nie wbudowują podobnych mechanizmów w tworzone przez siebie aplikacje?
Czy robią to tylko programiści?
Pewien poziom obojętności na osadzanie metryk nie jest ograniczony tylko do programistów. Pracowałem w firmach, które tworzyły aplikacje przy użyciu Tomcata i nie udostępniały żadnych własnych metryk, żadnych logów aktywności usług, z wyjątkiem ogólnych logów błędów Tomcata. Niektórzy programiści generują wiele logów, które nie mają żadnego znaczenia dla administratora systemu, który ma pecha i czyta je o 3:15 nad ranem.
Autor zdjęcia na
Inżynierowie systemowi, którzy umożliwiają wypuszczenie takich produktów, również muszą ponieść pewną odpowiedzialność za tę sytuację. Niewielu inżynierów systemów ma czas lub ochotę na wyodrębnianie znaczących metryk z logów bez kontekstu tych metryk i możliwości ich interpretacji w świetle aktywności aplikacji. Niektórzy nie rozumieją, jakie mogą z tego skorzystać poza wskaźnikami „coś jest obecnie (lub wkrótce będzie) nie tak”.
Zmiana myślenia o potrzebie metryk musi nastąpić nie tylko wśród programistów, ale także wśród inżynierów systemów.
Dla każdego inżyniera systemów, który musi nie tylko reagować na krytyczne zdarzenia, ale także zapewniać, że one nie wystąpią, brak wskaźników zwykle stanowi przeszkodę.
Jednak inżynierowie systemów zazwyczaj nie majstrują przy kodzie, aby zarabiać pieniądze dla swojej firmy. Potrzebują wiodących programistów, którzy rozumieją wagę odpowiedzialności inżyniera systemów w identyfikowaniu problemów, zwiększaniu świadomości problemów z wydajnością i tym podobnych.
To sprawa devopsa
Mentalność Devops opisuje synergię pomiędzy myśleniem programistycznym (dev) i operacyjnym (ops). Każda firma, która twierdzi, że „robi devops”, musi:
- mówiąc rzeczy, których prawdopodobnie nie mówią (odnosząc się do mema The Princess Bride – „Nie sądzę, że to znaczy to, co myślisz!”)
- Zachęcaj do ciągłego doskonalenia produktu.
Nie możesz ulepszyć produktu, wiedząc, że został ulepszony, jeśli nie wiesz, jak obecnie działa. Nie możesz wiedzieć, jak działa produkt, jeśli nie rozumiesz, jak działają jego komponenty, usługi, od których jest zależny, jego główne problemy i wąskie gardła.
Jeśli nie będziesz uważać na potencjalne wąskie gardła, nie będziesz w stanie zastosować się do techniki „Pięć powodów” podczas pisania sekcji zwłok. Nie będziesz w stanie umieścić wszystkiego na jednym ekranie, aby zobaczyć, jak działa produkt lub wiedzieć, jak wygląda „normalnie i szczęśliwie”.
Shift w lewo, W LEWO, POWIEDZIAŁEM LEEEE—
Dla mnie jedną z kluczowych zasad Devops jest „przesuń w lewo”. Przesunięcie w lewo w tym kontekście oznacza przesunięcie możliwości (żadnej odpowiedzialności, ale tylko możliwości), aby robić rzeczy, na których zwykle zależy inżynierom systemów, takie jak tworzenie wskaźników wydajności, efektywniejsze korzystanie z dzienników itp., po lewej stronie w cyklu życia dostarczania oprogramowania.
Autor zdjęcia na
Twórcy oprogramowania muszą umieć korzystać i znać narzędzia monitorujące, z których korzysta firma, aby prowadzić monitorowanie we wszystkich jego formach, metrykach, rejestrowaniu, interfejsach monitorowania i, co najważniejsze, zobacz, jak ich produkt sprawdza się w produkcji. Nie można nakłonić programistów do zainwestowania wysiłku i czasu w monitorowanie, dopóki nie zobaczą wskaźników i nie wpłyną na ich wygląd, na sposób, w jaki właściciel produktu przedstawia je CTO na następnej odprawie itp.
Krótko mówiąc
- Poprowadź konia do wody. Pokaż programistom, ile kłopotów mogą dla siebie uniknąć, pomóż im zidentyfikować odpowiednie KPI i metryki dla ich aplikacji, aby było mniej krzyków ze strony właściciela produktu, na którego krzyczy CTO. Wyprowadź je na światło, delikatnie i spokojnie. Jeśli to nie zadziała, przekup, groź i namawiaj ich lub właściciela produktu, aby jak najszybciej zaimplementowali pobieranie tych wskaźników z aplikacji, a następnie narysuj diagramy. Będzie to trudne, ponieważ nie będzie postrzegane jako priorytet, a plan działania dotyczący produktu będzie przewidywał wiele projektów generujących przychody w toku. Dlatego będziesz potrzebować uzasadnienia biznesowego, aby uzasadnić czas i wydatki poświęcone na wdrożenie monitorowania w produkcie.
- Pomóż inżynierom systemowym dobrze się wyspać. Pokaż im, że dobrze jest używać listy kontrolnej „wypuśćmy” dla każdego wypuszczanego produktu. A upewnienie się, że wszystkie aplikacje w środowisku produkcyjnym są objęte metrykami, pomoże Ci lepiej spać w nocy, umożliwiając programistom sprawdzenie, co i gdzie dzieje się nie tak. Jednak właściwym sposobem na zirytowanie i sfrustrowanie programisty, właściciela produktu lub dyrektora technologicznego jest upieranie się i stawianie oporu. To zachowanie będzie miało wpływ na datę wydania dowolnego produktu, jeśli ponownie będziesz czekać do ostatniej chwili, więc przesuń ponownie w lewo i jak najszybciej uwzględnij te problemy w planie projektu. Jeśli to konieczne, udaj się na spotkania produktowe. Noś sztuczne wąsy i filc lub coś takiego, to nigdy nie zawiedzie. Komunikuj swoje obawy, demonstruj wyraźne korzyści i ewangelizuj.
- Upewnij się, że zarówno programiści (programiści), jak i operatorzy (operatorzy) rozumieją znaczenie i konsekwencje przesunięcia wskaźników produktu do czerwonej strefy. Nie zostawiaj Ops jako jedynego strażnika kondycji produktu, upewnij się, że programiści również są zaangażowani (#productsquads).
- Dzienniki to świetna rzecz, ale równie ważne są metryki. Połącz je i nie pozwól, aby Twoje kłody zamieniły się w śmieci w ogromną, płonącą kulę bezużyteczności. Wyjaśnij i pokaż programistom, dlaczego nikt inny nie zrozumie ich logów, pokaż im, jak to jest patrzeć na bezużyteczne logi o 3:15 nad ranem.
Autor zdjęcia na
To wszystko. Nowy materiał ukaże się w przyszłym tygodniu. Jeśli chcesz dowiedzieć się więcej o kursie, zapraszamy , które odbędzie się w poniedziałek. A teraz tradycyjnie czekamy na Wasze komentarze.
Źródło: www.habr.com