Monitorizar métricas e registos no Azure Front Door
O Azure Front Door fornece vários recursos para ajudá-lo a monitorar seu aplicativo, rastrear solicitações e depurar sua configuração de Front Door.
Os logs e métricas são armazenados e gerenciados pelo Azure Monitor.
Os relatórios fornecem informações sobre como seu tráfego está fluindo através do Azure Front Door, o firewall de aplicativo Web (WAF) e para seu aplicativo.
Métricas
O Azure Front Door mede e envia suas métricas em intervalos de 60 segundos. As métricas podem levar até 3 minutos para serem processadas pelo Azure Monitor e podem não aparecer até que o processamento seja concluído. As métricas também podem ser exibidas em gráficos ou grades e podem ser acessadas por meio do portal do Azure, do Azure PowerShell, da CLI do Azure e das APIs do Azure Monitor. Para obter mais informações, consulte Métricas do Azure Monitor.
As métricas listadas na tabela a seguir são registradas e armazenadas gratuitamente por um período limitado de tempo. Por um custo extra, você pode armazenar por um longo período de tempo.
| Métricas do | Description | Dimensões | Agregações recomendadas |
|---|---|---|---|
| Taxa de acertos de byte | A percentagem de tráfego que foi servida a partir da cache da Porta da Frente do Azure, calculada em relação ao tráfego de saída total. A taxa de acertos de bytes é baixa se a maior parte do tráfego for encaminhada para a origem em vez de servida a partir do cache. Byte Hit Ratio = (saída da borda - saída da origem)/saída da borda. Cenários excluídos dos cálculos de taxa de acertos de bytes:
|
Ponto final | Preço médio, Min |
| Percentagem de Saúde de Origem | A porcentagem de sondas de integridade bem-sucedidas enviadas do Azure Front Door para as origens. | Origem, Grupo Origem | Média |
| Latência de origem | O Azure Front Door calcula o tempo desde o envio da solicitação para a origem até o recebimento do último byte de resposta da origem. WebSocket é excluído da latência de origem. | Ponto de extremidade, Origem | Preço médio, máximo |
| Contagem de Pedidos de Origem | O número de solicitações enviadas do Azure Front Door para origens. | Ponto de extremidade, origem, status HTTP, grupo de status HTTP | Preço médio, soma |
| Percentagem de 4XX | A porcentagem de todas as solicitações do cliente para as quais o código de status de resposta é 4XX. | Ponto de extremidade, País do cliente, Região do cliente | Preço médio, máximo |
| Percentagem de 5XX | A porcentagem de todas as solicitações do cliente para as quais o código de status da resposta é 5XX. | Ponto de extremidade, País do cliente, Região do cliente | Preço médio, máximo |
| Número de Pedidos | O número de solicitações de cliente atendidas por meio do Azure Front Door, incluindo solicitações atendidas inteiramente a partir do cache. | Ponto de extremidade, País do cliente, Região do cliente, Estado HTTP, Grupo de estado HTTP | Preço médio, soma |
| Tamanho do Pedido | O número de bytes enviados em solicitações de clientes para o Azure Front Door. | Ponto de extremidade, País do cliente, Região do cliente, Estado HTTP, Grupo de Estado HTTP | Preço médio, máximo |
| Tamanho da resposta | O número de bytes enviados como respostas do Front Door para clientes. | Ponto de extremidade, País do cliente, Região do cliente, Estado HTTP, Grupo de Estado HTTP | Preço médio, máximo |
| Latência Total | O Azure Front Door recebe a solicitação do cliente e envia o último byte de resposta para o cliente. Este é o tempo total despendido. Para WebSocket, essa métrica refere-se ao tempo que leva para estabelecer a conexão WebSocket. | Ponto de extremidade, País do cliente, Região do cliente, Estado HTTP, Grupo de estado HTTP | Preço médio, máximo |
| Contagem de solicitações do Web Application Firewall | O número de solicitações processadas pelo firewall do aplicativo Web Azure Front Door. | Ação, Nome da política, Nome da regra | Preço médio, soma |
Nota
Se uma solicitação para a origem expirar, o valor da dimensão Status Http será 0.
Registos
Os logs rastreiam todas as solicitações que passam pela Porta da Frente do Azure. Pode levar alguns minutos para que os logs sejam processados e armazenados.
Existem vários logs de porta da frente, que você pode usar para diferentes fins:
- Os logs de acesso podem ser usados para identificar solicitações lentas, determinar taxas de erro e entender como o comportamento de cache do Front Door está funcionando para sua solução.
- Os logs do WAF (Web Application Firewall) podem ser usados para detetar possíveis ataques e deteções de falsos positivos que podem indicar solicitações legítimas que o WAF bloqueou. Para obter mais informações sobre os logs WAF, consulte Monitoramento e registro em log do Firewall de Aplicativo Web do Azure.
- Os logs de sonda de integridade podem ser usados para identificar origens que não estão íntegras ou que não respondem a solicitações de alguns PoPs geograficamente distribuídos do Front Door.
- Os logs de atividades fornecem visibilidade sobre as operações executadas em seus recursos do Azure, como alterações de configuração em seu perfil do Azure Front Door.
Os logs de acesso e os logs WAF incluem uma referência de rastreamento, que também é propagada em solicitações para origens e respostas de clientes usando o X-Azure-Ref cabeçalho. Você pode usar a referência de acompanhamento para obter uma visão de ponta a ponta do processamento de sua solicitação de aplicativo.
Os logs de acesso, os logs de investigação de integridade e os logs WAF não são habilitados por padrão. Para habilitar e armazenar seus logs de diagnóstico, consulte Configurar logs da Porta da Frente do Azure. As entradas de registos de atividades são recolhidas por predefinição e pode visualizá-las no portal do Azure.
Registo de acesso
As informações sobre cada solicitação são registradas no log de acesso. Cada entrada de log de acesso contém as informações listadas na tabela a seguir.
| Property | Description |
|---|---|
| TrackingReference | A cadeia de referência única que identifica um pedido servido pelo Azure Front Door. A referência de rastreamento é enviada para o cliente e para a origem usando os X-Azure-Ref cabeçalhos. Utilize a referência de rastreio quando procurar um pedido específico nos registos de acesso ou do WAF. |
| Hora | A data e a hora em que a borda da Porta da Frente do Azure entregou o conteúdo solicitado ao cliente (em UTC). Para conexões WebSocket, o tempo representa quando a conexão é fechada. |
| Método Http | Método HTTP usado pela solicitação: DELETE, GET, HEAD, OPTIONS, PATCH, POST ou PUT. |
| Versão Http | A versão HTTP que o cliente especificou na solicitação. |
| RequestUri | O URI da solicitação recebida. Este campo contém o esquema completo, a porta, o domínio, o caminho e a cadeia de caracteres de consulta. |
| Nome do Anfitrião | O nome do host na solicitação do cliente. Se você habilitar domínios personalizados e tiver domínio curinga (*.contoso.com), o valor do campo de log HostName será subdomain-from-client-request.contoso.com. Se você usar o domínio Azure Front Door (contoso-123.z01.azurefd.net), o valor do campo de log HostName será contoso-123.z01.azurefd.net. |
| RequestBytes | O tamanho da mensagem de solicitação HTTP em bytes, incluindo os cabeçalhos da solicitação e o corpo da solicitação. Para conexões WebSocket, este é o número total de bytes enviados do cliente para o servidor através da conexão. |
| ResponseBytes | O tamanho da mensagem de resposta HTTP em bytes. Para conexões WebSocket, este é o número total de bytes enviados do servidor para o cliente através da conexão. |
| UserAgent | O agente de usuário que o cliente usou. Normalmente, o agente do usuário identifica o tipo de navegador. |
| ClientIp | O endereço IP do cliente que fez a solicitação original. Se houver um X-Forwarded-For cabeçalho na solicitação, o endereço IP do cliente será retirado do cabeçalho. |
| SocketIp | O endereço IP da conexão direta com a borda da Porta da Frente do Azure. Se o cliente usou um proxy HTTP ou um balanceador de carga para enviar a solicitação, o valor de SocketIp é o endereço IP do proxy ou balanceador de carga. |
| Tempo Gasto | A duração desde quando a borda da Porta da Frente do Azure recebeu a solicitação do cliente até quando o último byte da resposta foi enviado ao cliente, medido em segundos. Essa métrica exclui latência de rede e buffer TCP. Para conexões WebSocket, ele representa a duração da conexão desde o estabelecimento até o fechamento. |
| Protocolo de solicitação | O protocolo especificado pelo cliente na solicitação. Os valores possíveis incluem: HTTP, HTTPS. Para WebSocket, os protocolos são WS, WSS. Somente as solicitações que atualizarem com êxito para WebSocket terão WS/WSS. |
| SecurityProtocol | A versão do protocolo TLS/SSL usada pela solicitação, ou nula se a solicitação não usar criptografia. Os valores possíveis incluem: SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
| SecurityCipher | Quando o valor do protocolo de solicitação é HTTPS, esse campo indica a cifra TLS/SSL negociada pelo cliente e pela Porta da Frente do Azure. |
| Ponto final | O nome de domínio do ponto de extremidade da Porta da Frente do Azure, como contoso-123.z01.azurefd.net. |
| HttpStatusCode | O código de status HTTP retornado do Azure Front Door. Se a solicitação para a origem expirou, o valor para o campo HttpStatusCode é 0. Se o cliente fechou a conexão, o valor para o campo HttpStatusCode é 499. |
| Pop | O ponto de presença de borda (PoP) da Porta da Frente do Azure que respondeu à solicitação do usuário. |
| Cache Status | Como a solicitação foi tratada pelo cache da Porta da Frente do Azure. Os valores possíveis são:
|
| MatchedRulesSetName | Os nomes das regras do mecanismo de regras que foram processadas. |
| Nome da Rota | O nome da rota correspondente à solicitação. |
| ClientPort | A porta IP do cliente que fez a solicitação. |
| Referenciador | A URL do site que originou a solicitação. |
| TimetoFirstByte | O período de tempo, em segundos, desde quando a borda da Porta da Frente do Azure recebeu a solicitação até o momento em que o primeiro byte foi enviado ao cliente, conforme medido pela Porta da Frente do Azure. Esta propriedade não mede os dados do cliente. |
| ErrorInfo | Se ocorreu um erro durante o processamento do pedido, este campo fornece informações detalhadas sobre o erro. Os valores possíveis são:
|
| URL de origem | O URL completo da origem para onde o pedido foi enviado. A URL é composta pelo esquema, cabeçalho do host, porta, caminho e cadeia de caracteres de consulta. Regravação de URL: se a URL da solicitação foi reescrita pelo Mecanismo de Regras, o caminho se refere ao caminho reescrito. Cache no PoP de borda: se a solicitação foi atendida a partir do cache da Porta da Frente do Azure, a origem é N/A. Solicitação grande: se o conteúdo solicitado for grande e houver várias solicitações fragmentadas voltando à origem, esse campo corresponderá à primeira solicitação à origem. Para obter mais informações, consulte Fragmentação de objetos. |
| OriginIP | O endereço IP da origem que atendeu a solicitação. Cache no PoP de borda: se a solicitação foi atendida a partir do cache da Porta da Frente do Azure, a origem é N/A. Solicitação grande: se o conteúdo solicitado for grande e houver várias solicitações fragmentadas voltando à origem, esse campo corresponderá à primeira solicitação à origem. Para obter mais informações, consulte Fragmentação de objetos. |
| Nome da origem | O nome completo do host (nome DNS) da origem. Cache no PoP de borda: se a solicitação foi atendida a partir do cache da Porta da Frente do Azure, a origem é N/A. Solicitação grande: se o conteúdo solicitado for grande e houver várias solicitações fragmentadas voltando à origem, esse campo corresponderá à primeira solicitação à origem. Para obter mais informações, consulte Fragmentação de objetos. |
| Result | SSLMismatchedSNI é um código de status que significa uma solicitação bem-sucedida com um aviso de incompatibilidade entre o SNI e o cabeçalho do host. Esse código de status implica fronting de domínio, uma técnica que viola os termos de serviço do Azure Front Door. Os pedidos com SSLMismatchedSNI serão rejeitados após 22 de janeiro de 2024. |
| Sni | Este campo especifica a Indicação de Nome do Servidor (SNI) que é enviada durante o handshake TLS/SSL. Ele pode ser usado para identificar o valor exato do SNI se houver um código de SSLMismatchedSNI status. Além disso, ele pode ser comparado com o requestUri valor do host no campo para detetar e resolver o problema de incompatibilidade. |
Log da sonda de integridade
O Azure Front Door registra todas as solicitações de investigação de integridade com falha. Esses logs podem ajudá-lo a diagnosticar problemas com uma origem. Os logs fornecem informações que você pode usar para investigar o motivo da falha e, em seguida, trazer a origem de volta a um status íntegro.
Alguns cenários para os quais esse log pode ser útil são:
- Você notou que o tráfego da Porta da Frente do Azure foi enviado para um subconjunto das origens. Por exemplo, você deve ter notado que apenas três em cada quatro origens recebem tráfego. Você quer saber se as origens estão recebendo e respondendo a sondas de saúde para saber se as origens são saudáveis.
- Você notou que a métrica de porcentagem de integridade de origem é menor do que você esperava. Você quer saber quais origens são registradas como insalubres e o motivo das falhas na sonda de saúde.
Cada entrada de log da sonda de integridade tem o seguinte esquema:
| Property | Description |
|---|---|
| SaúdeProbeId | Um ID exclusivo para identificar a solicitação de sonda de integridade. |
| Hora | A data e a hora em que a sonda de integridade foi enviada (em UTC). |
| Método Http | O método HTTP usado pela solicitação de teste de integridade. Os valores incluem GET e HEAD, com base na configuração da sonda de integridade. |
| Result | O estado da sonda de saúde. O valor é sucesso ou uma descrição do erro que a sonda recebeu. |
| HttpStatusCode | O código de status HTTP retornado pela origem. |
| ProbeURL | A URL de destino completa para onde a solicitação de teste foi enviada. A URL é composta pelo esquema, cabeçalho do host, caminho e cadeia de caracteres de consulta. |
| Nome da origem | O nome da origem para a qual a sonda de saúde foi enviada. Este campo ajuda você a localizar origens de interesse se a origem estiver configurada para usar um FDQN. |
| POP | O PoP de borda que enviou a solicitação de teste. |
| IP de origem | O endereço IP da origem para a qual a sonda de integridade foi enviada. |
| TotalLatency | O tempo desde quando a borda da Porta da Frente do Azure enviou a solicitação de teste de integridade para a origem até quando a origem enviou a última resposta para a Porta da Frente do Azure. |
| ConnectionLatency | O tempo gasto na configuração da conexão TCP para enviar a solicitação de teste HTTP para a origem. |
| Latência DNSResolution | O tempo gasto na resolução DNS. Este campo só tem um valor se a origem estiver configurada para ser um FDQN em vez de um endereço IP. Se a origem estiver configurada para usar um endereço IP, o valor será N/A. |
O trecho JSON de exemplo a seguir mostra uma entrada de log de teste de integridade para uma solicitação de teste de integridade com falha.
{
"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"
}
}
]
}
Log do firewall do aplicativo Web
Para obter mais informações sobre os logs do WAF (Front Door Web Application Firewall), consulte Monitoramento e registro em log do Firewall de Aplicativo Web do Azure.
Registos de atividade
Os logs de atividades fornecem informações sobre as operações de gerenciamento em seus recursos do Azure Front Door. Os logs incluem detalhes sobre cada operação de gravação que foi executada em um recurso do Azure Front Door, incluindo quando a operação ocorreu, quem a executou e qual foi a operação.
Nota
Os logs de atividades não incluem operações de leitura. Eles também podem não incluir todas as operações que você executa usando o portal do Azure ou APIs de gerenciamento clássicas.
Para obter mais informações, consulte Exibir seus registros de atividades.
Próximos passos
Para habilitar e armazenar seus logs de diagnóstico, consulte Configurar logs da Porta da Frente do Azure.
Importante
O Azure Front Door (clássico) será desativado em 31 de março de 2027. Para evitar qualquer interrupção do serviço, é importante migrar seus perfis do Azure Front Door (clássico) para a camada Azure Front Door Standard ou Premium até março de 2027. Para obter mais informações, consulte Aposentadoria (clássica) do Azure Front Door.
Ao usar o Azure Front Door (clássico), você pode monitorar recursos das seguintes maneiras:
- Métricas. Atualmente, o Azure Front Door tem oito métricas para exibir contadores de desempenho.
- Registos. Os logs de atividade e diagnóstico permitem que o desempenho, o acesso e outros dados sejam salvos ou consumidos de um recurso para fins de monitoramento.
Métricas
As métricas são um recurso para determinados recursos do Azure que permitem exibir contadores de desempenho no portal. Estão disponíveis as seguintes métricas de porta frontal:
| Métrica | Nome de exibição da métrica | Unit | Dimensões | Description |
|---|---|---|---|---|
| RequestCount | Número de Pedidos | Count | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
O número de pedidos de clientes atendidos pela Front Door. |
| RequestSize | Tamanho do Pedido | Bytes | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
O número de bytes enviados como solicitações de clientes para o Front Door. |
| ResponseSize | Tamanho da resposta | Bytes | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
O número de bytes enviados como respostas do Front Door para clientes. |
| TotalLatency | Latência Total | Milissegundos | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
O tempo total desde o pedido do cliente recebido pela Front Door até ao último byte de resposta enviado do AFD para o cliente. |
| BackendRequestCount | Contagem de solicitações de back-end | Count | HttpStatus HttpStatusGroup Back-end |
O número de solicitações enviadas do Front Door para backends. |
| BackendRequestLatency | Latência de solicitação de back-end | Milissegundos | Back-end | O tempo calculado a partir de quando a solicitação foi enviada pela Front Door para o back-end até que a Front Door recebeu o último byte de resposta do back-end. |
| BackendHealthPercentage | Porcentagem de integridade de back-end | Percentagem | Back-end BackendPool |
A percentagem de sondas de saúde bem-sucedidas desde a porta da frente até aos backends. |
| WebApplicationFirewallRequestCount | Contagem de solicitações do Web Application Firewall | Count | Ação PolicyName RuleName |
O número de solicitações de clientes processadas pela camada de aplicação de segurança do Front Door. |
Registos de atividade
Os logs de atividades fornecem informações sobre as operações feitas em um perfil (clássico) do Azure Front Door. Eles também determinam o quê, quem e quando para quaisquer operações de gravação (colocar, postar ou excluir) feitas em um perfil (clássico) do Azure Front Door.
Nota
Se uma solicitação para a origem expirar, o valor para HttpStatusCode será definido como 0.
Aceda aos registos de atividade na sua porta da frente ou a todos os registos dos seus recursos do Azure no Azure Monitor. Para ver registos de atividades:
Selecione sua instância Front Door.
Selecione Registro de atividades.
Escolha um escopo de filtragem e selecione Aplicar.
Nota
O log de atividades não inclui nenhuma operação GET ou operações que você executa usando o portal do Azure ou a API de Gerenciamento original.
Registos de diagnósticos
Os logs de diagnóstico fornecem informações detalhadas sobre operações e erros que são importantes para auditoria e solução de problemas. Os logs de diagnóstico diferem dos logs de atividade.
Os logs de atividades fornecem informações sobre as operações feitas nos recursos do Azure. Os logs de diagnóstico fornecem informações sobre as operações que seu recurso realizou. Para obter mais informações, consulte Logs de diagnóstico do Azure Monitor.
Para configurar logs de diagnóstico para sua porta frontal do Azure (clássico):
Selecione seu perfil do Azure Front Door (clássico).
Escolha Configurações de diagnóstico.
Selecione Ativar diagnóstico. Arquive logs de diagnóstico juntamente com métricas em uma conta de armazenamento, transmita-os para um hub de eventos ou envie-os para logs do Azure Monitor.
Front Door atualmente fornece logs de diagnóstico. Os logs de diagnóstico fornecem solicitações de API individuais com cada entrada com o seguinte esquema:
| Property | Description |
|---|---|
| BackendHostname | Se a solicitação estava sendo encaminhada para um back-end, esse campo representa o nome do host do back-end. Esse campo ficará em branco se a solicitação for redirecionada ou encaminhada para um cache regional (quando o cache for habilitado para a regra de roteamento). |
| CacheStatus | Para cenários de cache, este campo define o acerto/erro do cache no POP |
| ClientIp | O endereço IP do cliente que fez a solicitação. Se houver um cabeçalho X-Forwarded-For na solicitação, o IP do cliente será escolhido do mesmo. |
| ClientPort | A porta IP do cliente que fez a solicitação. |
| Método Http | Método HTTP usado pela solicitação. |
| HttpStatusCode | O código de status HTTP retornado do proxy. Se uma solicitação para a origem expirar, o valor para HttpStatusCode será definido como 0. |
| HttpStatusDetails | Status resultante na solicitação. O significado desse valor de cadeia de caracteres pode ser encontrado em uma tabela de referência de status. |
| Versão Http | Tipo de solicitação ou conexão. |
| POP | Nome abreviado da borda onde o pedido pousou. |
| RequestBytes | O tamanho da mensagem de solicitação HTTP em bytes, incluindo os cabeçalhos da solicitação e o corpo da solicitação. |
| RequestUri | URI da solicitação recebida. |
| ResponseBytes | Bytes enviados pelo servidor back-end como resposta. |
| RoutingRuleName | O nome da regra de roteamento correspondente à solicitação. |
| RulesEngineMatchNames | Os nomes das regras que a solicitação correspondeu. |
| SecurityProtocol | A versão do protocolo TLS/SSL usada pela solicitação ou nula se não houver criptografia. |
| SentToOriginShield (preterido) * Consulte as notas sobre a substituição na seção a seguir. |
Se verdadeiro, significa que a solicitação foi respondida do cache do escudo de origem em vez do pop-pop-borda da borda. O escudo Origin é um cache pai usado para melhorar a taxa de acertos do cache. |
| isReceivedFromClient | Se for verdade, significa que o pedido veio do cliente. Se false, a solicitação é uma falha na borda (POP filho) e é respondida a partir do escudo de origem (POP pai). |
| Tempo Gasto | O período de tempo desde o primeiro byte de solicitação na Front Door até o último byte de resposta, em segundos. |
| TrackingReference | A cadeia de caracteres de referência exclusiva que identifica uma solicitação atendida pelo Front Door, também enviada como cabeçalho X-Azure-Ref para o cliente. Necessário para pesquisar detalhes nos logs de acesso para uma solicitação específica. |
| UserAgent | O tipo de navegador que o cliente usou. |
| ErrorInfo | Este campo contém o tipo específico de erro para solução de problemas adicionais. Os valores possíveis incluem: NoError: indica que nenhum erro foi encontrado. CertificateError: Erro de certificado SSL genérico. CertificateNameCheckFailed: O nome do host no certificado SSL é inválido ou não corresponde. ClientDisconnected: Falha de solicitação devido à conexão de rede do cliente. UnspecifiedClientError: Erro de cliente genérico. InvalidRequest: Solicitação inválida. Pode ocorrer devido a cabeçalho, corpo e URL malformados. DNSFailure: Falha de DNS. DNSNameNotResolved: Não foi possível resolver o nome ou endereço do servidor. OriginConnectionAborted: A conexão com a origem foi interrompida abruptamente. OriginConnectionError: Erro de conexão de origem genérica. OriginConnectionRefused: A conexão com a origem não pôde ser estabelecida. OriginError: Erro de origem genérico. OriginInvalidResponse: Origin retornou uma resposta inválida ou não reconhecida. OriginTimeout: O período de tempo limite para solicitação de origem expirou. ResponseHeaderTooBig: A origem retornou muito grande de um cabeçalho de resposta. RestrictedIP: A solicitação foi bloqueada devido ao IP restrito. SSLHandshakeError: Não é possível estabelecer conexão com a origem devido a uma falha de aperto de mão SSL. UnspecifiedError: Ocorreu um erro que não se encaixou em nenhum dos erros na tabela. SSLMismatchedSNI: A solicitação era inválida porque o cabeçalho da mensagem HTTP não correspondia ao valor apresentado na extensão SNI TLS durante a configuração da conexão SSL/TLS. |
| Result | SSLMismatchedSNI é um código de status que significa uma solicitação bem-sucedida com um aviso de incompatibilidade entre o SNI e o cabeçalho do host. Esse código de status implica fronting de domínio, uma técnica que viola os termos de serviço do Azure Front Door. Os pedidos com SSLMismatchedSNI serão rejeitados após 22 de janeiro de 2024. |
| Sni | Este campo especifica a Indicação de Nome do Servidor (SNI) que é enviada durante o handshake TLS/SSL. Ele pode ser usado para identificar o valor exato do SNI se houver um código de SSLMismatchedSNI status. Além disso, ele pode ser comparado com o requestUri valor do host no campo para detetar e resolver o problema de incompatibilidade. |
Descontinuação do escudo de origem enviado para a origem
A propriedade de log bruto isSentToOriginShield foi preterida e substituída por um novo campo isReceivedFromClient. Use o novo campo se já estiver usando o campo preterido.
Os logs brutos incluem logs gerados a partir da borda CDN (POP filho) e do escudo de origem. O escudo de origem refere-se a nós pai que estão estrategicamente localizados em todo o mundo. Esses nós se comunicam com os servidores de origem e reduzem a carga de tráfego na origem.
Para cada solicitação que vai para um escudo de origem, há duas entradas de log:
- Um para nós de borda
- Um para escudo de origem.
Para diferenciar a saída ou as respostas dos nós de borda versus escudo de origem, você pode usar o campo isReceivedFromClient para obter os dados corretos.
Se o valor for false, isso significa que a solicitação é respondida do escudo de origem para os nós de borda. Essa abordagem é eficaz para comparar logs brutos com dados de faturamento. As cobranças não são incorridas para a saída do escudo de origem para os nós de borda. Os encargos são incorridos pela saída dos nós de borda para os clientes.
Exemplo de consulta Kusto para excluir logs gerados no escudo de origem no Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Nota
Para várias configurações de roteamento e comportamentos de tráfego, alguns dos campos como backendHostname, cacheStatus, isReceivedFromClient e campo POP podem responder com valores diferentes. A tabela a seguir explica os diferentes valores que esses campos terão para vários cenários:
| Cenários | Contagem de entradas de log | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Regra de roteamento sem cache habilitado | 1 | Código POP de borda | Back-end onde a solicitação foi encaminhada | True | CONFIG_NOCACHE |
| Regra de roteamento com cache habilitado. Cache atingido na borda POP | 1 | Código POP de borda | Vazio | True | HIT |
| Regra de roteamento com cache habilitado. O cache perde no POP de borda, mas o cache é atingido no POP do cache pai | 2 | 1. Código POP de borda 2. Código POP de cache pai |
1. Nome do host POP do cache pai 2. Vazio |
1. Verdadeiro 2. False |
1. MISS 2. HIT |
| Regra de roteamento com cache habilitado. Caches perdidos no POP de borda, mas cache parcial atingido no POP do cache pai | 2 | 1. Código POP de borda 2. Código POP de cache pai |
1. Nome do host POP do cache pai 2. Back-end que ajuda a preencher o cache |
1. Verdadeiro 2. False |
1. MISS 2. PARTIAL_HIT |
| Regra de roteamento com cache habilitado. O cache PARTIAL_HIT no POP de borda, mas o cache é atingido no POP do cache pai | 2 | 1. Código POP de borda 2. Código POP de cache pai |
1. Código POP de borda 2. Código POP de cache pai |
1. Verdadeiro 2. False |
1. PARTIAL_HIT 2. HIT |
| Regra de roteamento com cache habilitado. O cache perde no POP de cache de borda e pai | 2 | 1. Código POP de borda 2. Código POP de cache pai |
1. Código POP de borda 2. Código POP de cache pai |
1. Verdadeiro 2. False |
1. MISS 2. SAUDADES |
| Erro ao processar o pedido | N/A |
Nota
Para cenários de cache, o valor para Status do Cache será partial_hit quando alguns dos bytes de uma solicitação forem atendidos a partir da borda da Porta da Frente do Azure ou do cache do escudo de origem, enquanto alguns dos bytes forem servidos da origem para objetos grandes.
O Azure Front Door usa uma técnica chamada fragmentação de objetos. Quando um arquivo grande é solicitado, o Azure Front Door recupera partes menores do arquivo da origem. Depois que o servidor POP do Azure Front Door recebe um intervalo completo ou de bytes do arquivo solicitado, o servidor de borda do Azure Front Door solicita o arquivo da origem em blocos de 8 MB.
Depois que o bloco chega à borda da Porta da Frente do Azure, ele é armazenado em cache e imediatamente servido ao usuário. Em seguida, a Porta da Frente do Azure pré-busca a próxima parte em paralelo. Essa pré-busca garante que o conteúdo fique um pedaço à frente do usuário, o que reduz a latência. Esse processo continua até que todo o arquivo seja baixado (se solicitado), todos os intervalos de bytes estejam disponíveis (se solicitado) ou o cliente feche a conexão. Para obter mais informações sobre a solicitação de intervalo de bytes, consulte RFC 7233. A Porta da Frente do Azure armazena em cache todas as partes à medida que são recebidas. O arquivo inteiro não precisa ser armazenado em cache no cache da Front Door. As solicitações subsequentes para os intervalos de arquivos ou bytes são atendidas a partir do cache da Porta da Frente do Azure. Se nem todos os blocos forem armazenados em cache na Porta da Frente do Azure, a pré-busca será usada para solicitar blocos da origem. Essa otimização depende da capacidade do servidor de origem de suportar solicitações de intervalo de bytes. Se o servidor de origem não suportar solicitações de intervalo de bytes, essa otimização não será eficaz.