Surveiller Azure Resource Manager
Cet article aborde les points suivants :
- Types de données de monitoring que vous pouvez collecter pour ce service.
- Comment analyser ces données.
Notes
Si vous connaissez déjà ce service et/ou Azure Monitor et que vous voulez simplement savoir comment analyser les données de monitoring, consultez la section Analyser vers la fin de cet article.
Quand vous avez des applications critiques et des processus métier qui s’appuient sur des ressources Azure, vous devez monitorer votre système et obtenir des alertes. Le service Azure Monitor collecte et agrège les métriques et les journaux de chaque composant de votre système. Azure Monitor vous fournit une vue de la disponibilité, des performances et de la résilience, et vous avertit des problèmes. 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.
- Pour plus d’informations sur Azure Monitor, consultez la vue d’ensemble d’Azure Monitor.
- Pour plus d’informations sur le monitoring des ressources Azure en général, consultez Monitorer les ressources Azure avec Azure Monitor.
Dans Azure, certains services ont un tableau de bord de monitoring intégré dans le portail Azure, qui constitue un point de départ pour le monitoring de votre service. Ces tableaux de bord sont appelés insights et vous pouvez les trouver dans le Hub d’insights d’Azure Monitor dans le portail Azure.
Pour plus d’informations, consultez Surveiller les insights sur les groupes de ressources d’Azure Monitor.
Azure utilise le concept de types de ressources et d’ID pour identifier tout dans un abonnement. Les types de ressource font également partie des ID de ressource pour chaque ressource exécutée dans Azure. Par exemple, le type de ressource pour une machine virtuelle peut être Microsoft.Compute/virtualMachines
. Pour obtenir la liste des services et leurs types de ressource associés, consultez Fournisseurs de ressources.
Azure Monitor organise de même manière les données de supervision de base en métriques et journaux en fonction des types de ressources, également appelés espaces de noms. Différentes métriques et journaux sont disponibles pour les différents types de ressource. Votre service peut être associé à plusieurs types de ressource.
Pour plus d’informations sur les types de ressources pour Resource Manager, consultez Informations de référence sur les données de surveillance d’Azure Resource Manager.
Pour Azure Monitor :
- Les données de métriques sont stockées dans la base de données des métriques Azure Monitor.
- Les données de journal sont stockées dans le magasin de journaux Azure Monitor. Log Analytics est un outil du portail Azure qui peut interroger ce magasin.
- Le journal d’activité Azure est un magasin distinct avec sa propre interface dans le portail Azure.
Vous pouvez aussi envoyer les données des métriques et des journaux d’activité vers le magasin de journaux Azure Monitor. Vous pouvez ensuite utiliser Log Analytics pour interroger les données et les mettre en corrélation avec d’autres données de journal.
De nombreux services peuvent utiliser les paramètres de diagnostic pour envoyer les données des métriques et des journaux vers d’autres emplacements de stockage en dehors d’Azure Monitor. Il peut ainsi s’agit du Stockage Azure, des systèmes partenaires hébergés et des systèmes partenaires non-Azure, en utilisant Event Hubs.
Pour plus d’informations sur la façon dont Azure Monitor stocke les données, consultez Plateforme de données Azure Monitor.
Azure Monitor fournit des métriques de plateforme pour la plupart des services. Ces mesures sont :
- Définies individuellement pour chaque espace de noms.
- Stockées dans la base de données de métriques de série chronologique Azure Monitor.
- Légères et capables de prendre en charge les alertes en quasi-temps réel.
- Utilisées pour suivre les performances d’une ressource au fil du temps.
Collecte : Azure Monitor collecte automatiquement les métriques de plateforme. Aucune configuration n'est requise.
Routage : vous pouvez également acheminer certaines mesures de plateforme vers Azure Monitor Logs/Log Analytics afin de pouvoir les interroger avec d’autres données de journal. Vérifiez le paramètre d’exportation DS pour chaque métrique pour voir si vous pouvez utiliser un paramètre de diagnostic pour acheminer la métrique vers Azure Monitor Logs/Log Analytics.
- Pour plus d’informations, consultez le paramètre de diagnostic des métriques.
- Pour configurer les paramètres de diagnostic d’un service, consultez Créer des paramètres de diagnostic dans Azure Monitor.
Pour obtenir la liste de toutes les métriques qu’il est possible de collecter pour toutes les ressources dans Azure Monitor, consultez Métriques prises en charge dans Azure Monitor.
Pour obtenir la liste des métriques disponibles pour Resource Manager, consultez Informations de référence sur les données de surveillance d’Azure Resource Manager.
Lorsque vous créez et gérez des ressources dans Azure, vos demandes sont orchestrées par l’intermédiaire d’un plan de contrôle Azure, Azure Resource Manager. Cet article explique comment superviser le volume et la latence des demandes de plan de contrôle envoyées à Azure.
Avec ces métriques, vous pouvez observer le trafic et la latence des demandes de plan de contrôle dans tous vos abonnements. Par exemple, vous pouvez maintenant savoir quand vos requêtes ont été limitées en examinant les requêtes limitées. Déterminez si elles ont échoué en filtrant sur des codes d’état spécifiques et en examinant les erreurs du serveur.
Les métriques restent disponibles pendant une période de trois mois (93 jours) ; elles permettent uniquement le suivi de demandes synchrones. Pour un scénario comme la création d’une machine virtuelle, les métriques ne représentent pas les performances ou la fiabilité de l’opération asynchrone de longue durée.
Vous pouvez accéder aux métriques du plan de contrôle en utilisant les API REST d’Azure Monitor, des Kits de développement logiciel (SDK) et le portail Azure en sélectionnant la métrique Azure Resource Manager. Pour avoir une vue d’ensemble d’Azure Monitor, consultez Métriques dans Azure Monitor.
L’accès aux métriques du plan de contrôle ne nécessite ni consentement ni inscription.
Pour obtenir des conseils sur la récupération d’un jeton porteur et l’envoi de demandes à Azure, consultez la documentation de référence des API REST Azure.
La définition des métriques Azure Resource Manager dans Azure Monitor est possible uniquement dans la version d’API 2017-12-01-preview. Pour récupérer la définition, vous pouvez exécuter l’extrait de code suivant. Remplacez 00000000-0000-0000-0000-000000000000
par votre ID d’abonnement.
curl --location --request GET 'https://management.azure.com/subscriptions/ffff5f5f-aa6a-bb7b-cc8c-dddddd9d9d9d/providers/microsoft.insights/metricDefinitions?api-version=2017-12-01-preview&metricnamespace=microsoft.resources/subscriptions' \
--header 'Authorization: bearer {{bearerToken}}'
Cet extrait retourne la définition du schéma de métriques. Notez en particulier que ce schéma inclut les dimensions sur lesquelles vous pouvez filtrer avec l’API Monitor.
Voici quelques scénarios qui peuvent vous aider à explorer les métriques Azure Resource Manager.
Commencez par accéder à la page Azure Monitor dans le portail :
Après avoir sélectionné Explorer les métriques, sélectionnez un abonnement, puis sélectionnez la métrique Azure Resource Manager :
Ensuite, après avoir sélectionné Appliquer, vous pouvez visualiser les métriques de plan de contrôle du trafic ou de la latence en appliquant un filtrage et un fractionnement personnalisés :
Après vous être authentifié auprès d’Azure, vous pouvez faire une requête pour récupérer les métriques du plan de contrôle de votre abonnement. Dans le script, remplacez 00000000-0000-0000-0000-000000000000
par votre ID d’abonnement. Le script récupère la latence moyenne en secondes des requêtes et le nombre total de requêtes sur une période de deux jours, décomposé en intervalles d’un jour :
curl --location --request GET "https://management.azure.com/subscriptions/ffff5f5f-aa6a-bb7b-cc8c-dddddd9d9d9d/providers/microsoft.insights/metrics?api-version=2021-05-01&interval=P1D&metricnames=Latency&metricnamespace=microsoft.resources/subscriptions®ion=global&aggregation=average,count×pan=2021-11-01T00:00:00Z/2021-11-03T00:00:00Z" \
--header "Authorization: bearer {{bearerToken}}"
Pour les métriques Azure Resource Manager, vous pouvez récupérer le volume de trafic en utilisant la métrique Latence et en incluant l’agrégation « count ». Vous voyez une réponse JSON pour la requête :
{
"cost": 5758,
"timespan": "2021-11-01T00:00:00Z/2021-11-03T00:00:00Z",
"interval": "P1D",
"value": [
{
"id": "subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Insights/metrics/Latency",
"type": "Microsoft.Insights/metrics",
"name": {
"value": "Latency",
"localizedValue": "Latency"
},
"displayDescription": "Latency data for all requests to Azure Resource Manager",
"unit": "Seconds",
"timeseries": [
{
"metadatavalues": [],
"data": [
{
"timeStamp": "2021-11-01T00:00:00Z",
"count": 1406.0,
"average": 0.19345163584637273
},
{
"timeStamp": "2021-11-02T00:00:00Z",
"count": 1517.0,
"average": 0.28294792353328935
}
]
}
],
"errorCode": "Success"
}
],
"namespace": "microsoft.resources/subscriptions",
"resourceregion": "global"
}
Si vous voulez récupérer seulement le volume du trafic, vous pouvez utiliser la métrique Trafic avec l’agrégation count
:
curl --location --request GET 'https://management.azure.com/subscriptions/ffff5f5f-aa6a-bb7b-cc8c-dddddd9d9d9d/providers/microsoft.insights/metrics?api-version=2021-05-01&interval=P1D&metricnames=Traffic&metricnamespace=microsoft.resources/subscriptions®ion=global&aggregation=count×pan=2021-11-01T00:00:00Z/2021-11-03T00:00:00Z' \
--header 'Authorization: bearer {{bearerToken}}'
Voici la réponse à la demande :
{
"cost": 2879,
"timespan": "2021-11-01T00:00:00Z/2021-11-03T00:00:00Z",
"interval": "P1D",
"value": [
{
"id": "subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Insights/metrics/Traffic",
"type": "Microsoft.Insights/metrics",
"name": {
"value": "Traffic",
"localizedValue": "Traffic"
},
"displayDescription": "Traffic data for all requests to Azure Resource Manager",
"unit": "Count",
"timeseries": [
{
"metadatavalues": [],
"data": [
{
"timeStamp": "2021-11-01T00:00:00Z",
"count": 1406.0
},
{
"timeStamp": "2021-11-02T00:00:00Z",
"count": 1517.0
}
]
}
],
"errorCode": "Success"
}
],
"namespace": "microsoft.resources/subscriptions",
"resourceregion": "global"
}
Pour les mesures prenant en charge des dimensions, vous devez spécifier la valeur de la dimension pour afficher les valeurs de mesures correspondantes. Par exemple, si vous voulez vous concentrer sur la Latence pour les requêtes réussies adressées à Resource Manager, vous devez filtrer la dimension StatusCodeClass sur 2XX.
Si vous préférez examiner le nombre de demandes de ressources réseau (réseaux virtuels et équilibreurs de charge, par exemple) qui ont été faites dans votre abonnement, vous devez filtrer la dimension Namespace (Espace de noms) sur MICROSOFT.NETWORK.
Pour voir uniquement vos demandes limitées, vous devez appliquer un filtre qui affiche seulement les réponses ayant le code d’état 429. Pour les appels d’API REST, le filtrage s’effectue en utilisant la propriété $filter et la dimension StatusCode en ajoutant $filter=StatusCode eq '429'
, comme vous le voyez à la fin de la requête dans l’extrait de code suivant :
curl --location --request GET 'https://management.azure.com/subscriptions/ffff5f5f-aa6a-bb7b-cc8c-dddddd9d9d9d/providers/microsoft.insights/metrics?api-version=2021-05-01&interval=P1D&metricnames=Latency&metricnamespace=microsoft.resources/subscriptions®ion=global&aggregation=count,average×pan=2021-11-01T00:00:00Z/2021-11-03T00:00:00Z&$filter=StatusCode%20eq%20%27429%27' \
--header 'Authorization: bearer {{bearerToken}}'
Vous aussi appliquer un filtre directement dans le portail :
Tout comme pour les demandes limitées, vous pouvez visualiser toutes les demandes qui ont reçu en réponse un code d’erreur serveur, en filtrant uniquement les réponses 5xx. Pour les appels d’API REST, le filtrage s’effectue en utilisant la propriété $filter et la dimension StatusCodeClass en ajoutant $filter=StatusCodeClass eq '5xx', comme vous le voyez à la fin de la requête dans l’extrait de code suivant :
curl --location --request GET 'https://management.azure.com/subscriptions/ffff5f5f-aa6a-bb7b-cc8c-dddddd9d9d9d/providers/microsoft.insights/metrics?api-version=2021-05-01&interval=P1D&metricnames=Latency&metricnamespace=microsoft.resources/subscriptions®ion=global&aggregation=count,average×pan=2021-11-01T00:00:00Z/2021-11-03T00:00:00Z&$filter=StatusCodeClass%20eq%20%275xx%27' \
--header 'Authorization: bearer {{bearerToken}}'
Vous pouvez également effectuer un filtrage sur les erreurs de serveur génériques au sein du portail en définissant la propriété filter sur StatusCodeClass
et la valeur sur 5xx
, comme ce qui a été fait dans l’exemple de limitation.
Les journaux de ressource fournissent des insights sur les opérations effectuées par une ressource Azure. Les journaux sont générés automatiquement, mais vous devez les acheminer vers les journaux d’Azure Monitor pour les enregistrer ou les interroger. Les journaux d’activité sont organisées par catégories. Un espace de noms donné peut avoir plusieurs catégories de journaux de ressources que vous pouvez collecter.
Ce service ne collecte pas les journaux des ressources, mais vous trouverez des informations les concernant dans Supervision des données à partir de ressources Azure.
Le journal d’activité contient des évènements au niveau de l’abonnement qui suivent les opérations sur chaque ressource Azure qui sont vues comme extérieures à cette ressource, par exemple, la création d’une ressource ou le démarrage d’une machine virtuelle.
Collecte : les évènements de journal d’activité sont générés et collectés automatiquement dans un magasin distinct pour leur consultation dans le portail Azure.
Routage : vous pouvez envoyer les données de journal d’activité aux journaux Azure Monitor afin de pouvoir les analyser en même temps que d’autres données de journal. D’autres emplacements comme le Stockage Azure, Azure Event Hubs et certains partenaires de monitoring de Microsoft sont également disponibles. Pour plus d’informations sur le routage du journal d’activité, consultez Vue d’ensemble du journal d’activité Azure.
Il existe de nombreux outils pour analyser les données de supervision.
Azure Monitor prend en charge les outils de base suivants :
Metrics Explorer, un outil du portail Azure qui vous permet de voir et d’analyser les métriques des ressources Azure. Pour plus d’informations, consultez Analyser les métriques avec l’Explorateur de métriques Azure Monitor.
Log Analytics, un outil du portail Azure qui vous permet d’interroger et d’analyser les données de journal en utilisant le langage de requête Kusto (KQL). Pour plus d’informations, voir Bien démarrer avec les requêtes de journal dans Azure Monitor.
Le journal d’activité, qui a une interface utilisateur dans le portail Azure pour la consultation et les recherches de base. 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.
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.
Vous pouvez extraire des données d’Azure Monitor dans d’autres outils en utilisant les méthodes suivantes :
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. L’API prend en charge les expressions de filtre pour affiner les données récupérées. 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.
Une autre option est l’exportation des données d’espace de travail.
Pour bien démarrer avec l’API REST pour Azure Monitor, consultez Procédure pas à pas de l’API REST d’analyse Azure.
Vous pouvez analyser les données de supervision dans les journaux Azure Monitor ou le magasin Log Analytics à l’aide du langage de requête Kusto (KQL).
Important
Quand vous sélectionnez Journaux dans le menu du service dans le portail, Log Analytics s’ouvre avec l’étendue de requête définie sur le service actuel. Cette étendue signifie que les requêtes de journal ont seulement des données de ce type de ressource. Si vous voulez exécuter une requête qui comprend des données d’autres services Azure, sélectionnez Journaux dans le menu Azure Monitor. Pour plus d’informations, consultez Étendue de requête de journal et intervalle de temps dans la fonctionnalité Log Analytics d’Azure Monitor.
Pour obtenir la liste des requêtes courantes pour n’importe quel service, consultez l’Interface de requêtes Log Analytics.
Azure Monitor vous alerte de façon proactive quand des conditions spécifiques sont détectées dans vos données de monitoring. Les alertes permettent d’identifier et de résoudre les problèmes affectant votre système avant que vos clients ne les remarquent. Pour plus d’informations, consultez Alertes Azure Monitor.
Il existe de nombreuses sources d’alertes courantes pour les ressources Azure. Pour obtenir des exemples d’alertes courantes pour les ressources Azure, consultez Exemples de requêtes d’alerte de journal. Le site Azure Monitor Baseline Alerts (AMBA) fournit une méthode semi-automatisée pour implémenter les alertes, les tableaux de bord et les recommandations associés·es les plus importants·es aux métriques de plateforme. Le site s’applique à un sous-ensemble des services Azure en constante expansion, y compris tous les services qui font partie de la zone d’atterrissage Azure (ALZ).
Le schéma d’alerte commun standardise la consommation de notifications d'alerte pour Azure Monitor. Pour plus d’informations, consultez Schéma d’alerte courant.
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 de nombreux types d’alertes différents en fonction des services que vous monitorez et des données de monitoring que vous collectez. Les différents types d’alertes ont divers avantages et inconvénients. Pour plus d’informations, consultez Choisir le bon type d’alerte de monitoring.
La liste suivante décrit les types d’alertes Azure Monitor que vous pouvez créer :
- Les alertes de métrique évaluent les métriques de ressource à intervalles réguliers. Les métriques peuvent être des métriques de plateforme, des métriques personnalisées, des journaux provenant d’Azure Monitor convertis en métriques ou des métriques Application Insights. Les alertes de métriques peuvent également appliquer plusieurs conditions et seuils dynamiques.
- Les alertes de journal permettent aux utilisateurs d’utiliser une requête Log Analytics pour évaluer les journaux de ressource à une fréquence prédéfinie.
- Les alertes de journal d’activité sont déclenchées quand un nouvel événement de journal d’activité correspond à des conditions définies. Les alertes Resource Health et les alertes Service Health sont des alertes de journal d’activité qui concernent l’intégrité de votre service et de vos ressources.
Certains services Azure prennent également en charge les alertes de détection intelligente, les alertes Prometheus ou les règles d’alerte recommandées.
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. Les notifications individuelles sont envoyées pour chaque ressource supervisée. Pour connaître les services et clouds Azure pris en charge, consultez Monitorer plusieurs ressources avec une seule règle d’alerte.
Notes
Si vous créez ou exécutez une application qui s’exécute sur votre service, il est possible qu’Azure Monitor Application Insights vous propose d’autres types d’alertes.
Vous pouvez définir des alertes pour n’importe quelle métrique, entrée de journal ou entrée de journal d’activité listée dans Informations de référence sur les données de surveillance d’Azure Resource Manager.
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.
- Consultez Informations de référence sur les données de surveillance d’Azure Resource Manager pour obtenir des informations de référence sur les métriques, les journaux et d’autres valeurs importantes créées pour Resource Manager.
- Pour obtenir des informations générales sur la supervision des ressources Azure, consultez Supervision de ressources Azure avec Azure Monitor.