Monitorowanie usługi Azure Front Door
Usługa Azure Monitor zbiera i agreguje metryki i dzienniki z systemu w celu monitorowania dostępności, wydajności i odporności oraz powiadamiania o problemach wpływających na system. Do konfigurowania i wyświetlania danych monitorowania można użyć witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia platformy Azure, interfejsu API REST lub bibliotek klienckich.
Różne metryki i dzienniki są dostępne dla różnych typów zasobów. W tym artykule opisano typy danych monitorowania, które można zbierać dla tej usługi i sposoby analizowania tych danych.
Raporty zapewniają wgląd w sposób przepływu ruchu przez usługę Azure Front Door, zaporę aplikacji internetowej (WAF) i aplikację.
Ważne
Usługa Azure Front Door (klasyczna) zostanie wycofana 31 marca 2027 r. Aby uniknąć zakłóceń w działaniu usługi, należy przeprowadzić migrację profilów usługi Azure Front Door (wersja klasyczna) do warstwy Azure Front Door Standard lub Premium do marca 2027 r. Aby uzyskać więcej informacji, zobacz Wycofywanie usługi Azure Front Door (wersja klasyczna).
Zbieranie danych za pomocą usługi Azure Monitor
W tej tabeli opisano sposób zbierania danych w celu monitorowania usługi oraz czynności, które można wykonać z danymi po zebraniu:
| Dane do zebrania | opis | Jak zbierać i kierować dane | Gdzie wyświetlić dane | Obsługiwane dane |
|---|---|---|---|---|
| Dane metryk | Metryki to wartości liczbowe, które opisują aspekt systemu w określonym punkcie w czasie. Metryki mogą być agregowane przy użyciu algorytmów, w porównaniu z innymi metrykami i analizowane pod kątem trendów w czasie. | — Zbierane automatycznie w regularnych odstępach czasu. — Niektóre metryki platformy można kierować do obszaru roboczego usługi Log Analytics w celu wykonywania zapytań dotyczących innych danych. Sprawdź ustawienie eksportu DS dla każdej metryki, aby sprawdzić, czy możesz użyć ustawienia diagnostycznego do kierowania danych metryk. |
Eksplorator metryk | Metryki usługi Azure Front Door obsługiwane przez usługę Azure Monitor |
| Dane dziennika zasobów | Dzienniki są rejestrowane zdarzenia systemowe ze znacznikiem czasu. Dzienniki mogą zawierać różne typy danych i mieć strukturę lub dowolny tekst. Dane dziennika zasobów można kierować do obszarów roboczych usługi Log Analytics na potrzeby wykonywania zapytań i analizy. | Utwórz ustawienie diagnostyczne do zbierania i kierowania danych dziennika zasobów. | Log Analytics | Dane dziennika zasobów usługi Azure Front Door obsługiwane przez usługę Azure Monitor |
| Dane dziennika aktywności | Dziennik aktywności usługi Azure Monitor zapewnia wgląd w zdarzenia na poziomie subskrypcji. Dziennik aktywności zawiera takie informacje, jak czas modyfikacji zasobu lub uruchomienia maszyny wirtualnej. | — Zbierane automatycznie. - Utwórz ustawienie diagnostyczne w obszarze roboczym usługi Log Analytics bez opłat. |
Dziennik aktywności |
Aby uzyskać listę wszystkich danych obsługiwanych przez usługę Azure Monitor, zobacz:
Wbudowane monitorowanie usługi Azure Front Door
Dzienniki śledzą wszystkie żądania przekazywane przez usługę Azure Front Door. Przetworzenie i zapisanie dzienników może potrwać kilka minut.
Istnieje wiele dzienników usługi Front Door, których można używać do różnych celów:
- Dzienniki dostępu mogą służyć do identyfikowania wolnych żądań, określania współczynników błędów i zrozumienia sposobu działania buforowania usługi Front Door dla rozwiązania.
- Dzienniki zapory aplikacji internetowej (WAF) mogą służyć do wykrywania potencjalnych ataków i wykrywania fałszywie dodatnich, które mogą wskazywać na uzasadnione żądania zablokowane przez zaporę aplikacji internetowej. Aby uzyskać więcej informacji na temat dzienników zapory aplikacji internetowej, zobacz Monitorowanie i rejestrowanie usługi Azure Web Application Firewall.
- Dzienniki sondy kondycji mogą służyć do identyfikowania źródeł, które są w złej kondycji lub które nie odpowiadają na żądania od niektórych geograficznie rozproszonych punktów poPs usługi Front Door.
- Dzienniki aktywności zapewniają wgląd w operacje wykonywane na zasobach platformy Azure, takie jak zmiany konfiguracji w profilu usługi Azure Front Door.
Dzienniki dostępu i dzienniki zapory aplikacji internetowej zawierają odwołanie do śledzenia, które jest również propagowane w żądaniach do źródeł i odpowiedzi klientów przy użyciu nagłówka X-Azure-Ref . Możesz użyć odwołania do śledzenia, aby uzyskać pełny widok przetwarzania żądań aplikacji.
Dzienniki dostępu, dzienniki sondy kondycji i dzienniki zapory aplikacji internetowej nie są domyślnie włączone. Aby włączyć i zapisać dzienniki diagnostyczne, zobacz Konfigurowanie dzienników usługi Azure Front Door. Wpisy dziennika aktywności są zbierane domyślnie i można je wyświetlać w witrynie Azure Portal.
Dziennik dostępu
Informacje o każdym żądaniu są rejestrowane w dzienniku dostępu. Każdy wpis dziennika dostępu zawiera informacje wymienione w poniższej tabeli.
| Właściwości | opis |
|---|---|
| TrackingReference | Unikatowy ciąg odniesienia identyfikujący żądanie obsługiwane przez usługę Azure Front Door. Odwołanie do śledzenia jest wysyłane do klienta i do źródła przy użyciu X-Azure-Ref nagłówków. Użyj odwołania śledzenia podczas wyszukiwania określonego żądania w dziennikach dostępu lub zapory aplikacji sieci Web. |
| Czas | Data i godzina dostarczenia przez usługę Azure Front Door edge żądanej zawartości do klienta (w formacie UTC). W przypadku połączeń protokołu WebSocket czas reprezentuje czas zamknięcia połączenia. |
| HttpMethod | Metoda HTTP używana przez żądanie: DELETE, GET, HEAD, OPTIONS, PATCH, POST lub PUT. |
| HttpVersion | Wersja HTTP określona przez klienta w żądaniu. |
| Identyfikator RequestUri | Identyfikator URI odebranego żądania. To pole zawiera pełny schemat, port, domenę, ścieżkę i ciąg zapytania. |
| HostName | Nazwa hosta w żądaniu od klienta. Jeśli włączysz domeny niestandardowe i masz domenę wieloznaczny (*.contoso.com), wartość pola dziennika Nazwa hosta to subdomain-from-client-request.contoso.com. Jeśli używasz domeny usługi Azure Front Door (contoso-123.z01.azurefd.net), wartość pola dziennika HostName to contoso-123.z01.azurefd.net. |
| Liczba bajtów żądań | Rozmiar komunikatu żądania HTTP w bajtach, w tym nagłówki żądania i treść żądania. W przypadku połączeń protokołu WebSocket ta wartość jest całkowitą liczbą bajtów wysyłanych z klienta do serwera za pośrednictwem połączenia. |
| Liczba bajtów odpowiedzi | Rozmiar komunikatu odpowiedzi HTTP w bajtach. W przypadku połączeń protokołu WebSocket ta wartość jest całkowitą liczbą bajtów wysyłanych z serwera do klienta za pośrednictwem połączenia. |
| UserAgent | Agent użytkownika używany przez klienta. Zazwyczaj agent użytkownika identyfikuje typ przeglądarki. |
| ClientIp | Adres IP klienta, który złożył oryginalne żądanie. Jeśli w żądaniu znajdował się X-Forwarded-For nagłówek, adres IP klienta jest pobierany z nagłówka. |
| SocketIp | Adres IP bezpośredniego połączenia z usługą Azure Front Door Edge. Jeśli klient użył serwera proxy HTTP lub modułu równoważenia obciążenia do wysłania żądania, wartość SocketIp jest adresem IP serwera proxy lub modułu równoważenia obciążenia. |
| TimeTaken | Czas trwania od momentu odebrania żądania klienta przez usługę Azure Front Door do momentu wysłania ostatniego bajtu odpowiedzi do klienta mierzonego w sekundach. Ta metryka wyklucza opóźnienie sieci i buforowanie TCP. W przypadku połączeń protokołu WebSocket reprezentuje czas trwania połączenia od ustanowienia do zamknięcia. |
| RequestProtocol | Protokół określony przez klienta w żądaniu. Możliwe wartości to: HTTP, HTTPS. W przypadku protokołu WebSocket protokoły to WS, WSS. Tylko żądania pomyślnego uaktualnienia do protokołu WebSocket mają usługę WS/WSS. |
| SecurityProtocol | Wersja protokołu TLS/SSL używana przez żądanie lub wartość null, jeśli żądanie nie używa szyfrowania. Możliwe wartości to: SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
| SecurityCipher | Gdy wartość protokołu żądania to HTTPS, to pole wskazuje szyfr TLS/SSL wynegocjowany przez klienta i usługę Azure Front Door. |
| Punkt końcowy | Nazwa domeny punktu końcowego usługi Azure Front Door, na przykład contoso-123.z01.azurefd.net. |
| HttpStatusCode | Kod stanu HTTP zwrócony z usługi Azure Front Door. Jeśli upłynął limit czasu żądania do źródła, wartość pola HttpStatusCode wynosi 0. Jeśli klient zamknął połączenie, wartość pola HttpStatusCode wynosi 499. |
| Pop | Punkt obecności usługi Azure Front Door (PoP), który odpowiedział na żądanie użytkownika. |
| Stan pamięci podręcznej | Jak pamięć podręczna usługi Azure Front Door obsługuje żądanie. Możliwe wartości to:
|
| MatchedRulesSetName | Nazwy przetworzonych reguł aparatu reguł. |
| RouteName | Nazwa trasy, która jest zgodna z żądaniem. |
| ClientPort | Port IP klienta, który złożył żądanie. |
| Referrer | Adres URL witryny, która pochodzi z żądania. |
| TimetoFirstByte | Czas w sekundach od momentu odebrania żądania przez krawędź usługi Azure Front Door do momentu wysłania pierwszego bajtu do klienta mierzonego przez usługę Azure Front Door. Ta właściwość nie mierzy danych klienta. |
| ErrorInfo | Jeśli podczas przetwarzania żądania wystąpił błąd, to pole zawiera szczegółowe informacje o błędzie. Możliwe wartości to:
|
| OriginURL | Pełny adres URL źródła, w którym wysłano żądanie. Adres URL składa się ze schematu, nagłówka hosta, portu, ścieżki i ciągu zapytania. Ponowne zapisywanie adresu URL: Jeśli aparat reguł ponownie zapisuje adres URL żądania, ścieżka odwołuje się do ścieżki przepisanej. Pamięć podręczna na brzegu poP: jeśli żądanie zostało obsłużone z pamięci podręcznej usługi Azure Front Door, źródłem jest N/A. Duże żądanie: jeśli żądana zawartość jest duża i istnieje wiele fragmentowanych żądań, które wracają do źródła, to pole odpowiada pierwszemu żądaniu źródła. Aby uzyskać więcej informacji, zobacz Fragmentowanie obiektów. |
| OriginIP | Adres IP źródła, który obsłużył żądanie. Pamięć podręczna na brzegu poP: jeśli żądanie zostało obsłużone z pamięci podręcznej usługi Azure Front Door, źródłem jest N/A. Duże żądanie: jeśli żądana zawartość jest duża i istnieje wiele fragmentowanych żądań, które wracają do źródła, to pole odpowiada pierwszemu żądaniu źródła. Aby uzyskać więcej informacji, zobacz Fragmentowanie obiektów. |
| Nazwa źródła | Pełna nazwa hosta (nazwa DNS) źródła. Pamięć podręczna na brzegu poP: jeśli żądanie zostało obsłużone z pamięci podręcznej usługi Azure Front Door, źródłem jest N/A. Duże żądanie: jeśli żądana zawartość jest duża i istnieje wiele fragmentowanych żądań, które wracają do źródła, to pole odpowiada pierwszemu żądaniu źródła. Aby uzyskać więcej informacji, zobacz Fragmentowanie obiektów. |
| Result |
SSLMismatchedSNI to kod stanu, który oznacza pomyślne żądanie z ostrzeżeniem o niezgodności między SNI i nagłówkiem hosta. Ten kod stanu oznacza fronting domeny, technikę, która narusza warunki świadczenia usługi Azure Front Door. Żądania z SSLMismatchedSNI zostaną odrzucone po 22 stycznia 2024 r. |
| Sni | To pole określa wskazanie nazwy serwera (SNI), które jest wysyłane podczas uzgadniania TLS/SSL. Może służyć do identyfikowania dokładnej wartości SNI, jeśli istnieje SSLMismatchedSNI kod stanu. Ponadto można ją porównać z wartością hosta w requestUri polu, aby wykryć i rozwiązać problem z niezgodnością. |
Dziennik sondy kondycji
Usługa Azure Front Door rejestruje każde żądanie sondy kondycji, które zakończyło się niepowodzeniem. Te dzienniki mogą pomóc w diagnozowaniu problemów ze źródłem. Dzienniki zawierają informacje, których można użyć do zbadania przyczyny błędu, a następnie przywrócenia źródła do stanu dobrej kondycji.
W niektórych scenariuszach ten dziennik może być przydatny:
- Zauważyliśmy, że ruch usługi Azure Front Door został wysłany do podzbioru źródeł. Można na przykład zauważyć, że tylko trzy z czterech źródeł odbierają ruch. Chcesz wiedzieć, czy źródła otrzymują sondy kondycji i odpowiadają na nie, aby wiedzieć, czy źródła są w dobrej kondycji.
- Zauważyliśmy, że metryka procentowa kondycji pochodzenia jest niższa niż oczekiwano. Chcesz wiedzieć, które źródła są rejestrowane jako w złej kondycji i przyczyna błędów sondy kondycji.
Każdy wpis dziennika sondy kondycji ma następujący schemat:
| Właściwości | opis |
|---|---|
| HealthProbeId | Unikatowy identyfikator identyfikująy żądanie sondy kondycji. |
| Czas | Data i godzina wysłania sondy kondycji (w formacie UTC). |
| HttpMethod | Metoda HTTP używana przez żądanie sondy kondycji. Wartości obejmują get i HEAD na podstawie konfiguracji sondy kondycji. |
| Result | Stan sondy kondycji. Wartość to powodzenie lub opis błędu odebranego sondy. |
| HttpStatusCode | Kod stanu HTTP zwrócony przez źródło. |
| ProbeURL | Pełny docelowy adres URL, do którego wysłano żądanie sondy. Adres URL składa się ze schematu, nagłówka hosta, ścieżki i ciągu zapytania. |
| Nazwa źródła | Nazwa źródła, do którego wysłano sondę kondycji. To pole ułatwia zlokalizowanie interesujących źródeł, jeśli źródło jest skonfigurowane do używania nazwy FQDN. |
| POP | Brzegowy punkt poP, który wysłał żądanie sondy. |
| Źródłowy adres IP | Adres IP źródła, do którego wysłano sondę kondycji. |
| TotalLatency | Czas od momentu wysłania żądania sondy kondycji przez usługę Azure Front Door do źródła do momentu wysłania ostatniej odpowiedzi do usługi Azure Front Door. |
| ConnectionLatency | Czas spędzony na skonfigurowaniu połączenia TCP w celu wysłania żądania sondy HTTP do źródła. |
| Opóźnienie usługi DNSResolution | Czas spędzony na rozpoznawaniu nazw DNS. To pole ma wartość tylko wtedy, gdy źródło jest skonfigurowane jako nazwa FQDN zamiast adresu IP. Jeśli źródło jest skonfigurowane do używania adresu IP, wartość to N/A. |
Poniższy przykładowy fragment kodu JSON przedstawia wpis dziennika sondy kondycji dla nieudanego żądania sondy kondycji.
{
"records": [
{
"time": "2021-02-02T07:15:37.3640748Z",
"resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/MyProfile",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://www.example.com:80/",
"originName": "www.example.com",
"originIP": "PublicI:Port",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}
Dziennik zapory aplikacji internetowej
Aby uzyskać więcej informacji na temat dzienników zapory aplikacji internetowej (WAF) usługi Front Door, zobacz Monitorowanie i rejestrowanie usługi Azure Web Application Firewall.
W przypadku klasycznej usługi Azure Front Door wbudowane monitorowanie obejmuje dzienniki diagnostyczne.
Dzienniki diagnostyczne
Dzienniki diagnostyczne zawierają szczegółowe informacje o operacjach i błędach, które są ważne dla inspekcji i rozwiązywania problemów. Dzienniki diagnostyczne różnią się od dzienników aktywności.
Dzienniki aktywności zapewniają wgląd w operacje wykonywane na zasobach platformy Azure. Dzienniki diagnostyczne zapewniają wgląd w operacje wykonywane przez zasób. Aby uzyskać więcej informacji, zobacz Dzienniki diagnostyczne usługi Azure Monitor.
Aby skonfigurować dzienniki diagnostyczne dla usługi Azure Front Door (wersja klasyczna):
Wybierz profil usługi Azure Front Door (klasyczny).
Wybierz pozycję Ustawienia diagnostyczne.
Wybierz pozycję Włącz diagnostykę. Archiwizowanie dzienników diagnostycznych wraz z metrykami na koncie magazynu, przesyłanie strumieniowe ich do centrum zdarzeń lub wysyłanie ich do dzienników usługi Azure Monitor.
Usługa Front Door obecnie udostępnia dzienniki diagnostyczne. Dzienniki diagnostyczne udostępniają poszczególne żądania interfejsu API z każdym wpisem o następującym schemacie:
| Właściwości | opis |
|---|---|
| Nazwa hosta zaplecza | Jeśli żądanie zostało przekazane do zaplecza, to pole reprezentuje nazwę hosta zaplecza. To pole jest puste, jeśli żądanie zostanie przekierowane lub przekazane do regionalnej pamięci podręcznej (gdy buforowanie zostanie włączone dla reguły routingu). |
| CacheStatus | W przypadku scenariuszy buforowania to pole definiuje trafienie/miss pamięci podręcznej w punkcie POP |
| ClientIp | Adres IP klienta, który złożył żądanie. Jeśli w żądaniu znajdował się nagłówek X-Forwarded-For, adres IP klienta jest wybierany z tego samego adresu. |
| ClientPort | Port IP klienta, który złożył żądanie. |
| HttpMethod | Metoda HTTP używana przez żądanie. |
| HttpStatusCode | Kod stanu HTTP zwrócony z serwera proxy. Jeśli upłynął limit czasu żądania do źródła, dla wartości HttpStatusCode ustawiono wartość 0. |
| HttpStatusDetails | Wynikowy stan żądania. Znaczenie tej wartości ciągu można znaleźć w tabeli odwołania do stanu. |
| HttpVersion | Typ żądania lub połączenia. |
| POP | Krótka nazwa krawędzi, na której wylądowało żądanie. |
| Liczba bajtów żądań | Rozmiar komunikatu żądania HTTP w bajtach, w tym nagłówki żądania i treść żądania. |
| Identyfikator RequestUri | Identyfikator URI odebranego żądania. |
| Liczba bajtów odpowiedzi | Bajty wysyłane przez serwer zaplecza jako odpowiedź. |
| RoutingRuleName | Nazwa reguły routingu, która jest zgodna z żądaniem. |
| RulesEngineMatchNames | Nazwy reguł, które są zgodne z żądaniem. |
| SecurityProtocol | Wersja protokołu TLS/SSL używana przez żądanie lub wartość null, jeśli nie ma szyfrowania. |
| SentToOriginShield (przestarzałe) * Zobacz uwagi dotyczące wycofywania w poniższej sekcji. |
Jeśli to prawda, oznacza to, że żądanie zostało odebrane z pamięci podręcznej osłony źródła zamiast wyskakującego okienka brzegowego. Osłona źródła to nadrzędna pamięć podręczna używana do poprawy współczynnika trafień pamięci podręcznej. |
| isReceivedFromClient | Jeśli wartość true, oznacza to, że żądanie pochodzi od klienta. Jeśli wartość false, żądanie jest pomijane w krawędzi (podrzędny punkt POP) i jest odpowiadane z osłony źródła (nadrzędnego punktu POP). |
| TimeTaken | Czas od pierwszego bajtu żądania do usługi Front Door do ostatniego bajtu odpowiedzi w ciągu kilku sekund. |
| TrackingReference | Unikatowy ciąg odwołania, który identyfikuje żądanie obsługiwane przez usługę Front Door, również wysyłane jako nagłówek X-Azure-Ref do klienta. Wymagane do wyszukiwania szczegółów w dziennikach dostępu dla określonego żądania. |
| UserAgent | Typ przeglądarki używany przez klienta. |
| ErrorInfo | To pole zawiera określony typ błędu w celu dalszego rozwiązywania problemów.
Możliwe wartości to: NoError: Wskazuje, że nie znaleziono błędu. CertificateError: błąd ogólnego certyfikatu SSL. CertificateNameCheckFailed: nazwa hosta w certyfikacie SSL jest nieprawidłowa lub jest niezgodna. ClientDisconnected: niepowodzenie żądania z powodu połączenia sieciowego klienta. NieokreślonyClientError: ogólny błąd klienta. InvalidRequest: Nieprawidłowe żądanie. Przyczyną może być źle sformułowany nagłówek, treść i adres URL. DNSFailure: niepowodzenie DNS. DNSNameNotResolved: nie można rozpoznać nazwy serwera lub adresu. OriginConnectionAborted: Połączenie ze źródłem zostało nagle zatrzymane. OriginConnectionError: błąd połączenia źródła ogólnego. OriginConnectionRefused: Nie można nawiązać połączenia ze źródłem. OriginError: błąd źródła ogólnego. OriginInvalidResponse: Źródło zwróciło nieprawidłową lub nierozpoznaną odpowiedź. OriginTimeout: limit czasu dla żądania pochodzenia wygasł. ResponseHeaderTooBig: źródło zwróciło zbyt duży nagłówek odpowiedzi. RestrictedIP: żądanie zostało zablokowane z powodu ograniczonego adresu IP. SSLHandshakeError: Nie można nawiązać połączenia z źródłem z powodu błędu wstrząsu ręki SSL. Nieokreślony Błąd: Wystąpił błąd, który nie mieści się w żadnej z błędów w tabeli. SSLMismatchedSNI: żądanie było nieprawidłowe, ponieważ nagłówek komunikatu HTTP nie był zgodny z wartością przedstawioną w rozszerzeniu SNI protokołu TLS podczas konfigurowania połączenia SSL/TLS. |
| Result |
SSLMismatchedSNI to kod stanu, który oznacza pomyślne żądanie z ostrzeżeniem o niezgodności między SNI i nagłówkiem hosta. Ten kod stanu oznacza fronting domeny, technikę, która narusza warunki świadczenia usługi Azure Front Door. Żądania z SSLMismatchedSNI zostaną odrzucone po 22 stycznia 2024 r. |
| Sni | To pole określa wskazanie nazwy serwera (SNI), które jest wysyłane podczas uzgadniania TLS/SSL. Może służyć do identyfikowania dokładnej wartości SNI, jeśli istnieje SSLMismatchedSNI kod stanu. Ponadto można ją porównać z wartością hosta w requestUri polu, aby wykryć i rozwiązać problem z niezgodnością. |
Wycofanie osłony źródła
Właściwość nieprzetworzonego dziennika toSentToOriginShield jest przestarzała i zastępowana przez nowe pole toReceivedFromClient. Jeśli używasz już przestarzałego pola, użyj nowego pola.
Nieprzetworzone dzienniki obejmują dzienniki generowane na podstawie krawędzi cdN (podrzędnego punktu POP) i osłony źródła. Osłona źródła odnosi się do węzłów nadrzędnych, które są strategicznie zlokalizowane na całym świecie. Te węzły komunikują się z serwerami pochodzenia i zmniejszają obciążenie ruchem źródła.
Dla każdego żądania, które przechodzi do osłony źródła, istnieją dwa wpisy dziennika:
- Jeden dla węzłów brzegowych
- Jedna dla osłony źródła
Aby odróżnić ruch wychodzący lub odpowiedzi od węzłów brzegowych w porównaniu z osłoną źródła, możesz użyć pola isReceivedFromClient , aby uzyskać poprawne dane.
Jeśli wartość ma wartość false, oznacza to, że żądanie jest odpowiadane z osłony źródła do węzłów brzegowych. Takie podejście jest skuteczne w przypadku porównywania nieprzetworzonych dzienników z danymi rozliczeniowymi. Opłaty nie są naliczane w przypadku ruchu wychodzącego z osłony źródła do węzłów brzegowych. Opłaty są naliczane za ruch wychodzący z węzłów brzegowych do klientów.
Przykładowe zapytanie Kusto w celu wykluczenia dzienników wygenerowanych na osłonie źródła w usłudze Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Uwaga
W przypadku różnych konfiguracji routingu i zachowań ruchu niektóre pola, takie jak backendHostname, cacheStatus, isReceivedFromClient, a pole POP może odpowiadać z różnymi wartościami. W poniższej tabeli wyjaśniono różne wartości, które mają te pola w różnych scenariuszach:
| Scenariusze | Liczba wpisów dziennika | POP | Nazwa hosta zaplecza | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Reguła routingu bez włączonego buforowania | 1 | Kod POP przeglądarki Microsoft Edge | Zaplecze, w którym żądanie zostało przesłane dalej | Prawda | CONFIG_NOCACHE |
| Reguła routingu z włączonym buforowaniem. Trafienie pamięci podręcznej na brzegowym punkcie POP | 1 | Kod POP przeglądarki Microsoft Edge | Pusty | Prawda | HIT |
| Reguła routingu z włączonym buforowaniem. Pamięć podręczna brakuje w punkcie POP krawędzi, ale pamięć podręczna trafiona w nadrzędnej pamięci podręcznej POP | 2 | 1. Kod POP krawędzi 2. Nadrzędny kod POP pamięci podręcznej |
1. Nadrzędna nazwa hosta POP pamięci podręcznej 2. Pusty |
1. Prawda 2. Fałsz |
1. MISS 2. HIT |
| Reguła routingu z włączonym buforowaniem. Chybienie pamięci podręcznej na krawędzi, ale częściowa pamięć podręczna trafiła w nadrzędnej pamięci podręcznej POP | 2 | 1. Kod POP krawędzi 2. Nadrzędny kod POP pamięci podręcznej |
1. Nadrzędna nazwa hosta POP pamięci podręcznej 2. Zaplecze, które pomaga wypełnić pamięć podręczną |
1. Prawda 2. Fałsz |
1. MISS 2. PARTIAL_HIT |
| Reguła routingu z włączonym buforowaniem. Buforowanie PARTIAL_HIT na krawędzi POP, ale pamięć podręczna trafiona w nadrzędnej pamięci podręcznej POP | 2 | 1. Kod POP krawędzi 2. Nadrzędny kod POP pamięci podręcznej |
1. Kod POP krawędzi 2. Nadrzędny kod POP pamięci podręcznej |
1. Prawda 2. Fałsz |
1. PARTIAL_HIT 2. HIT |
| Reguła routingu z włączonym buforowaniem. Chybień pamięci podręcznej zarówno na brzegu, jak i w nadrzędnej pamięci podręcznej | 2 | 1. Kod POP krawędzi 2. Nadrzędny kod POP pamięci podręcznej |
1. Kod POP krawędzi 2. Nadrzędny kod POP pamięci podręcznej |
1. Prawda 2. Fałsz |
1. MISS 2. TĘSKNIĆ |
| Błąd podczas przetwarzania żądania | Brak |
Uwaga
W przypadku scenariuszy buforowania wartość stanu pamięci podręcznej to PARTIAL_HIT, gdy niektóre bajty żądania są obsługiwane z usługi Azure Front Door Edge lub pamięci podręcznej osłony źródła, podczas gdy niektóre bajty są obsługiwane z punktu początkowego dla dużych obiektów.
Usługa Azure Front Door używa techniki nazywanej fragmentowaniem obiektów. Po zażądaniu dużego pliku usługa Azure Front Door pobiera mniejsze fragmenty pliku ze źródła. Gdy serwer POP usługi Azure Front Door otrzyma pełne lub bajtowe zakresy żądanego pliku, serwer brzegowy usługi Azure Front Door zażąda pliku od źródła we fragmentach o rozmiarze 8 MB.
Po nadejściu fragmentu na brzegu usługi Azure Front Door jest on buforowany i natychmiast obsługiwany dla użytkownika. Następnie usługa Azure Front Door pobiera następny fragment równolegle. Dzięki temu wstępnemu pobieraniu zawartość pozostaje jedną częścią przed użytkownikiem, co zmniejsza opóźnienie. Ten proces będzie kontynuowany do momentu pobrania całego pliku (jeśli jest to wymagane), wszystkie zakresy bajtów są dostępne (jeśli jest to wymagane) lub klient zamyka połączenie. Aby uzyskać więcej informacji na temat żądania zakresu bajtów, zobacz RFC 7233. Usługa Azure Front Door buforuje wszystkie fragmenty w miarę ich odbierania. Cały plik nie musi być buforowany w pamięci podręcznej usługi Front Door. Żądania dotyczące plików lub zakresów bajtów są obsługiwane z pamięci podręcznej usługi Azure Front Door. Jeśli nie wszystkie fragmenty są buforowane w usłudze Azure Front Door, pobieranie wstępne jest używane do żądania fragmentów ze źródła. Ta optymalizacja opiera się na możliwości serwera pochodzenia do obsługi żądań zakresu bajtów. Jeśli serwer pochodzenia nie obsługuje żądań zakresu bajtów, ta optymalizacja nie jest skuteczna.
Analizowanie danych przy użyciu narzędzi usługi Azure Monitor
Te narzędzia usługi Azure Monitor są dostępne w witrynie Azure Portal, aby ułatwić analizowanie danych monitorowania:
Niektóre usługi platformy Azure mają wbudowany pulpit nawigacyjny monitorowania w witrynie Azure Portal. Te pulpity nawigacyjne są nazywane szczegółowymi informacjami i można je znaleźć w sekcji Szczegółowe informacje usługi Azure Monitor w witrynie Azure Portal.
Eksplorator metryk umożliwia wyświetlanie i analizowanie metryk dla zasobów platformy Azure. Aby uzyskać więcej informacji, zobacz Analizowanie metryk za pomocą Eksploratora metryk usługi Azure Monitor.
Usługa Log Analytics umożliwia wykonywanie zapytań i analizowanie danych dzienników przy użyciu języka zapytań Kusto (KQL). Aby uzyskać więcej informacji, zobacz Rozpoczynanie pracy z zapytaniami dzienników w usłudze Azure Monitor.
Witryna Azure Portal ma interfejs użytkownika do wyświetlania i podstawowych wyszukiwań w dzienniku aktywności. Aby przeprowadzić bardziej szczegółową analizę, należy kierować dane do dzienników usługi Azure Monitor i uruchamiać bardziej złożone zapytania w usłudze Log Analytics.
Usługa Application Insights monitoruje dostępność, wydajność i użycie aplikacji internetowych, dzięki czemu można identyfikować i diagnozować błędy bez oczekiwania na ich zgłaszanie przez użytkownika.
Usługa Application Insights obejmuje punkty połączenia z różnymi narzędziami programistycznymi i integruje się z programem Visual Studio w celu obsługi procesów DevOps. Aby uzyskać więcej informacji, zobacz Monitorowanie aplikacji dla usługi App Service.
Narzędzia, które umożliwiają bardziej złożoną wizualizację, obejmują:
- Pulpity nawigacyjne, które umożliwiają łączenie różnych rodzajów danych w jednym okienku w witrynie Azure Portal.
- Skoroszyty, dostosowywalne raporty, które można utworzyć w witrynie Azure Portal. Skoroszyty mogą zawierać tekst, metryki i zapytania dziennika.
- Grafana to otwarte narzędzie platformy, które wyróżnia się na operacyjnych pulpitach nawigacyjnych. Za pomocą narzędzia Grafana można tworzyć pulpity nawigacyjne zawierające dane z wielu źródeł innych niż usługa Azure Monitor.
- Power BI, usługa analizy biznesowej, która udostępnia interaktywne wizualizacje w różnych źródłach danych. Usługę Power BI można skonfigurować tak, aby automatycznie importować dane dziennika z usługi Azure Monitor, aby korzystać z tych wizualizacji.
Eksportowanie danych usługi Azure Monitor
Dane z usługi Azure Monitor można wyeksportować do innych narzędzi przy użyciu:
Metryki: użyj interfejsu API REST dla metryk , aby wyodrębnić dane metryk z bazy danych metryk usługi Azure Monitor. Aby uzyskać więcej informacji, zobacz Dokumentacja interfejsu API REST usługi Azure Monitor.
Dzienniki: użyj interfejsu API REST lub skojarzonych bibliotek klienckich.
Eksportowanie danych obszaru roboczego usługi Log Analytics.
Aby rozpocząć pracę z interfejsem API REST usługi Azure Monitor, zobacz Przewodnik po interfejsie API REST monitorowania platformy Azure.
Używanie zapytań Kusto do analizowania danych dziennika
Dane dziennika usługi Azure Monitor można analizować przy użyciu języka zapytań Kusto (KQL). Aby uzyskać więcej informacji, zobacz Log queries in Azure Monitor (Zapytania dzienników w usłudze Azure Monitor).
Używanie alertów usługi Azure Monitor do powiadamiania o problemach
Alerty usługi Azure Monitor umożliwiają identyfikowanie i rozwiązywanie problemów w systemie oraz proaktywne powiadamianie o znalezieniu określonych warunków w danych monitorowania przed ich zauważeniem przez klientów. Możesz otrzymywać alerty dotyczące dowolnej metryki lub źródła danych dziennika na platformie danych usługi Azure Monitor. Istnieją różne typy alertów usługi Azure Monitor w zależności od usług, które monitorujesz i zbieranych danych monitorowania. Zobacz Wybieranie odpowiedniego typu reguły alertu.
Przykłady typowych alertów dotyczących zasobów platformy Azure można znaleźć w temacie Przykładowe zapytania alertów dziennika.
Implementowanie alertów na dużą skalę
W przypadku niektórych usług można monitorować na dużą skalę, stosując tę samą regułę alertu metryki do wielu zasobów tego samego typu, które istnieją w tym samym regionie świadczenia usługi Azure. Alerty linii bazowej usługi Azure Monitor (AMBA) udostępnia częściowo zautomatyzowaną metodę implementowania ważnych alertów metryk platformy, pulpitów nawigacyjnych i wytycznych na dużą skalę.
Uzyskiwanie spersonalizowanych zaleceń przy użyciu usługi Azure Advisor
W przypadku niektórych usług, jeśli podczas operacji zasobów wystąpią krytyczne warunki lub nieuchronne zmiany, na stronie Przegląd usługi w portalu zostanie wyświetlony alert. Więcej informacji i zalecanych poprawek alertu można znaleźć w temacie Zalecenia usługi Advisor w obszarze Monitorowanie w menu po lewej stronie. Podczas normalnych operacji nie są wyświetlane żadne zalecenia doradcy.
Aby uzyskać więcej informacji na temat usługi Azure Advisor, zobacz Omówienie usługi Azure Advisor.