Metryki i dzienniki w usłudze Azure Monitor
Usługa Azure Front Door udostępnia kilka funkcji ułatwia monitorowanie aplikacji, śledzenie żądań i debugowanie konfiguracji usługi Front Door.
Dzienniki i metryki są przechowywane i zarządzane przez usługę Azure Monitor.
Raporty zapewniają wgląd w sposób przepływu ruchu przez usługę Azure Front Door, zaporę aplikacji internetowej (WAF) i aplikację.
Metryki
Usługa Azure Front Door mierzy i wysyła metryki w 60-sekundowych odstępach czasu. Przetwarzanie metryk przez usługę Azure Monitor może potrwać do 3 minut, a przetwarzanie może nie pojawić się dopiero po zakończeniu przetwarzania. Metryki można również wyświetlać na wykresach lub siatkach i są dostępne za pośrednictwem witryny Azure Portal, programu Azure PowerShell, interfejsu wiersza polecenia platformy Azure i interfejsów API usługi Azure Monitor. Aby uzyskać więcej informacji, zobacz Metryki usługi Azure Monitor.
Metryki wymienione w poniższej tabeli są rejestrowane i przechowywane bezpłatnie przez ograniczony czas. W przypadku dodatkowych kosztów można przechowywać przez dłuższy czas.
| Mierniki | opis | Wymiary |
|---|---|---|
| Współczynnik trafień bajtów | Procent ruchu obsługiwanego z pamięci podręcznej usługi Azure Front Door obliczony względem całkowitego ruchu wychodzącego. Współczynnik trafień bajtów jest niski, jeśli większość ruchu jest przesyłana do źródła, a nie obsługiwana z pamięci podręcznej. Współczynnik trafień bajtów = (ruch wychodzący z krawędzi — ruch wychodzący ze źródła)/ruch wychodzący z krawędzi. Scenariusze wykluczone z obliczeń współczynnika trafień bajtów:
|
Punkt końcowy |
| Procent kondycji źródła | Procent pomyślnych sond kondycji wysłanych z usługi Azure Front Door do źródeł. | Źródło, grupa źródła |
| Opóźnienie źródła | Usługa Azure Front Door oblicza czas od wysłania żądania do źródła do otrzymania ostatniego bajtu odpowiedzi ze źródła. | Punkt końcowy, źródło |
| Liczba żądań źródła | Liczba żądań wysyłanych z usługi Azure Front Door do źródeł. | Punkt końcowy, źródło, stan HTTP, grupa stanu HTTP |
| Procent 4XX | Procent wszystkich żądań klientów, dla których kod stanu odpowiedzi to 4XX. | Punkt końcowy, Kraj klienta, Region klienta |
| Procent 5XX | Procent wszystkich żądań klienta, dla których kod stanu odpowiedzi to 5XX. | Punkt końcowy, Kraj klienta, Region klienta |
| Liczba żądań | Liczba żądań klientów obsługiwanych za pośrednictwem usługi Azure Front Door, w tym żądań obsługiwanych całkowicie z pamięci podręcznej. | Punkt końcowy, kraj klienta, region klienta, stan HTTP, grupa stanu HTTP |
| Rozmiar żądania | Liczba bajtów wysyłanych w żądaniach od klientów do usługi Azure Front Door. | Punkt końcowy, kraj klienta, region klienta, stan HTTP, grupa stanu HTTP |
| Rozmiar odpowiedzi | Liczba bajtów wysłanych jako odpowiedzi z usługi Front Door do klientów. | Punkt końcowy, kraj klienta, region klienta, stan HTTP, grupa stanu HTTP |
| Łączne opóźnienie | Usługa Azure Front Door odbiera żądanie klienta i wysyła ostatni bajt odpowiedzi do klienta. Jest to łączny czas potrzebny. | Punkt końcowy, kraj klienta, region klienta, stan HTTP, grupa stanu HTTP |
| Liczba żądań zapory aplikacji internetowej | Liczba żądań przetwarzanych przez zaporę aplikacji internetowej usługi Azure Front Door. | Akcja, nazwa zasad, nazwa reguły |
Uwaga
Jeśli limit czasu żądania do źródła wynosi 0, wartość wymiaru Stanu http wynosi 0.
Dzienniki
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 odwołania 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 do śledzenia podczas wyszukiwania określonego żądania w dziennikach dostępu lub zapory aplikacji internetowej. |
| Czas | Data i godzina dostarczenia przez usługę Azure Front Door edge żądanej zawartości do klienta (w formacie UTC). |
| HttpMethod | Metoda HTTP używana przez żądanie: DELETE, GET, HEAD, OPTIONS, PATCH, POST lub PUT. |
| HttpVersion | Wersja HTTP określona przez klienta w żądaniu. |
| 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. |
| Liczba bajtów odpowiedzi | Rozmiar komunikatu odpowiedzi HTTP w bajtach. |
| 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 od momentu odebrania żądania klienta przez usługę Azure Front Door do momentu wysłania ostatniego bajtu odpowiedzi do klienta przez usługę Azure Front Door w sekundach. To pole nie uwzględnia opóźnień sieci i buforowania TCP. |
| RequestProtocol | Protokół określony przez klienta w żądaniu. Możliwe wartości to: HTTP, HTTPS. |
| 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 | Sposób obsługi żądania przez pamięć podręczną usługi Azure Front Door. 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 adres URL żądania został przepisany przez aparat reguł, ścieżka odwołuje się do ponownie przepisanej ścieżki. 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ł. Na przykład można 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 FDQN. |
| 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. |
| Połączenie ionLatency | 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 FDQN 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/27CAFCA8-B9A4-4264-B399-45D0C9CCA1AB/RESOURCEGROUPS/AFDXPRIVATEPREVIEW/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDXPRIVATEPREVIEW-JESSIE",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://afdxprivatepreview.blob.core.windows.net:80/",
"originName": "afdxprivatepreview.blob.core.windows.net",
"originIP": "52.239.224.228:80",
"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.
Dzienniki aktywności
Dzienniki aktywności zawierają informacje o operacjach zarządzania w zasobach usługi Azure Front Door. Dzienniki zawierają szczegółowe informacje o każdej operacji zapisu wykonanej w zasobie usługi Azure Front Door, w tym o tym, kiedy wystąpiła operacja, kto ją wykonał, oraz o tym, jaka była operacja.
Uwaga
Dzienniki aktywności nie obejmują operacji odczytu. Mogą również nie zawierać wszystkich operacji wykonywanych przy użyciu witryny Azure Portal lub klasycznych interfejsów API zarządzania.
Aby uzyskać więcej informacji, zobacz Wyświetlanie dzienników aktywności.
Następne kroki
Aby włączyć i zapisać dzienniki diagnostyczne, zobacz Konfigurowanie dzienników usługi Azure Front Door.
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).
W przypadku korzystania z usługi Azure Front Door (wersja klasyczna) zasoby można monitorować w następujący sposób:
- Metryki. Usługa Azure Front Door ma obecnie osiem metryk do wyświetlania liczników wydajności.
- Dzienniki. Dzienniki aktywności i diagnostyki umożliwiają zapisywanie lub używanie danych z zasobu na potrzeby monitorowania wydajności, dostępu i innych danych.
Metryki
Metryki to funkcja dla niektórych zasobów platformy Azure, które umożliwiają wyświetlanie liczników wydajności w portalu. Dostępne są następujące metryki usługi Front Door:
| Metric | Nazwa wyświetlana metryki | Jednostka | Wymiary | opis |
|---|---|---|---|---|
| RequestCount | Liczba żądań | Count | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Liczba żądań klientów obsługiwanych przez usługę Front Door. |
| RequestSize | Rozmiar żądania | Bajty | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Liczba bajtów wysyłanych jako żądania od klientów do usługi Front Door. |
| Rozmiar odpowiedzi | Rozmiar odpowiedzi | Bajty | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Liczba bajtów wysłanych jako odpowiedzi z usługi Front Door do klientów. |
| TotalLatency | Łączne opóźnienie | Milisekundy | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Łączny czas od żądania klienta odebranego przez usługę Front Door do ostatniego bajtu odpowiedzi wysłanego z usługi AFD do klienta. |
| BackendRequestCount | Liczba żądań zaplecza | Count | HttpStatus HttpStatusGroup — zaplecze |
Liczba żądań wysyłanych z usługi Front Door do zapleczy. |
| BackendRequestLatency | Opóźnienie żądania zaplecza | Milisekundy | Zaplecze | Czas obliczony od momentu wysłania żądania przez usługę Front Door do zaplecza do momentu odebrania ostatniego bajtu odpowiedzi z zaplecza przez usługę Front Door. |
| BackendHealthPercentage | Procent kondycji zaplecza | Procent | Pula zaplecza zaplecza |
Procent pomyślnych sond kondycji z usługi Front Door do zapleczy. |
| WebApplicationFirewallRequestCount | Liczba żądań zapory aplikacji internetowej | Count | Akcja PolicyName RuleName |
Liczba żądań klientów przetwarzanych przez zabezpieczenia warstwy aplikacji usługi Front Door. |
Dzienniki aktywności
Dzienniki aktywności zawierają informacje o operacjach wykonywanych w profilu usługi Azure Front Door (klasycznym). Określają również, kto i kiedy dla wszystkich operacji zapisu (umieścić, opublikować lub usunąć) wykonanych względem profilu usługi Azure Front Door (wersja klasyczna).
Uwaga
Jeśli upłynął limit czasu żądania do źródła, dla wartości HttpStatusCode ustawiono wartość 0.
Uzyskaj dostęp do dzienników aktywności w usłudze Front Door lub wszystkich dziennikach zasobów platformy Azure w usłudze Azure Monitor. Aby wyświetlić dzienniki aktywności:
Wybierz wystąpienie usługi Front Door.
Wybierz pozycję Dziennik aktywności.
Wybierz zakres filtrowania, a następnie wybierz pozycję Zastosuj.
Uwaga
Dziennik aktywności nie zawiera żadnych operacji GET ani operacji wykonywanych przy użyciu witryny Azure Portal lub oryginalnego interfejsu API zarządzania.
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 wykonane 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. |
| 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. Origin Połączenie ionAborted: Połączenie ze źródłem zostało nagle zatrzymane. Origin Połączenie ionError: ogólny błąd połączenia źródła. Origin Połączenie ionRefused: 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
- Jeden dla tarczy pochodzenia.
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 będą miały 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. MISS |
| Błąd podczas przetwarzania żądania | Brak |
Uwaga
W przypadku scenariuszy buforowania wartość stanu pamięci podręcznej będzie partial_hit, gdy niektóre bajty żądania zostaną obsłużone z usługi Azure Front Door Edge lub pamięci podręcznej osłony źródła, podczas gdy niektóre bajty będą 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.
Następne kroki
- Dowiedz się, jak utworzyć profil usługi Azure Front Door (klasyczny)
- Dowiedz się , jak działa usługa Azure Front Door (klasyczna)