Dzienniki diagnostyczne dla usługi Application Gateway
Dzienniki usługi Application Gateway zawierają szczegółowe informacje dotyczące zdarzeń związanych z zasobem i jego operacjami. Te dzienniki są dostępne dla zdarzeń, takich jak dostęp, aktywność, zapora i wydajność (tylko dla wersji 1). Szczegółowe informacje w dziennikach są przydatne podczas rozwiązywania problemu lub tworzenia pulpitu nawigacyjnego analizy przez użycie tych nieprzetworzonych danych.
Dzienniki są dostępne dla wszystkich zasobów usługi Application Gateway; jednak w celu ich użycia należy włączyć ich kolekcję w wybranej lokalizacji przechowywania. Rejestrowanie w usłudze aplikacja systemu Azure Gateway jest włączone przez usługę Azure Monitor. Zalecamy używanie obszaru roboczego usługi Log Analytics, ponieważ można łatwo używać wstępnie zdefiniowanych zapytań i ustawiać alerty na podstawie określonych warunków dziennika.
Typy dzienników diagnostycznych
Do zarządzania bramami aplikacji i rozwiązywania problemów z nimi można używać różnych typów dzienników na platformie Azure. Więcej informacji o tych typach można dowiedzieć się poniżej:
- Dziennik aktywności: możesz użyć dzienników aktywności platformy Azure (wcześniej znanych jako dzienniki operacyjne i dzienniki inspekcji), aby wyświetlić wszystkie operacje przesyłane do subskrypcji platformy Azure i ich stan. Wpisy dziennika aktywności są zbierane domyślnie i można je wyświetlać w witrynie Azure Portal.
- Dziennik dostępu: ten dziennik służy do wyświetlania wzorców dostępu usługi Application Gateway i analizowania ważnych informacji. Obejmuje to adres IP elementu wywołującego, żądany adres URL, opóźnienie odpowiedzi, kod zwrotny i bajty w i na wyjęcie. Dziennik dostępu jest zbierany co 60 sekund. Ten dziennik zawiera jeden rekord na wystąpienie usługi Application Gateway. Wystąpienie usługi Application Gateway jest identyfikowane przez właściwość instanceId.
- Dziennik wydajności: ten dziennik służy do wyświetlania sposobu działania wystąpień usługi Application Gateway. Ten dziennik przechwytuje informacje o wydajności dla każdego wystąpienia, w tym łączną liczbę obsługiwanych żądań, przepływność w bajtach, łączną liczbę obsługiwanych żądań, liczbę żądań niepomyślnie oraz liczbę wystąpień zaplecza w złej kondycji i złej kondycji. Dziennik wydajności jest zbierany co 60 sekund. Dziennik wydajności jest dostępny tylko dla jednostki SKU w wersji 1. W przypadku jednostki SKU w wersji 2 użyj metryk dla danych wydajności.
- Dziennik zapory: ten dziennik służy do wyświetlania żądań rejestrowanych za pośrednictwem trybu wykrywania lub zapobiegania bramie aplikacji skonfigurowanej za pomocą zapory aplikacji internetowej. Dzienniki zapory są zbierane co 60 sekund.
Uwaga
Dzienniki są dostępne tylko dla zasobów wdrożonych w modelu wdrażania usługi Azure Resource Manager. Nie można używać dzienników dla zasobów w klasycznym modelu wdrażania. Aby lepiej zrozumieć dwa modele, zobacz artykuł Understanding Resource Manager deployment and classic deployment (Opis wdrażania przy użyciu usługi Resource Manager i wdrażania klasycznego).
Lokalizacje magazynu
Dostępne są następujące opcje przechowywania dzienników w preferowanej lokalizacji.
Obszar roboczy analizy dzienników: ta opcja umożliwia czytelne używanie wstępnie zdefiniowanych zapytań, wizualizacji i ustawiania alertów na podstawie określonych warunków dziennika. Tabele używane przez dzienniki zasobów w obszarze roboczym usługi Log Analytics zależą od typu kolekcji używanej przez zasób:
Diagnostyka platformy Azure: dane są zapisywane w tabeli Diagnostyka Azure. Diagnostyka Azure tabela jest udostępniana między wieloma typami zasobów, a każdy z nich dodaje własne pola niestandardowe. Jeśli liczba pól niestandardowych pozyskanych do Diagnostyka Azure tabeli przekracza 500, nowe pola nie są dodawane jako najwyższego poziomu, ale dodawane do pola "AdditionalFields" jako pary wartości klucza dynamicznego.
Specyficzne dla zasobu (zalecane): dane są zapisywane w dedykowanych tabelach dla każdej kategorii zasobu. W trybie specyficznym dla zasobu każda kategoria dziennika wybrana w ustawieniu diagnostycznym ma przypisaną własną tabelę w wybranym obszarze roboczym. Ma to kilka korzyści, w tym:
- Łatwiejsze manipulowanie danymi w zapytaniach dzienników
- Ulepszona możliwość odnajdywania schematów i ich struktur
- Zwiększona wydajność pod względem opóźnienia pozyskiwania i czasów wykonywania zapytań
- Możliwość przypisywania praw kontroli dostępu opartej na rolach platformy Azure do określonych tabel
W przypadku usługi Application Gateway tryb specyficzny dla zasobu tworzy trzy tabele:
Uwaga
Opcja specyficzna dla zasobu jest obecnie dostępna we wszystkich regionach publicznych.
Istniejący użytkownicy mogą nadal korzystać z Diagnostyka Azure lub zdecydować się na dedykowane tabele, przełączając przełącznik w ustawieniach diagnostycznych na Wartość specyficzną dla zasobu lub do pozycji Dedykowane w miejscu docelowym interfejsu API. Tryb podwójny nie jest możliwy. Dane we wszystkich dziennikach mogą przepływać do Diagnostyka Azure lub do dedykowanych tabel. Można jednak mieć wiele ustawień diagnostycznych, w których jeden przepływ danych jest do diagnostyki platformy Azure, a drugi używa zasobu specyficznego w tym samym czasie.
Wybranie tabeli docelowej w usłudze Log Analytics: wszystkie usługi platformy Azure ostatecznie używają tabel specyficznych dla zasobów. W ramach tego przejścia możesz wybrać tabelę diagnostyki lub zasobu platformy Azure w ustawieniu diagnostycznym przy użyciu przycisku przełącznika. Przełącznik jest domyślnie ustawiony na wartość Zasób specyficzny dla zasobu, a w tym trybie dzienniki dla nowych wybranych kategorii są wysyłane do dedykowanych tabel w usłudze Log Analytics, podczas gdy istniejące strumienie pozostają niezmienione. Zobacz poniższy przykład.
Przekształcenia obszaru roboczego: wybranie opcji Specyficzne dla zasobu umożliwia filtrowanie i modyfikowanie danych przed ich pozyskiwaniem za pomocą przekształceń obszaru roboczego. Zapewnia to szczegółową kontrolę, umożliwiając skoncentrowanie się na najbardziej odpowiednich informacjach z dzienników, zmniejszając koszty danych i zwiększając bezpieczeństwo. Aby uzyskać szczegółowe instrukcje dotyczące konfigurowania przekształceń obszaru roboczego, zobacz: Samouczek: dodawanie przekształcenia obszaru roboczego do dzienników usługi Azure Monitor przy użyciu witryny Azure Portal.
Przykłady optymalizacji dzienników dostępu przy użyciu przekształceń obszaru roboczego
Przykład 1: Selektywne projekcje kolumn: Załóżmy, że masz dzienniki dostępu do bramy aplikacji z 20 kolumnami, ale interesuje Cię analizowanie danych tylko z 6 określonych kolumn. Dzięki przekształceniu obszaru roboczego można projektować te 6 kolumn w obszarze roboczym, co skutecznie wyklucza pozostałe 14 kolumn. Mimo że oryginalne dane z tych wykluczonych kolumn nie będą przechowywane, puste symbole zastępcze nadal będą wyświetlane w bloku Dzienniki. Takie podejście optymalizuje magazyn i zapewnia, że tylko odpowiednie dane są przechowywane do analizy.
Uwaga
W bloku Dzienniki wybranie opcji Wypróbuj nową usługę Log Analytics zapewnia większą kontrolę nad kolumnami wyświetlanymi w interfejsie użytkownika.
Przykład 2: Skupienie się na określonych kodach stanu: podczas analizowania dzienników dostępu zamiast przetwarzania wszystkich wpisów dziennika można napisać zapytanie w celu pobrania tylko wierszy z określonymi kodami stanu HTTP (takimi jak 4xx i 5xx). Ponieważ większość żądań najlepiej mieści się w kategoriach 2xx i 3xx (reprezentujących pomyślne odpowiedzi), koncentrując się na problematycznych kodach stanu zawęża zestaw danych. Takie ukierunkowane podejście umożliwia wyodrębnianie najbardziej odpowiednich i przydatnych informacji, co czyni je zarówno korzystnymi, jak i opłacalnymi.
Zalecana strategia przejścia z diagnostyki platformy Azure do tabeli specyficznej dla zasobów:
- Ocena bieżącego przechowywania danych: określ czas przechowywania danych w tabeli diagnostyki platformy Azure (na przykład: załóżmy, że tabela diagnostyki przechowuje dane przez 15 dni).
- Ustanów przechowywanie specyficzne dla zasobu: zaimplementuj nowe ustawienie diagnostyczne z tabelą specyficzną dla zasobu.
- Równoległe zbieranie danych: w przypadku okresu tymczasowego zbieraj dane współbieżnie zarówno w Diagnostyka Azure, jak i w ustawieniach specyficznych dla zasobów.
- Potwierdź dokładność danych: sprawdź, czy zbieranie danych jest dokładne i spójne w obu ustawieniach.
- Usuń ustawienie diagnostyki platformy Azure: usuń ustawienie diagnostyki platformy Azure, aby zapobiec zduplikowaniu zbierania danych.
Inne lokalizacje magazynu:
- Konto usługi Azure Storage: konta magazynu najlepiej używać w przypadku dzienników, gdy dzienniki są przechowywane przez dłuższy czas i przeglądane w razie potrzeby.
- Azure Event Hubs: usługa Event Hubs to świetna opcja integracji z innymi narzędziami do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM), aby otrzymywać alerty dotyczące zasobów.
- Integracje partnerów usługi Azure Monitor.
Dowiedz się więcej o miejscach docelowych ustawień diagnostycznych usługi Azure Monitor.
Włączanie rejestrowania za pomocą programu PowerShell
Rejestrowanie aktywności jest automatycznie włączone dla wszystkich zasobów usługi Resource Manager. Aby rozpocząć zbieranie danych dostępnych za pośrednictwem tych dzienników, należy włączyć rejestrowanie dostępu i wydajności. Aby włączyć rejestrowanie, wykonaj następujące czynności:
Zanotuj identyfikator zasobu konta magazynu, w ramach którego są przechowywane dane dzienników. Ta wartość ma postać: /subscriptions/subscriptionId/<resourceGroups/<nazwa grupy> zasobów/providers/Microsoft.Storage/storageAccounts/<nazwa> konta> magazynu. Użyć możesz dowolnego konta magazynu w ramach subskrypcji. Te informacje możesz znaleźć w witrynie Azure Portal.
Zanotuj identyfikator zasobu bramy aplikacji, dla którego włączono rejestrowanie. Ta wartość ma postać: /subscriptions/subscriptionId/<resourceGroups/<nazwa grupy> zasobów/providers/Microsoft.Network/applicationGateways/<nazwa> bramy> aplikacji. Te informacje możesz znaleźć w portalu.
Włącz rejestrowanie diagnostyczne przy użyciu następującego polecenia cmdlet programu PowerShell:
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
Napiwek
Dzienniki aktywności nie wymagają oddzielnego konta magazynu. Użycie magazynu na potrzeby rejestrowania danych o dostępie i wydajności powoduje naliczenie opłat za usługę.
Włączanie rejestrowania za pośrednictwem witryny Azure Portal
W witrynie Azure Portal znajdź zasób i wybierz pozycję Ustawienia diagnostyczne.
W przypadku usługi Application Gateway dostępne są trzy dzienniki:
- Dziennik dostępu
- Dziennik wydajności
- Dziennik zapory
Aby rozpocząć zbieranie danych, wybierz pozycję Włącz diagnostykę.
Strona Ustawienia diagnostyczne zawiera ustawienia dzienników diagnostycznych. W tym przykładzie usługa Log Analytics przechowuje dzienniki. Na potrzeby zapisywania dzienników diagnostycznych można także skorzystać z usługi Event Hubs i konta magazynu.
Wpisz nazwę ustawień, potwierdź ustawienia i wybierz pozycję Zapisz.
Dziennik aktywności
Platforma Azure domyślnie generuje dziennik aktywności. Dzienniki są zachowywane przez 90 dni w magazynie dzienników zdarzeń platformy Azure. Dowiedz się więcej o tych dziennikach, czytając artykuł Wyświetlanie zdarzeń i dziennika aktywności.
Dziennik dostępu
Dziennik dostępu jest generowany tylko wtedy, gdy włączono go w każdym wystąpieniu usługi Application Gateway, zgodnie z opisem w poprzednich krokach. Dane są przechowywane na koncie magazynu określonym podczas włączania rejestrowania. Każdy dostęp do usługi Application Gateway jest rejestrowany w formacie JSON, jak pokazano poniżej.
W przypadku usługi Application Gateway i jednostki SKU zapory aplikacji internetowej w wersji 2
Uwaga
Informacje dotyczące serwera proxy TLS/TCP można znaleźć w dokumentacji danych.
| Wartość | Opis |
|---|---|
| instanceId | Wystąpienie usługi Application Gateway, które obsłużyło żądanie. |
| clientIP | Adres IP natychmiastowego klienta usługi Application Gateway. Jeśli inny serwer proxy frontuje bramę aplikacji, zostanie wyświetlony adres IP tego serwera proxy frontingu. |
| httpMethod | Metoda HTTP używana przez żądanie. |
| Requesturi | Identyfikator URI odebranego żądania. |
| UserAgent | Agent użytkownika z nagłówka żądania HTTP. |
| httpStatus | Kod stanu HTTP zwrócony klientowi z usługi Application Gateway. |
| httpVersion | Wersja HTTP żądania. |
| odebrane bajty | Rozmiar odebranego pakietu w bajtach. |
| sentBytes | Rozmiar wysyłanego pakietu w bajtach. |
| clientResponseTime | Różnica czasu (w sekundach) między pierwszym bajtem a ostatnią bramą aplikacji bajtów wysłaną do klienta. Pomocne w uściśliwaniu czasu przetwarzania usługi Application Gateway dla odpowiedzi lub powolnych klientów. |
| timeTaken | Czas (w sekundach) potrzebny na przetworzenie pierwszego bajtu żądania klienta i jego ostatni bajt wysłany w odpowiedzi na klienta. Należy pamiętać, że pole Czas podjąć zwykle obejmuje czas, przez który pakiety żądań i odpowiedzi są przesyłane przez sieć. |
| WAFEvaluationTime | Czas (w sekundach) potrzebny do przetworzenia żądania przez zaporę aplikacji internetowej. |
| Tryb zapory aplikacji internetowej | Wartość może być wykrywaniem lub zapobieganiem |
| transactionId | Unikatowy identyfikator korelowania żądania odebranego od klienta |
| sslEnabled | Określa, czy komunikacja z pulami zaplecza używa protokołu TLS. Prawidłowe wartości są włączone i wyłączone. |
| sslCipher | Pakiet szyfrowania używany do komunikacji TLS (jeśli protokół TLS jest włączony). |
| sslProtocol | Używany protokół SSL/TLS (jeśli protokół TLS jest włączony). |
| serverRouted | Serwer zaplecza, do którego brama aplikacji kieruje żądanie. |
| serverStatus | Kod stanu HTTP serwera zaplecza. |
| serverResponseLatency | Opóźnienie odpowiedzi (w sekundach) z serwera zaplecza. |
| host | Adres wymieniony w nagłówku hosta żądania. W przypadku ponownego zapisywania nagłówka to pole zawiera zaktualizowaną nazwę hosta |
| originalRequestUriWithArgs | To pole zawiera oryginalny adres URL żądania |
| Requesturi | To pole zawiera adres URL po operacji ponownego zapisywania w usłudze Application Gateway |
| upstreamSourcePort | Port źródłowy używany przez usługę Application Gateway podczas inicjowania połączenia z obiektem docelowym zaplecza |
| originalHost | To pole zawiera oryginalną nazwę hosta żądania |
| error_info | Przyczyna błędu 4xx i 5xx. Wyświetla kod błędu żądania, który zakończył się niepowodzeniem. Więcej szczegółów znajduje się w temacie Informacje o kodzie błędu. |
| Contenttype | Typ zawartości lub danych przetwarzanych lub dostarczanych przez bramę aplikacji |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"listenerName": "HTTP-Listener",
"ruleName": "Storage-Static-Rule",
"backendPoolName": "StaticStorageAccount",
"backendSettingName": "StorageStatic-HTTPS-Setting",
"operationName": "ApplicationGatewayAccess",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "appgw_2",
"clientIP": "185.42.129.24",
"clientPort": 45057,
"httpMethod": "GET",
"originalRequestUriWithArgs": "\/",
"requestUri": "\/",
"requestQuery": "",
"userAgent": "Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/52.0.2743.116 Safari\/537.36",
"httpStatus": 200,
"httpVersion": "HTTP\/1.1",
"receivedBytes": 184,
"sentBytes": 466,
"clientResponseTime": 0,
"timeTaken": 0.034,
"WAFEvaluationTime": "0.000",
"WAFMode": "Detection",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"sslEnabled": "on",
"sslCipher": "ECDHE-RSA-AES256-GCM-SHA384",
"sslProtocol": "TLSv1.2",
"sslClientVerify": "NONE",
"sslClientCertificateFingerprint": "",
"sslClientCertificateIssuerName": "",
"serverRouted": "52.239.221.65:443",
"serverStatus": "200",
"serverResponseLatency": "0.028",
"upstreamSourcePort": "21564",
"originalHost": "20.110.30.194",
"host": "20.110.30.194",
"error_info":"ERRORINFO_NO_ERROR",
"contentType":"application/json"
}
}
Uwaga
Dzienniki dostępu z wartością clientIP 127.0.0.1 pochodzą z wewnętrznego procesu zabezpieczeń uruchomionego w wystąpieniach bramy aplikacji. Możesz bezpiecznie zignorować te wpisy dziennika.
W przypadku usługi Application Gateway w warstwie Standardowa i jednostki SKU zapory aplikacji internetowej (wersja 1)
| Wartość | Opis |
|---|---|
| instanceId | Wystąpienie usługi Application Gateway, które obsłużyło żądanie. |
| clientIP | Źródłowy adres IP żądania. |
| clientPort | Port źródłowy dla żądania. |
| httpMethod | Metoda HTTP używana przez żądanie. |
| Requesturi | Identyfikator URI odebranego żądania. |
| RequestQuery | Server-Routed: wystąpienie puli zaplecza, które zostało wysłane żądanie. X-AzureApplicationGateway-LOG-ID: identyfikator korelacji używany dla żądania. Może służyć do rozwiązywania problemów z ruchem na serwerach zaplecza. STAN SERWERA: kod odpowiedzi HTTP odebrany przez usługę Application Gateway z zaplecza. |
| UserAgent | Agent użytkownika z nagłówka żądania HTTP. |
| httpStatus | Kod stanu HTTP zwrócony klientowi z usługi Application Gateway. |
| httpVersion | Wersja HTTP żądania. |
| odebrane bajty | Rozmiar odebranego pakietu w bajtach. |
| sentBytes | Rozmiar wysyłanego pakietu w bajtach. |
| timeTaken | Czas (w milisekundach), który wymaga przetworzenia żądania i wysłania jego odpowiedzi. Jest to obliczane jako interwał od momentu odebrania przez usługę Application Gateway pierwszego bajtu żądania HTTP do czasu zakończenia operacji wysyłania odpowiedzi. Należy pamiętać, że pole Czas podjąć zwykle obejmuje czas, przez który pakiety żądań i odpowiedzi są przesyłane przez sieć. |
| sslEnabled | Czy komunikacja z pulami zaplecza korzystała z protokołu TLS/SSL. Prawidłowe wartości są włączone i wyłączone. |
| host | Nazwa hosta, dla którego żądanie zostało wysłane do serwera zaplecza. Jeśli nazwa hosta zaplecza jest zastępowana, ta nazwa odzwierciedla tę nazwę. |
| originalHost | Nazwa hosta, dla którego żądanie zostało odebrane przez usługę Application Gateway od klienta. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIP": "191.96.249.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-AzureApplicationGateway-LOG-ID=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"host": "www.contoso.com",
"originalHost": "www.contoso.com"
}
}
Informacje o kodzie błędu
Jeśli brama aplikacji nie może ukończyć żądania, przechowuje jeden z następujących kodów przyczyn w polu error_info dziennika dostępu.
| Błędy 4XX | (Kody błędów 4xx wskazują, że wystąpił problem z żądaniem klienta, a usługa Application Gateway nie może go spełnić). |
|---|---|
| ERRORINFO_INVALID_METHOD | Klient wysłał żądanie niezgodne z specyfikacją RFC. Możliwe przyczyny: klient korzystający z metody HTTP nie jest obsługiwany przez serwer, błędnie napisany metodę, niezgodną wersję protokołu HTTP itp. |
| ERRORINFO_INVALID_REQUEST | Serwer nie może spełnić żądania z powodu nieprawidłowej składni. |
| ERRORINFO_INVALID_VERSION | Brama aplikacji odebrała żądanie z nieprawidłową lub nieobsługiwaną wersją protokołu HTTP. |
| ERRORINFO_INVALID_09_METHOD | Klient wysłał żądanie z protokołem HTTP w wersji 0.9. |
| ERRORINFO_INVALID_HOST | W nagłówku "Host" brakuje wartości , nieprawidłowo sformatowanych lub nie jest zgodna z oczekiwaną wartością hosta. Jeśli na przykład nie ma odbiornika podstawowego, a żadna z nazw hostów odbiorników w wielu lokacjach nie jest zgodna z hostem. |
| ERRORINFO_INVALID_CONTENT_LENGTH | Długość zawartości określonej przez klienta w nagłówku content-Length nie odpowiada rzeczywistej długości zawartości w żądaniu. |
| ERRORINFO_INVALID_METHOD_TRACE | Klient wysłał metodę HTTP TRACE, która nie jest obsługiwana przez bramę aplikacji. |
| ERRORINFO_CLIENT_CLOSED_REQUEST | Klient zamknął połączenie z bramą aplikacji przed upływem limitu czasu bezczynności. Sprawdź, czy limit czasu klienta jest większy niż limit czasu bezczynności dla bramy aplikacji. |
| ERRORINFO_REQUEST_URI_INVALID | Wskazuje problem z identyfikatorem URI (Uniform Resource Identifier) podanym w żądaniu klienta. |
| ERRORINFO_HTTP_NO_HOST_HEADER | Klient wysłał żądanie bez nagłówka hosta. |
| ERRORINFO_HTTP_TO_HTTPS_PORT | Klient wysłał zwykłe żądanie HTTP do portu HTTPS. |
| ERRORINFO_HTTPS_NO_CERT | Wskazuje, że klient nie wysyła prawidłowego i prawidłowo skonfigurowanego certyfikatu TLS podczas wzajemnego uwierzytelniania TLS. |
| Błędy 5XX | opis |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | Brama aplikacji nie może odnaleźć żadnych aktywnych lub osiągalnych serwerów zaplecza do obsługi żądań przychodzących |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | Serwer zaplecza nieoczekiwanie zamknął połączenie lub zanim żądanie zostało w pełni przetworzone. Może się to zdarzyć z powodu osiągnięcia limitów przez serwer zaplecza, awarii itp. |
| ERRORINFO_UPSTREAM_TIMED_OUT | Nawiązane połączenie TCP z serwerem zostało zamknięte, ponieważ połączenie trwało dłużej niż skonfigurowana wartość limitu czasu. |
Dziennik wydajności
Dziennik wydajności jest generowany tylko wtedy, gdy włączono go w każdym wystąpieniu usługi Application Gateway, zgodnie z opisem w poprzednich krokach. Dane są przechowywane na koncie magazynu określonym podczas włączania rejestrowania. Dane dziennika wydajności są generowane w 1-minutowych odstępach czasu. Jest ona dostępna tylko dla jednostki SKU w wersji 1. W przypadku jednostki SKU w wersji 2 użyj metryk dla danych wydajności. Rejestrowane są następujące dane:
| Wartość | Opis |
|---|---|
| instanceId | Wystąpienie usługi Application Gateway, dla którego są generowane dane wydajności. W przypadku bramy aplikacji z wieloma wystąpieniami istnieje jeden wiersz na wystąpienie. |
| healthyHostCount | Liczba hostów w dobrej kondycji w puli zaplecza. |
| unHealthyHostCount | Liczba hostów w złej kondycji w puli zaplecza. |
| requestCount | Liczba obsługiwanych żądań. |
| opóźnienie | Średnie opóźnienie (w milisekundach) żądań z wystąpienia do zaplecza obsługującego żądania. |
| failedRequestCount | Liczba żądań zakończonych niepowodzeniem. |
| danych | Średnia przepływność od ostatniego dziennika mierzona w bajtach na sekundę. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
Uwaga
Opóźnienie jest obliczane od momentu odebrania pierwszego bajtu żądania HTTP do momentu wysłania ostatniego bajtu odpowiedzi HTTP. Jest to suma czasu przetwarzania usługi Application Gateway oraz koszt sieci do zaplecza oraz czas potrzebny na przetworzenie żądania przez zaplecze.
Dziennik zapory
Dziennik zapory jest generowany tylko wtedy, gdy włączono go dla każdej bramy aplikacji, zgodnie z opisem w poprzednich krokach. Ten dziennik wymaga również skonfigurowania zapory aplikacji internetowej w bramie aplikacji. Dane są przechowywane na koncie magazynu określonym podczas włączania rejestrowania. Rejestrowane są następujące dane:
| Wartość | Opis |
|---|---|
| instanceId | Wystąpienie usługi Application Gateway, dla którego są generowane dane zapory. W przypadku bramy aplikacji z wieloma wystąpieniami istnieje jeden wiersz na wystąpienie. |
| clientIp | Źródłowy adres IP żądania. |
| clientPort | Port źródłowy dla żądania. |
| Requesturi | Adres URL odebranego żądania. |
| ruleSetType | Typ zestawu reguł. Dostępna wartość to OWASP. |
| ruleSetVersion | Używana wersja zestawu reguł. Dostępne wartości to 2.2.9 i 3.0. |
| Ruleid | Identyfikator reguły zdarzenia wyzwalającego. |
| wiadomość | Przyjazny dla użytkownika komunikat dotyczący zdarzenia wyzwalającego. Więcej szczegółów znajduje się w sekcji szczegółów. |
| action | Akcja podjęta na żądanie. Dostępne wartości są zablokowane i dozwolone (w przypadku reguł niestandardowych), dopasowane (gdy reguła pasuje do części żądania) i Wykryto i Zablokowane (są to zarówno reguły obowiązkowe, w zależności od tego, czy zapora aplikacji internetowej jest w trybie wykrywania lub zapobiegania). |
| lokacja | Lokacja, dla której wygenerowano dziennik. Obecnie na liście znajduje się tylko wartość Global, ponieważ reguły są globalne. |
| szczegóły | Szczegóły zdarzenia wyzwalania. |
| details.message | Opis reguły. |
| details.data | Określone dane znalezione w żądaniu, które pasują do reguły. |
| details.file | Plik konfiguracji zawierający regułę. |
| details.line | Numer wiersza w pliku konfiguracji, który wyzwolił zdarzenie. |
| nazwa hosta | Nazwa hosta lub adres IP usługi Application Gateway. |
| transactionId | Unikatowy identyfikator dla danej transakcji, która ułatwia grupowanie wielu naruszeń reguł, które wystąpiły w ramach tego samego żądania. |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_2",
"clientIp": "185.42.129.24",
"clientPort": "",
"requestUri": "\/",
"ruleSetType": "OWASP_CRS",
"ruleSetVersion": "3.0.0",
"ruleId": "920350",
"message": "Host header is a numeric IP address",
"action": "Matched",
"site": "Global",
"details": {
"message": "Warning. Pattern match \\\"^[\\\\d.:]+$\\\" at REQUEST_HEADERS:Host .... ",
"data": "20.110.30.194:80",
"file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
"line": "791"
},
"hostname": "20.110.30.194:80",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"policyId": "default",
"policyScope": "Global",
"policyScopeName": "Global"
}
}
Wyświetlanie i analizowanie dziennika aktywności
Dane dziennika aktywności można wyświetlać i analizować przy użyciu dowolnej z następujących metod:
- Narzędzia platformy Azure: pobierz informacje z dziennika aktywności przy użyciu programu Azure PowerShell, interfejsu wiersza polecenia platformy Azure, interfejsu API REST platformy Azure lub witryny Azure Portal. Instrukcje krok po kroku dla każdej metody są szczegółowo opisane w artykule Activity operations with Resource Manager (Operacje działań przy użyciu usługi Resource Manager).
- Usługa Power BI: jeśli nie masz jeszcze konta usługi Power BI, możesz ją wypróbować bezpłatnie. Korzystając z aplikacji szablonu usługi Power BI, możesz analizować dane.
Wyświetlanie i analizowanie dzienników dostępu, wydajności i zapory
Dzienniki usługi Azure Monitor mogą zbierać pliki dziennika liczników i zdarzeń z konta usługi Blob Storage. Obejmuje ona wizualizacje oraz zaawansowane możliwości wyszukiwania na potrzeby analizowania dzienników.
Ponadto możesz połączyć się z kontem magazynu i pobrać wpisy dziennika JSON dotyczące dostępu i wydajności. Po pobraniu plików JSON możesz je przekonwertować do formatu CSV i wyświetlać w programie Excel, usłudze Power BI lub innym narzędziu do wizualizacji danych.
Napiwek
Jeśli znasz program Visual Studio i podstawowe pojęcia dotyczące zmieniania wartości dla stałych i zmiennych w języku C#, możesz użyć narzędzi konwertera dzienników dostępnych w usłudze GitHub.
Analizowanie dzienników dostępu za pośrednictwem funkcji GoAccess
Opublikowaliśmy szablon usługi Resource Manager, który instaluje i uruchamia popularny analizator dzienników usługi GoAccess dla dzienników dostępu usługi Application Gateway. Funkcja GoAccess udostępnia cenne statystyki ruchu HTTP, takie jak unikatowe odwiedzający, żądane pliki, hosty, systemy operacyjne, przeglądarki, kody stanu HTTP i inne. Aby uzyskać więcej informacji, zobacz plik Readme w folderze szablonu usługi Resource Manager w usłudze GitHub.
Następne kroki
- Wizualizowanie dzienników liczników i zdarzeń przy użyciu dzienników usługi Azure Monitor.
- Wizualizowanie dziennika aktywności platformy Azure za pomocą wpisu w blogu usługi Power BI .
- Wyświetlanie i analizowanie dzienników aktywności platformy Azure w usłudze Power BI i więcej wpisu w blogu.