Witajcie w piątek! Drodzy, dzisiaj kontynuujemy serię publikacji poświęconych kursowi , ponieważ zajęcia w nowej grupie kursu zaczynają się już pod koniec przyszłego tygodnia. Zaczynajmy!
Monitoring to po prostu. To powszechnie znany fakt. Włącz Nagios, uruchom NRPE na zdalnym systemie, skonfiguruj Nagiosa przy użyciu portu NRPE TCP 5666 i masz monitoring.
To takie łatwe, że aż nudne. Teraz masz podstawowe metryki dotyczące czasu CPU, subsystemu dyskowego, pamięci RAM, które są domyślnie dostarczane przez Nagios i NRPE. Ale w rzeczywistości to nie jest 'monitoring' jako taki. To tylko początek.
(Zazwyczaj instaluje się PNP4Nagios, RRDtool i Thruk, ustawia powiadomienia w Slacku i od razu wskakuje na nagiosexchange, ale na razie pomińmy to).
Dobry monitoring jest w rzeczywistości dość skomplikowany, naprawdę musisz znać wnętrze aplikacji, którą monitorujesz.
Czy monitoring jest trudny?
Każdy serwer, czy to Linux, czy Windows, z definicji będzie służył jakiemuś celowi. Apache, Samba, Tomcat, przechowywanie plików, LDAP - wszystkie te usługi są w pewnym stopniu unikalne w jednym lub kilku aspektach. Każda z nich ma swoją funkcję, swoje cechy. Istnieją różne sposoby pozyskiwania metryk, KPI (kluczowych wskaźników wydajności), które mogą cię interesować, gdy serwer jest obciążony.
Autor zdjęcia na
(chciałbym, aby moje pulpity były w neonowo-niebieskich kolorach – marząc… hmm…)
Każde oprogramowanie, które świadczy usługi, musi mieć mechanizm do zbierania metryk. Apache ma moduł mod-status, który wyświetla stronę stanu serwera. Nginx ma stub_status. Tomcat ma JMX lub specjalne aplikacje webowe, które pokazują kluczowe metryki. W MySQL jest komenda 'show global status' itp.
Dlaczego więc deweloperzy nie wbudowują takich mechanizmów w aplikacje, które tworzą?
Czy tylko deweloperzy to robią?
Pewien poziom obojętności wobec wbudowywania metryk nie ogranicza się tylko do deweloperów. Pracowałem w firmach, które tworzyły aplikacje przy użyciu Tomcat, a nie wydawały żadnych swoich metryk, żadnych logów aktywności serwisu, poza ogólnymi dziennikami błędów Tomcat. Niektórzy deweloperzy generują mnóstwo logów, które nic nie znaczą dla administratora systemu, któremu zdarza się je czytać o 3:15 w nocy.
Autor zdjęcia na
Inżynierowie systemów, którzy pozwalają na wprowadzenie takich produktów na rynek, również muszą ponosić pewną odpowiedzialność za sytuację. Nieliczni inżynierowie systemów mają czas i troskę, aby spróbować uzyskać znaczące metryki z logów, bez kontekstu tych metryk i możliwości ich interpretacji w świetle aktywności aplikacji. Niektórzy nie rozumieją, jaką korzyść mogą z tego uzyskać, poza wskaźnikami typu „coś obecnie (lub wkrótce) jest nie tak”.
Zmiana myślenia o potrzebie metryk musi zachodzić nie tylko wśród deweloperów, ale również wśród inżynierów systemów.
Dla każdego inżyniera systemów, który musi nie tylko reagować na krytyczne wydarzenia, ale także zapewnić ich brak, brak metryk zazwyczaj stanowi przeszkodę w tym.
Jednakże inżynierowie systemów zazwyczaj nie grzebią w kodzie, zarabiając pieniądze dla swojej firmy. Potrzebują wiodących deweloperów, którzy rozumieją znaczenie odpowiedzialności inżyniera systemów w wykrywaniu problemów, zwiększaniu świadomości na temat problemów wydajnościowych i tym podobnych.
To zagadnienie devops.
Mentalność devops opisuje synergiczną myśl deweloperów (dev) i eksploatacji (ops). Każda firma, która twierdzi, że „robi devops”, powinna:
- mówić to, czego prawdopodobnie nie robi (nawiązując do memu z filmu „Księżniczka Bride” – „Nie sądzę, żeby to oznaczało to, co myślisz, że to oznacza!”)
- zachęcać do postawy stałego doskonalenia produktu.
Nie możesz poprawić produktu i wiedzieć, że został ulepszony, jeśli nie wiesz, jak działa obecnie. Nie dowiesz się, jak działa produkt, jeśli nie rozumiesz, jak działają jego komponenty, usługi, od których zależy, jego podstawowe punkty bólu i wąskie gardła.
Jeśli nie obserwujesz potencjalnych wąskich gardeł, nie będziesz mógł zastosować techniki „Pięć dlaczego” przy pisaniu Postmortem. Nie będziesz w stanie zebrać wszystkiego na jednym ekranie, aby zobaczyć, jak działa produkt lub odkryć, jak wygląda „normalnie i szczęśliwie”.
Przesunięcie w lewo, W LEWO, POWIEDZIAŁEM, LEEEEEE—
Dla mnie jednym z kluczowych zasad Devops jest „Przesunięcie w lewo” (shift left). Przesunięcie w lewo w tym kontekście oznacza przesunięcie możliwości (nie odpowiedzialności, a tylko możliwości) robić to, o czym zwykle troszczą się inżynierowie systemowi, na przykład tworzyć metryki wydajności, efektywniej wykorzystywać logi itp., w lewo w cyklu dostarczania oprogramowania (Software Delivery Life Cycle).
Autor zdjęcia na
Programiści powinni mieć możliwość korzystania i znajomości narzędzi monitorujących, które wykorzystuje firma, aby monitorować w różnych formach, metrykach, logowaniu, interfejsach monitorujących i, co najważniejsze, obserwować, jak ich produkt działa w produkcji. Nie możesz zmusić programistów do wkładania sił i czasu w monitorowanie, dopóki nie będą mogli zobaczyć metryk i wpływać na to, jak wyglądają, jak właściciel produktu przedstawi je swojemu CTO na następnej odprawie itd.
Krótko mówiąc
- Przyprowadź konia do wody. Pokaż programistom, ile problemów mogą uniknąć, pomagając im wyróżnić odpowiednie KPI i metryki dla swoich aplikacji, aby było mniej krzyku od właściciela produktu, na którego krzyczy CTO. Wydobądź ich na światło dzienne, delikatnie i spokojnie. Jeśli to się nie uda, to przekup ich, groź lub namawiaj ich albo właściciela produktu, aby jak najszybciej zrealizować uzyskanie tych metryk z aplikacji, a następnie stwórz wykresy. To będzie trudne, ponieważ nie będzie to traktowane jako priorytet, a w mapie drogowej produktu będzie wiele projektów czekających na realizację, które przynoszą przychody. Dlatego potrzebujesz uzasadnienia ekonomicznego, aby usprawiedliwić czas i środki wydane na wdrożenie monitorowania w produkcie.
- Pomóż inżynierom systemowym dobrze się wyspać. Pokaż im, że stosowanie checklisty „wydanie wersji” dla każdego produktu, który jest wydawany, jest dobre. A upewnienie się, że wszystkie aplikacje w produkcji są pokryte metrykami, pomoże uzyskać zdrowy sen w nocy, pozwalając programistom zobaczyć, co i gdzie działa nie tak. Niemniej jednak, najlepszym sposobem na zdenerwowanie i frustrowanie każdego programisty, właściciela produktu i dyrektora technicznego jest uporczywe wstawianie kłód pod nogi i opieranie się. Tego rodzaju zachowanie wpłynie na datę wydania jakiegokolwiek produktu, jeśli znów trzeba będzie czekać do ostatniej minuty, więc ponownie wykonaj przesunięcie w lewo i jak najszybciej włącz te kwestie do planu projektu. Jeśli to konieczne, pojaw się na spotkaniach poświęconych produktowi. Noś sztuczne wąsy i filc lub coś w tym stylu, to nigdy nie zawodzi. Zgłoś swoje problemy, pokaż oczywiste korzyści i ewangelizuj.
- Upewnij się, że zarówno programiści (dev), jak i operacje (ops) rozumieją znaczenie i konsekwencje przejścia metryk produktu do „strefy czerwonej”. Nie pozostawiaj operacji jako jedynego strażnika wydolności produktu, upewnij się, że programiści również w tym uczestniczą (#productsquads).
- Logi to doskonała rzecz, ale metryki też. Połącz je i nie pozwól, aby twoje logi stały się śmieciami w ogromnym płonącym kuli bezsensowności. Wyjaśnij i pokaż programistom, dlaczego nikt poza nimi nie zrozumie ich logów, pokaż im, jak to jest przeglądać bezużyteczne logi o 3:15 rano.
Autor zdjęcia na
To wszystko. Nowy materiał pojawi się w przyszłym tygodniu. Jeśli chcesz dowiedzieć się więcej o kursie, zapraszamy na , który odbędzie się już w poniedziałek. A teraz tradycyjnie czekamy na twoje komentarze.
Źródło: habr.com
