Niedawno David O'Brien założył swoją własną firmę Xirus (https://xirus.com.au), koncentrując się na produktach chmurowych Microsoft Azure Stack. Są one przeznaczone do spójnego tworzenia i uruchamiania aplikacji hybrydowych w centrach danych, lokalizacjach brzegowych, zdalnych biurach oraz w chmurze.
David szkoli osoby i firmy we wszystkim, co związane z Microsoft Azure i Azure DevOps (dawniej VSTS) oraz nadal zajmuje się praktycznym doradztwem i infrastrukturą jako kodem. Od pięciu lat jest posiadaczem nagrody Microsoft MVP (Najcenniejszy Profesjonalista Microsoft), a niedawno otrzymał nagrodę MVP Azure. Jako współorganizator Melbourne Microsoft Cloud i Datacentre Meetup, O'Brien regularnie występuje na międzynarodowych konferencjach, łącząc swoje zainteresowanie podróżami po świecie z pasją do dzielenia się historiami IT z społecznością. Blog Davida znajduje się pod adresem , publikuje także swoje szkolenia online na platformie Pluralsight.
W wystąpieniu omawiana jest ważność metryk w zrozumieniu, co dzieje się w Twoim środowisku i jak działa Twoja aplikacja. Microsoft Azure oferuje potężny i prosty sposób wyświetlania metryk dla wszystkich rodzajów obciążeń roboczych, a w wykładzie mówi się, jak można je wszystkie wykorzystać.
O trzeciej w nocy, w niedzielę, podczas snu nagle budzi Cię dźwięk wiadomości tekstowej: „Krytyczna aplikacja znów nie odpowiada”. Co się dzieje? Gdzie i w czym leży przyczyna „zawieszenia”? Z tego sprawozdania dowiesz się o usługach, które Microsoft Azure oferuje klientom do zbierania logów, a w szczególności metryk Twoich chmurowych obciążeń roboczych. David opowie, jakie metryki powinny Cię interesować podczas pracy na platformie chmurowej i jak się do nich dostać. Poznasz narzędzia z otwartym kodem i budowania paneli monitorujących, a w rezultacie zdobędziesz wystarczającą wiedzę, aby stworzyć własne panele.
I jeśli o trzeciej w nocy znów obudzi Cię wiadomość o awarii krytycznej aplikacji, będziesz mógł szybko zrozumieć jej przyczynę.
Dzień dobry, dzisiaj porozmawiamy o metrykach. Nazywam się David O’Brien, jestem współzałożycielem i właścicielem małej australijskiej firmy konsultingowej Xirus. Jeszcze raz dziękuję, że przyszliście tutaj, by spędzić ze mną czas. A więc, po co tutaj jesteśmy? Aby porozmawiać o metrykach, a dokładniej, ja wam o nich opowiem, a zanim przejdziemy do konkretów, zaczniemy od teorii.
Opowiem, czym są metryki, co można z nimi zrobić, na co zwrócić uwagę, jak zbierać metryki oraz jak włączać ich zbieranie w Azure i czym jest wizualizacja metryków. Pokażę wam, jak te rzeczy wyglądają w chmurze Microsoftu oraz jak z nią działać.
Zanim zaczniemy, poproszę o podniesienie rąk tych, którzy korzystają z Microsoft Azure. A kto pracuje z AWS? Widzę, że niewielu. A z Google? ALI Cloud? Jedna osoba! Świetnie. A więc, czym są metryki? Oficjalna definicja Narodowego Instytutu Standardów i Technologii USA brzmi: „Metryka to standard pomiaru, który opisuje warunki i zasady wykonywania pomiaru jakiejś cechy i służy do zrozumienia wyników pomiaru”. Co to oznacza?
Rozważmy jako przykład metrykę dotyczącą zmiany wolnego miejsca na dysku maszyny wirtualnej. Na przykład, gdy otrzymujemy liczbę 90, oznacza to procenty, a więc wolne miejsce na dysku wynosi 90%. Zaznaczam, że nie jest zbyt interesujące czytać opis definicji metryki, który zajmuje 40 stron w formacie pdf.
Jednak metryka nie mówi, w jaki sposób uzyskano wynik pomiaru, tylko pokazuje ten wynik. Co robimy z metrykami?
Przede wszystkim mierzymy wartość czegoś, aby następnie wykorzystać wynik pomiaru.
Na przykład, dowiedzieliśmy się o wielkości dostępnego miejsca na dysku i teraz możemy go wykorzystać, używać tej pamięci itd. Po otrzymaniu wyniku metryki, musimy go zinterpretować. Na przykład, metryka dała wynik 90. Musimy wiedzieć, co oznacza ta liczba: wielkość dostępnego miejsca lub zajętego miejsca na dysku w procentach lub gigabajtach, opóźnienie sieci wynoszące 90 ms, itd., co oznacza, że musimy zrozumieć sens wartości metryki. Aby metryki miały sens, po interpretacji jednej wartości musimy zapewnić zbieranie wielu wartości. To bardzo ważne, ponieważ wielu ludzi nie zdaje sobie sprawy z potrzeby zbierania metryk. Microsoft ułatwił proces pozyskiwania metryk, ale sami musisz zapewnić ich zbieranie. Te metryki są przechowywane przez 41 dni, a w dniu 42. znikają. Dlatego w zależności od właściwości twojego sprzętu zewnętrznego lub wewnętrznego, powinieneś zadbać o to, jak przechowywać metryki przez więcej niż 41 dni – w postaci logów, dzienników itd. W ten sposób, po zebraniu, musisz umieścić je w jakimś miejscu, które umożliwi przywrócenie całej statystyki zmiany wyników metryk w razie potrzeby. Umieszczając je tam, będziesz mógł rozpocząć z nimi skuteczną pracę.
Tylko po uzyskaniu wartości metryk, ich zinterpretowaniu i zebraniu, będziesz mógł stworzyć SLA – umowę o poziomie świadczenia usługi. Ten SLA może nie mieć szczególnego znaczenia dla twoich klientów, jest bardziej istotny dla twoich współpracowników, menedżerów, tych, którzy odpowiadają za działanie systemu i są zaniepokojeni jego funkcjonalnością. Metryka może mierzyć liczbę zgłoszeń – na przykład, otrzymujesz 5 zgłoszeń dziennie, a w tym przypadku pokazuje szybkość reakcji na zapytania użytkowników i prędkość usuwania usterek. Metryka nie powinna tylko informować, że twoja strona ładuje się w 20 ms lub że czas odpowiedzi wynosi 20 ms, metryka to więcej niż tylko jeden wskaźnik techniczny.
Zatem celem naszej rozmowy jest przedstawienie ci rozbudowanego obrazu istoty metryk. Metryka służy temu, abyś, spoglądając na nią, mógł uzyskać pełny obraz procesu.
Gdy tylko uzyskamy metrykę, możemy w 99% zagwarantować poprawne działanie systemu, ponieważ to nie tylko spojrzenie na plik logów, w którym napisano, że system działa. Gwarancja 99% operacyjności oznacza, że na przykład w 99% przypadków API odpowiada z normalną prędkością 30 ms. To właśnie to interesuje Twoich użytkowników, kolegów i menedżerów. Wielu naszych klientów śledzi logi serwerów WWW, nie zauważając w nich żadnych błędów i myśląc, że wszystko jest w porządku. Na przykład widzą wskaźnik prędkości sieci 200 Mb/s i myślą: „ok, wszystko świetnie!”. Ale aby osiągnąć te 200, użytkownicy potrzebują czasu odpowiedzi wynoszącego 30 milisekund, a to właśnie ten wskaźnik, który nie jest mierzony ani zbierany w plikach logów. W rezultacie użytkownicy są zaskoczeni, że strona ładowana jest bardzo wolno, ponieważ, nie mając odpowiedniej metryki, nie znają przyczyny takiego zachowania.
Jednak ponieważ mamy SLA gwarantujące 100% operacyjności, klienci zaczynają wyrażać swoje oburzenie, ponieważ w rzeczywistości korzystanie ze strony jest bardzo trudne. Dlatego do stworzenia obiektywnego SLA konieczne jest widzenie pełnego obrazu procesu, tworzonego na podstawie zbieranych metryk. To jest przedmiotem mojego stałego sporu z niektórymi dostawcami, którzy przy tworzeniu SLA nie rozumieją, co oznacza termin „uptime” i w większości przypadków nie wyjaśniają swoim klientom, jak działa ich API.
Jeśli stworzyłeś usługę, na przykład API dla osoby trzeciej, musisz rozumieć, co oznacza uzyskana metryka 39,5 – odpowiedź, udana odpowiedź, odpowiedź z prędkością 20 ms lub z prędkością 5 ms. To Ty musisz dostosować ich SLA do własnego SLA, do swoich własnych metryk.
Gdy już to wszystko ustalisz, możesz przystąpić do tworzenia wspaniałego panelu monitorowania. Powiedzcie, czy ktoś korzystał już z aplikacji do interaktywnej wizualizacji Grafana? Świetnie! Jestem dużym fanem tego otwartego oprogramowania, ponieważ jest to darmowe i łatwe w użyciu.
Jeśli jeszcze nie korzystałeś z Grafany, wyjaśnię, jak z nią pracować. Ci, którzy urodzili się w latach 80-90, pewnie pamiętają troskliwe misie CareBears? Nie wiem, jak popularne były w Rosji, ale w kontekście metryk musimy być tak samo „troskliwymi misiami”. Jak już wspomniałem, potrzebujesz pełnego obrazu działania całego systemu, który nie powinien dotyczyć tylko Twojego API, Twojej strony internetowej czy usługi uruchomionej na maszynie wirtualnej.
Musisz zorganizować zbieranie tych metryk, które najlepiej odzwierciedlają działanie całego systemu. Większość z Was jest programistami, dlatego Wasze życie nieustannie się zmienia, dostosowując się do nowych wymagań produktów. Tak samo, jak martwicie się procesami kodowania, musicie zadbać o metryki. Powinniście wiedzieć, jak metryka dotyczy każdego wiersza napisanego przez Was kodu. Na przykład w przyszłym tygodniu rozpoczynacie nową kampanię marketingową i oczekujecie, że Wasza strona internetowa przyciągnie dużą liczbę użytkowników. Aby przeanalizować to zdarzenie, potrzebne będą Wam metryki i być może cała tablica do śledzenia aktywności tych osób. Metryki będą Wam potrzebne, aby zrozumieć, jak skuteczna i w rzeczywistości działa Wasza kampania marketingowa. Pomogą Wam na przykład w opracowaniu skutecznego CRM — systemu zarządzania relacjami z klientami.
Zatem przejdźmy do naszego rozwiązania w chmurze Azure. W nim bardzo łatwo znaleźć i zorganizować zbieranie metryk, ponieważ istnieje Azure Monitor. Ten monitor centralizuje zarządzanie konfiguracją Twojego systemu. Każdy z elementów Azure, który chcesz zastosować w swoim systemie, ma wiele domyślnie włączonych metryk. To darmowa aplikacja, która działa od razu „z pudełka” i nie wymaga żadnych wstępnych ustawień; nie musisz nic pisać ani „przyczepiać” do swojego systemu. Upewnimy się o tym, przeglądając następne demo.
Ponadto istnieje możliwość wysyłania tych metryk do aplikacji zewnętrznych, takich jak system do przechowywania i analizy logów Splunk, chmurowa aplikacja do zarządzania logami SumoLogic, narzędzie do przetwarzania logów ELK oraz IBM Radar. Istnieją jednak pewne niewielkie różnice, które zależą od używanych przez Państwa zasobów – maszyn wirtualnych, usług sieciowych, baz danych Azure SQL, to znaczy, że wykorzystanie metryk różni się w zależności od funkcji środowiska roboczego. Nie twierdzę, że te różnice są poważne, ale niestety są, i należy je uwzględnić. Włączenie i przesyłanie metryk możliwe jest na kilka sposobów: przez Portal, CLI/Power Shell lub za pomocą szablonów ARM.
Zanim zaczniemy pierwszą prezentację, odpowiem na Państwa pytania. Jeśli nie ma pytań, przystąpmy do działania. Na ekranie widać, jak wygląda strona Azure Monitor. Czy ktoś z Państwa może powiedzieć, że ten monitor nie działa?
Zatem, teraz wszystko jest w porządku, widzą Państwo, jak wyglądają usługi monitorowania. Mogę powiedzieć, że jest to doskonałe i bardzo proste narzędzie do codziennej pracy. Dzięki niemu można monitorować aplikacje, sieć i infrastrukturę. Niedawno interfejs monitorowania został ulepszony, a jeśli wcześniej usługi były rozmieszczone w różnych miejscach, to teraz wszystkie informacje o usługach są skonsolidowane na stronie głównej monitora.
Tabela metryk to zakładka na ścieżce HomeMonitorMetrics, którą można odwiedzić, aby zobaczyć wszystkie dostępne metryki i wybrać te, które są potrzebne. Jednak jeśli chcą Państwo włączyć zbieranie metryk, należy skorzystać ze ścieżki katalogu HomeMonitorDiagnostic settings i zaznaczyć pola wyboru dla metryk Włączone/Wyłączone. Domyślnie prawie wszystkie metryki są włączone, ale jeśli potrzebują Państwo włączyć coś dodatkowego, należy zmienić status diagnostyki z Wyłączone na Włączone.
Aby to zrobić, należy kliknąć w wiersz wybranej metryki, a na otwartej zakładce włączyć tryb diagnostyki. Jeśli zamierzają Państwo analizować wybraną metrykę, po kliknięciu w link Włącz diagnostykę należy zaznaczyć w pojawiającym się oknie pole wyboru Wyślij do Log Analytics.
Log Analytics jest nieco podobny do Splunk, ale jest tańszy. Usługa ta pozwala na zbieranie wszystkich Twoich metryk, logów i wszystkiego, co potrzebujesz, oraz umieszczanie ich w przestrzeni roboczej Log Analytics. Usługa wykorzystuje specjalny język zapytań KQL – Kusto Query Language, którego działanie omówimy w następnej demonstracji. Jak na razie warto zaznaczyć, że za jego pomocą można formułować zapytania dotyczące metryk, logów, terminów, trendów, wzorców itp. oraz tworzyć pulpit nawigacyjny.
Zaznaczamy więc pole wyboru Wyślij do Log Analytics oraz pola wyboru na panelu LOG: DataPlaneRequests, MongoRequests i QueryRuntimeStatistics, a poniżej na panelu METRIC – pole wyboru Requests. Następnie nadajemy jakąś nazwę i zapisujemy ustawienia. W linii poleceń będzie to dwie linijki kodu. A propos, powłoka Azure Cloud przypomina Google, który również pozwala na korzystanie z linii poleceń w przeglądarce internetowej. AWS nie ma nic podobnego, więc Azure jest w tym względzie znacznie bardziej wygodne.
Na przykład mogę uruchomić demonstrację przez interfejs internetowy, nie używając do tego żadnego kodu na swoim laptopie. W tym celu muszę przejść autoryzację za pomocą mojego konta Azure. Następnie można użyć na przykład terrafone, jeśli już z niego korzystasz, poczekać na połączenie z usługą i uzyskać środowisko robocze Linux, które Microsoft używa domyślnie.
Następnie korzystam z Basha, który jest wbudowany w Azure Cloud Shell. Bardzo przydatną rzeczą jest wbudowane w przeglądarkę IDE, uproszczona wersja VS Code. Potem mogę wejść w mój szablon metryki błędów, zmienić go i dostosować do swoich potrzeb.
Po skonfigurowaniu w tym szablonie zbierania metryk, możesz go użyć do tworzenia metryk dla całej swojej infrastruktury. Po tym, jak zastosowaliśmy metryki, zebraliśmy je i zapisaliśmy, będziemy musieli je zwizualizować.
Azure Monitor zajmuje się wyłącznie metrykami i nie daje możliwości uzyskania ogólnego obrazu stanu Twojego systemu. Możesz mieć wiele innych aplikacji, które działają poza środowiskiem Azure. Więc jeśli potrzebujesz monitorować wszystkie procesy, wizualizując wszystkie zebrane metryki w jednym miejscu, Azure Monitor nie będzie odpowiedni.
Aby rozwiązać ten problem, Microsoft oferuje narzędzie Power BI – kompleksowe oprogramowanie do analizy biznesowej, które obejmuje wizualizację różnorodnych danych. Jest to dość drogi produkt, którego cena zależy od wymaganych funkcji. Domyślnie oferuje 48 rodzajów przetwarzanych danych i jest powiązany z magazynami danych SQL Azure, Azure Data Lake Storage, usługami uczenia maszynowego Azure oraz Azure Databricks. Dzięki skalowalności można co 30 minut uzyskiwać nowe dane. Może to wystarczyć dla Twoich potrzeb, lub nie wystarczyć, jeśli potrzebujesz wizualizacji w czasie rzeczywistym. W takim przypadku zaleca się korzystanie z aplikacji takich jak wspomniana przeze mnie Grafana. Ponadto w dokumentacji Microsoft opisano możliwość przesyłania metryk, logów i tabel zdarzeń za pomocą SIEM – narzędzi do systemów wizualizacji Splunk, SumoLogic, ELK i IBM radar.
23:40 min
Ciąg dalszy wkrótce…
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
