Limites du service Azure Monitor
Cet article répertorie les limites dans différentes zones d’Azure Monitor.
Alertes
| Ressource | Limite par défaut | Limite maximale |
|---|---|---|
| Alertes de métrique (classiques) | 100 règles d’alerte actives par abonnement. Les alertes classique sont hors service pour les utilisateurs du cloud public. Les alertes classiques pour le cloud Azure Government et Microsoft Azure géré par 21Vianet vont être mises hors service le 29 février 2024. |
Appelez le support technique. |
| Alertes de métrique | 5000 règles d’alerte actives par abonnement dans les clouds Azure public, Microsoft Azure opéré par 21Vianet et Azure Government. Si vous atteignez cette limite, déterminez si vous pouvez utiliser des alertes à plusieurs ressources de même type. 5 000 séries chronologiques de métriques par règle d’alerte. |
Appelez le support technique. |
| Alertes de journal d’activité | 100 règles d’alerte actives par abonnement (ne peut pas être augmentée). Cette limite ne pouvant pas être augmentée, envisagez l’envoi de vos journaux d’activité à un espace de travail Log Analytics et de créer plutôt des alertes de recherche dans les journaux, si vous avez besoin d’un plus grand nombre de règles par abonnement. |
Identique à la valeur par défaut. |
| Alertes de journal | 5,000 règles d’alerte actives par abonnement. Dont 100 règles d’alerte actives avec une fréquence de une minute. 1,000 règles d’alerte actives par ressource. Chaque règle d’alerte sans état peut déclencher jusqu’à 6 000 alertes par évaluation. Chaque règle d’alerte avec état peut déclencher jusqu’à 300 alertes par évaluation. Jusqu’à 5 000 alertes avec état déclenchées à la fois par règle d’alerte. La taille combinée de toutes les données dans les propriétés d’une règle d’alerte de journal ne peut pas dépasser 64 Ko. Les résultats de la requête Kusto ne peuvent pas dépasser plus de 20 Mo. |
Appelez le support technique. |
| Règles de traitement des alertes | 1,000 règles actives par abonnement. | Appelez le support technique. |
| Règles d’alerte et longueur de description des règles de traitement des alertes | Alertes de recherche dans les journaux avec 4,096 caractères. Tous les autres sont de 2 048 caractères. |
Identique à la valeur par défaut. |
API d’alertes
Les alertes Azure Monitor permettent d’établir des limitations pour bloquer les utilisateurs qui effectuent un nombre excessif d’appels. Ce comportement peut en effet surcharger les ressources back-end du système et compromettre la réactivité du service. Les limites suivantes sont conçues pour protéger les clients des interruptions et maintenir le niveau de service. Les restrictions et les limites imposées aux utilisateurs sont conçues pour n'affecter que les scénarios d'utilisation extrêmes. Elles ne doivent pas être pertinentes pour une utilisation classique.
Remarque
Il existe une limite d’appels d’API par instance. Le nombre limite exact dépend du nombre d’instances.
| Ressource | Limite par défaut | Limite maximale |
|---|---|---|
| Alertes : Afficher le résumé | 50 appels par minute et par abonnement | Identique à la valeur par défaut |
| Alertes : Récupérer tout (et non « Récupérer par ID ») | 100 appels par minute et par abonnement | Identique à la valeur par défaut |
| Tous les autres appels d’alertes | 1,000 appels par minute et par abonnement | Identique à la valeur par défaut |
Groupes d’actions
Vous pouvez avoir un nombre illimité de groupes d’actions dans un abonnement.
| Ressource | Limite par défaut | Limite maximale |
|---|---|---|
| Envoi de l’application Azure | 10 actions d’application Azure par groupe d’actions. | Identique à la valeur par défaut |
| 1,000 actions d’e-mail par groupe d’actions. Pas plus de 100 e-mails par heure pour chaque adresse e-mail par région La limite de caractère dans une adresse de messagerie est de 64. La limite de caractères dans un e-mail est de 55 296. Consultez également Informations de limitation du débit. |
Identique à la valeur par défaut | |
| Envoyer un e-mail au rôle Azure Resource Manager | 10 actions de rôle ARM de messagerie par groupe d’actions. En production : pas plus de 100 e-mails par heure par région. Dans un groupe d’actions de test : Pas plus de deux e-mails chaque (1) minute. |
Identique à la valeur par défaut |
| Event Hubs | 10 actions Event Hub par groupe d’actions. | Identique à la valeur par défaut |
| ITSM | 10 actions ITSM (gestion des services informatiques) par groupe d’actions. | Identique à la valeur par défaut |
| Application logique | 10 actions d’application logique par groupe d’actions. | Identique à la valeur par défaut |
| Runbook | 10 actions de runbook par groupe d’actions. | Identique à la valeur par défaut |
| Webhook sécurisé | 10 actions de webhook sécurisées par groupe d’actions. Le nombre maximal d’appels de webhook est de 1 500 par minute et par abonnement. | Identique à la valeur par défaut |
| sms | 10 actions SMS par groupe d’actions. En production : Pas plus d’un SMS toutes les cinq minutes. Dans un groupe d’actions de test : pas plus d’un SMS chaque minute. |
Identique à la valeur par défaut |
| Voix | 10 actions de voix par groupe d’actions. En production : Pas plus d’un appel vocal toutes les cinq minutes. Dans un groupe d’actions de test : Pas plus d’un appel vocal chaque minute. |
Identique à la valeur par défaut |
| webhook | 10 actions de webhook par groupe d’actions. Le nombre maximal d’appels de webhook est de 1 500 par minute et par abonnement. | Identique à la valeur par défaut |
Mise à l’échelle automatique
| Ressource | Limite par défaut | Limite maximale |
|---|---|---|
| Paramètres de mise à l'échelle automatique | 100 par région et par abonnement. | Identique à la valeur par défaut |
| Profils de mise à l’échelle automatique | 20 profils par paramètre de mise à l’échelle automatique. | Identique à la valeur par défaut |
Métriques Prometheus
Ingestion
Prometheus managé par Azure est un système qui ne respecte pas la casse. Il traite les chaînes, telles que les noms de métriques, les noms d’étiquettes ou les valeurs d’étiquette, comme les mêmes séries chronologiques si elles diffèrent d’une autre série chronologique uniquement par le cas de la chaîne. Pour plus d’informations, consultez Vue d’ensemble des métriques Prometheus.
Les limites suivantes s’appliquent à l’espace de travail Azure Monitor qui ingère vos métriques Prometheus.
| Limite | Valeur |
|---|---|
| Séries chronologiques actives avec métriques qui ont été signalées au cours des ~12 dernières heures. | 1 000 000 Vous pouvez demander une augmentation. |
| Événements ingérés par minute. | 1 000 000 Vous pouvez demander une augmentation. |
Les limites suivantes s’appliquent à la règle de collecte de données (DCR) et au point de terminaison de collecte de données (DCE) qui envoient les données des métriques Prometheus à votre espace de travail Azure Monitor.
| Limite | Valeur |
|---|---|
| Demandes d’ingestion par minute vers un point de terminaison de collecte de données | 15,000 Cette limite ne peut pas être augmentée. |
| Ingestion de données par minute vers un point de terminaison de collecte de données | 50 Go Cette limite ne peut pas être augmentée. |
Requêtes
Les requêtes Prometheus sont créées à l’aide de PromQL et peuvent être générées dans Azure Managed Grafana ou dans une version autogérée de Grafana.
| Limite | Valeur |
|---|---|
| Conservation des données | 18 mois. Cette limite ne peut pas être augmentée. |
| Intervalle de temps de la requête | 32 jours entre l’heure de début et l’heure de fin de votre requête PromQL. Cette limite ne peut pas être augmentée. |
| Séries chronologiques de requête par métrique | 500 000 séries chronologiques. |
| Exemples de requêtes renvoyés | 50 000 000 échantillons par requête. |
| Taille d’étape de requête minimale avec intervalle de temps >= 48 heures |
60 secondes. |
Limites de données des requêtes
Pour le trafic client :
| Limite | Valeur |
|---|---|
| Durée de la recherche de fenêtre de limitation | 30 secondes |
| Données retournées par l’espace de travail Azure Monitor | 0,5 Go |
Pour l’enregistrement du trafic des règles :
| Limite | Valeur |
|---|---|
| Durée de la recherche de fenêtre de limitation | 3 minutes |
| Données retournées par l’espace de travail Azure Monitor | 1 Go |
Limites de pré-analyse des requêtes
En fonction de l’intervalle de temps et du type de la requête, sur une fenêtre de 30 secondes (pour le trafic client) :
| Limite | Valeur |
|---|---|
| Heures de requête par utilisateur (Microsoft Entra ID, identité managée, espace de travail Azure Managed Grafana) | 30,000 |
| Heures de requête par espace de travail Azure Monitor | 60 000 |
| Heures de requête par locataire Azure | 600 000 |
En fonction de l’intervalle de temps de la requête et du type de requête, sur une fenêtre de 3 minutes (pour l’enregistrement du trafic des règles) :
| Limite | Valeur |
|---|---|
| Heures de requête par espace de travail Azure Monitor | 60 000 |
| Heures de requête par locataire Azure | 600 000 |
Limites de post-analyse des requêtes
En fonction de l’intervalle de temps et des vecteurs d’intervalle de la requête sur une fenêtre de 30 secondes (pour le trafic client) :
| Limite | Valeur |
|---|---|
| Heures de requête par utilisateur (Microsoft Entra ID, identité managée, espace de travail Azure Managed Grafana) | 2 000 000 |
| Heures de requête par espace de travail Azure Monitor | 2 000 000 |
| Heures de requête par locataire Azure | 20 000 000 |
En fonction de l’intervalle de temps et des vecteurs d’intervalle de la requête sur une fenêtre de 3 minutes (pour l’enregistrement du trafic des règles) :
| Limite | Valeur |
|---|---|
| Heures de requête par espace de travail Azure Monitor | 2 000 000 |
| Heures de requête par locataire Azure | 20 000 000 |
Limites des limitations de coût des requêtes
| Limite | Valeur |
|---|---|
| Coût maximal de requête par requête | 15000 |
| Coût maximal de requête pour une requête de règles d’enregistrement | 3000 |
Le calcul du coût de requête est effectué comme suit :
Coût de la requête = (Nombre de séries chronologiques demandées * (durée de l’interrogation en secondes / Résolution de temps déduite des données interrogées)) / 5000
Résolution de temps déduite des données interrogées = Nombre de points de données stockés dans une seule clé de série chronologique sélectionnée aléatoirement de la métrique interrogée / durée de la période interrogée en secondes
Règles d’alerte et d’enregistrement
Les règles d’alerte et les règles d’enregistrement Prometheus sont définies dans PromQL. Elles sont exécutées sur le service géré Ruler dans le cadre du service géré Azure Monitor pour Prometheus.
| Limite | Valeur |
|---|---|
| Groupes de règles par espace de travail Azure Monitor, dans un abonnement Azure | 500 Vous pouvez demander une augmentation. |
| Règles par groupe de règles | 20 Cette limite ne peut pas être augmentée. |
| Intervalle d’évaluation du groupe de règles | Entre 1 minute et 24 heures. La valeur par défaut est de 1 minute. |
| Alertes actives | Aucune limite à ce stade. |
Écriture à distance
Les calculs ont été déterminés à l’aide d’une taille de lot à distance de 500, qui est la valeur par défaut.
| Limite | Valeur |
|---|---|
| Utilisation de l’UC | 0,25 x (nombre de métriques) + 1,25 x (nombre moyen de séries par métrique) |
| Demande d’UC | 0,75 x (utilisation du processeur) |
| Limite UC | 2 x (demande d’UC) |
| Demande de mémoire | 150 Mo |
| Limite de mémoire | 200 Mo |
| Débit maximal | Le conteneur d’écriture à distance peut traiter jusqu’à 150 000 séries chronologiques uniques. En raison du nombre élevé de connexions simultanées, le conteneur peut générer des erreurs de traitement de requêtes au-delà de 150 000. Ce problème peut être atténué en faisant passer la taille des lots distants de 500 à 1 000. Ce changement réduit le nombre de connexions ouvertes. |
API d’ingestion de journaux
| Limite | Valeur | Commentaires |
|---|---|---|
| Taille maximale de l’appel d’API | 1 Mo | Données compressées et non compressées. |
| Taille maximale des valeurs de champ | 64 Ko | Les champs de plus de 64 Ko de champs sont tronqués. |
| Nombre maximal de données/minute par règle DCR | 2 Go | Données compressées et non compressées. Réessayez après la durée indiquée dans l’en-tête Retry-After de la réponse. |
| Nombre maximal de demandes/minute par règle DCR | 12,000 | Réessayez après la durée indiquée dans l’en-tête Retry-After de la réponse. |
Règles de collecte des données
| Limite | Valeur |
|---|---|
| Nombre maximal de sources de données | 10 |
| Nombre maximal de spécificateurs de compteur du compteur de performances | 100 |
| Nombre maximal de caractères des noms des installations dans SysLog | 20 |
| Nombre maximal de requêtes XPath dans le journal des événements | 100 |
| Nombre maximal de flux de données | 10 |
| Nombre maximal de flux de données | 10 |
| Nombre maximal d’extensions | 10 |
| Taille maximale des paramètres d’extension | 32 Kb |
| Nombre maximal d’espaces de travail Log Analytics | 10 |
| Nombre maximal de caractères dans une transformation | 15 360 |
Paramètres de diagnostic
| Ressource | Limite par défaut | Limite maximale |
|---|---|---|
| Nombre maximal de paramètres de diagnostic par ressource | 5 | Identique à la valeur par défaut. |
Requêtes dans les journaux et langage
Limites générales concernant les requêtes
| Limite | Description |
|---|---|
| Langage de requête | Azure Monitor utilise le même Langage de requête Kusto (KQL) qu’Azure Data Explorer. Consultez Différences propres au langage de requête de journal d’Azure Monitor pour les éléments du langage KQL non pris en charge dans Azure Monitor. |
| Régions Azure | Les requêtes sur les journaux peuvent connaître une surcharge excessive quand des données concernent des espaces de travail Log Analytics dans plusieurs régions Azure. Pour plus d’informations, consultez Limites des requêtes. |
| Requêtes inter-ressources | Nombre maximal de ressources Application Insights et d’espaces de travail Log Analytics dans une requête unique limitée à 100. Les requêtes inter-ressources ne sont pas prises en charge dans le Concepteur de vues. Les requêtes inter-ressources des alertes de journal sont prises en charge par la nouvelle API scheduledQueryRules. Pour plus de détails, voir Limites de requête inter-ressources. |
| Requêtes du tableau de bord Log Analytics | Le nombre maximal d’enregistrements retournés dans une seule requête de tableau de bord Log Analytics est 2 000. |
Limitation de requêtes utilisateur
Azure Monitor applique plusieurs limitations pour gérer les situations où les utilisateurs envoient un nombre de requêtes excessif. Ce comportement peut en effet surcharger les ressources back-end du système et compromettre la réactivité du service. Les limites suivantes sont conçues pour protéger les clients des interruptions et maintenir le niveau de service. Les limites et limitations d’utilisateurs sont conçues pour affecter uniquement des scénarios d’usage extrême. Elles ne s’appliquent pas aux cas d’usage classiques.
| Measure | Limite par utilisateur | Description |
|---|---|---|
| Requêtes simultanées | 5 | Un utilisateur peut exécuter jusqu’à cinq requêtes simultanées. Toute autre requête est ajoutée à une file d’attente. Lorsque l’une des requêtes en cours d’exécution se termine, la première requête de la file d’attente est extraite de la file d’attente et commence à s’exécuter. Les requêtes d’alertes ne font pas partie de cette limite. |
| Temps de conservation dans la file d’attente de concurrence | 3 minutes | Si une requête reste dans la file d’attente pendant plus de 3 minutes sans être démarrée, elle se termine avec une réponse d’erreur HTTP avec le code 429. |
| Nombre total de requêtes dans la file d’attente de concurrence | 200 | Une fois que le nombre de requêtes dans la file d’attente atteint 200, la requête suivante est rejetée avec un code d’erreur HTTP 429. Ce nombre s’ajoute aux 5 requêtes qui peuvent être exécutées simultanément. |
| Taux de requêtes | 200 requêtes par tranche de 30 secondes | Taux global d’émission de requêtes par un même utilisateur vers tous les espaces de travail. Cette limite s’applique aux requêtes programmatiques ou aux requêtes lancées par des composants de visualisation tels que des tableaux de bord Azure ou la page récapitulative de l’espace de travail Log Analytics (déconseillé). |
- L’API de journaux d’activité a une limite de débit distincte de 50 requêtes toutes les 30 secondes.
- Optimisez vos requêtes comme décrit dans Optimiser les requêtes de journal dans Azure Monitor.
- Les tableaux de bord et les classeurs peuvent contenir plusieurs requêtes dans une même vue, générant une rafale de requêtes chaque fois qu’ils sont chargés ou actualisés. Envisagez de les scinder en plusieurs vues, chargées à la demande.
- Dans Power BI, pensez à extraire uniquement des résultats agrégés plutôt que des journaux bruts.
Espaces de travail Log Analytics
Volume et rétention de collecte de données
| Niveau tarifaire | Limite par jour | Conservation des données | Commentaire |
|---|---|---|---|
| Paiement à l’utilisation (introduit en avril 2018) |
Aucune limite | Jusqu’à 730 jours de rétention interactive / jusqu’à 12 ans d’archivage de données |
La conservation des données au-delà de 31 jours est disponible contre des frais supplémentaires. En savoir plus sur la tarification Azure Monitor. |
| Niveaux d’engagement (introduit en novembre 2019) |
Aucune limite | Jusqu’à 730 jours de rétention interactive / jusqu’à 12 ans d’archivage de données |
La conservation des données au-delà de 31 jours est disponible contre des frais supplémentaires. En savoir plus sur la tarification Azure Monitor. |
| Par nœud hérité (OMS) (introduit en avril 2016) |
Aucune limite | 30 à 730 jours | La conservation des données au-delà de 31 jours est disponible contre des frais supplémentaires. En savoir plus sur la tarification Azure Monitor. L’accès au niveau d’utilisation est limité aux abonnements qui contenaient un espace de travail Log Analytics ou une ressource Application Insights le 2 avril 2018, ou qui sont liés à un Contrat Entreprise qui a débuté avant le 1er février 2019 et qui est toujours actif. |
| Niveau autonome hérité (introduit en avril 2016) |
Aucune limite | 30 à 730 jours | La conservation des données au-delà de 31 jours est disponible contre des frais supplémentaires. En savoir plus sur la tarification Azure Monitor. L’accès au niveau d’utilisation est limité aux abonnements qui contenaient un espace de travail Log Analytics ou une ressource Application Insights le 2 avril 2018, ou qui sont liés à un Contrat Entreprise qui a débuté avant le 1er février 2019 et qui est toujours actif. |
| Niveau gratuit hérité (introduit en avril 2016) |
500 Mo | 7 jours | Lorsque votre espace de travail atteint la limite de 500 Mo par jour, l’ingestion de données s’interrompt et reprend au début de la journée suivante. Les journées sont basées sur l’heure UTC. Les données collectées par Microsoft Defender pour le cloud ne sont pas incluses dans cette limite de 500 Mo par jour et continueront à être collectées au-delà de cette limite. La création de nouveaux espaces de travail dans (ou en déplaçant des espaces de travail existants dans) le niveau tarifaire Essai gratuit hérité est uniquement possible jusqu’au 1er juillet 2022. |
| Niveau standard hérité | Aucune limite | 30 jours | La rétention ne peut pas être ajustée. Ce niveau n’est plus disponible pour les nouveaux espaces de travail depuis le 1er octobre 2016. |
| Niveau Premium hérité | Aucune limite | 365 jours | La rétention ne peut pas être ajustée. Ce niveau n’est plus disponible pour les nouveaux espaces de travail depuis le 1er octobre 2016. |
Nombre d’espaces de travail par abonnement
| Niveau tarifaire | Limite d’espace de travail | Commentaires |
|---|---|---|
| Niveau gratuit hérité | 10 | Cette limite ne peut pas être augmentée. La création de nouveaux espaces de travail dans (ou en déplaçant des espaces de travail existants dans) le niveau tarifaire Essai gratuit hérité est uniquement possible jusqu’au 1er juillet 2022. |
| Tous les autres niveaux | Aucune limite | Vous êtes limité par le nombre de ressources au sein d’un groupe de ressources et le nombre de groupes de ressources par abonnement. |
Azure portal
| Category | Limite | Commentaires |
|---|---|---|
| Nombre maximum d’enregistrements retournés par une requête de journal | 30,000 | Réduisez les résultats à l’aide d’une étendue de requête, d’un intervalle de temps et de filtres dans la requête. |
API de collecte de données
| Category | Limite | Commentaires |
|---|---|---|
| Taille maximale d’une publication | 30 Mo | Fractionner les volumes plus importants en plusieurs publications. |
| Taille maximale des valeurs de champ | 32 Ko | Les champs de plus de 32 Ko de champs sont tronqués. |
API de requête
| Category | Limite | Commentaires |
|---|---|---|
| Nombre maximal d’enregistrements retournés dans une requête | 500 000 | |
| Taille maximale des données retournées | ~ 104 Mo (~ 100 Mio) | L’API renvoie jusqu’à 64 Mo de données compressées, ce qui se traduit par un maximum de 100 Mo de données brutes. |
| Durée maximale d’exécution de requête | 10 minutes | Consultez Délais d’expiration pour plus d’informations. |
| Taux maximum de requêtes | 200 requêtes par période de 30 secondes par utilisateur Microsoft Entra ou par adresse IP du client | Consultez Requêtes dans les journaux et langage. |
Connecteur des journaux Azure Monitor
| Category | Limite | Commentaires |
|---|---|---|
| Taille maximale des données | ~ 16.7 Mo (~ 16 Mio) | L’infrastructure de connecteur impose que la limite soit définie avec une valeur inférieure à la limite de l’API de requête. |
| Nombre maximal d’enregistrements | 500 000 | |
| Délai d’expiration maximal du connecteur | 110 secondes | |
| Délai d’expiration maximal de la requête | 100 secondes | |
| Graphiques | La page Journaux et le connecteur utilisent des bibliothèques de graphiques différentes pour la visualisation. Certaines fonctionnalités ne sont actuellement pas disponibles dans le connecteur. |
Règles de résumé
| Catégorie | Limite |
|---|---|
| Nombre maximal de règles actives dans un espace de travail | 30 |
| Nombre maximal de résultats par bac | 500 000 |
| Volume maximal du jeu de résultats | 100 Mo |
| Délai d’attente des requêtes pour le traitement bin | 10 minutes |
Limites d’espace de travail général
| Category | Limite | Commentaires |
|---|---|---|
| Nombre maximum de colonnes dans une table | 500 | AzureDiagnostics -- les colonnes dépassant la limite sont ajoutées à la colonne « AdditionalFields » dynamique Journal personnalisé créé par l’API Collecteur de données -- les colonnes dépassant la limite sont ajoutées à la colonne « AdditionalFields » dynamique Journal personnalisé -- contacter le support technique pour découvrir plus d’informations |
| Nombre maximal de tables de journaux personnalisées | 500 | Contacter le support technique pour en savoir plus |
| Nombre maximum de caractères pour le nom de colonne | 45 |
Débit d’ingestion de données
Azure Monitor est un service de données à grande échelle qui sert des milliers de clients envoyant des téraoctets de données chaque jour et à un rythme croissant. Une limite souple du débit en volume vise à isoler les clients Azure Monitor des pics d’ingestion soudains dans un environnement multilocataire. Le seuil par défaut du débit en volume d’ingestion dans les espaces de travail est de 500 Mo (compressé), ce qui se traduit par environ 6 Go/min non compressé.
La limite du débit du volume s’applique aux données ingérées à partir de ressources Azure via les Paramètres de diagnostic et l’API Collecteur de données. Quand la limite du débit en volume est atteinte, un mécanisme de nouvelle tentative tente d’ingérer les données quatre fois sur une période de 12 heures et de les supprimer si l’opération échoue. Elle ne s’applique pas aux données ingérées à partir d’agents ou de la Règle de collecte de données.
Quand les données envoyées à un espace de travail sont à un débit supérieur à 80 % du seuil configuré dans votre espace de travail, un événement est envoyé au tableau Operation de votre espace de travail toutes les 6 heures tant que le seuil continue d’être dépassé. Quand le débit de volume ingéré est plus élevé que le seuil, des données sont supprimées et un événement est envoyé toutes les 6 heures dans la table Operation de votre espace de travail tant que le seuil continue d’être dépassé.
Si votre débit en volume d’ingestion continue de dépasser le seuil ou si vous pensez l’atteindre bientôt, vous pouvez demander l’augmentation de cette limite en ouvrant une demande de support.
Il est également recommandé de créer une règle d’alerte pour être notifié de façon proactive quand vous atteignez les limites d’ingestion. Consultez Superviser l’intégrité d’un espace de travail Log Analytics dans Azure Monitor.
Remarque
En fonction de la durée pendant laquelle vous utilisez Log Analytics, vous pouvez avoir accès aux niveaux de tarification hérités. En savoir plus sur les niveaux tarifaires hérités de Log Analytics.
Application Insights
Il existe certaines limites au nombre de métriques et d’événements par application, c’est-à-dire, par clé d’instrumentation. Les limites varient selon le plan de tarification que vous choisissez.
| Ressource | Limite par défaut | Limite maximale | Notes |
|---|---|---|---|
| Total des données par jour | 100 Go | Contactez le support technique. | Vous pouvez définir une limite pour réduire les données. Si vous avez besoin de davantage de données, vous pouvez augmenter la limite dans le portail, jusqu’à 1 000 Go. Pour une capacité supérieure à 1 000 Go, envoyez un e-mail à AIDataCap@microsoft.com. |
| Limitation | 32 000 événements/seconde | Contactez le support technique. | La limite est mesurée par minute. |
| Journaux de conservation des données | 30 à 730 jours | 730 jours | Cette ressource est destiné aux journaux. |
| Métriques de conservation des données | 90 jours | 90 jours | Cette ressource est destinée à Metrics Explorer. |
| Conservation des résultats détaillés du test de disponibilité à plusieurs étapes | 90 jours | 90 jours | Cette ressource fournit des résultats détaillés de chaque étape. |
| Taille maximale des éléments de télémétrie | 64 Ko | 64 Ko | |
| Nombre maximal d’éléments de télémétrie par lot | 64 000 | 64 000 | |
| Longueur des noms de propriétés et de mesures | 150 | 150 | Consultez les schémas par type. |
| Longueur de chaîne de valeur de propriété | 8 192 | 8 192 | Consultez les schémas par type. |
| Longueur des messages de trace et d’exception | 32,768 | 32,768 | Consultez les schémas par type. |
| Nombre de tests de disponibilité par ressource Application Insights | 100 | 100 | |
| Nombre de tests de disponibilité par groupe de ressources | 800 | 800 | Consultez Azure Resource Manager |
| Tests de disponibilité nombre maximal de redirections par test | 10 | 10 | |
| Tests de disponibilité fréquence minimale des tests | 300 secondes | Les fréquences de test personnalisées ou les fréquences inférieures à 5 minutes nécessitent implémentations personnalisées de TrackAvailability . | |
| Conservation des données du Profileur .NET et du Débogueur de capture instantanée | Deux semaines | Contactez le support technique. La limite maximale de conservation est de six mois. | |
| Données du Profileur .NET envoyées par jour | Aucune limite | Aucune limite. | |
| Données du Débogueur de capture instantanée envoyées par jour | 30 instantanés par jour par application monitorée | Aucune limite. | Le nombre d’instantanés collectés par application peut être modifié dans la configuration. |
Pour plus d’informations sur la tarification et les quotas, consultez Facturation d’Application Insights.
Étendue de liaison privée Azure Monitor (AMPLS)
Les objets AMPLS ont les limites suivantes :
- Un réseau virtuel ne peut pas se connecter à un seul objet AMPLS. Cela signifie que l’objet AMPLS doit fournir l’accès à toutes les ressources Azure Monitor auxquelles le réseau virtuel doit avoir accès.
- Un objet AMPLS peut se connecter à 300 espaces de travail Log Analytics et 1 000 composants Application Insights au maximum.
- Une ressource Azure Monitor peut se connecter à cinq étendues AMPLS au maximum.
- Un objet AMPLS peut se connecter à jusqu’à 10 points de terminaison privés.