Monitorar métricas e logs no Azure Front Door
O Azure Front Door fornece vários recursos para ajudar você a monitorar seu aplicativo, acompanhar solicitações e depurar sua configuração do Front Door.
Os logs e as métricas são armazenados e gerenciados pelo Azure Monitor.
Os relatórios fornecem insights sobre como o tráfego está fluindo por meio do Azure Front Door, do WAF (firewall de aplicativo Web) e para o 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. Por um custo extra, você pode armazenar por um período mais longo.
| Métricas | Descrição | Dimensões | Agregações recomendadas |
|---|---|---|---|
| Índice de ocorrências em bytes | O percentual de tráfego que foi atendido do cache do Azure Front Door, calculado em relação ao tráfego total de saída. A taxa de ocorrências de bytes será baixa se a maior parte do tráfego for encaminhada para a origem em vez de ser atendida do cache. Taxa de acertos de bytes = (saída da borda-saída da origem)/egress da borda. Cenários excluídos dos cálculos da taxa de ocorrências de bytes:
|
Ponto de extremidade | Média, Mínimo |
| Porcentagem de integridade da origem | O percentual de investigações de integridade bem-sucedidas enviadas do Azure Front Door às origens. | Origem, grupo de origem | Avg |
| Latência da 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 | Média, Máximo |
| Contagem de solicitações de origem | O número de solicitações enviadas do Azure Front Door às origens. | Ponto de extremidade, origem, status do HTTP, grupo de status do HTTP | Avg, Sum |
| Porcentagem de 4XX | A porcentagem de todas as solicitações de cliente para as quais o código de status de resposta é 4XX. | Ponto de extremidade, país do cliente, região do cliente | Média, Máximo |
| Porcentagem de 5XX | A porcentagem de todas as solicitações de cliente para as quais o código de status de resposta é 5XX. | Ponto de extremidade, país do cliente, região do cliente | Média, Máximo |
| Contagem de solicitações | O número de solicitações de cliente atendidas por meio do Azure Front Door, incluindo solicitações atendidas inteiramente do cache. | Ponto de extremidade, país do cliente, região do cliente, status do HTTP, grupo de status do HTTP | Avg, Sum |
| Tamanho da solicitação | 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, status do HTTP, grupo de status do HTTP | Média, 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, status do HTTP, grupo de status do HTTP | Média, 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. Esse é o tempo total gasto. Para WebSocket, essa métrica refere-se ao tempo necessário para estabelecer a conexão WebSocket. | Ponto de extremidade, país do cliente, região do cliente, status do HTTP, grupo de status do HTTP | Média, Máximo |
| Contagem de solicitações do Firewall de Aplicativo Web | O número de solicitações processadas pelo firewall de aplicativo Web do Azure Front Door. | Ação, nome da política, nome da regra | Avg, Sum |
Observação
Se uma solicitação para a origem atingir o tempo limite, o valor da dimensão Status Http será 0.
Logs
Os logs acompanham todas as solicitações que passam pelo Azure Front Door. Pode levar alguns minutos para que os logs sejam processados e armazenados.
Há vários logs do Front Door, que você pode usar para diferentes finalidades:
- 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 (firewall de aplicativo Web) podem ser usados para detectar possíveis ataques e detecções de falsos positivos que podem indicar solicitações legítimas que o WAF bloqueou. Para obter mais informações sobre logs do WAF, confira Registro em log e monitoramento do Firewall de Aplicativo Web do Azure.
- Os logs de investigação de integridade podem ser usados para identificar origens nã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 das operações executadas em seus recursos do Azure, como alterações de configuração no perfil do Azure Front Door.
Os logs de acesso e os logs do WAF incluem uma referência de rastreamento, que também é propagada em solicitações para origens e para respostas do cliente usando o cabeçalho X-Azure-Ref. Você pode usar a referência de acompanhamento para obter uma exibição de ponta a ponta do processamento da solicitação de aplicativo.
Os logs de acesso, os logs de investigação de integridade e os logs do WAF não estão habilitados por padrão. Para habilitar e armazenar seus logs de diagnóstico, confira Configurar logs do Azure Front Door. As entradas do log de atividades são coletadas por padrão e podem ser exibidas no portal do Azure.
Log 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.
| Propriedade | Descrição |
|---|---|
| TrackingReference | A cadeia de caracteres de referência exclusiva que identifica uma solicitação atendida pelo Azure Front Door. A referência de acompanhamento é enviada para o cliente e para a origem usando os cabeçalhos X-Azure-Ref. Use a referência de acompanhamento ao pesquisar uma solicitação específica nos logs de acesso ou do WAF. |
| Hora | A data e a hora em que a borda do Azure Front Door forneceu o conteúdo solicitado ao cliente (em UTC). Para conexões WebSocket, o tempo representa quando a conexão é fechada. |
| HttpMethod | Método HTTP usado pela solicitação: DELETE, GET, HEAD, OPTIONS, PATCH, POST ou PUT. |
| HttpVersion | A versão HTTP que o cliente especificou na solicitação. |
| RequestUri | A URI da solicitação recebida. Esse campo contém um esquema, porta, domínio, caminho e cadeia de consulta completos. |
| HostName | O nome do host na solicitação do cliente. Se você habilitar domínios personalizados e tiver um 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 do 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 de solicitação e o corpo da solicitação. Para conexões WebSocket, esse é o número total de bytes enviados do cliente para o servidor por meio da conexão. |
| ResponseBytes | O tamanho da mensagem de resposta HTTP, em bytes. Para conexões WebSocket, esse é o número total de bytes enviados do servidor para o cliente por meio da conexão. |
| UserAgent | O agente do 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 cabeçalho X-Forwarded-For na solicitação, o endereço IP do cliente será escolhido do cabeçalho. |
| SocketIp | O endereço IP da conexão direta à borda do Azure Front Door. Se o cliente usou um proxy HTTP ou um balanceador de carga para enviar a solicitação, o valor de SocketIp será o endereço IP do balanceador de carga ou do proxy. |
| TimeTaken | A duração de quando a borda do Azure Front Door recebeu a solicitação do cliente para quando o último byte da resposta foi enviado ao cliente, medido em segundos. Essa métrica exclui a latência de rede e o buffer TCP. Para conexões WebSocket, ele representa a duração da conexão do estabelecimento ao fechamento. |
| RequestProtocol | 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 o WebSocket terão WS/WSS. |
| SecurityProtocol | A versão do protocolo TLS/SSL usada pela solicitação ou NULL se a solicitação não usou 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 criptografia TLS/SSL negociada pelo cliente e o Azure Front Door. |
| Ponto de extremidade | O nome de domínio do ponto de extremidade do Azure Front Door, como contoso-123.z01.azurefd.net. |
| HttpStatusCode | O código de status HTTP retornado pelo Azure Front Door. No caso de uma solicitação para o tempo limite de origem, o valor do campo HttpStatusCode será 0. Se o cliente fechou a conexão, o valor do campo HttpStatusCode será 499. |
| Pop | O PoP (ponto de presença) da borda do Azure Front Door que respondeu à solicitação do usuário. |
| Status do cache | Como a solicitação foi tratada pelo cache do Azure Front Door. Os valores possíveis são os seguintes:
|
| MatchedRulesSetName | Os nomes das regras do mecanismo de regras que foram processadas. |
| RouteName | O nome da rota correspondente à solicitação. |
| ClientPort | Endereço IP do cliente que fez a solicitação. |
| Referenciador | A URL do site que originou a solicitação. |
| TimetoFirstByte | O período, em segundos, desde quando o Azure Front Door recebeu a solicitação até o momento em que o primeiro byte foi enviado para o cliente, conforme medido pelo Azure Front Door. Essa propriedade não mede os dados do cliente. |
| ErrorInfo | Se ocorreu um erro durante o processamento da solicitação, esse campo fornece informações detalhadas sobre o erro. Os valores possíveis são os seguintes:
|
| OriginURL | A URL completa da origem em que a solicitação foi enviada. A URL é composta por esquema, cabeçalho de host, porta, caminho e cadeia de consulta. Reescrita de URL: se a URL de solicitação foi reescrita pelo mecanismo de regras, o caminho se refere ao caminho reescrito. Cache no PoP de borda: se a solicitação tiver sido atendida do cache do Azure Front Door, a origem será N/D. Solicitação grande: se o conteúdo solicitado for grande com várias solicitações em partes retornando para a origem, esse campo corresponderá à primeira solicitação para a origem. Para obter mais informações, confira Agrupamento de objetos. |
| OriginIP | O endereço IP da origem que atendeu à solicitação. Cache no PoP de borda: se a solicitação tiver sido atendida do cache do Azure Front Door, a origem será N/D. Solicitação grande: se o conteúdo solicitado for grande com várias solicitações em partes retornando para a origem, esse campo corresponderá à primeira solicitação para a origem. Para obter mais informações, confira Agrupamento de objetos. |
| OriginName | O nome do host completo (nome DNS) da origem. Cache no PoP de borda: se a solicitação tiver sido atendida do cache do Azure Front Door, a origem será N/D. Solicitação grande: se o conteúdo solicitado for grande com várias solicitações em partes retornando para a origem, esse campo corresponderá à primeira solicitação para a origem. Para obter mais informações, confira Agrupamento de objetos. |
| Resultado | SSLMismatchedSNI é um código de status que significa uma solicitação bem-sucedida com um aviso incompatível entre a SNI e o cabeçalho de host. Esse código de status implica a frente de domínio, uma técnica que viola os termos de serviço do Azure Front Door. As solicitações com SSLMismatchedSNI serão rejeitadas após 22 de janeiro de 2024. |
| Sni | Esse campo especifica a SNI (Indicação de Nome do Servidor) que é enviada durante o handshake TLS/SSL. Ele pode ser usado para identificar o valor SNI exato se houver um código de status SSLMismatchedSNI. Além disso, ele pode ser comparado com o valor do host no campo requestUri para detectar e resolver o problema de incompatibilidade. |
Log de investigação de integridade
O Azure Front Door registra todas as solicitações de investigação de integridade com falha. Esses logs podem ajudar você 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 para um status de integridade.
Alguns cenários para os quais esse log pode ser útil são:
- Você observou que o tráfego do Azure Front Door foi enviado para um subconjunto das origens. Por exemplo, talvez você tenha notado que apenas três em cada quatro origens recebem tráfego. Você deseja saber se as origens estão recebendo e respondendo a investigações de integridade para saber se as origens estão íntegras.
- Você observou que a métrica de percentual de integridade da origem é menor do que o esperado. Você deseja saber quais origens são registradas como não íntegras e o motivo das falhas de investigação de integridade.
Cada entrada de log de investigação de integridade tem o seguinte esquema:
| Propriedade | Descrição |
|---|---|
| HealthProbeId | Uma ID exclusiva para identificar a solicitação de investigação de integridade. |
| Hora | A data e a hora em que a investigação de integridade foi enviada (em UTC). |
| HttpMethod | O método HTTP usado pela solicitação de investigação de integridade. Os valores incluem GET e HEAD com base nas configurações de investigação de integridade. |
| Result | O status da investigação de integridade. O valor é êxito ou uma descrição do erro que a investigação recebeu. |
| HttpStatusCode | O código de status HTTP retornado da origem. |
| ProbeURL | A URL de destino completa para onde a solicitação de investigação foi enviada. A URL é composta por esquema, cabeçalho de host, caminho e cadeia de consulta. |
| OriginName | O nome da origem para a qual a investigação de integridade foi enviada. Esse campo ajuda a localizar origens de interesse se a origem estiver configurada para usar um FQDN. |
| POP | O PoP da borda que enviou a solicitação de investigação. |
| IP de Origem | O endereço IP da origem para a qual a investigação de integridade foi enviada. |
| TotalLatency | A hora em que a borda do Azure Front Door enviou a solicitação de investigação de integridade para a origem para quando a origem enviou a última resposta ao Azure Front Door. |
| ConnectionLatency | O tempo de duração gasto na configuração da conexão TCP para enviar a solicitação de investigação de HTTP para a origem. |
| Latência de DNSResolution | O tempo gasto na resolução DNS. Esse campo só tem valor se a origem estiver configurada para ser um FQDN em vez de um endereço IP. Se a origem estiver configurada para usar um endereço IP, o valor será N/D. |
O snippet JSON de exemplo a seguir mostra uma entrada de log de investigação de integridade para uma solicitação de investigação 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 de Aplicativo Web
Para obter mais informações sobre os logs do WAF (firewall de aplicativo Web) do Front Door, confira Registro em log e monitoramento do Firewall de Aplicativo Web do Azure.
Logs de atividades
Os logs de atividade fornecem informações sobre as operações de gerenciamento realizadas em seus recursos do Azure Front Door. Os logs incluem detalhes sobre cada operação de gravação executada em um recurso do Azure Front Door, incluindo quando a operação ocorreu, quem a executou e qual foi a operação.
Observação
Os logs de atividades não incluem operações de leitura. Também não incluem todas as operações que você executa usando o portal do Azure ou as APIs de gerenciamento clássicas.
Para obter mais informações, confira Exibir logs de atividades.
Próximas etapas
Para habilitar e armazenar seus logs de diagnóstico, confira Configurar logs do Azure Front Door.
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 que você migre 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, veja Desativação do Azure Front Door (clássico).
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 exibição de contadores de desempenho.
- Logs. Os logs de atividade e diagnóstico permitem que dados sobre desempenho, acesso e outros sejam salvos ou consumidos de um recurso para fins de monitoramento.
Métricas
Métricas são um recurso usado em alguns componentes do Azure para exibir contadores de desempenho no portal. Estas são as métricas do Front Door disponíveis:
| Métrica | Nome de exibição da métrica | Unidade | Dimensões | Descrição |
|---|---|---|---|---|
| RequestCount | Contagem de solicitações | Contagem | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
O número de solicitações de cliente atendidas pelo Front Door. |
| RequestSize | Tamanho da solicitação | 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 |
Tempo total da solicitação do cliente recebida pelo Front Door até o último byte de resposta enviado do AFD ao cliente. |
| BackendRequestCount | Contagem de solicitações de back-end | Contagem | HttpStatus HttpStatusGroup Backend |
O número de solicitações enviadas do Front Door aos back-ends. |
| BackendRequestLatency | Latência de solicitação de back-end | Milissegundos | Back-end | O tempo calculado de quando a solicitação foi enviada pelo Front Door ao back-end até o Front Door receber o último byte de resposta do back-end. |
| BackendHealthPercentage | Percentual de integridade do back-end | Porcentagem | Backend BackendPool |
O percentual de investigações de integridade bem-sucedidas do Front Door aos back-ends. |
| WebApplicationFirewallRequestCount | Contagem de solicitações do Firewall de Aplicativo Web | Contagem | PolicyName RuleName Action |
O número de solicitações de cliente processadas pela segurança da camada de aplicativo do Front Door. |
Logs de atividades
Os logs de atividade fornecem informações sobre as operações realizadas em um perfil do Azure Front Door (clássico). Eles também determinam o que, quem e quando executou as operações de gravação (put, post ou delete) realizada em um perfil do Azure Front Door (clássico).
Observação
No caso de uma solicitação para o tempo limite de origem, o valor de HttpStatusCode será definido como 0.
Acesse os logs de atividades no seu Front Door, ou todos os logs dos seus recursos do Azure no Azure Monitor. Para exibir logs de atividade:
Selecione sua instância do Front Door.
Selecione Log de atividades.
Escolha um escopo de filtragem e selecione Aplicar.
Observação
O log de atividades não inclui as operações GET nem as operações executadas usando o portal do Azure ou a API de Gerenciamento original.
Logs de diagnóstico
Os logs de diagnóstico fornecem informações avançadas sobre operações e erros importantes para auditoria e solução de problemas. Os logs de diagnóstico diferem dos logs de atividades.
Os logs de atividades informam sobre operações realizadas em recursos do Azure. Os logs de diagnóstico informam sobre operações que o seu recurso executou. Para obter mais informações, consulte Logs de diagnóstico do Azure Monitor.
Para configurar logs de diagnóstico para o Azure Front Door (clássico):
Selecione o perfil do Azure Front Door (clássico).
Selecione Configurações de diagnóstico.
Selecione Ativar diagnóstico. Você pode arquivar logs de diagnóstico junto com métricas em uma conta de armazenamento, transmiti-los para um hub de eventos ou enviá-los para logs do Azure Monitor.
Atualmente, o Front Door fornece logs de diagnóstico. Os logs de diagnóstico fornecem solicitações de API individuais com cada entrada, com o seguinte esquema:
| Propriedade | Descrição |
|---|---|
| BackendHostname | Se a solicitação tiver sido 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 | Em cenários de cache, esse campo define a ocorrência/perda do cache no POP |
| ClientIp | 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á colhido dele. |
| ClientPort | Endereço IP do cliente que fez a solicitação. |
| HttpMethod | Método HTTP usado pela solicitação. |
| HttpStatusCode | O código de status HTTP retornado do proxy. No caso de uma solicitação para o tempo limite de origem, o valor de 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. |
| HttpVersion | O tipo da conexão ou solicitação. |
| POP | Nome curto da borda onde a solicitação foi entregue. |
| RequestBytes | O tamanho da mensagem de solicitação HTTP em bytes, incluindo os cabeçalhos de solicitação e o corpo da solicitação. |
| RequestUri | URI da solicitação recebida. |
| ResponseBytes | Bytes enviados pelo servidor de back-end como a resposta. |
| RoutingRuleName | Nome da regra de roteamento com a qual a solicitação foi correspondida. |
| RulesEngineMatchNames | Nomes das regras às quais a solicitação correspondeu. |
| SecurityProtocol | A versão do protocolo TLS/SSL usada pela solicitação ou NULL se não houver criptografia. |
| SentToOriginShield (preterido) * Consulte as observações sobre reprovação na próxima seção. |
Se for verdadeiro, significa que a solicitação foi respondida do cache da blindagem de origem em vez do pop de borda. A blindagem de origem é um cache pai usado para melhorar a taxa de acertos do cache. |
| isReceivedFromClient | Se for verdadeiro, significa que a solicitação veio do cliente. Se for falso, significa que a solicitação é uma perda na borda (POP filho), respondida na blindagem de origem (POP pai). |
| TimeTaken | O período em segundos do primeiro byte de solicitação no Front Door ao último byte de resposta. |
| TrackingReference | A cadeia de caracteres de referência exclusiva que identifica uma solicitação atendida pela Front Door, também enviada como o 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 | Esse campo contém o tipo específico de erro para solução de problemas. Os valores possíveis incluem: NoError: indica que nenhum erro foi encontrado. CertificateError: erro genérico de certificado SSL. CertificateNameCheckFailed: o nome do host no certificado SSL é inválido ou não corresponde. ClientDisconnected: Falha na solicitação devido à conexão de rede do cliente. UnspecifiedClientError: erro genérico do cliente. InvalidRequest: Solicitação inválida. Pode ocorrer devido a erros de cabeçalho, corpo e URL. 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 genérico de conexão de origem. OriginConnectionRefused: A conexão com a origem não foi possível estabelecer. OriginError: Erro de origem genérico. OriginInvalidResponse: O 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 um cabeçalho de resposta muito grande. RestrictedIP: A solicitação foi bloqueada devido a IP restrito. SSLHandshakeError: Não foi possível estabelecer conexão com a origem devido a falha no handshake SSL. UnspecifiedError: Ocorreu um erro que não se encaixa em nenhum dos erros da tabela. SSLMismatchedSNI: A solicitação foi inválida porque o cabeçalho da mensagem HTTP não correspondia ao valor apresentado na extensão TLS SNI durante a configuração da conexão SSL/TLS. |
| Resultado | SSLMismatchedSNI é um código de status que significa uma solicitação bem-sucedida com um aviso incompatível entre a SNI e o cabeçalho de host. Esse código de status implica a frente de domínio, uma técnica que viola os termos de serviço do Azure Front Door. As solicitações com SSLMismatchedSNI serão rejeitadas após 22 de janeiro de 2024. |
| Sni | Esse campo especifica a SNI (Indicação de Nome do Servidor) que é enviada durante o handshake TLS/SSL. Ele pode ser usado para identificar o valor SNI exato se houver um código de status SSLMismatchedSNI. Além disso, ele pode ser comparado com o valor do host no campo requestUri para detectar e resolver o problema de incompatibilidade. |
Enviado para reprovação na blindagem de origem
A propriedade de log bruto isSentToOriginShield foi preterida e substituída por um novo campo isReceivedFromClient. Use o novo campo se você já estiver usando o campo preterido.
Os logs brutos incluem logs gerados da borda da CDN (POP filho) e da blindagem de origem. A blindagem de origem se refere a nós pai estrategicamente localizados em todo o mundo. Esses nós se comunicam com servidores de origem e reduzem a carga de tráfego na origem.
Para cada solicitação que vai para uma blindagem de origem, há duas entradas de log:
- Uma para nós de borda
- Uma para a blindagem de origem.
Para estabelecer a diferença entre a saída ou as respostas dos nós de borda e a blindagem de origem, é possível usar o campo isReceivedFromClient para obter os dados corretos.
Se o valor for falso, significa que a solicitação é respondida na blindagem de origem para nós de borda. Essa abordagem é eficaz para comparar logs brutos com dados de cobrança. Não há encargos para a saída da blindagem de origem para os nós de borda. Há encargos para a saída dos nós de borda para os clientes.
Exemplo de consulta Kusto para exclusão de logs gerados na blindagem de origem no Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Observação
Em várias configurações de roteamento e comportamentos de tráfego, alguns campos como backendHostname, cacheStatus, isReceivedFromClient e POP podem responder com valores diferentes. A seguinte tabela explica os diferentes valores desses campos em vários cenários:
| Cenários | Contagem de entradas de log | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Regra de roteamento sem cache habilitado | 1 | Código do POP de borda | Back-end no qual a solicitação foi encaminhada | Verdadeiro | CONFIG_NOCACHE |
| Regra de roteamento com cache habilitado. Ocorrência no cache no POP de borda | 1 | Código do POP de borda | Vazio | Verdadeiro | HIT |
| Regra de roteamento com cache habilitado. Perdas de cache no POP de borda, mas acesso ao cache no POP do cache pai | 2 | 1. Código do POP de borda 2. Código POP do cache pai |
1. Nome do host POP do cache pai 2. Vazio |
1. True 2. Falso |
1. MISS 2. HIT |
| Regra de roteamento com cache habilitado. Perda de cache no POP de borda, mas acesso PARTIAL ao cache no POP do cache pai | 2 | 1. Código do POP de borda 2. Código POP do cache pai |
1. Nome do host POP do cache pai 2. 2. Back-end que ajuda a preencher o cache |
1. True 2. Falso |
1. MISS 2. PARTIAL_HIT |
| Regra de roteamento com cache habilitado. PARTIAL_HIT do cache no POP de borda, mas acesso ao cache no POP do cache pai | 2 | 1. Código do POP de borda 2. Código POP do cache pai |
1. Código do POP de borda 2. Código POP do cache pai |
1. True 2. Falso |
1. PARTIAL_HIT 2. HIT |
| Regra de roteamento com cache habilitado. Perdas de cache no POP de borda e do cache pai | 2 | 1. Código do POP de borda 2. Código POP do cache pai |
1. Código do POP de borda 2. Código POP do cache pai |
1. True 2. Falso |
1. MISS 2. MISS |
| Erro ao processar a solicitação | N/D |
Observação
Em cenários de cache, o valor de Status do Cache será partial_hit quando alguns dos bytes de uma solicitação forem atendidos no cache de borda ou de blindagem de origem do Azure Front Door e outros na origem para objetos grandes.
O Azure Front Door usa uma técnica chamada agrupamento de objeto. Quando um arquivo grande é solicitado, o Azure Front Door recupera partes menores desse arquivo na 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 partes de 8 MB.
Depois que a parte chega à borda do Azure Front Door, é armazenada em cache e imediatamente disponibilizada para o usuário. Em seguida, o Azure Front Door executa uma pré-busca da próxima parte em paralelo. Essa pré-busca garante que o conteúdo permaneça uma parte à 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 encerre a conexão. Para obter mais informações sobre a solicitação de intervalo de bytes, consulte RFC 7233. O Azure Front Door armazena em cache todas as partes conforme são recebidas. Não é preciso armazenar o arquivo inteiro no cache do Front Door. As solicitações subsequentes para o arquivo ou intervalos de bytes são disponibilizadas pelo cache do Azure Front Door. Se nem todas as partes forem armazenadas em cache no Azure Front Door, será usada uma pré-busca para solicitar as partes na origem. Essa otimização se baseia na capacidade do servidor de origem de dar suporte a solicitações de intervalo de bytes. Se o servidor de origem não dá suporte a solicitações de intervalo de bytes, essa otimização não é eficaz.