Monitorar o Azure Front Door
O Azure Monitor recolhe e agrega métricas e registos do seu sistema para monitorizar a disponibilidade, o desempenho e a resiliência e notificá-lo de problemas que afetam o seu sistema. Você pode usar o portal do Azure, PowerShell, CLI do Azure, API REST ou bibliotecas de cliente para configurar e exibir dados de monitoramento.
Diferentes métricas e logs 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 maneiras de analisar esses dados.
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.
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.
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 recolher | Description | Como recolher e encaminhar os dados | Onde visualizar os dados | Dados suportados |
|---|---|---|---|---|
| Dados métricos | As métricas são valores numéricos que descrevem um aspeto de um sistema em um determinado momento. As métricas podem ser agregadas usando algoritmos, em comparação com outras métricas, e analisadas quanto às tendências ao longo do tempo. | - Recolhido automaticamente a intervalos regulares. - Você pode rotear algumas métricas da plataforma para um espaço de trabalho do Log Analytics para consultar outros dados. Verifique a configuração de exportação DS para cada métrica para ver se você pode usar uma configuração de diagnóstico para rotear os dados da métrica. |
Explorador de métricas | Métricas do Azure Front Door suportadas pelo Azure Monitor |
| Dados do log de recursos | Os logs são eventos do sistema gravados 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 espaços de trabalho 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 suportados pelo Azure Monitor |
| Dados do registo de atividades | O log de atividades do Azure Monitor fornece informações sobre eventos no nível de assinatura. O registo de atividades inclui informações como quando um recurso é modificado ou uma máquina virtual é iniciada. | - Recolhido automaticamente. - Crie uma configuração de diagnóstico para um espaço de trabalho do Log Analytics gratuitamente. |
Registo de atividades |
Para obter a lista de todos os dados suportados pelo Azure Monitor, consulte:
Monitoramento interno para o Azure Front Door
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, esse valor é 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 valor é o número total de bytes enviados do servidor para o cliente por meio 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 atualizam com êxito para WebSocket têm 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 o cache da Porta da Frente do Azure lida com a solicitação. 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 o mecanismo de regras reescrever a URL de solicitação, 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ê pode notar 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 FQDN. |
| 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 FQDN 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.
Para o Azure Front Door clássico, o monitoramento interno inclui logs de diagnóstico.
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 faz. 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 têm 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 é um PARTIAL_HIT quando alguns dos bytes de uma solicitação são servidos da borda da Porta da Frente do Azure ou do cache do escudo de origem, enquanto alguns dos bytes são 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.
Usar as ferramentas do Azure Monitor para analisar os dados
Estas ferramentas do Azure Monitor estão disponíveis no portal do Azure para ajudá-lo a analisar 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.
O explorador de métricas permite que você exiba e analise métricas para recursos do Azure. Para obter mais informações, 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 linguagem de consulta Kusto (KQL). Para obter mais informações, consulte Introdução às consultas de log no Azure Monitor.
O portal do Azure tem uma interface de usuário para exibição e pesquisas básicas do log de atividades. Para fazer uma análise mais aprofundada, encaminhe 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 para várias ferramentas de desenvolvimento e integra-se ao Visual Studio para dar suporte aos seus processos de DevOps. Para obter mais informações, consulte Monitoramento de aplicativos para o Serviço de Aplicativo.
As ferramentas que permitem uma visualização mais complexa incluem:
- Painéis que permitem combinar 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 se destaca em dashboards operacionais. Você pode usar o Grafana para criar painéis que incluem dados de várias fontes diferentes do Azure Monitor.
- Power BI, um serviço de análise de negócios que fornece visualizações interativas em várias fontes de dados. Você pode configurar o Power BI para importar automaticamente dados de log do Azure Monitor para 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, consulte Referência da API REST do Azure Monitor.
Logs: use a API REST ou as bibliotecas de cliente associadas.
A exportação de dados do espaço de trabalho do Log Analytics.
Para começar a usar a API REST do Azure Monitor, consulte Passo a passo da API REST de monitoramento do Azure.
Usar consultas Kusto para analisar dados de log
Você pode analisar os dados do Log do Azure Monitor usando a linguagem de consulta Kusto (KQL). Para obter mais informações, consulte Registrar consultas no Azure Monitor.
Usar alertas do Azure Monitor para notificá-lo sobre problemas
Os alertas do Azure Monitor permitem-lhe identificar e resolver problemas no seu sistema e notificá-lo proativamente quando são encontradas condições específicas nos seus dados de monitorização antes que os seus clientes as percebam. Você pode alertar sobre qualquer fonte de dados de métrica ou log na plataforma de dados do Azure Monitor. Há diferentes tipos de alertas do Azure Monitor, dependendo dos serviços que você está monitorando e dos dados de monitoramento que você está coletando. Consulte Escolher o tipo correto de regra de alerta.
Para obter exemplos de alertas comuns para recursos do Azure, consulte Consultas de alerta de log de exemplo.
Implementação de alertas em escala
Para alguns serviços, você pode monitorar em escala aplicando a mesma regra de alerta de métrica 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 métricos de plataforma importantes, painéis e diretrizes em escala.
Obtenha recomendações personalizadas usando o Azure Advisor
Para alguns serviços, se ocorrerem condições críticas ou alterações iminentes durante as operações de recursos, será exibido um alerta na página Visão geral do serviço no portal. Você pode encontrar mais informações e correções recomendadas para o alerta em Recomendações do Advisor em Monitoramento no menu à esquerda. Durante as operações normais, nenhuma recomendação do consultor é exibida.
Para obter mais informações sobre o Azure Advisor, consulte Visão geral do Azure Advisor.