Tworzenie aplikacji na Azure w postaci kodu uruchamianego „serverless” jest popularne wśród klientów. Problem tylko w tym, że zdiagnozowanie problemu może być dość kłopotliwe.
Owszem, można konfigurować application insights, które znacznie ten proces ułatwiają, ale co zrobić, jeśli klient zdecydował się nie korzystać z tej funkcjonlności? Bo za dorogo, bo nie widzi wartościw dobrym diagnozowaniu problemów? No cóż…
Mam na to swój własny sposób:
Oznaczanie uruchomienia funkcji
Funkcja może być jednocześnie uruchamiana w wielu sesjach. Jak rozpoznać logi gromadzone w LogAnalytics Workspace, żeby to wszystko się nie wymieszało? Na początku działania funkcji dodaję kod, który identyfikuje ten jeden wątek. Nie chcę przy tym, żeby był to jakiś nic-nie-znaczący UID. Chciałbym coś, co potrafię wypowiedzieć i zapamiętać. Generuję więc sobie losowy kod składający się z 6 liter, tak że pierwsza litera to spółgłoska i na zmianę występują w nim samo- i spół- głoski. Powstaje coś w rodzaju MATOKA. Napis dziwny, ale da radę go zapamiętać w skali powiedzmy 10 minut, prawda? Oto funkcja generująca taki kod w PowerShell:
# Crate ID to easier find the entries in the logs
$gr1 = "BCFFGHJKLMNPQRSRVWXZ";
$gr2 = "AEIOUY"
$ID = "";
for ($i = 0; $i -lt 3; $i++) { $ID += $gr1[(Get-Random -Maximum $gr1.Length)]; $ID += $gr2[(Get-Random -Maximum $gr2.Length)] }
Potem, gdziekolwiek w funkcji, kiedy chcę coś „zalogować” używam funkcji:
function ShowInfo{
param(
$ID, $MSG
)
Write-Output "$ID - O - $MSG"
}Np. tak:
ShowInfo $ID "JSON INPUT: $json_input"Wyszukiwanie logów
Szczęśliwie każda funkcja loguje do LogAnalytics Workspace. Wystarczy otworzyć dany log i uruchomić odpowiednio przygotowane wyrażenie KUSTO:
FunctionAppLogs
| where FunctionName == 'MyFunctionName'
| where Message contains "FAFOBE"
| project TimeGenerated, MessageLogi na żywo
Powyższy proces jest już całkiem ok, dla tych zdarzeń, które rzeczywiście są „zaplanowane” i „zaprogramowane”. A co jeśli dochodzi do exception, którego nie przewidzieliśmy. Jak dla mnie bardzo dobrze sprawdza się „Log stream” dostępny w konsoli Kudu. W portalu Azure w funkcji przejdź do Development Tools i wybierz Advanced Tools (oznaczony ikonką scyzoryka). Otworzy to nową stronę do konsoli Kudu właśnie, a tam u góry można znaleźć między innymi Log Stream. Kliknięcie tego linka powoduje, że zobaczysz stronę prezentującą wszystkie logi aplikacji, (te własne jak i te aplikacyjne), które będą się wyświetlać „na żywo”. Jeśli więc w programie został wyrzucony jakiś wyjątek, którego lepiej nie obsłużyliśmy, to znajdziemy go właśnie tutaj
Jeśli z kolei chcemy pogrzebać po wszystkich logach jak za dawnych czasów, to można wybrać link Bash i przejść do katalogu /home/LogFiles, a tam jest już administracyjny raj troubleshootera. Logi w plikach tekstowych, które można grepować, przeszukiwać filtrować i co tam tylko zechcesz!
