Azure Monitor : trois échéances entre le 31 août et le 30 septembre 2026

Trois échéances Azure Monitor se suivent entre le 31 août et le 30 septembre 2026 : une exigence d’identité managée pour lier un compte de stockage à un espace de travail Log Analytics, la fin de la prise en charge de l’API HTTP Data Collector, et la fin de la prise en charge de l’authentification héritée de Container Insights. Aucune des trois n’arrête l’ingestion des données : pour celle du 14 septembre, Microsoft écrit que l’ingestion existante continue de fonctionner ; les deux autres bloquent une opération de configuration ou mettent fin à une prise en charge, sans qu’aucune page décrive d’arrêt de collecte. Les pages qui portent ces dates décrivent en revanche des mécanismes qui, eux, arrêtent une remontée de journaux, et aucun n’est attaché à ces échéances.

L’identité managée devient une condition pour lier un compte de stockage

À compter du 31 août 2026, un espace de travail Log Analytics doit disposer d’une identité managée pour qu’on puisse ajouter ou mettre à jour un compte de stockage lié servant aux requêtes enregistrées et aux requêtes d’alerte de journal enregistrées. Le blocage porte sur l’opération elle-même : créer un lien, et aussi mettre à jour un lien existant.

Il y a deux exigences, et non une. La première est l’identité managée sur l’espace de travail. La seconde est une attribution de rôle pour cette identité sur le compte de stockage : Storage Table Data Contributor. Un espace de travail qui porte une identité managée sans cette attribution reste bloqué. Le compte de stockage doit par ailleurs se trouver dans la même région que l’espace de travail.

Les comptes de stockage liés pour les journaux personnalisés et les journaux IIS ne se créent plus depuis le 30 juin 2025, et ceux qui existaient ont été dissociés le 1er novembre 2025. Ce qui reste concerné par l’échéance, ce sont les liaisons de type Query et Alerts, celles qui servent au chiffrement des requêtes enregistrées et des alertes par clé gérée par le client.

La page qui porte cette exigence date son entrée en application au plus tôt du 31 août 2026. Le blocage peut donc commencer à cette date, ou après.

Remarque : tant que l’application n’a pas commencé, l’espace de travail n’utilise pas l’identité managée pour s’authentifier auprès du stockage privé. Microsoft demande de ne pas retirer la méthode d’authentification en place avant d’avoir annoncé que les identités managées sont actives pour cette authentification. Assigner l’identité et l’attribution de rôle est une préparation, pas une bascule.

API HTTP Data Collector : la prise en charge s’arrête, l’ingestion continue

La prise en charge de l’API HTTP Data Collector se termine le 14 septembre 2026. La page de migration décrit l’effet sur l’ingestion.

L’ingestion existante continue de fonctionner, mais l’API reçoit uniquement des correctifs de sécurité critiques.

La même page revient sur ce point pour la date elle-même : le 14 septembre 2026, l’API se met hors service, mais l’ingestion continue pour les clients compatibles TLS. Elle ajoute qu’il faut vérifier la configuration TLS d’un client avant de supposer que son ingestion est saine, quel que soit le calendrier de migration retenu.

Une date antérieure a, elle, arrêté des ingestions. Le 1er mars 2026, le point de terminaison a cessé d’accepter les versions TLS héritées : un client qui ne négocie pas TLS 1.2 ou une version ultérieure n’ingère plus de données depuis cette date. C’est la première chose à vérifier sur un script qui ne remonte plus rien.

Recenser ce qui utilise encore cette API

Microsoft documente trois pistes pour retrouver les tables concernées. Dans le portail, les tables alimentées par cette API affichent Custom table (classic) comme propriété Type. Par l’API de gestion des journaux, leur tableSubType vaut Classic, ce qu’une commande Azure CLI liste directement :

az monitor log-analytics workspace table list \ --resource-group myResourceGroupName --workspace-name myWorkspaceName \ --query "[?schema.tableSubType=='Classic'].{Name:name, SubType:schema.tableSubType}" -o table

Enfin, les enregistrements écrits par cette API portent SourceSystem à la valeur RestAPI. Dans le code et les tâches planifiées, le point de terminaison à chercher est ods.opinsights.azure.com/api/logs, appelé avec api-version=2016-04-01.

Ce que la migration change

Le remplacement est l’API d’ingestion des journaux. Elle demande deux ressources que l’API HTTP Data Collector ne demandait pas : un point de terminaison de collecte de données et une règle de collecte de données. Elle accepte 1 Mo par appel, contre 30 Mo pour l’ancienne — un envoi de plus de 1 Mo doit donc être découpé en plusieurs appels parallèles.

Des limites à connaître avant de commencer. Migrer une table tout en continuant d’ingérer par l’ancienne API n’est pas recommandé : les changements de type de données et les changements de schéma répétés sur ces tables peuvent entraîner des erreurs. Et sur une table déjà migrée qu’alimente encore l’ancienne API, introduire une modification de schéma par l’API Tables ou par Modifier le schéma interrompt l’ingestion héritée.

Un dernier point de périmètre : l’API HTTP Data Collector ne prend pas en charge Azure Monitor Private Link Scope. Pour un espace de travail derrière une liaison privée, Microsoft renvoie vers l’API d’ingestion des journaux.

Container Insights : les clusters en authentification héritée sortent du support

L’authentification héritée de Container Insights est retirée. Après le 30 septembre 2026, les clusters qui l’utilisent encore ne sont pas pris en charge. C’est une position de support et non un arrêt technique : la documentation ne décrit pas de coupure de collecte à cette date. La conséquence est opérationnelle, et elle compte pour qui exploite des conteneurs en production : sur un cluster resté en authentification héritée, le support Microsoft ne prendra pas en charge un incident de supervision.

Un mécanisme documenté arrête en revanche la collecte sur ces clusters, et il ne porte pas de date : la rotation des clés de l’espace de travail Log Analytics. La supervision cesse alors de remonter, et il faut désactiver puis réactiver le module complémentaire Container Insights pour rétablir le flux avec les nouvelles clés. L’authentification par identité managée n’utilise pas ces clés.

Deux requêtes Resource Graph listent ces clusters, l’une pour les clusters AKS, l’autre pour les clusters Kubernetes raccordés par Azure Arc : elles retiennent ceux dont useAADAuth n’est pas à true. La requête applicable vérifie la bascule, puisqu’un cluster migré n’apparaît plus dans ses résultats.

Sur AKS, la bascule commence par désactiver la supervision, puis met le cluster à niveau vers l’identité managée avant de réactiver le module complémentaire ; la collecte peut être interrompue le temps de la manipulation. Trois clouds la prennent en charge : le cloud public, Azure Government et Microsoft Azure opéré par 21Vianet. Pour un cluster à identité affectée par l’utilisateur, seul le cloud public est pris en charge.

Passer à l’identité managée donne accès à des fonctionnalités plus récentes de Container Insights, dont la collecte des journaux syslog et le mode journaux à grande échelle.

Les interruptions d’ingestion que Microsoft documente

Les pages citées décrivent aussi des mécanismes qui arrêtent une remontée de journaux, sans qu’aucun soit attaché à l’une des trois échéances :

• un client de l’API HTTP Data Collector qui ne négocie pas TLS 1.2 ou une version ultérieure, depuis le 1er mars 2026 ;
• une modification de schéma introduite sur une table migrée que l’ancienne API alimente encore ;
• une rotation des clés de l’espace de travail sur un cluster Container Insights resté en authentification héritée.

Les deux premiers se contrôlent sur la configuration des clients et des tables. Le troisième disparaît avec la bascule vers l’identité managée.

Vérifications à mener avant le 30 septembre 2026

1. Contrôler la version TLS des clients qui appellent l’API HTTP Data Collector. Cette vérification porte sur une ingestion peut-être arrêtée depuis le 1er mars 2026, et elle ne dépend d’aucune des trois échéances.
2. Lister les tables dont tableSubType vaut Classic, puis décider pour chacune entre migration de la table et implémentation côte à côte. Une table migrée ne revient pas à son état précédent.
3. Assigner une identité managée aux espaces de travail Log Analytics qui portent une liaison de type Query ou Alerts, et attribuer à cette identité le rôle Storage Table Data Contributor sur le compte de stockage — sans retirer la méthode d’authentification en place.
4. Lancer les deux requêtes Resource Graph et planifier la bascule des clusters listés, en tenant compte de l’interruption de collecte pendant la manipulation.

Ces quatre vérifications font partie de l’entretien courant d’un socle Azure, que nous décrivons sur notre page Infrastructure et Cloud.

Les sources Microsoft

• Migrer de l’API HTTP Data Collector vers l’API Logs Ingestion — Microsoft Learn
• Authentification héritée pour Container Insights — Microsoft Learn
• Use customer-managed storage accounts in Azure Monitor Logs — Microsoft Learn
• Azure Monitor HTTP Data Collector API — Microsoft Learn, page archivée
• What’s new in Azure Monitor documentation — Microsoft Learn