Azure Monitor Private Link : diagnostiquer une perte d’ingestion avant de rouvrir l’accès public

Une équipe désactive l’accès public à Azure Monitor après avoir raccordé son réseau à un Azure Monitor Private Link Scope. Le déploiement est vert, le Private Endpoint est approuvé et les machines restent joignables. Vingt minutes plus tard, les heartbeats se raréfient, puis les journaux système disparaissent. La réaction la plus rapide serait de réactiver l’accès public au workspace. Elle rétablit parfois le flux, mais elle ne dit pas si la panne vient du DNS, du scope AMPLS, du Data Collection Endpoint, de l’association DCR ou de l’agent.

Azure Monitor Private Link ne se résume pas à un endpoint devant un workspace. Le chemin d’un Azure Monitor Agent comporte au moins deux fonctions : récupérer sa configuration et ingérer la télémétrie. Ces fonctions peuvent emprunter des endpoints différents. Ce runbook vise une décision précise : corriger le chemin privé avec un changement borné, maintenir temporairement un mode d’accès contrôlé, ou rollbacker le dernier durcissement réseau avec les preuves nécessaires.

Définir exactement ce qui a cessé d’arriver

Commencez par séparer absence, retard et perte partielle. Un heartbeat absent sur toutes les machines n’a pas le même diagnostic qu’un seul stream DCR manquant. Une requête vide peut aussi venir d’une mauvaise fenêtre ou d’une transformation, alors que l’ingestion fonctionne.

incident:
started_at_utc: "<timestamp>"
last_known_good_change: "<change-id>"
affected_networks:
  - "<vnet-or-on-prem-segment>"
representative_sources:
  - "<vm-or-arc-resource-id>"

signals:
heartbeat_missing: true
all_dcr_streams_missing: false
one_stream_missing: true
query_access_healthy: true

expected_path:
configuration: "source -> DNS -> DCE -> Azure Monitor configuration service"
ingestion: "source -> DNS -> DCE or workspace ingestion endpoint"
query: "operator or service -> AMPLS query endpoint -> workspace"

change_window:
- AMPLS access mode
- DCE public network access
- AMPLS scoped resources
- private DNS links or forwarders
- DCR or DCR association
- route, firewall or proxy policy

Choisissez au moins une source affectée et une source saine. Elles serviront à rejouer exactement les mêmes vérifications après correction. Sans ce témoin, une reprise naturelle de l’ingestion peut être confondue avec un correctif efficace.

Cartographier AMPLS, DCE, DCR et destination

Un AMPLS définit la frontière privée des ressources Azure Monitor. Le DCE expose les endpoints nécessaires à la collecte et, selon le scénario, à la récupération de configuration. La DCR décrit les sources, transformations et destinations. Enfin, une association relie la machine ou le cluster au DCR et peut aussi le relier au DCE utilisé pour la configuration.

Inventoriez ces objets avant de changer une règle réseau. Le but est de prouver que la source affectée est attachée au bon ensemble de ressources, dans la bonne région, et que les ressources nécessaires figurent bien dans le scope privé.

SUBSCRIPTION_ID="<subscription-id>"
RG="<observability-resource-group>"
AMPLS="<ampls-name>"
DCE="<dce-name>"
DCR="<dcr-name>"
SOURCE_ID="<vm-or-arc-resource-id>"

az account set --subscription "$SUBSCRIPTION_ID"

az monitor private-link-scope show --resource-group "$RG" --name "$AMPLS" --output json > ampls-before.json

az monitor data-collection endpoint show --resource-group "$RG" --name "$DCE" --output json > dce-before.json

az monitor data-collection rule show --resource-group "$RG" --name "$DCR" --output json > dcr-before.json

az monitor data-collection rule association list --resource "$SOURCE_ID" --output json > associations-before.json

Complétez cet état avec les scoped resources de l’AMPLS, le Private Endpoint, ses adresses IP, les zones DNS privées et leurs liens VNet. Conservez les sorties dans le dossier d’incident. Une capture du portail ne suffit pas pour comparer proprement l’avant et l’après.

Tester le DNS depuis le réseau réellement affecté

AMPLS modifie la résolution de plusieurs endpoints Azure Monitor, dont certains sont partagés et d’autres propres à une ressource. Une résolution correcte depuis un poste d’administration ne prouve rien pour une VM qui utilise un résolveur personnalisé, un forwarder on-premises ou une autre VNet.

Depuis la source affectée, récupérez d’abord les endpoints déclarés par le DCE et la DCR, puis résolvez ces noms avec le DNS réellement configuré sur la machine.

DCE_CONFIG_ENDPOINT="<configuration-endpoint-from-dce>"
DCE_INGEST_ENDPOINT="<ingestion-endpoint-from-dce-or-dcr>"

printf '%s
' "$DCE_CONFIG_ENDPOINT" "$DCE_INGEST_ENDPOINT"

getent ahosts "<configuration-fqdn>"
getent ahosts "<ingestion-fqdn>"

curl --connect-timeout 5 -sv "https://<configuration-fqdn>/" -o /dev/null
curl --connect-timeout 5 -sv "https://<ingestion-fqdn>/" -o /dev/null

Un code HTTP d’erreur peut être attendu sans authentification ; ce test cherche d’abord à prouver résolution, route, connexion TCP et négociation TLS. Un timeout pointe vers le chemin réseau. Un certificat présenté pour un autre nom suggère un proxy ou une inspection TLS. Une adresse publique après passage en mode privé pointe vers DNS, zones ou forwarding. Une adresse privée injoignable ramène vers routes, NSG ou firewall.

Ne créez pas un enregistrement DNS à la main avant d’avoir identifié la zone et le lien manquants. Les endpoints Azure Monitor partagés rendent les doublons de zones particulièrement difficiles à exploiter.

Vérifier séparément configuration et ingestion

Un agent peut être installé et afficher un état d’extension réussi tout en ne recevant plus sa configuration. À l’inverse, il peut encore connaître sa DCR mais ne plus atteindre l’endpoint d’ingestion. Classez le symptôme avec une matrice simple.

Extension provisioned, no recent heartbeat, all streams missing
Check agent process, DCE configuration association, configuration endpoint and identity.

Heartbeat present, one stream missing
Check DCR source, stream, transformation, destination and processing errors.

All sources in one VNet fail after AMPLS change
Check DNS path, AMPLS access mode, scoped resources, route and firewall.

Only one source fails
Check its DCR associations, agent logs, local DNS and machine identity.

Queries fail but ingestion continues
Diagnose query access separately; do not rewrite the collection path.

Logs ingestion API fails while AMA is healthy
Check client identity, DCR immutable ID, stream name and the DCE or DCR ingestion endpoint used by that client.

Cette séparation empêche deux faux correctifs fréquents : réinstaller l’agent alors que tout un segment réseau ne résout plus le DCE, ou modifier la DCR alors que l’agent ne peut plus la récupérer.

Utiliser le heartbeat et les métriques DCR comme preuves

Le heartbeat confirme que l’agent envoie encore des données, mais il ne prouve pas que chaque stream métier est sain. Comparez la dernière arrivée par ressource, puis contrôlez les tables attendues et la latence d’ingestion sur la même fenêtre.

let Window = 2h;
let ExpectedResources = dynamic([
"<affected-resource-id>",
"<healthy-control-resource-id>"
]);
Heartbeat
| where TimeGenerated > ago(Window)
| where Category == "Azure Monitor Agent"
| where _ResourceId in~ (ExpectedResources)
| summarize
  LastHeartbeat=max(TimeGenerated),
  Heartbeats=count(),
  P95IngestionDelay=percentile(ingestion_time() - TimeGenerated, 95)
by _ResourceId
| extend Status=case(
  LastHeartbeat < ago(10m), "missing",
  P95IngestionDelay > 10m, "late",
  "healthy")
| order by Status asc, _ResourceId asc

Ajoutez une requête équivalente sur chaque table critique et examinez les métriques ou journaux d’erreur de traitement de la DCR. Si le heartbeat revient mais qu’un stream reste absent, le chemin privé n’est probablement plus le premier suspect : reprenez le contrat de la DCR, la transformation et la destination.

Choisir la plus petite correction

La correction doit correspondre à la preuve collectée. Ajoutez le DCE ou le workspace manquant au scope si la frontière AMPLS est incomplète. Corrigez une association DCE si l’agent ne récupère pas sa configuration. Réparez un lien de zone ou une règle de forwarding si la source obtient la mauvaise adresse. Ouvrez un flux firewall uniquement pour le FQDN, le port et le segment démontrés, selon le modèle réseau approuvé.

Évitez de changer en même temps le mode AMPLS, la DCR, les zones DNS et l’agent. Un incident d’observabilité supporte mal les correctifs impossibles à attribuer. Appliquez un seul changement, attendez la propagation prévue, puis rejouez les mêmes preuves.

Valider, maintenir sous surveillance ou rollbacker

La validation doit démontrer la reprise du chemin privé, pas seulement le retour de quelques lignes.

Validate
Affected and control sources resolve the expected endpoints.
DNS answers use the intended private path.
TCP and TLS succeed without a hosts-file override.
DCE and DCR associations match the approved design.
Heartbeat returns within the agreed delay.
Every critical stream resumes without abnormal ingestion latency.
DCR processing errors remain within the expected baseline.
Public access remains in the intended state.

Rollback
Restore the previous AMPLS access mode or scoped-resource set.
Restore the previous DCE association or private DNS link.
Revert the last route or firewall policy change.
Do not delete the new objects until before/after evidence is retained.
Replay DNS, connectivity, heartbeat and critical-stream checks.
Set a deadline to remove any temporary public-access exception.

Si un rollback temporaire vers un mode plus ouvert est nécessaire pour restaurer l’observabilité, bornez-le par réseau, ressource, propriétaire et durée. Une réouverture sans échéance transforme un incident de collecte en dette de sécurité silencieuse.

Conclusion

Une perte d’ingestion après activation d’Azure Monitor Private Link doit être traitée comme une rupture de chaîne. AMPLS définit la frontière, le DCE porte les endpoints, la DCR décrit le flux, les associations ciblent les sources et le DNS décide du chemin réellement emprunté. L’état « déployé » de chacun de ces objets ne prouve pas que la chaîne fonctionne.

La bonne décision repose sur quatre preuves rejouables : résolution depuis la source affectée, accès aux endpoints attendus, récupération de configuration et reprise des streams critiques. Avec ces éléments, l’équipe peut corriger précisément ou rollbacker proprement, sans utiliser la réouverture générale de l’accès public comme outil de diagnostic permanent.