Logowanie i analiza zdarzeń aplikacji

Analiza działającego systemu informatycznego coraz częściej realizowana jest z pomocą mechanizmu logowania. Logi pozwalają na tworzenie różnego rodzaju statystyk, wykrywanie błędów czy debugowanie działającego na produkcji systemu. Można zaobserwować jak użytkownicy korzystają z aplikacji, w których częściach przesiadują dłużej, w których krócej. Analizując logi można bardzo szybko dojść w którym miejscu aplikacji dochodzi do błędów, wycieków pamięci, dlaczego aplikacja działa wolniej itp. Logowanie najczęściej sprowadza się do zapisywania informacji, o różnym poziomie szczegółowości, na temat tego co aktualnie dzieje się w systemie. Zapiski te najczęściej trafiają do pliku tekstowego, aczkolwiek coraz częściej loguje się je również do baz danych lub bezpośrednio wyrzuca na konsolę. Logi mogą być bardziej szczegółowe – logować można dosłownie wszystko, lub mniej szczegółowe – skupiamy się na wyłapaniu interesujących nas rzeczy, np. samych błędów. Pliki logów najczęściej przechowują datę i godzinę zajścia zdarzenia, rodzaj oraz krótki opis tego, co się właśnie wydarzyło.

Konfiguracja logowania po stronie chmury

Azure domyślnie nie loguje żadnych informacji związanych z aplikacją, o wszystko należy zadbać samemu. Po wybraniu web aplikacji klikamy w Dzienniki diagnostyczne (Diagnostic logs). W tym miejscu można aktywować logowanie, zarówno po stronie aplikacji (Application Logging) oraz po stronie serwera sieci Web (Web Server Logging). Logi aplikacji zbierane są tylko przez 12h, jeśli po tym czasie dalej będą Ci potrzebne, należy tu wrócić i ponownie je aktywować.

Logi mogą być zapisywane do pliku lub magazynu danych (Azure Storage). Uważam, że system plików jest tutaj w pełni wystarczający, aczkolwiek na potrzeby egzaminu proponuję przetestować logowanie do blob – przypominam o dodatkowej opłacie za magazyn danych. Niech system plików loguje na poziomie Błąd (Error), natomiast blob Informacje Pełne (Verbose). Kiedy decydujesz się na logowania z wykorzystaniem blob’ów należy wskazać magazyn danych, który będzie je przechowywał. Najlepiej stworzyć nowe konto magazynu, które będzie odpowiadało tylko i wyłącznie za przechowywanie logów (wybierz wydajność standardową oraz replikację na poziomie LRS). Następnie będziesz musiał jeszcze dodać nowy kontener – może być prywatny. Gdy będziesz już miał gotowy magazyn wybierz go, wraz z kontenerem do którego powędrują logi. Dalej musisz jeszcze skonfigurować liczbę dni, po których logi zostaną automatycznie usunięte.

Niżej znajdują się logi związane z serwerem aplikacji IIS, które mogą być również logowane do systemu plików lub magazynu danych (najlepiej osobnego lub przynajmniej innego kontenera). Ponadto można włączyć szczegółowe komunikaty o błędach (Detailed Error Messages) oraz rejestrowanie nieudanych żądań (Failed Request Tracking). Szczegółowe komunikaty dostarczają o wiele bardziej rozbudowane logi – dodawany jest kod błędu oraz szczegółowa wiadomość na temat zaistniałego błędu. Rejestrowanie nieudanych żądań loguje informacje na temat niepoprawnych odwołań do serwera. Żeby troszkę odchudzić logi proponuję uaktywnić logi samej aplikacji:

Konfiguracja logowania za pomocą portalu
Konfiguracja logowania za pomocą portalu

Na samym dole znajdują się jeszcze informacje na temat połączenia do serwerów FTP oraz FTPS, z których będzie można pobrać pliki z logami.

Logowanie można również aktywować z pomocą komend PowerShella:

Gdzie i jak logować

W przeciwieństwie do logów serwerowych, które tak naprawdę generowane są automatycznie, za logi aplikacji odpowiedzialni są deweloperzy. Tylko i wyłącznie Oni decydują o tym, co i gdzie będzie logowane. W aplikacji należy napisać dodatkowy kod, odpowiedzialny za zapis do logu. W przypadku projektów realizowanych np. w technologii node.js można posłużyć się poleceniami console.log() lub console.error(). Można pokusić się o wykorzystanie jakiejś dodatkowej biblioteki logującej, takiej jak Winston czy Bunyan. W aplikacjach .NET’owych najprostszym rozwiązaniem jest klasa Trace, wchodząca w skład przestrzeni System.Diagnostics. Fragment kodu (ASP.MVC):

Pozostało jeszcze pytanie, gdzie znajdują się moje pliki z logami? Jeżeli zdecydowaliśmy się na wykorzystanie systemu plików poszczególne logi znajdziemy w następujących katalogach:

  • logi aplikacji: D:\home\LogFiles\Application
  • logi serwera: D:\home\LogFiles\HTTP\RawLogs
  • szczegółowe komunikaty o błędach: D:\home\LogFiles\DetailedErrors
  • zarejestrowane nieudane żądania: D:\home\LogFiles\W3SVC<losowy_identyfikator#>

W przypadku logów znajdujących się w magazynie danych wystarczy odwiedzić odpowiedni kontener, a następnie pobrać plik z logiem.

Pamiętaj, żeby po wdrożeniu aplikacji na serwer , trochę po niej poklikać – trzeba wygenerować trochę logów 🙂

Pobieramy logi

Pliki z logami możemy pobrać na wiele różnych sposobów:

  • z wykorzystaniem portalu Kudu – po zalogowaniu do portalu klikamy w Debug Console, a następnie w CMD. Nawigujemy w jedną z ścieżek wyszczególnionych powyżej, gdzie powinny znajdować się logi – możesz je podejrzeć przez ikonkę edycji pliku. Przeglądając logi aplikacji powinieneś zobaczyć tylko i wyłącznie wpisy z poziomu error,
  • za pomocą portalu – po wybraniu web aplikacji kliknij w zakładkę Konsola (Console), a następnie posłuż się następującym skryptem:

    Podgląd logów z wykorzystaniem konsoli portalu
    Podgląd logów z wykorzystaniem konsoli portalu
  • połączenie z serwerem za pomocą FTP lub FTPS – pobieramy pliki lub mapujemy FTP na nową partycję,
  • WebJobs – pobieramy wszystkie logi, przetwarzamy, wysyłamy np. emailem lub wystawiamy do pobrania gotową paczkę,
  • Visual Studio – łączymy się z chmurą za pomocą Cloud Explorer’a. Następnie rozwijamy wybraną subskrypcję, potem App Services i web apkę. Następnie wybieramy katalog Log Files gdzie możemy podejrzeć wszystkie logi na serwerze.

Podgląd logów na żywo

Jedną z najciekawszych funkcjonalności jest możliwość podglądu logowania informacji „na żywo”, podczas działania aplikacji. Funkcja ta dostępna jest z poziomu Visual Studio – konieczne tutaj będzie uaktywnienie zdalnego debuggowania aplikacji (Remote Debugging) o którym więcej za chwilę. Logi można również podglądać w trakcie działania aplikacji z pomocą portalu Azure’owego oraz Kudu.

Rejestrowanie strumienia z pomocą portalu Azure oraz Kudu

Po kliknięciu na aplikację odszukaj zakładkę Rejestruj strumień (Stream Logs). Wybierz zakładkę odpowiadająca interesującym Cię logom, a następnie trochę poklikaj po aplikacji. Oczekiwany rezultat:

Strumieniowanie logów działania aplikacji wewnątrz portalu
Strumieniowanie logów działania aplikacji wewnątrz portalu

W przypadku portalu Kudu, od razu po zalogowaniu, wybieramy zakładkę Tools, a następnie Log stream.

Zdalne debugowanie oraz podgląd logów w Visual Studio

Na portalu wejdź w Ustawienia aplikacji (Application Settings), a następnie włącz zdalne debugowanie zgodnie z wykorzystywaną wersją Visual Studio:

Konfiguracja zdalnego debugowania w ustawieniach aplikacji webowej
Konfiguracja zdalnego debugowania w ustawieniach aplikacji webowej

Teraz przechodzimy do Visual Studio. Ponownie odwiedzamy Cloud Explorer’a,  wyklikujemy web aplikację, prawy przycisk myszy i wybieramy Attach debugger. Aplikacja powinna zostać automatycznie uruchomiona w nowym oknie przeglądarki. W zakładce Output znajdziesz wszystkie zalogowane informacje.

Podgląd logów w Visual Studio 2015
Podgląd logów w Visual Studio 2015

Jakby było tego mało mamy możliwość zdalnego debugowania aplikacji znajdującej się w chmurze 🙂 Całkiem przydatna funkcja.