Microsoft AZ-204: Monitorowanie, diagnostyka i integracja z DevOps w Azure — Przewodnik do nauki

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Część Microsoft Azure Developer Associate AZ-204 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Usługi Azure Monitor i Application Insights zapewniają zjednoczony, zorientowany na deweloperów stos obserwowalności dla aplikacji na platformie Azure. Application Insights zbiera telemetrię aplikacji, taką jak żądania, zależności, wyjątki i ślady, podczas gdy Azure Monitor agreguje metryki i logi ze wszystkich zasobów w obszarze roboczym Log Analytics oraz napędza alerty i integracje DevOps. Opanowanie opcji instrumentacji, semantyki telemetrii, testowania dostępności, języka Kusto Query Language (KQL), alertów z grupami akcji, śledzenia rozproszonego oraz Infrastructure as Code z szablonami ARM zapewnia niezawodne, diagnozowalne i automatyzowalne rozwiązania.

Instrumentacja i telemetria Application Insights

Zasoby Application Insights są identyfikowane do pozyskiwania danych za pomocą klucza instrumentacji lub connection string. Klucz instrumentacji to starszy, pojedynczy identyfikator GUID używany przez zestawy SDK do kierowania telemetrii. Connection string jest obecnie zalecanym rozwiązaniem; zawiera on klucz instrumentacji oraz metadane punktów końcowych (punkty końcowe pozyskiwania danych i Live Metrics) i pozwala na kierowanie ruchu do niestandardowych punktów końcowych (dla chmur suwerennych lub prywatnych). Używaj connection string w nowym kodzie i konfiguracji; umożliwia to przyszłe zmiany punktów końcowych bez ponownego wdrażania kodu. W ramach App Service, włączenie Application Insights na poziomie platformy spowoduje umieszczenie connection string w ustawieniach środowiskowych dla automatycznie wykrytych środowisk uruchomieniowych.

Instrumentację można przeprowadzić za pomocą SDK lub auto-instrumentacji. Podejście z użyciem SDK (na przykład Microsoft.ApplicationInsights.AspNetCore dla .NET, applicationinsights dla Node.js i agent Application Insights Java) oferuje kontrolę na poziomie kodu: niestandardowe zdarzenia, metryki i wzbogaconą telemetrię za pomocą TelemetryInitializers i procesorów, w tym próbkowanie adaptacyjne (adaptive sampling). Auto-instrumentacja (codeless attach) jest dostępna dla App Service i niektórych stosów obliczeniowych i wykorzystuje rozszerzenia witryn/agentów do zbierania przychodzących żądań, zależności i wyjątków bez żadnych zmian w kodzie. Używaj instrumentacji SDK, gdy potrzebujesz niestandardowych zdarzeń, metryk biznesowych lub jawnej korelacji w zadaniach działających w tle; używaj dołączania bez kodu (codeless attach) w celu szybkiego uzyskania wglądu przy niskim nakładzie pracy lub dla obciążeń typu lift-and-shift. W obu przypadkach ustaw nazwę roli chmury (cloud role name), aby odróżnić usługi w architekturze mikrousług i starannie skonfiguruj próbkowanie, aby zrównoważyć szczegółowość i koszty.

Application Insights emituje kilka podstawowych typów telemetrii:

Requests (Żądania) przechwytują operacje przychodzące (żądania HTTP, wywołania funkcji), z czasem trwania, kodem odpowiedzi i informacją o powodzeniu.
Dependencies (Zależności) przechwytują wywołania wychodzące (HTTP, SQL, wywołania Azure SDK, kolejki), z celem, typem, czasem trwania i informacją o powodzeniu.
Exceptions (Wyjątki) przechwytują zgłoszone błędy, ślady stosu i obsłużone wyjątki, gdy są jawnie śledzone.
Traces (Ślady) przechwytują komunikaty logów; zestawy SDK integrują się z popularnymi frameworkami do logowania, dzięki czemu logi i telemetria współdzielą korelację.
Events (Zdarzenia) przechwytują niestandardowe zdarzenia na poziomie biznesowym za pomocą TrackEvent, wspierając niestandardowe wymiary i liczniki.
Metrics (Metryki) przechwytują pomiary numeryczne; możesz śledzić niestandardowe metryki dla wskaźników KPI i analizować je w Metrics Explorer.

Śledzenie rozproszone w Application Insights opiera się na korelacji. Każda operacja end-to-end ma identyfikator operacji (operation ID, czyli trace ID w terminologii W3C) współdzielony przez powiązaną telemetrię; każdy span ma relacje rodzic-dziecko wymuszane przez nagłówki propagacji. Nowoczesne zestawy SDK używają W3C Trace Context (traceparent, tracestate). Operation_Id w KQL łączy żądania (Requests), zależności (Dependencies), wyjątki (Exceptions) i ślady (Traces) dla tej samej transakcji. Upewnij się, że wychodzące klienty HTTP propagują nagłówki; w przypadku .NET, System.Diagnostics.Activity i SDK Application Insights obsługują to automatycznie. Śledzenie zależności instrumentuje popularnych klientów (HTTP, SQL, Service Bus, Storage). Gdy usługi przekraczają granice (np. z App Service do AKS), spójna propagacja tworzy jedną, połączoną mapę transakcji. W przypadku przepływów asynchronicznych i opartych na komunikatach upewnij się, że zestawy SDK przechwytują i przekazują identyfikatory korelacji w metadanych wiadomości; większość zestawów SDK Azure robi to domyślnie.

Testowanie dostępności i monitorowanie syntetyczne

Testy dostępności weryfikują zewnętrzną osiągalność i responsywność z wielu lokalizacji geograficznych. Test URL ping wysyła żądania HTTP z skonfigurowaną częstotliwością z wielu lokalizacji testowych i weryfikuje kody statusu, stan certyfikatu SSL oraz opcjonalne dopasowanie treści. Używaj ponownych prób i wielu lokalizacji, aby zmniejszyć liczbę fałszywych alarmów, i konfiguruj alerty w przypadku niepowodzeń testów, aby otrzymywać powiadomienia, które można wykorzystać do podjęcia działań.

Wieloetapowe testy dostępności historycznie wykonywały zarejestrowane sekwencje żądań HTTP z ciasteczkami przechowującymi stan w celu weryfikacji przepływów pracy. Klasyczne wieloetapowe testy internetowe zostały wycofane; w przypadku scenariuszy z wieloma żądaniami lub uwierzytelnianiem, zaimplementuj testy syntetyczne, instrumentując własnego klienta lub usługę za pomocą API TrackAvailability (lub eksporterów OpenTelemetry) w celu emitowania AvailabilityTelemetry. Takie podejście pozwala na niestandardowe uwierzytelnianie, dane (payloads) i walidację specyficzną dla domeny, zachowując jednocześnie scentralizowane raportowanie i alertowanie.

Niestandardowe użycie TrackAvailability daje Ci kontrolę nad:

Nazwą testu, lokalizacją uruchomienia i identyfikatorami sekwencji do analizy trendów i deduplikacji.
Czasem trwania i semantyką powodzenia opartą na Twoich walidacjach, a nie tylko na statusie HTTP.
Bogatymi komunikatami i niestandardowymi wymiarami, które dostarczają wskazówek dotyczących pierwotnej przyczyny i korelacji z telemetrią backendu.

Połącz testy dostępności z telemetrią zależności i żądań backendu, aby szybko odróżnić problemy z dostępnością punktu końcowego (sieć, DNS, TLS) od awarii aplikacji (wyjątki, przekroczenia czasu) i awarii systemów podrzędnych (SQL, zewnętrzne API). Powiąż niepowodzenia testów dostępności z grupami akcji, aby uruchamiać przepływy pracy związane z incydentami.

Dane Azure Monitor, KQL i alerty z grupami akcji

Azure Monitor pozyskuje dwa podstawowe typy danych: metryki i logi. Metryki to lekkie, numeryczne szeregi czasowe pozyskiwane w czasie zbliżonym do rzeczywistego, z możliwością analizy wielowymiarowej (np. według instancji, trasy API). Najlepiej nadają się do szybkiego wykrywania (CPU, pamięć, częstotliwość żądań, opóźnienie, dostępność) i domyślnie obsługują do 93 dni retencji. Logi to ustrukturyzowane rekordy, które można odpytywać, przechowywane w obszarze roboczym Log Analytics. Obejmują dane z Application Insights, logi zasobów platformy oraz logi niestandardowe z konfigurowalną retencją. Użyj ustawień diagnostycznych (Diagnostic settings), aby kierować metryki platformy i logi zasobów do obszaru roboczego, Event Hub lub konta Storage w celu archiwizacji i analityki.

Kusto Query Language (KQL) napędza analizę eksploracyjną, pulpity nawigacyjne i alerty oparte na logach. Podstawowe wzorce obejmują:

Podstawowe zapytania: Table | take 10 do szybkiego próbkowania; dla wydajności zawsze wcześnie ograniczaj czas za pomocą where TimeGenerated >= ago(…).
Filtrowanie i projekcja: Table | where Column == "Value" | project KeyColumns, aby zmniejszyć ilość danych (payload) i skupić analizę.
Agregacja: summarize count() by bin(TimeGenerated, 5m), Dimension do obliczania wskaźników, percentyli lub średnich; użyj percentile() i make-series dla wykresów czasowych.
Złączenia (Joins): join kind=inner lub leftouter on na kluczach korelacji, takich jak operation_Id, aby połączyć Requests z Dependencies lub Exceptions; w przypadku złączeń między zasobami (cross-resource joins) upewnij się, że oba wysyłają dane do tego samego obszaru roboczego lub włącz zapytania między zasobami.
Użyteczne tabele: requests, dependencies, exceptions, traces, availabilityResults dla Application Insights; AzureDiagnostics i AzureActivity dla logów platformy; Perf i Heartbeat dla VM insights.
Dobre praktyki: projektuj (project) tylko potrzebne kolumny, filtruj wcześnie, grupuj (bin) w rozsądnych interwałach i unikaj kosztownych złączeń krzyżowych (cross-joins) na dużych oknach czasowych, chyba że jest to konieczne.

Alerty obejmują metryki i logi. Alerty metryk oceniają progi metryk w czasie zbliżonym do rzeczywistego, obsługują wymiary i dzielenie według wymiaru (splitting by dimension) oraz mogą używać progów statycznych lub dynamicznych (linie bazowe oparte na ML). Są stanowe, mogą się uruchamiać i automatycznie zamykać w zależności od wyników oceny, generując jedno powiadomienie przy zmianie stanu. Alerty z logów (zaplanowane zapytania) uruchamiają KQL cyklicznie i wyzwalają się na podstawie wyników zapytania (liczby dopasowań lub progów miary). Używaj alertów z logów, gdy warunki zależą od złożonych wzorców obejmujących wiele tabel lub wymagają analizy tekstu. Alerty Smart Detection i wykrywania anomalii w Application Insights mogą wskazywać na regresje bez jawnie zdefiniowanych progów.

Grupy akcji (Action groups) definiują zestawy odpowiedzi wielokrotnego użytku dla alertów. Typy powiadomień obejmują e-mail, SMS, połączenie głosowe i powiadomienia push w aplikacji mobilnej Azure. Integracje obejmują:

Webhooki (v1 i v2) z Common Alert Schema dla spójnych ładunków (payloads); ustaw niestandardowe nagłówki do uwierzytelniania i kieruj do systemów zarządzania incydentami (np. PagerDuty lub niestandardowe odbiorniki).
Azure Functions, Logic Apps i elementy runbook usługi Automation do programistycznego usuwania skutków awarii i wzbogacania danych; używaj Logic Apps do elastycznych transformacji i obsługi konektorów.
Konektory ITSM (np. ServiceNow) do otwierania incydentów z mapowanymi polami. Połącz grupy akcji z regułami przetwarzania alertów (alert processing rules), aby wyciszać je podczas prac konserwacyjnych, kierować według ważności lub stosować akcje dynamiczne. Aby zabezpieczyć wychodzące webhooki, ogranicz odbiornik do adresów IP platformy Azure lub wymagaj podpisów/nagłówków i waliduj właściwości Common Alert Schema, takie jak Essentials.AlertRule i AlertContext.

Szablony ARM dla monitorowalności i powtarzalnych wdrożeń

Szablony Azure Resource Manager (ARM) deklaratywnie definiują zasoby i konfigurację monitorowania jako kod. Struktura szablonu obejmuje:

$schema i contentVersion do identyfikacji wersji szablonu.
parameters dla wartości zewnętrznych (np. nazwy obszarów roboczych, lokalizacje, jednostki SKU). Używaj secureString/secureObject dla sekretów.
variables dla wartości obliczeniowych w celu unikania powtórzeń.
resources dla deklaratywnego wdrażania Application Insights, obszarów roboczych Log Analytics, reguł alertów, grup akcji i ustawień diagnostycznych.
outputs do emitowania wartości, takich jak connectionString Application Insights, dla dalszych etapów wdrożenia.

Używaj szablonów połączonych lub zagnieżdżonych do tworzenia złożonych wdrożeń. Zasób wdrożenia (Microsoft.Resources/deployments) odwołuje się do szablonu podrzędnego poprzez templateLink (zewnętrzny URI) lub osadza go wbudowanie. Przekazuj obiekty parametrów przez parameters lub parametersLink, definiuj dependsOn w celu określenia kolejności i ponownie wykorzystuj moduły w różnych środowiskach. Przykłady domyślnej monitorowalności poprzez ARM:

Wdróż obszar roboczy Log Analytics i ustaw wyjścia workspaceResourceId używane przez zasoby Application Insights (tryb oparty na obszarze roboczym).
Utwórz Application Insights (w trybie opartym na obszarze roboczym) i zwróć jego connectionString; unikaj eksponowania przestarzałych kluczy instrumentacji.
Włącz ustawienia diagnostyczne (Diagnostic settings) na zasobach (np. App Service, Key Vault, Storage), aby przesyłać strumieniowo logi i metryki do obszaru roboczego i/lub Event Hub.
Provision metric alerts (microsoft.insights/metricAlerts) z kryteriami i wymiarami oraz scheduled query alerts (microsoft.insights/scheduledQueryRules) z KQL, łącząc grupy akcji za pomocą identyfikatora zasobu.
Zdefiniuj grupy akcji (microsoft.insights/actionGroups) z odbiorcami e-mail/SMS i webhook; sparametryzuj adresy i punkty końcowe dla routingu specyficznego dla danego środowiska.

Wykorzystuj warunki (conditions) i pętle copy do skalowalnych wdrożeń (np. stosowanie ustawień diagnostycznych do zestawu identyfikatorów zasobów). Używaj funkcji ARM, takich jak resourceId, subscriptionResourceId, reference, concat i guid, do budowania dynamicznych odwołań i stabilnych nazw. Utrzymuj spójność konfiguracji telemetrii między usługami, centralizując konwencje nazw ról (role name) i próbkowanie w ustawieniach aplikacji dostarczanych przez ARM lub zasoby konfiguracyjne App Service.

Praktyczny scenariusz problemowy

Firma Adobe potrzebuje kompleksowej obserwowalności (end-to-end) dla nowego, wieloregionalnego potoku przetwarzania mediów zbudowanego na API Azure App Service i mikrousługach AKS. Wymagają szybkiego wykrywania regresji opóźnień, śledzenia rozproszonego między usługami, proaktywnych testów dostępności dla publicznych punktów końcowych oraz zautomatyzowanego kierowania incydentów do swojego systemu dyżurów z powtarzalnością w modelu infrastruktury jako kodu.

Instrumentacja usług za pomocą Application Insights z użyciem connection strings

Skonfiguruj każdą aplikację App Service i obciążenie AKS tak, aby używały connection string Application Insights zamiast przestarzałych kluczy, zapewniając prawidłowe punkty końcowe pozyskiwania danych i przyszłościowe trasowanie. Ustaw nazwy ról chmurowych (cloud role names) dla każdej usługi, aby umożliwić przejrzyste filtrowanie i mapy. Wybierz instrumentację opartą na SDK w kluczowych API, aby emitować zdarzenia domenowe i metryki; włącz bezkodowe dołączanie (codeless attach) dla usług pomocniczych, aby przyspieszyć pokrycie. Dlaczego: Connection strings pozwalają na elastyczność punktów końcowych; SDK zapewniają niestandardową telemetrię, podczas gdy bezkodowe dołączanie utrzymuje niski koszt wdrożenia.

Włączenie śledzenia rozproszonego i śledzenia zależności

Upewnij się, że wychodzące klienty HTTP i zestawy SDK Azure propagują kontekst śledzenia W3C; zweryfikuj ciągłość operation_Id w KQL. W przypadku przepływów komunikatów w tle (Service Bus) upewnij się, że korelacja jest wstrzykiwana i wyodrębniana przez SDK; uzupełnij to za pomocą TelemetryInitializers, gdy używane są niestandardowe nagłówki. Dlaczego: Spójna propagacja śledzenia zapewnia dokładne pomiary opóźnień end-to-end i atrybucję błędów w mikrousługach.

Implementacja testów dostępności i niestandardowych testów syntetycznych

Skonfiguruj testy ping adresu URL dla publicznych API z wielu lokalizacji geograficznych z dopasowaniem treści na lekkim punkcie końcowym kondycji. Dla przepływów uwierzytelnionych (pozyskiwanie tokenu i przesyłanie mediów) zaimplementuj klienta syntetycznego, który wywołuje przepływ pracy i emituje wyniki TrackAvailability z lokalizacją uruchomienia i szczegółowymi komunikatami. Dlaczego: Testy ping URL zapewniają szybką weryfikację zewnętrzną; TrackAvailability obsługuje złożone, uwierzytelnione przepływy biznesowe wykraczające poza podstawowe pingi.

Centralizacja danych w obszarze roboczym Log Analytics i kierowanie logów platformy

Wdróż obszar roboczy i skonfiguruj ustawienia diagnostyczne (Diagnostic settings) w App Services, logach płaszczyzny sterowania AKS, Key Vault i Storage, aby przesyłać strumieniowo logi i metryki do obszaru roboczego. Upewnij się, że zasoby Application Insights są oparte na obszarze roboczym, aby zunifikować zapytania. Dlaczego: Pojedynczy obszar roboczy umożliwia zapytania KQL obejmujące wiele usług, łącząc żądania, zależności i logi platformy w celu całościowej analizy.

Tworzenie alertów metryk i logów z grupami akcji

Zdefiniuj alerty metryk dotyczące percentyli czasu trwania żądań i dostępności według lokalizacji z progami dynamicznymi, z podziałem na nazwę roli chmurowej (cloud role name). Dodaj alerty zaplanowanych zapytań, które wykrywają skoki błędów według nazwy operacji i korelują je z awariami zależności za pomocą złączenia KQL na operation_Id. Dlaczego: Alerty metryk zapewniają wykrywanie w czasie zbliżonym do rzeczywistego; alerty logów wychwytują złożone wzorce, których nie można wyrazić za pomocą prostych progów.

Integracja reagowania na incydenty za pomocą grup akcji i webhooków

Skonfiguruj grupę akcji z powiadomieniami e-mail dla właścicieli usług, SMS dla liderów dyżurów i bezpiecznym webhookiem do platformy incydentów Adobe, używając Common Alert Schema. Dodaj odbiornik Logic App, aby wzbogacać ładunki (payloads) o najnowsze wyniki zapytań KQL i metadane topologii. Dlaczego: Powiadomienia wielokanałowe skracają MTTA; webhook i Logic App umożliwiają zautomatyzowane tworzenie zgłoszeń i incydenty bogate w kontekst.

Kodyfikacja monitorowania za pomocą szablonów ARM

Stwórz szablony ARM do wdrożenia obszaru roboczego Log Analytics, Application Insights (w trybie opartym na obszarze roboczym), ustawień diagnostycznych, alertów metryk, alertów zaplanowanych zapytań i grup akcji. Sparametryzuj nazwy środowisk, regiony i punkty kontaktowe; zwróć connectionString Application Insights dla dalszej konfiguracji aplikacji. Użyj szablonów połączonych dla modułów należących do zespołów (platforma vs. aplikacja). Dlaczego: Infrastruktura jako kod zapewnia spójną, powtarzalną obserwowalność w środowiskach deweloperskich, testowych i produkcyjnych oraz wspiera CI/CD.

Walidacja za pomocą dashboardów KQL

Zbuduj dashboardy używające KQL, które podsumowują opóźnienia według usług (agreguj percentyle według przedziałów i ról), wskaźniki błędów połączone z celami zależności oraz dostępność syntetyczną według lokalizacji. Wprowadź filtry zakresu czasowego i możliwość przechodzenia do szczegółów śledzenia i wyjątków. Dlaczego: KQL zapewnia elastyczną analizę i praktyczne wizualizacje dla zespołów inżynieryjnych i operacyjnych.

← Buforowanie · Wszystkie domeny

Przećwicz te pytania → · Testy na czas na ExamRoll.io →