Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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 zbierania | Opis | Jak zbierać i kierować dane | Gdzie wyświetlić dane | Obsługiwane dane |
|---|---|---|---|---|
| Dane metryczne | 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ń przy użyciu innych danych. Sprawdź ustawienie eksportu DS dla każdej metryki, aby ustalić, czy możesz użyć ustawienia diagnostycznego do przekierowywania danych metrycznych. |
Eksplorator metryk | Metryki usługi Azure Front Door obsługiwane przez usługę Azure Monitor |
| Dane dziennika zasobów | Dzienniki to zarejestrowane zdarzenia systemowe z sygnaturą czasową. 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 konfigurację diagnostyczną 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 dla obszaru roboczego usługi Log Analytics bez opłat. |
dziennika 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, które przechodzą 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 powolnych żądań, określania współczynników błędów i zrozumienia, jak zachowanie buforowania usługi Front Door działa dla Twojego rozwiązania.
- Dzienniki zapory aplikacji internetowej (WAF) mogą służyć do wykrywania potencjalnych ataków oraz fałszywie pozytywnych wykryć, które mogą wskazywać na uzasadnione żądania zablokowane przez zaporę aplikacji internetowej. Aby uzyskać więcej informacji na temat dzienników WAF, zobacz Azure Web Application Firewall monitoring i logowanie.
- Dzienniki sondy kondycji mogą służyć do identyfikowania źródeł, które są w złej kondycji lub nie odpowiadają na żądania z niektórych geograficznie rozproszonych punktów PoP usługi Front Door.
- Dzienniki aktywności zapewniają wgląd w operacje wykonywane na zasobach platformy Azure, takie jak zmiany konfiguracji profilu usługi Azure Front Door.
Logi dostępu i logi WAF zawierają odwołanie do śledzenia, które jest również propagowane w żądaniach do źródeł i odpowiedzi do klienta za pomocą nagłówka X-Azure-Ref. Możesz użyć referencji śledzenia, aby uzyskać pełny przegląd przetwarzania żądania aplikacji.
Dzienniki dostępu, dzienniki sondy kondycji i dzienniki WAF nie są domyślnie włączone. Aby włączyć i przechowywać 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.
| Majątek | Opis |
|---|---|
| Numer śledzenia | Unikatowy ciąg odniesienia identyfikujący żądanie obsługiwane przez usługę Azure Front Door. Referencja śledzenia jest wysyłana do klienta i źródła przy użyciu nagłówków X-Azure-Ref. Użyj identyfikatora śledzenia podczas wyszukiwania określonego żądania w logach dostępu lub logach WAF. |
| Czas | Data i godzina, kiedy krawędź usługi Azure Front Door dostarczyła żądaną zawartość do klienta (w formacie UTC). W przypadku połączeń protokołu WebSocket czas reprezentuje moment zamknięcia połączenia. |
| Metoda HTTP | Metoda HTTP używana przez żądanie: DELETE, GET, HEAD, OPTIONS, PATCH, POST lub PUT. |
| Wersja HTTP | Wersja HTTP określona przez klienta w żądaniu. |
| RequestUri (Żądanie URI) | Identyfikator URI odebranego żądania. To pole zawiera pełny schemat, port, domenę, ścieżkę i ciąg zapytania. |
| Nazwa hosta | Nazwa hosta w żądaniu od klienta. Jeśli włączysz domeny niestandardowe i masz domenę z symbolami wieloznacznymi (*.contoso.com), wartość pola dziennika HostName 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 łączną liczbą bajtów wysłanych przez 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 łączną liczbą bajtów wysłanych z serwera do klienta za pośrednictwem połączenia. |
| UserAgent (agent użytkownika) | Klient użytkownika używany przez klienta. Zazwyczaj klient użytkownika identyfikuje typ przeglądarki. |
| Adres IP klienta | Adres IP klienta, który złożył oryginalne żądanie. Jeśli w żądaniu znajdował X-Forwarded-For się nagłówek, adres IP klienta jest pobierany z nagłówka. |
| Adres IP gniazda | Adres IP bezpośredniego połączenia z węzłem usługi Azure Front Door. 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. |
| Wykorzystany czas | Czas trwania od momentu, gdy krawędź usługi Azure Front Door odebrała żądanie klienta, do momentu, gdy ostatni bajt odpowiedzi został wysłany do klienta, mierzony w sekundach. Ta metryka nie obejmuje opóźnienia sieci i buforowania TCP. W przypadku połączeń protokołu WebSocket reprezentuje czas trwania połączenia od ustanowienia do zamknięcia. |
| Protokół żądania | 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, które pomyślnie uaktualniły się do WebSocket, mają WS/WSS. |
| Protokół Bezpieczeństwa | Wersja protokołu TLS/SSL używana przez żądanie lub null, jeśli żądanie nie używało szyfrowania. Możliwe wartości to: SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
| SecurityCipher (szyfr bezpieczeństwa) | Jeśli 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) | 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 krawędzi 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 (Nazwa_zestawu) | Nazwy reguł aparatu reguł, które zostały przetworzone. |
| RouteName (Nazwa trasy) | Nazwa trasy, do której pasowało żądanie. |
| Port klienta | Port IP klienta, który złożył żądanie. |
| Odsyłacz | Adres URL witryny, z której pochodzi żądanie. |
| Czas do pierwszego bajtu | Czas (w sekundach) od momentu, gdy krawędź usługi Azure Front Door odebrała żądanie do czasu wysłania pierwszego bajtu do klienta, mierzona przez usługę Azure Front Door. Ta właściwość nie mierzy danych klienta. |
| Informacje o błędzie | Jeśli podczas przetwarzania żądania wystąpił błąd, to pole zawiera szczegółowe informacje o błędzie. Możliwe wartości to:
|
| Adres URL źródła | Pełny adres URL źródła, do którego wysłano żądanie. Adres URL składa się ze schematu, nagłówka hosta, portu, ścieżki i ciągu zapytania. Ponowne zapisywanie adresów URL: Jeśli aparat reguł ponownie zapisze adres URL żądania, ścieżka odwołuje się do ponownie zapisanej ścieżki. Pamięć podręczna w punkcie brzegowym PoP: jeśli żądanie zostało obsłużone z pamięci podręcznej usługi Azure Front Door, źródło to Brak danych. Duże żądanie: Jeśli żądana zawartość jest duża i istnieje wiele fragmentarycznych żądań wracających do źródła, to pole odpowiada pierwszemu żądaniu do źródła. Aby uzyskać więcej informacji, zobacz Fragmentowanie obiektów. |
| Pochodzenie IP | Adres IP źródła, które obsłużyło żądanie. Pamięć podręczna w punkcie brzegowym PoP: jeśli żądanie zostało obsłużone z pamięci podręcznej usługi Azure Front Door, źródło to Brak danych. Duże żądanie: Jeśli żądana zawartość jest duża i istnieje wiele fragmentarycznych żądań wracających do źródła, to pole odpowiada pierwszemu żądaniu do źródła. Aby uzyskać więcej informacji, zobacz Fragmentowanie obiektów. |
| Nazwa pochodzenia | Pełna nazwa hosta (nazwa DNS) źródła. Pamięć podręczna w punkcie brzegowym PoP: jeśli żądanie zostało obsłużone z pamięci podręcznej usługi Azure Front Door, źródło to Brak danych. Duże żądanie: Jeśli żądana zawartość jest duża i istnieje wiele fragmentarycznych żądań wracających do źródła, to pole odpowiada pierwszemu żądaniu do źródła. Aby uzyskać więcej informacji, zobacz Fragmentowanie obiektów. |
| Wynik |
SSLMismatchedSNI to kod stanu, który oznacza pomyślne żądanie z ostrzeżeniem o niezgodności między SNI a nagłówkiem hosta. Ten kod stanu oznacza ukrywanie domeny, technikę, która narusza warunki korzystania z usługi Azure Front Door. Żądania z SSLMismatchedSNI zostaną odrzucone po 22 stycznia 2024 r. |
| Sni | To pole określa Indykację Nazwy Serwera (SNI), która jest wysyłana 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 kontroli 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 awarii, a następnie przywrócenia źródła do stanu dobrej kondycji.
Niektóre scenariusze, w których ten dziennik może być przydatny, to:
- Zauważono, ż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 odbierają sondy kondycji i odpowiadają na nie, aby wiedzieć, czy źródła są w dobrej kondycji.
- Zauważono, że metryka procentowa kondycji źródła jest niższa niż oczekiwano. Chcesz wiedzieć, które źródła są rejestrowane jako niezdatne oraz poznanie przyczyn niepowodzeń testów zdrowotnych.
Każdy wpis dziennika sondy kondycji ma następujący schemat:
| Majątek | Opis |
|---|---|
| Identyfikator HealthProbeId | Unikatowy identyfikator identyfikujący żądanie sondy kondycji. |
| Czas | Data i godzina wysłania sondy kondycji (w formacie UTC). |
| Metoda HTTP | Metoda HTTP używana przez żądanie sondy kondycji. Wartości obejmują GET i HEAD, na podstawie konfiguracji sondy zdrowia. |
| Wynik | Status sondy zdrowotnej. Wartość to sukces lub opis błędu odebranego przez sondę. |
| HttpStatusCode (Kod stanu HTTP) | Kod stanu HTTP zwrócony przez źródło. |
| Adres URL sondy | 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 pochodzenia | Nazwa źródła, do którego sonda kondycji została wysłana. To pole pomaga zlokalizować interesujące źródła, jeśli źródło jest skonfigurowane do używania nazwy FQDN. |
| POP | Brzegowy punkt dostępu (PoP), który wysłał żądanie sondy. |
| Adres IP pochodzenia | Adres IP źródła, do którego została wysłana sonda kondycji. |
| Całkowite opóźnienie | Czas od momentu, gdy punkt końcowy usługi Azure Front Door wysłał żądanie sondy sprawdzającej kondycję do źródła, do chwili, gdy źródło wysłało ostatnią odpowiedź do usługi Azure Front Door. |
| ConnectionLatency (Opóźnienie połączenia) | Czas poświęcony na konfigurowanie połączenia TCP w celu wysłania żądania sondy HTTP do źródła. |
| Opóźnienie rozwiązania DNS | Czas poświęcony na rozpoznawanie nazw DNS. To pole ma wartość tylko wtedy, gdy źródło jest skonfigurowane jako nazwa FQDN, a nie adres IP. Jeśli źródło jest skonfigurowane do używania adresu IP, wartość to Nie dotyczy. |
Poniższy przykładowy fragment kodu JSON przedstawia wpis dziennika sondy kondycji dla żądania sondy kondycji, które zakończyło się niepowodzeniem.
{
"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 Azure Web Application Firewall monitorowanie i rejestrowanie.
W przypadku klasycznej usługi Azure Front Door wbudowane monitorowanie obejmuje dzienniki diagnostyczne.
Dzienniki diagnostyczne
Dzienniki diagnostyczne zawierają rozbudowane 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, które wykonuje twój 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 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ą indywidualne żądania interfejsu API, a każdy wpis ma następujący schemat:
| Majątek | Opis |
|---|---|
| Nazwa hosta zaplecza | Jeśli żądanie było przekazywane 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). |
| Status pamięci podręcznej | W przypadku scenariuszy buforowania to pole definiuje trafienie/brak pamięci podręcznej w węźle POP |
| Adres IP klienta | Adres IP klienta, który złożył żądanie. Jeśli w żądaniu znajdował się nagłówek X-Forwarded-For, wtedy adres IP klienta jest pobierany z niego. |
| Port klienta | Port IP klienta, który złożył żądanie. |
| Metoda HTTP | Metoda HTTP używana przez żądanie. |
| HttpStatusCode (Kod stanu HTTP) | Kod stanu HTTP zwrócony z serwera proxy. Jeśli upłynie limit czasu żądania do źródła, wartość HttpStatusCode zostanie ustawiona na 0. |
| HttpStatusDetails (Szczegóły HttpStatusDetails) | Wynikowy stan żądania. Znaczenie tej wartości ciągu można znaleźć w tabeli statusów. |
| Wersja HTTP | 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 (Żądanie URI) | URI żądania odebranego |
| Liczba bajtów odpowiedzi | Bajty wysyłane jako odpowiedź przez serwer backendowy. |
| RoutingRuleName (Nazwa_reguły routingu) | Nazwa reguły routingu, która jest zgodna z żądaniem. |
| RulesEngineMatchNames (NazwaRegułyEngineMatchNames) | Nazwy reguł, które są zgodne z żądaniem. |
| Protokół Bezpieczeństwa | 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. Tarcza źródłowa to nadrzędna pamięć podręczna używana do poprawy współczynnika trafień. |
| odebraneOdKlienta | 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). |
| Wykorzystany czas | Czas od pierwszego bajtu żądania do usługi Front Door do ostatniego bajtu odpowiedzi na wyjściu w sekundach. |
| Numer śledzenia | Unikatowy ciąg znaków referencyjnych identyfikujący żądanie, które obsługuje usługa Front Door, wysyłany również jako nagłówek X-Azure-Ref do klienta. Wymagane do wyszukiwania szczegółów w dziennikach dostępu dla określonego żądania. |
| UserAgent (agent użytkownika) | Typ przeglądarki używany przez klienta. |
| Informacje o błędzie | To pole zawiera określony typ błędu do dalszego rozwiązywania problemów.
Możliwe wartości to: NoError: wskazuje, że nie znaleziono żadnego błędu. CertificateError: Ogólny błąd certyfikatu SSL. CertificateNameCheckFailed: nazwa hosta w certyfikacie SSL jest nieprawidłowa lub nie jest zgodna. 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: ogólny błąd połączenia z źródłem. 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: upłynął limit czasu dla żądania pochodzenia. 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 ze źródłem z powodu błędu uzgadniania SSL. UnspecifiedError: Wystąpił błąd, który nie mieścił się w żadnym z błędów w tabeli. SSLMismatchedSNI: żądanie było nieprawidłowe, ponieważ nagłówek wiadomości HTTP nie był zgodny z wartością przedstawioną w rozszerzeniu TLS SNI podczas konfiguracji połączenia SSL/TLS. |
| Wynik |
SSLMismatchedSNI to kod stanu, który oznacza pomyślne żądanie z ostrzeżeniem o niezgodności między SNI a nagłówkiem hosta. Ten kod stanu oznacza ukrywanie domeny, technikę, która narusza warunki korzystania z usługi Azure Front Door. Żądania z SSLMismatchedSNI zostaną odrzucone po 22 stycznia 2024 r. |
| Sni | To pole określa Indykację Nazwy Serwera (SNI), która jest wysyłana 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ą. |
Wysłano do wycofania osłony źródłowej
Właściwość isSentToOriginShield jest przestarzała i zastępowana przez nowe pole isReceivedFromClient. 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 na źródłach.
Dla każdego żądania, które trafia do osłony źródła, istnieją dwa wpisy dziennika:
- Jeden dla węzłów brzegowych
- Jeden dla tarczy początkowej
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 zaporze źródłowej w usłudze Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Uwaga / Notatka
W przypadku różnych konfiguracji routingu i zachowań ruchu niektóre pola, takie jak backendHostname, cacheStatus, isReceivedFromClient i pole POP, mogą odpowiadać różnymi wartościami. W poniższej tabeli wyjaśniono różne wartości tych pól dla różnych scenariuszy:
| Scenariusze | Liczba wpisów w dzienniku | POP | Nazwa hosta zaplecza | odebraneOdKlienta | Status pamięci podręcznej |
|---|---|---|---|---|---|
| Reguła routingu bez włączonej pamięci podręcznej | 1 | Kod POP przeglądarki Edge | Serwer zaplecza, do którego przekazano żądanie | Prawda | CONFIG_NOCACHE |
| Reguła routingu z włączonym buforowaniem. Trafienie pamięci podręcznej na krawędzi POP | 1 | Kod POP przeglądarki Edge | Pusty | Prawda | PRZEBÓJ |
| Reguła routingu z włączonym buforowaniem. Pominięcie pamięci podręcznej w węźle brzegowym POP, ale trafienie pamięci podręcznej w nadrzędnym węźle POP pamięci podręcznej. | 2 | 1. Kod Edge POP 2. Kod POP nadrzędnej pamięci podręcznej |
1. Nazwa hosta POP nadrzędnej pamięci podręcznej 2. Pusty |
1. Prawda 2. Nieprawda |
1. PUDŁO 2. PRZEBÓJ |
| Reguła routingu z włączonym buforowaniem. Pamięć podręczna brak trafienia w punkcie POP krawędzi, ale CZĘŚCIOWE trafienie w POP pamięci podręcznej nadrzędnej. | 2 | 1. Kod Edge POP 2. Kod POP nadrzędnej pamięci podręcznej |
1. Nazwa hosta POP nadrzędnej pamięci podręcznej 2. Zaplecze, które pomaga zapełnić pamięć podręczną |
1. Prawda 2. Nieprawda |
1. PUDŁO 2. CZĘŚCIOWE_TRAFNIENIE |
| Reguła routingu z włączonym buforowaniem. Pamięć podręczna PARTIAL_HIT w węźle brzegowym POP, ale trafienie w pamięć podręczną w nadrzędnym węźle POP. | 2 | 1. Kod Edge POP 2. Kod POP nadrzędnej pamięci podręcznej |
1. Kod Edge POP 2. Kod POP nadrzędnej pamięci podręcznej |
1. Prawda 2. Nieprawda |
1. CZĘŚCIOWE_TRAFIENIE 2. PRZEBÓJ |
| Reguła routingu z włączonym buforowaniem. Niepowodzenia w pamięci podręcznej występują zarówno w punkcie POP krawędzi, jak i w nadrzędnym punkcie POP pamięci podręcznej. | 2 | 1. Kod Edge POP 2. Kod POP nadrzędnej pamięci podręcznej |
1. Kod Edge POP 2. Kod POP nadrzędnej pamięci podręcznej |
1. Prawda 2. Nieprawda |
1. PUDŁO 2. Panna |
| Błąd podczas przetwarzania żądania | N/A |
Uwaga / Notatka
W przypadku scenariuszy buforowania stan pamięci podręcznej ma wartość PARTIAL_HIT, gdy część bajtów żądania jest serwowana z pamięci podręcznej na krawędzi Azure Front Door albo z pamięci podręcznej osłony źródła, podczas gdy inne bajty są serwowane bezpośrednio ze źródła, szczególnie w przypadku dużych obiektów.
Usługa Azure Front Door używa techniki nazywanej fragmentowaniem obiektów. Gdy żądany jest duży plik, usługa Azure Front Door pobiera mniejsze fragmenty pliku ze źródła. Gdy serwer POP usługi Azure Front Door otrzyma pełny lub zakresy bajtów żądanego pliku, serwer brzegowy usługi Azure Front Door żąda pliku ze źródła we fragmentach o rozmiarze 8 MB.
Gdy fragment dotrze do krawędzi usługi Azure Front Door, jest keszowany i natychmiast dostarczany użytkownikowi. Następnie usługa Azure Front Door pobiera równolegle następny fragment. Prefetching zapewnia, że zawartość jest o jeden krok przed użytkownikiem, co zmniejsza opóźnienia. Ten proces jest kontynuowany do momentu, gdy cały plik zostanie pobrany (jeśli zostanie zażądany), wszystkie zakresy bajtów będą dostępne (jeśli zostanie zażądane) lub klient zamknie 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. Wynikające z tego żądania dotyczące zakresów plików lub 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, funkcja pobierania wstępnego jest używana 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 tablice są nazywane insights i można je znaleźć w sekcji Insights usługi Azure Monitor w portalu Azure.
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.
Portal Azure ma interfejs użytkownika do wyświetlania i przeprowadzania 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.
Application Insights zawiera 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ą:
- Panele, które umożliwiają łączenie różnych rodzajów danych w jednym okienku w portalu Azure.
- Skoroszyty, dostosowywalne raporty, które można utworzyć w witrynie Azure Portal. Skoroszyty mogą zawierać tekst, metryki danych i zapytania dziennika.
- Grafana to otwarte narzędzie platformowe, które wyróżnia się w tworzeniu dashboardów operacyjnych. 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.
Logi: użyj interfejsu API REST lub powiązanych 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 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 właściwego typu reguły alertu.
Aby zapoznać się z przykładami typowych alertów dotyczących zasobów platformy Azure, zobacz Przykładowe zapytania dziennika alertów.
Implementowanie alertów na dużą skalę
W przypadku niektórych usług można monitorować na dużą skalę, stosując tę samą regułę alertu metrycznego do wielu zasobów tego samego typu w tym samym regionie Azure. Alerty bazowe usługi Azure Monitor (AMBA) zapewniają częściowo zautomatyzowaną metodę implementowania ważnych alertów metryk platformy, dashboardów 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.