Azure Front Door : diagnostiquer un origin unhealthy avant de modifier le routage

Une API servie par Azure Front Door commence à renvoyer des 503 dans une région. Un origin apparaît unhealthy et le trafic se reporte sur le second backend. La réaction immédiate consiste souvent à mettre son poids à zéro, élargir la fenêtre de tolérance ou désactiver le probe. Ces changements peuvent rétablir le trafic, mais aussi masquer un certificat expiré, une route de santé trop coûteuse ou un backend qui ne supporte déjà plus la charge transférée.

Le cas d’usage est un profil Azure Front Door Standard ou Premium avec deux origins régionaux. Le runbook doit distinguer cinq branches : probe incorrect, DNS ou TLS entre Front Door et l’origin, Private Link non établi quand il est utilisé, saturation applicative et changement de routage. La sortie attendue est une décision bornée : remettre l’origin en service, le garder drainé, basculer explicitement, corriger la configuration ou revenir au dernier état connu.

Figer un origin, une route et une fenêtre UTC

Ne commencez pas par les poids. Conservez le profil, l’endpoint, la route, l’origin group, l’origin affecté et l’heure du premier échec. Un 503 vu par le client ne prouve pas à lui seul que le health probe a retiré l’origin : le même code peut venir du backend, de l’absence d’origin sain ou d’un timeout.

incident:
started_at_utc: 2026-08-31T06:20:00Z
profile: afd-api-prod
endpoint: api-prod
route: api-route
origin_group: api-regions
affected_origin: api-westeurope
standby_origin: api-northeurope

observed:
client_status: 503
origin_health_percentage: <measured-value>
traffic_shift: true-or-false
last_configuration_change: <activity-log-operation>

preserve:
- profile and origin-group configuration
- failed health probe logs by POP
- access logs and X-Azure-Ref samples
- backend health and deployment events
- certificate and Private Link state when applicable

stop_conditions:
- the standby origin approaches its tested capacity
- the candidate origin fails the probe from several POPs
- error rate rises after a weight change
- rollback would target an incompatible backend release

Notez aussi le nombre d’origins actifs. Avec un seul origin, un statut unhealthy ne provoque pas de bascule vers une cible inexistante. Le probe reste un signal, mais ne fournit pas de chemin de secours.

Lire la configuration réellement appliquée

Le probe appartient à l’origin group ; hostname, host header, ports, priorité, poids et Private Link appartiennent à l’origin. La route relie l’endpoint à l’origin group. Capturez les trois objets avant toute correction.

RG="rg-edge-prod"
PROFILE="afd-api-prod"
ENDPOINT="api-prod"
ROUTE="api-route"
ORIGIN_GROUP="api-regions"
ORIGIN="api-westeurope"

az afd route show \
--resource-group "$RG" \
--profile-name "$PROFILE" \
--endpoint-name "$ENDPOINT" \
--route-name "$ROUTE" \
--output json

az afd origin-group show \
--resource-group "$RG" \
--profile-name "$PROFILE" \
--origin-group-name "$ORIGIN_GROUP" \
--output json

az afd origin show \
--resource-group "$RG" \
--profile-name "$PROFILE" \
--origin-group-name "$ORIGIN_GROUP" \
--origin-name "$ORIGIN" \
--output json

PROFILE_ID=$(az afd profile show \
--resource-group "$RG" \
--profile-name "$PROFILE" \
--query id --output tsv)

az monitor metrics list-definitions \
--resource "$PROFILE_ID" \
--query "[].{metric:name.value,dimensions:dimensions[].value}" \
--output table

Vérifiez le protocole, la méthode, le chemin, l’intervalle et le nombre d’échantillons du probe. Le chemin est sensible à la casse. Vérifiez ensuite que l’origin est activé, que le hostname et le host header attendu correspondent au certificat et au virtual host du backend, et que la route pointe bien vers le groupe inspecté.

Ne rendez pas un probe plus permissif avant d’avoir compris son échec. Augmenter la tolérance réduit la vitesse de détection ; modifier son chemin change ce qui est réellement validé.

Exploiter les probes échoués par origin et par POP

Les health probe logs Azure Front Door consignent les probes échoués, pas un journal exhaustif des succès. Utilisez donc la métrique OriginHealthPercentage pour la tendance, puis les logs pour expliquer la baisse. La requête suivante vise le mode AzureDiagnostics ; adaptez les noms si le workspace utilise des tables dédiées.

let StartTime = datetime(2026-08-31T06:00:00Z);
let EndTime = datetime(2026-08-31T07:00:00Z);
AzureDiagnostics
| where TimeGenerated between (StartTime .. EndTime)
| where Category == "FrontDoorHealthProbeLog"
| extend
  Origin = tostring(originName_s),
  Result = tostring(result_s),
  Status = tostring(httpStatusCode_s),
  ProbeUrl = tostring(probeURL_s),
  Pop = tostring(POP_s),
  OriginIp = tostring(originIP_s),
  TotalMs = todouble(totalLatencyMilliseconds_s),
  ConnectMs = todouble(connectionLatencyMilliseconds_s),
  DnsUs = todouble(DNSLatencyMicroseconds_s)
| where Origin == "api-westeurope.contoso.internal"
| summarize
  Failures=count(),
  Results=make_set(Result, 10),
  Statuses=make_set(Status, 10),
  OriginIps=make_set(OriginIp, 10),
  P95TotalMs=percentile(TotalMs, 95),
  P95ConnectMs=percentile(ConnectMs, 95)
by ProbeUrl, Pop, bin(TimeGenerated, 5m)
| order by TimeGenerated asc, Failures desc

Un échec limité à quelques POPs oriente vers résolution, chemin régional ou dépendance intermittente. Un échec simultané depuis plusieurs POPs renforce l’hypothèse d’un changement global : certificat, host header, deployment, firewall ou disponibilité du backend. Un 404 ou 405 régulier indique souvent un contrat de probe incorrect. Des 5xx avec latence croissante demandent de lire l’application et ses dépendances.

Séparer DNS, TCP, TLS et réponse applicative

Un test depuis un poste d’administration ne reproduit pas le chemin Front Door, mais il permet de qualifier le contrat public de l’origin. Testez le hostname configuré, avec le SNI et le host header attendus. N’utilisez pas uniquement l’IP courante.

ORIGIN_HOST="api-we.contoso.net"
ORIGIN_PORT="443"
PROBE_PATH="/health/ready"

dig +short "$ORIGIN_HOST"

openssl s_client \
-connect "$ORIGIN_HOST:$ORIGIN_PORT" \
-servername "$ORIGIN_HOST" \
-verify_return_error \
-brief </dev/null

curl --silent --show-error \
--head \
--connect-timeout 5 \
--max-time 15 \
--resolve "$ORIGIN_HOST:$ORIGIN_PORT:<validated-origin-ip>" \
"https://$ORIGIN_HOST:$ORIGIN_PORT$PROBE_PATH"

Interprétez chaque couche séparément :

• DNSFailure ou un ensemble d’IP inattendu demande de vérifier le hostname et la publication DNS de l’origin ;
• OriginConnectionRefused ou un connect timeout demande de lire listener, filtrage et capacité de connexion ;
• SSLHandshakeError ou CertificateNameCheckFailed demande de vérifier chaîne, expiration, SNI et subject name ;
• un statut HTTP stable mais refusé par le probe demande de corriger la route de santé ou sa méthode ;
• une réponse lente ou 5xx demande de corréler la santé applicative, les pools de connexion et les dépendances.

Le endpoint de santé doit être peu coûteux, déterministe et représentatif de la capacité à servir. Il ne doit pas exécuter une transaction lourde à chaque POP, ni retourner healthy alors qu’une dépendance indispensable est indisponible.

Traiter Private Link comme une branche, pas comme l’explication par défaut

Sur Azure Front Door Premium, un origin peut être joint via Private Link. Dans ce cas, vérifiez que la demande de private endpoint créée pour Front Door est approuvée et que l’association est établie. Les probes suivent le même chemin privé que le trafic vers l’origin.

Private Link n’explique pas un incident sur un origin public et ne dispense pas de vérifier hostname, TLS et application. Après une activation ou une modification, laissez l’association converger avant de conclure. Ne réouvrez pas l’accès public comme premier test : cela change la surface de sécurité et le chemin réseau en même temps.

Corréler le trafic utilisateur et le backend

Les access logs donnent OriginName, OriginIP, HttpStatusCode, ErrorInfo, OriginURL et la référence X-Azure-Ref. Utilisez-les pour savoir si Front Door a réellement envoyé les requêtes au backend affecté, si les erreurs sont des timeouts, des refus ou des erreurs applicatives, et si le second origin absorbe la charge.

Confrontez la même fenêtre UTC avec :

• le taux de requêtes et de 5xx par origin ;
• la latence Front Door et la latence backend ;
• CPU, mémoire, connexions, files et saturation des dépendances ;
• les événements de déploiement et les changements du profil ;
• les événements WAF uniquement pour écarter un blocage en amont, sans confondre WAF et santé de l’origin.

Un origin sain dans son portail local mais absent du trafic Front Door n’est pas une preuve de bout en bout. Inversement, un probe en échec pendant que des réponses cachées restent en 200 peut retarder la visibilité client sans résoudre le backend.

Décider corriger, drainer, basculer ou rollbacker

Corriger le probe
Le chemin ou la methode ne correspond plus au endpoint de sante
Le backend sert le trafic utile mais retourne 404 ou 405 au probe
La nouvelle route de probe est testee sans effet de bord

Corriger DNS ou TLS
Les logs montrent DNSFailure, SSLHandshakeError ou name mismatch
Le hostname, le SNI et le certificat attendu sont identifies
La correction conserve le contrat de securite de l'origin

Garder l'origin draine et corriger le backend
Les probes echouent depuis plusieurs POPs
Le backend est sature ou une release est en regression
L'autre origin reste dans son enveloppe de capacite

Basculer ou changer les poids
Le second origin est valide et dimensionne
La session, les donnees et les dependances supportent la bascule
La fenetre d'observation et les criteres de retour sont ecrits

Rollbacker
L'incident commence avec une modification Front Door ou backend
L'etat precedent est compatible avec les donnees et certificats actuels
Le rollback peut etre valide par canari puis par metriques

Ne pas changer le routage
La cause n'est pas localisee
Le second origin approche deja sa limite
Les logs de probe ou d'acces manquent

Changer priorité ou poids n’est pas une correction du backend. C’est une action de continuité qui doit avoir sa propre capacité, ses critères d’arrêt et son chemin retour.

Valider le retour sans réintroduire tout le trafic

Réactivez ou remontez le poids progressivement. Vérifiez d’abord un probe stable depuis plusieurs POPs, puis une faible part de trafic utilisateur. Comparez erreurs, latence, connexions et métriques métier avec l’origin témoin.

Promouvez seulement si OriginHealthPercentage reste dans sa baseline, si aucun nouveau résultat d’échec n’apparaît, si les access logs montrent l’origin attendu et si le backend tient un cycle représentatif. Revenez au drainage si les 5xx, timeouts ou files repartent à la hausse. Conservez les logs et la configuration fautive jusqu’à la clôture de l’incident.

Conclusion

Un origin Azure Front Door unhealthy est un incident de chaîne : route, probe, DNS, TCP, TLS, Private Link éventuel, application et capacité de secours. Modifier les poids trop tôt déplace le symptôme et peut saturer le dernier origin sain.

La décision fiable vient d’une fenêtre UTC commune, des probes échoués par POP, du trafic réellement envoyé et d’un retour progressif. Corrigez le contrat quand il est faux, drainez quand le backend est réellement dégradé, basculez seulement vers une cible qualifiée et gardez le rollback ouvert jusqu’à la validation complète.