Monitorar o Azure Front Door
O Azure Monitor coleta e agrega métricas e logs do seu sistema para monitorar a disponibilidade, o desempenho e a resiliência e notificá-lo sobre problemas que afetam seu sistema. Você pode usar o portal do Azure, o PowerShell, a CLI do Azure, a API REST ou as bibliotecas de cliente para configurar e exibir dados de monitoramento.
Métricas e logs diferentes estão disponíveis para diferentes tipos de recursos. Este artigo descreve os tipos de dados de monitoramento que você pode coletar para esse serviço e as maneiras de analisar esses dados.
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.
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, consulte Desativação do Azure Front Door (clássico).
Coletar dados com o Azure Monitor
Esta tabela descreve como você pode coletar dados para monitorar seu serviço e o que você pode fazer com os dados depois de coletados:
| Dados a serem coletados | Descrição | Como coletar e rotear os dados | Onde visualizar os dados | Tipos de dados compatíveis |
|---|---|---|---|---|
| Dados de métrica | As métricas são valores numéricos que descrevem um aspecto de um sistema em um ponto específico no tempo. As métricas podem ser agregadas usando algoritmos, comparadas a outras métricas e analisadas quanto a tendências ao longo do tempo. | – Coletados automaticamente a intervalos regulares. – Você pode rotear algumas métricas de plataforma para um workspace do Log Analytics para consultar usando outros dados. Verifique a configuração de exportação para o DS de cada métrica para ver se você pode usar uma configuração de diagnóstico para rotear os dados da métrica. |
Metrics Explorer | Métricas do Azure Front Door compatíveis com o Azure Monitor |
| Dados do log de recursos | Os logs são eventos registrados do sistema com um carimbo de data/hora. Os logs podem conter diferentes tipos de dados e ser texto estruturado ou de forma livre. Você pode rotear dados de log de recursos para workspaces do Log Analytics para consulta e análise. | Crie uma configuração de diagnóstico para coletar e rotear dados de log de recursos. | Log Analytics | Dados de log de recursos do Azure Front Door compatíveis com o Azure Monitor |
| Dados do log de atividades | O log de atividades do Azure Monitor fornece informações sobre eventos no nível da assinatura. O log de atividades inclui informações sobre a alteração de um recurso ou a inicialização de uma máquina virtual. | – Coletados automaticamente. - Crie uma configuração de diagnóstico para um workspace do Log Analytics sem custo. |
Log de atividades |
Para obter a lista de todos os dados compatíveis com o Azure Monitor, consulte:
Monitoramento interno do Azure Front Door
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 o Mecanismo de Regras reescreveu a URL de solicitação, 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.
Para o Azure Front Door clássico, o monitoramento interno inclui logs de diagnóstico.
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 fornecem insights sobre as operações que o seu recurso executa. 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 de certificado SSL genérico. CertificateNameCheckFailed: o nome do host no certificado SSL é inválido ou não corresponde. ClientDisconnected: falha de solicitação devida à conexão de rede do cliente. UnspecifiedClientError: erro genérico de 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 com a origem. OriginConnectionRefused: não foi possível estabelecer a conexão com a origem. OriginError: erro de origem genérica. OriginInvalidResponse: a origem retornou uma resposta inválida ou não reconhecida. OriginTimeout: o tempo limite para a solicitação da origem expirou. ResponseHeaderTooBig: o cabeçalho de resposta da origem é muito grande. RestrictedIP: a solicitação foi bloqueada devido ao IP restrito. SSLHandshakeError: não foi possível estabelecer conexão com a origem por falha de handshake de SSL. UnspecifiedError: ocorreu um erro não correspondente a nenhum dos listados na 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.
Usar as ferramentas do Azure Monitor para analisar os dados
Essas ferramentas do Azure Monitor estão disponíveis no portal do Azure para ajudar você a analisar os dados de monitoramento:
Alguns serviços do Azure têm um painel de monitoramento interno no portal do Azure. Esses painéis são chamados de insights e você pode encontrá-los na seção insights do Azure Monitor no portal do Azure.
Gerenciador de métricas permite exibir e analisar métricas para recursos do Azure. Para obter mais informações sobre essa ferramenta, consulte Analisar métricas com o explorador de métricas do Azure Monitor.
O Log Analytics permite consultar e analisar dados de log usando a KQL (linguagem de consulta Kusto). Para obter mais informações, veja Introdução às consultas de log no Azure Monitor.
O portal do Azure tem uma interface do usuário para exibição e pesquisas básicas do log de atividades. Para fazer uma análise mais aprofundada, roteie os dados para os logs do Azure Monitor e execute consultas mais complexas no Log Analytics.
O Application Insights monitora a disponibilidade, o desempenho e o uso de seus aplicativos Web, para que você possa identificar e diagnosticar erros sem esperar que um usuário os relate. O
Application Insights inclui pontos de conexão com várias ferramentas de desenvolvimento e se integra ao Visual Studio para dar suporte aos seus processos de DevOps. Para obter mais informações, confira Monitoramento de aplicativos do Serviço de Aplicativo.
As ferramentas que permitem uma visualização mais complexa incluem:
- Painéis, que permitem que você combine diferentes tipos de dados em um único painel no portal do Azure.
- Pastas de Trabalho, relatórios personalizáveis que você pode criar no portal do Azure. As pastas de trabalho podem incluir texto, métricas e consultas de log.
- Grafana, uma ferramenta de plataforma aberta que oferece excelência em termos de painéis operacionais. Você pode usar o Grafana para criar painéis que incluem dados de várias fontes além do Azure Monitor.
- Power BI, um serviço de análises corporativas que fornece visualizações interativas nas diversas fontes de dados. Você pode configurar o Power BI para importar dados de log automaticamente do Azure Monitor a fim de aproveitar essas visualizações.
Exportar dados do Azure Monitor
Você pode exportar dados do Azure Monitor para outras ferramentas usando:
Métricas: Use a API REST para métricas para extrair dados de métricas do banco de dados de métricas do Azure Monitor. Para obter mais informações, confira Referência da API REST do Azure Monitor.
Logs: Use a API REST ou as bibliotecas de cliente associadas.
Para começar a usar a API REST do Azure Monitor, confira Passo a passo da API REST de monitoramento do Azure.
Usar consultas Kusto para analisar dados de log
Você pode analisar os dados de log do Azure Monitor usando a linguagem de consulta Kusto (KQL). Para obter mais informações, confira Consultas de log no Azure Monitor.
Usar alertas do Azure Monitor para notificá-lo sobre problemas
Os alertas do Azure Monitor permitem que você identifique e resolva problemas em seu sistema e notifique proativamente quando condições específicas são encontradas em seus dados de monitoramento antes que seus clientes as percebam. Você pode receber alertas sobre qualquer fonte de dados de log ou métrica na plataforma de dados do Azure Monitor. Há tipos diferentes de alertas do Azure Monitor dependendo dos serviços que você está monitorando e dos dados de monitoramento que está coletando. Consulte Escolhendo o tipo certo de regra de alerta.
Para obter exemplos de alertas comuns para recursos do Azure, confira Amostra de consultas de alerta de logs.
Implementando alertas em escala
No caso de alguns serviços, você pode monitorar em larga escala aplicando a mesma regra de alerta de métricas a vários recursos do mesmo tipo que existem na mesma região do Azure. Os Alertas de Linha de Base do Azure Monitor (AMBA) fornecem um método semiautomatizado de implementação de alertas de métrica de plataforma importantes, painéis e diretrizes em escala.
Obter recomendações personalizadas usando o Assistente do Azure
Para alguns serviços, se ocorrerem condições críticas ou alterações iminentes durante operações de recurso, um alerta será exibido na página de Visão geral do serviço no portal. Você pode encontrar mais informações e correções recomendadas para o alerta nas Recomendações do assistente em Monitoramento no menu à esquerda. Durante as operações normais, nenhuma recomendação do assistente será exibida.
Para obter mais informações sobre o Assistente do Azure, confira Visão geral do Assistente do Azure.