Superviser les métriques et journaux dans Azure Front Door
Azure Front Door fournit plusieurs fonctionnalités pour vous aider à superviser votre application, à suivre les demandes et à déboguer votre configuration Front Door.
Les journaux et les métriques sont stockés et gérés par Azure Monitor.
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.
Mesures
Azure Front Door mesure et envoie ses métriques par intervalles de 60 secondes. Le traitement des métriques par Azure Monitor peut prendre jusqu’à 3 minutes et elles peuvent ne pas apparaître avant la fin du traitement. Les métriques peuvent également être présentées dans des graphiques ou des grilles et elles sont accessibles par le biais du portail Azure, d’Azure PowerShell, d’Azure CLI et des API Azure Monitor. Pour plus d’informations, voir Mesures Azure Monitor.
Les métriques listées dans le tableau suivant sont enregistrées et stockées gratuitement pendant une période limitée. Des frais peuvent être facturés pour vous permettre de les stocker plus longtemps.
| Mesures | Description | Dimensions |
|---|---|---|
| Taux de réussite en octets | Pourcentage de trafic servi à partir du cache Azure Front Door, calculé par rapport au trafic de sortie total. Le taux de réussite en octets est faible si la majeure partie du trafic est transférée à l’origine plutôt que servie à partir du cache. Taux de réussite en octets = (sortie de la périphérie - sortie de l’origine)/sortie de la périphérie. Scénarios exclus du calcul du taux de réussite en octets :
|
Point de terminaison |
| Pourcentage d’intégrité de l’origine | Pourcentage des sondes d’intégrité qui ont réussi envoyé depuis Azure Front Door aux origines. | Origine, groupe d’origines |
| latence de l’origine | Azure Front Door calcule le temps d’envoi de la requête à l’origine jusqu’à la réception du dernier octet de réponse depuis l’origine. | Point de terminaison, origine |
| Nombre de demandes de l’origine | Nombre de requêtes envoyées depuis Azure Front Door aux origines. | Point de terminaison, origine, état HTTP, groupe d’états HTTP |
| Pourcentage de 4XX | Pourcentage de toutes les requêtes clientes pour lesquelles le code d’état de la réponse est 4XX. | Point de terminaison, pays du client, région du client |
| Pourcentage de 5XX | Pourcentage de toutes les demandes client pour lesquelles le code d’état de la réponse est 5XX. | Point de terminaison, pays du client, région du client |
| Nombre de requêtes | Nombre de requêtes de client servies par Azure Front Door, y compris les requêtes entièrement servies à partir du cache. | Point de terminaison, pays du client, région du client, état HTTP, groupe d’états HTTP |
| Taille de la requête | Nombre d’octets envoyés dans les requêtes provenant de clients à Azure Front Door. | Point de terminaison, pays du client, région du client, état HTTP, groupe d’états HTTP |
| Taille de la réponse | Nombre d’octets envoyés en tant que réponses de Front Door aux clients. | Point de terminaison, pays du client, région du client, état HTTP, groupe d’états HTTP |
| Latence totale | Azure Front Door reçoit la requête du client et lui envoie le dernier octet de réponse. C’est la durée totale nécessaire. | Point de terminaison, pays du client, région du client, état HTTP, groupe d’états HTTP |
| Nombre de requêtes du pare-feu d’applications web | Nombre de requêtes traitées par le pare-feu d’applications web Azure Front Door. | Action, nom de la règle, nom de la stratégie |
Notes
Si une requête adressée à l’origine expire, la valeur de la dimension État HTTP est 0.
Journaux d’activité
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. |
| 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. |
| ResponseBytes | Taille du message de réponse HTTP en octets. |
| 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 | Temps compris entre le moment auquel la périphérie Azure Front Door a reçu la requête du client et le moment auquel Azure Front Door a envoyé le dernier octet de la réponse au client, en secondes. Ce champ ne tient pas compte de la latence du réseau et de la mise en mémoire tampon TCP. |
| RequestProtocol | Protocole spécifié par le client dans la requête. Les valeurs possibles sont : HTTP, HTTPS. |
| 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 | Manière dont la requête a été gérée par le cache Azure Front Door. 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 l’URL de la requête a été réécrite par le moteur de règles, le chemin fait référence au chemin 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 avez peut-être remarqué 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/27CAFCA8-B9A4-4264-B399-45D0C9CCA1AB/RESOURCEGROUPS/AFDXPRIVATEPREVIEW/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDXPRIVATEPREVIEW-JESSIE",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://afdxprivatepreview.blob.core.windows.net:80/",
"originName": "afdxprivatepreview.blob.core.windows.net",
"originIP": "52.239.224.228:80",
"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.
Journaux d’activité
Les journaux d’activité fournissent des informations relatives aux opérations de gestion effectuées sur vos ressources Azure Front Door. Les journaux incluent des détails sur chaque opération d’écriture effectuée sur une ressource Azure Front Door, notamment le moment auquel l’opération s’est produite, qui l’a effectuée et ce en quoi elle consistait.
Notes
Les journaux d’activité n’incluent pas les opérations de lecture. Ils n’incluent pas non plus toutes les opérations que vous effectuez à l’aide du portail Azure ou des API de gestion classiques.
Pour plus d’informations, consultez Afficher vos journaux d’activité.
Étapes suivantes
Pour activer et stocker vos journaux de diagnostic, consultez Configurer les journaux Azure Front Door.
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).
Lorsque vous utilisez Azure Front Door (classique), vous pouvez superviser les ressources des manières suivantes :
- Métriques. Azure Front Door dispose actuellement de huit métriques pour afficher les compteurs de performances.
- Journaux. Les journaux d’activité et de diagnostic permettent d’enregistrer ou de consommer les données de performances, d’accès et autres provenant d’une ressource à des fins de supervision.
Mesures
Les métriques représentent une fonctionnalité de certaines ressources Azure qui vous permettent de voir les compteurs de performances dans le portail. Les métriques Front Door disponibles sont les suivantes :
| Métrique | Nom d’affichage de la métrique | Unité | Dimensions | Description |
|---|---|---|---|---|
| RequestCount | Nombre de requêtes | Count | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Nombre de requêtes de clients prises en charge par Front Door |
| RequestSize | Taille de la requête | Octets | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Nombre d’octets envoyés en tant que requêtes de clients à Front Door. |
| ResponseSize | Taille de la réponse | Octets | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Nombre d’octets envoyés en tant que réponses de Front Door aux clients. |
| TotalLatency | Latence totale | Millisecondes | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Durée totale de la requête du client reçue par Front Door jusqu’au dernier octet de réponse envoyé d’AFD au client. |
| BackendRequestCount | Nombre de requêtes de backend | Count | HttpStatus HttpStatusGroup Backend |
Nombre de requêtes envoyées de Front Door aux backends. |
| BackendRequestLatency | Latence de requête du backend | Millisecondes | Backend | Temps calculé à partir du moment où la requête est envoyée par Front Door au backend jusqu’à ce que Front Door reçoive le dernier octet de la réponse du backend. |
| BackendHealthPercentage | Pourcentage d’intégrité du backend | Pourcentage | Backend BackendPool |
Pourcentage de sondes d’intégrité réussies de Front Door vers les backends. |
| WebApplicationFirewallRequestCount | Nombre de requêtes du pare-feu d’applications web | Count | PolicyName RuleName Action |
Nombre de requêtes de clients traitées par la sécurité de couche Application de Front Door. |
Journaux d’activité
Les journaux d’activité fournissent des informations sur les opérations effectuées sur un profil Azure Front Door (classique). Ils répondent également aux questions quoi, qui et quand pour toutes les opérations d’écriture (put, post ou delete) effectuées sur un profil Azure Front Door (classique).
Remarque
Si une demande adressée à l’origine expire, la valeur de HttpStatusCode est définie sur 0.
Vous pouvez accéder aux journaux d’activité de votre service Front Door ou à tous les journaux de vos ressources Azure dans Azure Monitor. Pour afficher les journaux d’activité :
Sélectionnez votre instance de Front Door.
Sélectionnez Journal d’activité.
Choisissez une étendue de filtrage, puis sélectionnez Appliquer.
Notes
Le journal d’activité n’inclut pas d’opérations GET ou d’opérations que vous effectuez à l’aide du portail Azure ou de l’API de gestion d’origine.
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 requête n’était pas valide, car l’en-tête de message HTTP ne correspondait pas à la valeur présentée dans l’extension SNI TLS pendant la configuration de la connexion SSL/TLS. |
| 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é. |
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
- l’autre 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
Notes
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 |
Notes
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.
Étapes suivantes
- Découvrir comment Créer un profil Azure Front Door (classique)
- En savoir plus sur le fonctionnement d’Azure Front Door (classique)