Surveiller Azure Front Door
Azure Monitor collecte et agrège les métriques et les journaux d’activité de votre système pour surveiller la disponibilité, les performances et la résilience, et vous avertir des problèmes affectant votre système. Vous pouvez utiliser le portail Azure, PowerShell, Azure CLI, l’API REST ou des bibliothèques de client pour configurer et visualiser les données de monitoring.
Différentes métriques et journaux sont disponibles pour les différents types de ressource. Cet article décrit les types de données de surveillance que vous pouvez collecter pour ce service et les moyens d’analyser ces données.
Les rapports fournissent des informations sur la façon dont votre trafic transite par Azure Front Door et le pare-feu d’applications web (WAF) jusqu’à votre application.
Important
Azure Front Door (classique) va être mis hors service le 31 mars 2027. Pour éviter toute interruption de service, il est important de migrer vos profils Azure Front Door (classique) vers le niveau Azure Front Door Standard ou Premium au plus en mars 2027. Pour plus d’informations, consultez Mise hors service d’Azure Front Door (classique).
Collecter des données avec Azure Monitor
Ce tableau décrit comment collecter des données pour surveiller votre service et ce que vous pouvez faire avec les données une fois collectées :
| Données à collecter | Description | Comment collecter et acheminer les données | Où visualiser les données | Données prises en charge |
|---|---|---|---|---|
| Données métriques | Les métriques sont des valeurs numériques décrivant un aspect d’un système à un moment précis dans le temps. Les métriques peuvent être agrégées à l’aide d’algorithmes, comparées à d’autres métriques et analysées afin de révéler des tendances au fil du temps. | - Collectées automatiquement à intervalles réguliers. - Vous pouvez acheminer certaines métriques de la plateforme vers un espace de travail Log Analytics pour les interroger avec d'autres données. Vérifiez le paramètre d’exportation DS de chaque métrique pour voir si vous pouvez utiliser un paramètre de diagnostic pour acheminer les données de métriques. |
Metrics Explorer | Métriques Azure Front Door prises en charge par Azure Monitor |
| Données du journal des ressources | Les journaux d’activité sont des événements système enregistrés avec un horodatage. Les journaux peuvent contenir différents types de données et être du texte structuré ou de forme libre. Vous pouvez acheminer des données de journaux de ressources vers des espaces de travail Log Analytics à des fins d’interrogation et d’analyse. | Créez un paramètre de diagnostic pour collecter et acheminer les données du journal des ressources. | Log Analytics | Données du journal des ressources Azure Front Door prises en charge par Azure Monitor |
| Données du journal d'activité | Le journal d’activité Azure Monitor fournit des insights sur les événements de niveau abonnement. Le journal d’activité inclut des informations telles que le moment auquel une ressource a été modifiée ou une machine virtuelle démarrée. | - Collectées automatiquement. - Créez un paramètre de diagnostic pour un espace de travail Log Analytics sans frais. |
Journal d’activité |
Pour obtenir la liste de toutes les données prises en charge par Azure Monitor, consultez :
- Métriques prises en charge par Azure Monitor
- Journaux de ressources pris en charge par Azure Monitor
Surveillance intégrée pour Azure Front Door
Les journaux suivent toutes les requêtes qui passent par Azure Front Door. Le traitement et le stockage des journaux peuvent prendre quelques minutes.
Il existe plusieurs journaux Front Door, que vous pouvez utiliser à différentes fins :
- Les journaux d’accès peuvent être utilisés pour identifier les requêtes lentes, déterminer les taux d’erreur et comprendre la manière dont le comportement de mise en cache de Front Door fonctionne pour votre solution.
- Les journaux du pare-feu d’applications web (WAF) peuvent être utilisés pour détecter les attaques potentielles et les faux positifs susceptibles d’indiquer des requêtes légitimes que le WAF a bloquées. Pour plus d’informations sur les journaux du WAF, consultez Monitoring et journalisation d’Azure Web Application Firewall.
- Les journaux de sonde d’intégrité peuvent être utilisés pour identifier les origines qui ne sont pas saines ou qui ne répondent pas aux requêtes provenant de certains points de présence distribués géographiquement de Front Door.
- Les journaux d’activité fournissent une visibilité sur les opérations effectuées sur vos ressources Azure, comme les modifications de configuration apportées à votre profil Azure Front Door.
Le journal d’accès et le journal WAF incluent une référence de suivi, qui est également propagée dans les requêtes aux origines et aux réponses du client à l’aide de l’en-tête X-Azure-Ref. Vous pouvez utiliser la référence de suivi pour obtenir une vue de bout en bout du traitement des requêtes de votre application.
Les journaux d’accès, de sonde d’intégrité et du WAF ne sont pas activés par défaut. Pour activer et stocker vos journaux de diagnostic, consultez Configurer les journaux Azure Front Door. Les entrées du journal d’activité sont recueillies par défaut et vous pouvez les afficher dans le Portail Azure.
Journal d’accès
Les informations relatives à chaque requête sont consignées dans le journal d’accès. Chaque entrée du journal d’accès contient les informations listées dans le tableau suivant.
| Propriété | Description |
|---|---|
| TrackingReference | Chaîne de référence unique qui identifie une requête prise en charge par Azure Front Door. La référence de suivi est envoyée au client et à l’origine à l’aide des en-têtes X-Azure-Ref. Utilisez la référence de suivi lors de la recherche d’une requête spécifique dans les journaux d’accès ou du WAF. |
| Temps | Date et heure (UTC) de distribution du contenu demandé au client par la périphérie Azure Front Door. Pour les connexions WebSocket, l'heure représente le moment où la connexion est fermée. |
| HttpMethod | Méthode HTTP utilisée par la requête : DELETE, GET, HEAD, OPTIONS, PATCH, POST ou PUT. |
| HttpVersion | Version HTTP spécifiée par le client dans la requête. |
| RequestUri | URI de la requête reçue. Ce champ se compose du schéma, du port, du domaine, du chemin et de la chaîne de requête. |
| HostName | Nom d’hôte dans la requête du client. Si vous activez des domaines personnalisés et que vous avez un domaine générique (*.contoso.com), la valeur du champ de journal HostName est subdomain-from-client-request.contoso.com. Si vous utilisez le domaine Azure Front Door (contoso-123.z01.azurefd.net), la valeur du champ de journal HostName est contoso-123.z01.azurefd.net. |
| RequestBytes | Taille du message de requête HTTP en octets, en-têtes de requête et corps de requête compris. Pour les connexions WebSocket, cette valeur est le nombre total d'octets envoyés du client au serveur via la connexion. |
| ResponseBytes | Taille du message de réponse HTTP en octets. Pour les connexions WebSocket, cette valeur est le nombre total d'octets envoyés du serveur au client via la connexion. |
| UserAgent | Agent utilisateur utilisé par le client. En règle générale, l’agent utilisateur identifie le type de navigateur. |
| ClientIp | Adresse IP du client à l’origine de la requête. S’il l’en-tête X-Forwarded-For figurait dans la requête, alors l’adresse IP du client est extraite de l’en-tête. |
| SocketIp | Adresse IP de la connexion directe à la périphérie Azure Front Door. Si le client a utilisé un proxy HTTP ou un équilibreur de charge pour envoyer la requête, la valeur de SocketIp est l’adresse IP du proxy ou de l’équilibreur de charge. |
| TimeTaken | Durée entre le moment où le périphérique Azure Front Door a reçu la demande du client et le moment où le dernier octet de la réponse a été envoyé au client, mesurée en secondes. Cette mesure exclut la latence du réseau et la mise en mémoire tampon TCP. Pour les connexions WebSocket, il représente la durée de la connexion depuis l'établissement jusqu'à la fermeture. |
| RequestProtocol | Le protocole spécifié par le client dans la demande. Les valeurs possibles sont : HTTP, HTTPS. Pour WebSocket, les protocoles sont WS, WSS. Seules les requêtes mises à niveau avec succès vers WebSocket ont WS/WSS. |
| SecurityProtocol | Version du protocole TLS/SSL utilisée par la requête, ou Null si la requête n’a pas utilisé de chiffrement. Les valeurs possibles sont : SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
| SecurityCipher | Quand le protocole de la requête a la valeur HTTPS, ce champ indique le chiffrement TLS/SSL négocié par le client et Azure Front Door. |
| Point de terminaison | Nom de domaine du point de terminaison Azure Front Door, comme contoso-123.z01.azurefd.net. |
| HttpStatusCode | Code d’état HTTP retourné par Azure Front Door. Si la requête à l’origine a expiré, la valeur du champ HttpStatusCode est 0. Si le client a fermé la connexion, la valeur du champ HttpStatusCode est 499. |
| Pop | Point de présence (PoP) de la périphérie Azure Front Door qui a répondu à la requête de l’utilisateur. |
| Cache Status | Comment le cache Azure Front Door gère la requête. Les valeurs possibles sont les suivantes :
|
| MatchedRulesSetName | Noms des règles du moteur de règles qui ont été traitées. |
| RouteName | Nom de la route à laquelle correspond la requête. |
| ClientPort | Adresse IP du port du client qui a effectué la requête. |
| Referrer | URL du site à l’origine de la requête. |
| TimetoFirstByte | Temps, en secondes, entre le moment auquel la périphérie Azure Front Door a reçu la requête et le moment auquel le premier octet a été envoyé au client, comme mesuré par Azure Front Door. Cette propriété ne mesure pas les données clientes. |
| ErrorInfo | Si une erreur s’est produite pendant le traitement de la requête, ce champ fournit des informations détaillées sur l’erreur. Les valeurs possibles sont les suivantes :
|
| OriginURL | URL complète de l’origine où la requête a été envoyée. L’URL se compose du schéma, de l’en-tête de l’hôte, du port, du chemin et de la chaîne de requête. Réécriture d’URL : si le moteur de règles réécrit l'URL de la demande, le chemin d'accès fait référence au chemin d'accès réécrit. Cache sur PoP de périphérie : Si la requête a été servie à partir du cache Azure Front Door, l’origine est N/A. Grande requête : Si le contenu demandé est volumineux et que plusieurs requêtes segmentées retournent à l’origine, ce champ correspond à la première requête destinée à l’origine. Pour plus d’informations, consultez Segmentation des objets. |
| OriginIP | Adresse IP de l’origine qui a servi la requête. Cache sur PoP de périphérie : Si la requête a été servie à partir du cache Azure Front Door, l’origine est N/A. Grande requête : Si le contenu demandé est volumineux et que plusieurs requêtes segmentées retournent à l’origine, ce champ correspond à la première requête destinée à l’origine. Pour plus d’informations, consultez Segmentation des objets. |
| OriginName | Nom d’hôte complet (nom DNS) de l’origine. Cache sur PoP de périphérie : Si la requête a été servie à partir du cache Azure Front Door, l’origine est N/A. Grande requête : Si le contenu demandé est volumineux et que plusieurs requêtes segmentées retournent à l’origine, ce champ correspond à la première requête destinée à l’origine. Pour plus d’informations, consultez Segmentation des objets. |
| Result |
SSLMismatchedSNI est un code d’état impliquant la réussite d’une requête avec un avertissement d’incompatibilité entre l’Indication du nom du serveur (SNI) et l’en-tête de l’hôte. Ce code d’état implique une utilisation de domaine-écran, une technique qui enfreint les conditions d’utilisation du service Azure Front Door. Les requêtes avec SSLMismatchedSNI lesquelles elles seront rejetées après le 22 janvier 2024. |
| Sni | Ce champ spécifie l’indication de nom du serveur (SNI) envoyée lors de l’établissement d’une liaison TLS/SSL. Il peut être utilisé pour identifier la valeur SNI exacte s’il existe un code d’état SSLMismatchedSNI. En outre, il peut être comparé à la valeur de l’hôte dans le champ requestUri pour détecter et résoudre le problème d’incompatibilité. |
Journal des sondes d’intégrité
Azure Front Door journalise chaque requête de sonde d’intégrité ayant échoué. Ces journaux peuvent vous aider à diagnostiquer les problèmes liés à une origine. Les journaux vous fournissent des informations que vous pouvez utiliser pour examiner la raison de l’échec, puis ramener l’origine à un état sain.
Ils peuvent être utiles dans une diversité de scénarios, notamment :
- Vous avez remarqué que le trafic Azure Front Door est envoyé à un sous-ensemble des origines. Par exemple, vous remarquerez peut-être que seules trois origines sur quatre reçoivent du trafic. Vous voulez savoir si les origines reçoivent les sondes d’intégrité et y répondent afin de déterminer si les origines sont saines.
- Vous avez remarqué que la métrique du pourcentage d’intégrité de l’origine est inférieure à ce que vous attendiez. Vous voulez savoir quelles origines sont enregistrées comme étant non saines et la raison des échecs de la sonde d’intégrité.
Chaque entrée du journal de sonde d’intégrité présente le schéma suivant :
| Propriété | Description |
|---|---|
| HealthProbeId | ID unique permettant d’identifier la requête de sonde d’intégrité. |
| Temps | Date et heure (UTC) d’envoi de la sonde d’intégrité. |
| HttpMethod | Méthode HTTP utilisée par la requête de sonde d’intégrité. Les valeurs peuvent être GET ou HEAD selon les configurations de la sonde d’intégrité. |
| Résultat | État de la sonde d’intégrité. La valeur est réussite ou une description de l’erreur reçue par la sonde. |
| HttpStatusCode | Code d’état HTTP retourné par l’origine. |
| ProbeURL | URL cible complète vers laquelle la requête de sonde a été envoyée. L’URL se compose du schéma, de l’en-tête de l’hôte, du chemin et de la chaîne de requête. |
| OriginName | Nom de l’origine à laquelle la sonde d’intégrité a été envoyée. Ce champ vous permet de localiser les origines concernées si l’origine est configurée pour utiliser un nom de domaine complet. |
| POP | PoP de périphérie qui a envoyé la requête de sonde. |
| Adresse IP d’origine | Adresse IP de l’origine à laquelle la sonde d’intégrité a été envoyée. |
| TotalLatency | Temps entre le moment auquel la périphérie Azure Front Door a envoyé la requête de sonde d’intégrité à l’origine et le moment auquel l’origine a envoyé la dernière réponse à Azure Front Door. |
| ConnectionLatency | Temps passé à configurer la connexion TCP pour envoyer la requête de sonde HTTP à l’origine. |
| DNSResolution Latency | Temps passé à la résolution DNS. Ce champ a une valeur uniquement si l’origine est configurée pour être un nom de domaine complet au lieu d’une adresse IP. Si l’origine est configurée pour utiliser une adresse IP, la valeur est N/A. |
L’exemple d’extrait de code JSON suivant montre une entrée de journal de sonde d’intégrité pour une requête de sonde d’intégrité qui a échoué.
{
"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"
}
}
]
}
Journal du pare-feu d’applications web
Pour plus d’informations sur les journaux du pare-feu d’applications web (WAF) Front Door, consultez Monitoring et journalisation d’Azure Web Application Firewall.
Pour azure Front Door classique, la supervision intégrée inclut les journaux de diagnostic.
Journaux de diagnostic
Les journaux de diagnostic offrent des informations détaillées sur les opérations et erreurs qui sont importantes pour l’audit et le dépannage. Les journaux de diagnostic diffèrent des journaux d’activité.
Les journaux d’activité fournissent des informations détaillées sur les opérations effectuées sur des ressources Azure. Les journaux de diagnostic fournissent des informations détaillées sur les opérations effectuées par votre ressource. Pour plus d’informations, consultez Journaux de diagnostic Azure Monitor.
Pour configurer les journaux de diagnostic pour votre service Azure Front Door (classique) :
Sélectionnez votre profile Azure Front Door (classique).
Choisissez Paramètres de diagnostic.
Sélectionnez Activer les diagnostics. Archivez les journaux de diagnostic et les métriques dans un compte de stockage, envoyez-les en streaming à un hub d’événements ou envoyez-les aux journaux Azure Monitor.
Front Door fournit actuellement des journaux de diagnostic. Les journaux de diagnostic présentent chaque requête d’API individuellement, chaque entrée ayant le schéma suivant :
| Propriété | Description |
|---|---|
| BackendHostname | Si la demande a été transférée à un serveur principal, ce champ représente le nom d’hôte du serveur principal. Ce champ est vide si la requête est redirigée ou transférée vers un cache régional (lorsque la mise en cache est activée pour la règle d’acheminement). |
| CacheStatus | Pour les scénarios de mise en cache, ce champ définit une absence/une correspondance dans le cache au niveau POP |
| ClientIp | Adresse IP du client à l’origine de la demande. S’il existait un en-tête X-Forwarded-For dans la demande, l’adresse IP du client est sélectionnée de la même façon. |
| ClientPort | Adresse IP du port du client qui a effectué la requête. |
| HttpMethod | Méthode HTTP utilisée par la requête. |
| HttpStatusCode | Code d’état HTTP retourné par le proxy. Si une demande adressée à l’origine expire, la valeur de HttpStatusCode est définie sur 0. |
| HttpStatusDetails | État résultant de la requête. Vous trouverez la signification de cette valeur de chaîne dans la Table de référence des états. |
| HttpVersion | Type de la requête ou de la connexion. |
| POP | Nom abrégé de la périphérie où la demande est arrivée. |
| RequestBytes | Taille du message de requête HTTP en octets, en-têtes de requête et corps de requête compris. |
| RequestUri | URI de la requête reçue. |
| ResponseBytes | Octets envoyés en tant que réponse par le serveur back-end. |
| RoutingRuleName | Nom de la règle de routage correspondant à la requête. |
| RulesEngineMatchNames | Noms des règles correspondant à la demande. |
| SecurityProtocol | Version du protocole TLS/SSL utilisée par la requête, ou Null si aucun chiffrement. |
| SentToOriginShield (déprécié) * Consultez les notes sur la dépréciation dans la section suivante. |
Si la valeur est true, cela signifie que la requête a été traitée à partir du cache de protection d’origine au lieu du pop de périphérie. La protection d’origine est un cache parent utilisé pour améliorer le taux d’accès au cache. |
| isReceivedFromClient | Si la valeur est true, cela signifie que la requête provient du client. Si la valeur est false, la requête est en échec dans la périphérie (POP enfant) et reçoit une réponse à partir de la protection d’origine (POP parent). |
| TimeTaken | Durée, en secondes, écoulée entre le premier octet de la requête Front Door et le dernier octet de la réponse. |
| TrackingReference | Chaîne de référence unique qui identifie une requête traitée par Front Door, également envoyée en tant qu’en-tête X-Azure-Ref au client. Nécessaire pour pouvoir effectuer une recherche détaillée dans les journaux d’accès pour une requête spécifique. |
| UserAgent | Type de navigateur utilisé par le client. |
| ErrorInfo | Ce champ contient le type d’erreur spécifique pour la résolution des problèmes.
Les valeurs possibles sont les suivantes : NoError : indique qu’aucune erreur n’a été trouvée. CertificateError : Erreur de certificat SSL générique. CertificateNameCheckFailed : le nom d’hôte dans le certificat SSL n’est pas valide ou ne correspond pas. ClientDisconnected : Échec de la requête en raison de la connexion réseau du client. UnspecifiedClientError : Erreur du client générique. InvalidRequest : Requête non valide. Cela peut se produire en raison d’un en-tête, d’un corps et d’une URL incorrect(e)s. DNSFailure : Échec de DNS. DNSNameNotResolved : Le nom ou l’adresse du serveur n’a pas pu être résolu. OriginConnectionAborted : La connexion avec l’origine a été brusquement interrompue. OriginConnectionError : Erreur de connexion d’origine générique. OriginConnectionRefused : La connexion avec l’origine n’a pas pu être établie. OriginError : Erreur d’origine générique. OriginInvalidResponse : L’origine a retourné une réponse non valide ou non reconnue. OriginTimeout : le délai d’expiration de la requête d’origine a expiré. ResponseHeaderTooBig : L’origine a retourné un en-tête de réponse trop grand. RestrictedIP : La requête a été bloquée en raison d’une adresse IP restreinte. SSLHandshakeError : Impossible d’établir la connexion avec l’origine en raison d’un échec d’établissement d’une liaison SSL. UnspecifiedError : Une erreur ne correspondant à aucune des erreurs dans le tableau s’est produite. SSLMismatchedSNI : La demande n'était pas valide car l'en-tête du message HTTP ne correspondait pas à la valeur présentée dans l'extension TLS SNI lors de la configuration de la connexion SSL/TLS. |
| Résultat |
SSLMismatchedSNI est un code d’état impliquant la réussite d’une requête avec un avertissement d’incompatibilité entre l’Indication du nom du serveur (SNI) et l’en-tête de l’hôte. Ce code d’état implique une utilisation de domaine-écran, une technique qui enfreint les conditions d’utilisation du service Azure Front Door. Les requêtes avec SSLMismatchedSNI lesquelles elles seront rejetées après le 22 janvier 2024. |
| Sni | Ce champ spécifie l’indication de nom du serveur (SNI) envoyée lors de l’établissement d’une liaison TLS/SSL. Il peut être utilisé pour identifier la valeur SNI exacte s’il existe un code d’état SSLMismatchedSNI. En outre, il peut être comparé à la valeur de l’hôte dans le champ requestUri pour détecter et résoudre le problème d’incompatibilité. |
Dépréciation de Sent to origin shield
La propriété de journal brut isSentToOriginShield est déconseillée et remplacée par un nouveau champ isReceivedFromClient. Utilisez le nouveau champ si vous utilisez déjà le champ déconseillé.
Les journaux bruts incluent les journaux générés à partir de la périphérie de CDN (POP enfant) et de la protection d’origine. La protection d’origine fait référence aux nœuds parents qui se trouvent stratégiquement dans le monde entier. Ces nœuds communiquent avec les serveurs d’origine et réduisent la charge du trafic sur l’origine.
Pour chaque requête qui accède à une protection d’origine, il existe deux entrées de journal :
- une pour les nœud de périphérie
- Un pour la protection d’origine
Pour différencier la sortie ou les réponses des nœuds de périphérie par rapport à la protection d’origine, vous pouvez utiliser le champ isReceivedFromClient pour récupérer les données correctes.
Si la valeur est false, cela signifie que la requête reçoit une réponse de la protection d’origine jusqu’aux nœuds de périphérie. Cette approche est efficace pour comparer les journaux bruts aux données de facturation. Les frais ne sont pas facturés pour la sortie de la protection d’origine jusqu’aux nœuds de périphérie. Des frais sont facturés pour la sortie des nœuds de périphérie jusqu’aux clients.
Exemple de requête Kusto pour exclure les journaux générés sur la protection d’origine dans Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Remarque
Pour les différentes configurations de routage et les différents comportements de trafic, certains des champs, comme backendHostname, cacheStatus, isReceivedFromClient et POP peuvent renvoyer des valeurs différentes. Le tableau suivant explique les différentes valeurs que contiennent ces champs dans différents scénarios :
| Scénarios | Nombre d’entrées de journal | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Règle d’acheminement sans mise en cache | 1 | Code POP Edge | Serveur principal où la demande a été envoyée | True | CONFIG_NOCACHE |
| Règle d’acheminement avec mise en cache. Correspondance dans le cache au niveau de la périphérie POP | 1 | Code POP Edge | Vide | True | HIT |
| Règle d’acheminement avec mise en cache. Absence dans le cache au niveau de la périphérie POP, mais correspondance dans le cache au niveau POP du cache parent | 2 | 1. Code POP Edge 2. Code POP du cache parent |
1. Nom d’hôte POP du cache parent 2. Vide |
1. True 2. False |
1. ÉCHEC 2. HIT |
| Règle d’acheminement avec mise en cache. Absence dans le cache au niveau de la périphérie POP, mais correspondance PARTIAL dans le cache au niveau POP du cache parent | 2 | 1. Code POP Edge 2. Code POP du cache parent |
1. Nom d’hôte POP du cache parent 2. Serveur principal qui permet de remplir le cache |
1. True 2. False |
1. ÉCHEC 2. PARTIAL_HIT |
| Règle d’acheminement avec mise en cache. Cache PARTIAL_HIT au niveau de la périphérie POP, mais correspondance dans cache au niveau POP du cache parent | 2 | 1. Code POP Edge 2. Code POP du cache parent |
1. Code POP Edge 2. Code POP du cache parent |
1. True 2. False |
1. PARTIAL_HIT 2. HIT |
| Règle d’acheminement avec mise en cache. Absence dans le cache à la fois dans la périphérie et dans le POP du cache parent | 2 | 1. Code POP Edge 2. Code POP du cache parent |
1. Code POP Edge 2. Code POP du cache parent |
1. True 2. False |
1. ÉCHEC 2. MISS |
| Erreur lors du traitement de la demande | N/A |
Remarque
Pour les scénarios de mise en cache, la valeur de l’état du cache est PARTIAL_HIT lorsque certains octets d’une requête sont traités à partir du cache de la périphérie Azure Front Door ou du cache de la protection d’origine, tandis que certains octets sont traités à partir de l’origine pour les objets volumineux.
Azure Front Door utilise une technique appelée segmentation d’objets. Quand un fichier volumineux est demandé, l’instance Azure Front Door récupère les petits éléments du fichier à partir de l’origine. Une fois que le serveur POP de l’instance Azure Front Door a reçu une requête de fichier complet ou de plage d’octets de fichier, le serveur de périphérie Azure Front Door demande le fichier au serveur d’origine par segments de 8 Mo.
Quand un segment arrive à la périphérie Azure Front Door, il est mis en cache et immédiatement servi à l’utilisateur. L’instance Azure Front Door se prépare ensuite à récupérer le bloc suivant en parallèle. Cette prérécupération garantit que le contenu a un bloc d’avance sur l’utilisateur, ce qui a réduit la latence. Ce processus se poursuit jusqu'à ce que le fichier entier soit téléchargé (si nécessaire), que toutes les plages d’octets soient disponibles (si nécessaire), ou que le client mette fin à la connexion. Pour plus d’informations sur la demande de plage d’octets, voir RFC 7233. L’instance Azure Front Door met en cache les blocs au fur et à mesure de leur réception. Le fichier entier n’a pas besoin d’être mis en cache sur le cache Front Door. Les demandes suivantes concernant le fichier ou les plages d’octets sont traitées à partir du cache Azure Front Door. Si tous les blocs sont mis en cache sur l’instance Azure Front Door, une prérécupération est utilisée pour demander des blocs de l’origine. Cette optimisation s’appuie sur la capacité du serveur d’origine à prendre en charge des demandes de plages d’octets. Si le serveur d’origine ne prend pas en charge les demandes de plages d’octets, cette optimisation n’est pas effective.
Utiliser les outils Azure Monitor pour analyser les données
Ces outils Azure Monitor sont disponibles dans le portail Azure pour vous aider à analyser les données de surveillance :
Certains services Azure ont un tableau de bord de supervision intégré dans le portail Azure. Ces tableaux de bord sont appelés des insights et vous pouvez les trouver dans la section Insights d’Azure Monitor dans le portail Azure.
Metrics Explorer vous permet d’afficher et d’analyser les métriques pour les ressources Azure. Pour plus d’informations, consultez Analyser les métriques avec l’Explorateur de métriques Azure Monitor.
Log Analytics vous permet d’interroger et d’analyser des données de journal à l’aide du langage de requête Kusto (KQL). Pour plus d’informations, consultez Bien démarrer avec les requêtes de journal dans Azure Monitor.
Le portail Azure dispose d’une interface utilisateur pour l’affichage et les recherches de base du journal d’activité. Pour effectuer une analyse plus approfondie, vous devez router les données vers les journaux Azure Monitor et exécuter des requêtes plus complexes dans Log Analytics.
Application Insights analyse la disponibilité, les performances et l’utilisation de vos applications web, pour que vous puissiez identifier et diagnostiquer les erreurs sans attendre qu’un utilisateur les signale.
Application Insights inclut des points de connexion à divers outils de développement et s’intègre à Visual Studio pour prendre en charge vos processus DevOps. Pour plus d’informations, consultez Supervision des applications pour App Service.
Les outils qui permettent une visualisation plus complexe sont notamment :
- Les tableaux de bord, qui vous permettent de combiner différentes sortes de données dans un même volet du portail Azure.
- Les workbooks, des rapports personnalisables que vous pouvez créer dans le portail Azure. Les workbooks peuvent inclure du texte, des métriques et des requêtes de journal.
- Grafana, un outil de plateforme ouvert, parfait pour les tableaux de bord opérationnels. Vous pouvez utiliser Grafana pour créer des tableaux de bord à partir de données de plusieurs sources autres qu’Azure Monitor.
- Power BI, un service d’analyse métier qui fournit des visualisations interactives pour diverses sources de données. Vous pouvez configurer Power BI pour importer automatiquement les données de journal à partir d’Azure Monitor afin de tirer parti de ces visualisations supplémentaires.
Exporter des données Azure Monitor
Vous pouvez exporter des données en dehors d’Azure Monitor dans d’autres outils à l’aide de :
Métriques : utilisez l’API REST pour les métriques pour extraire les données de métriques de la base de données de métriques Azure Monitor. Pour plus d’informations, consultez Informations de référence sur l’API REST Azure Monitor.
Journaux : utilisez l’API REST ou les bibliothèques de client associées.
L’exportation de données de l’espace de travail Log Analytics.
Pour bien démarrer avec l’API REST pour Azure Monitor, consultez Procédure pas à pas de l’API REST d’analyse Azure.
Utiliser des requêtes Kusto pour analyser les données de journal
Vous pouvez analyser les données du journal Azure Monitor à l’aide du langage de requête Kusto (KQL). Pour plus d’informations, consultez Requêtes de journal dans Azure Monitor.
Utiliser des alertes Azure Monitor pour vous avertir des problèmes
Les alertes Azure Monitor vous permettent d’identifier et de résoudre les problèmes dans votre système et de vous avertir de manière proactive lorsque des conditions spécifiques sont observées dans vos données de surveillance avant que vos clients ne les remarquent. Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor. Il existe différents types d’alertes Azure Monitor en fonction des services que vous surveillez et des données de monitoring que vous collectez. Consultez Choix du type approprié de règle d’alerte.
Pour obtenir des exemples d’alertes courantes pour les ressources Azure, consultez Exemples de requêtes d’alerte de journal.
Implémentation d’alertes à grande échelle
Pour certains services, vous pouvez opérer une surveillance à grande échelle en appliquant la même règle d’alerte de métrique à plusieurs ressources du même type qui existent dans la même région Azure. Azure Monitor Baseline Alerts (AMBA) fournit une méthode semi-automatisée de mise en œuvre des alertes, des tableaux de bord et des recommandations concernant les métriques à grande échelle.
Obtenir des recommandations personnalisées à l’aide d’Azure Advisor
Pour certains services, si des conditions critiques ou des changements imminents se produisent pendant des opérations de ressources, une alerte s’affiche dans la page Vue d’ensemble du service concerné dans le portail. Des informations supplémentaires et les correctifs recommandés pour l’alerte sont disponibles dans les Recommandations Advisor sous Surveillance dans le menu de gauche. Pendant les opérations normales, aucune recommandation Advisor ne s’affiche.
Pour plus d’informations sur Azure Advisor, consultez Vue d’ensemble d’Azure Advisor.