Azure GetLogger, czyli o logach w zachmurzonych mikroserwisach

Azure GetLogger, czyli o logach w zachmurzonych mikroserwisach

Mariusz Budzyn 13 czerwca 2017

Logi – temat stary jak świat... programistów :) Wydaje się, że wszystko zostało już wymyślone – a jednak nie wszystko! Wciąż jeszcze zdarzają się świeże pomysły. Na przykład narzędzie Application Insights Microsoftu, która przenosi logi na wyższy poziom! Oczywiście sama usługa to zdecydowanie więcej, niż tylko logi - i nie chciałbym, byście kojarzyli ją tylko w ten sposób. Ale sami zobaczcie, jak świetnie wpisuje się w ten scenariusz.

W tym i w przyszłych wpisach chciałbym Wam przybliżyć, jak w FinAi wykorzystaliśmy Application Insights. Dziś na warsztat weźmiemy strukturę, przykładowe użycie, otrzymacie też kilka porad: o czym pomyśleć przed produkcyjnym wdrożeniem? A w kolejnym odcinku zagłębimy się w konsumpcję alertów.

Zaczynajmy! :)

 

Krótko o usłudze Application Insights

Usługa Application Insights składa się kilku komponentów, które wzajemnie się uzupełniają i rozszerzają funkcjonalność. Centralnym elementem jest usługa chmurowa (Azure), która służy jako kontener dla zdarzeń. Źródłem zdarzeń jest zestaw bibliotek na różne platformy i języki. Można by uogólnić: loggery i plik w chmurze.

Tym, co wyróżnia rozwiązanie Microsoft, jest analityka. Portal Analytics jest przeglądarkowym interfejsem dostępu do „bazy danych” z własnym językiem zapytań przypominającym wymieszanego SQL-a z Linq.

Dopełnieniem jest komponent Azure, który pozwala konfigurować usługę chmurową oraz posiada podstawowe raporty bazujące na zdarzeniach.

 

 

Kontener zdarzeń w Azure

"Gdzie trafiają logi Waszych aplikacji? Do bazy danych? Jednej? A jeśli nie działa? Do plików? Ale ilu plików?"

Chyba nie jestem w stanie zliczyć ile razy zdarzyło mi się prosić użytkowników końcowych aplikacji, by przesłali mi logi produkcji na maila żeby zdiagnozować problem: jako wycinek wpisów z bazy danych w CSV lub spakowane pliki płaskie. A to nie ten plik, a to potrzeba pliku z logami innego komponentu. Czasem logi w bazie danych były zbyt ubogie w treść (schemat nie uwzględniał specyficznych danych) i dochodziło szukanie po dyskach dokładniejszych informacji.

Rozwiązanie Microsoft Application Insights: jeden kontener. Zawiera kilka schematów (traces, requests, exceptions, customEvents itd.) z podstawowymi atrybutami (np. duration, sucess, session_id) oraz miejscem na własne atrybuty – my dodaliśmy m.in. httpMethod, urlReferrer, LoggerName, ClassName, ThreadName.

Logi zapisywane są jako JSON-y – jak debugujecie aplikację w VS możecie podejrzeć, jaki JSON leci do Azure. Jako że jest to JSON to możecie dorzucić cokolwiek innego, od stack trace po cały zserializowany obiekt – np. kontekst, request header.

Sam kontener przechowuje dane przez maksymalnie 90 dni. Mało? Jest na to rozwiązanie: eksport do bloba. Kilka kliknięć w portalu Azure (dosłownie kilka: aktywacja, wybranie komponentu i nazwanie/wskazanie kontenera) i po prostu działa. Do samego bloba wystarczy dopiąć strumieniowanie np. do Log Analytics lub ELK i można cieszyć się logami „od początku świata” 😊

A na koniec dodatkowy atut usługi: Microsoft daje w pełni funkcjonalną wersję za darmo - z ograniczeniem na wielkość danych: 1GB miesięcznie. Nie jest to dużo – my dla bloga codziennie generujemy średnio 120MB przy 1500 odsłonach. Oczywiście można podnieść limit i płacić za nadwyżkę – około 2€ za każdy dodatkowy GB danych w miesiącu i/lub zmienić logowanie z każdego eventu na próbkowanie.

 

Biblioteki oraz API

Microsoft standardowo daje biblioteki do wykorzystania Application Insights w środowisku .NET – ale również powstają otwarte biblioteki dla innych języków. Miałem okazje wypróbować wersje dla PHP i działa równie dobrze co dla C# - oczywiście było mniej gotowych konfiguracji, a te dla C# są już bardzo dobrze predefiniowane i dużo rzeczy jest gotowych od razu po instalacji. Przykładowo, do zaraportowania czasu wykonania metody w PHP:

 

1.	$startFile = microtime(true);
2.	$startFileTime=time();
3.	WebStart();
4.	$execMiliSek = (microtime(true) - $start) * 1000;
5.	$telemetryClient->trackDependency('PHP page proceesing', \ApplicationInsights\Channel\Contracts\Dependency_Type::OTHER, str_replace($IP,"",__FILE__).'->WebStart', $startTime, $execMiliSek, true, NULL, NULL, ['CallID' => $oper]);

 A w C#:

1.	var startTime = DateTime.UtcNow;
2.	var timer = System.Diagnostics.Stopwatch.StartNew();
3.	try
4.	{
5.	 success = myObj.DoJob();
6.	}
7.	finally
8.	{
9.	 timer.Stop();
10.	 telemetry.TrackDependency("myObj", "DoJob", startTime, timer.Elapsed, success);
11.	}

Do tego, jako wisienka na torcie, dochodzi biblioteka javascript, która działa bezpośrednio w przeglądarce użytkownika – mierząc i wysyłając informacje o zdarzeniach na urządzeniach końcowych, jak np. czas ładowania strony oraz czas przeglądania strony. Dodawanie własnych informacji jest równie proste:

1.	try
2.	{
3.	   ...
4.	}
5.	catch (ex)
6.	{
7.	   appInsights.trackException(ex);
8.	}

Aby jeszcze bardziej ułatwić integrację usługi Microsoft, powstają dedykowane target’y dla popularnych bibliotek do logowania - np. log4net oraz nlog. Dobre doraźne rozwiązanie, ale zdecydowanie polecam skorzystanie z bibliotek do logowania semantycznego jak np. Serilog.

 

Application Insights Analytics

Portal Azure dostarcza pierwszych podstawowych raportów na bazie zdarzeń, takich jak: czas ładowania stron/ wykonywania funkcji, czas czekania na komponenty zewnętrzne (np. API, baza danych), czas generowania odpowiedzi po stronie serwera oraz klienta, najczęstsze strony, użytkownicy, lokalizacje użytkowników itp.

Zazwyczaj będzie to za mało, dlatego Microsoft daje dedykowany portal w którym można budować własne raporty. Zdarzenia podzielone są na kilka grup, m.in.: exceptions, traces, dependencies, custom events, page views. Każda grupa ma zdefiniowane własne atrybuty zdarzenia, ale jest też tablica par string-string, gdzie można dodawać wszelkie własne informacje.

Raporty buduje się w dedykowanym języku, który jest całkiem intuicyjny i szybko przyswajalny – w moim odczuciu to mix SQL i Linq. Oczywiście w ten sposób możemy budować proste raporty i, na szczęście, do budowy bardziej zaawansowanych dashboardów można korzystać z konektorów. My wykorzystaliśmy Microsoft PowerBI do przeglądania podstawowych technicznych statystyk z filtrami „user friendly” oraz dodatkowymi statystykami (np. kwantyle).

Dodatkową dobroć Microsoft’u czuć również w automatycznych powiadomieniach o niepokojących sytuacjach. Microsoft daje zestaw swoich powiadomień, jak również pozwala na zdefiniowanie własnych. W kolejnym artykule pokażę Wam, jak u nas zdefiniowaliśmy i skonsumowaliśmy alerty o błędach. Automatycznie na podstawie logów (dependency) wyznaczana jest mapa aplikacji, która w graficzny sposób przedstawia zależności komponentów oraz średni czas wywołań + wskaźnik błędów.

 

Gdzie potrzeba prawdziwej pracy architekta/programisty

Microsoft zrobił dużo dobrej roboty, ale wcale nie wyczerpał tematu w 100%. Wykorzystanie mocy Application Insights wymaga trochę wkładu własnego.

Przede wszystkim zaplanujcie jak to ma działać. Cały czas poprawiamy swoje użycie w kontekście logowania zdarzeń pomiędzy komponentami. W aplikacji monolitycznej Microsoft z automatu wszystko robi za Was – oznacza sesje, nadaje identyfikator użytkownika, zapisuje referencje od requesta po zależności (np. zapytanie do bazy danych) – wszystko oznaczone przez operationId oraz parentOperationId.

Ale gdy mówimy o architekturze mikroserwisów, to chcemy mieć powiązania pomiędzy serwisami, by złożyć całą sekwencje komunikacji. Technicznie nic trudnego. Ale koncepcyjnie trzeba się dobrze zastanowić, by móc odtworzyć wszystko od pierwszego żądania klienta po późniejsze asynchroniczne AJAX-y.

Dodatkowo brakuje prostych informacji, np. adresu URL, z którego wyszedł request, pełny adres IP żądającego (standardowo ostatni segment jest zerowy) czy czasu przeglądania samej strony. Wszystkie te informacje łatwo dodaliśmy do atrybutów telemetrii.

telemetry.Properties.Add("urlReferrer", ctx.Request.UrlReferrer != null ? ctx.Request.UrlReferrer.ToString() : null);

Do starego konceptu logowania Microsoft dodał analitykę oraz automatyczne powiadomienia, a to wszystko - w komplecie z łatwo konfigurowalną usługą dostępną za darmo - pokazuje, że można na świeżo podejść do tego starego i prostego konceptu. Nie wyklucza to tradycyjnych rozwiązań i ma bardzo niski koszt wdrożenia – dlatego zdecydowanie polecam wykorzystać i wypróbować w swoich projektach.

 

Mariusz Budzyn, FinAi.com

Warszawa, 13 czerwca 2017 roku

Location icon Facebook icon Twitter icon Google+ icon LinkedIn icon Technology icon Business icon Marketing icon Phone icon Mail icon User icon Tag icon Bubble icon Arrow right icon Arrow left icon Calendar PR Contact