Ce document liste les quotas et les limites du système qui s'appliquent Cloud Monitoring. Les quotas spécifient la quantité d'une ressource partagée dénombrable que vous pouvez utiliser. Ils sont définis par des services Google Cloud tels que Cloud Monitoring. Les limites système sont des valeurs fixes qui ne peuvent pas être modifiées.
Google Cloud utilise des quotas pour garantir l'équité et réduire les pics d'utilisation et de disponibilité des ressources. Un quota limite la quantité de ressources Google Cloud que votre projet Google Cloud peut utiliser. Les quotas s'appliquent à différents types de ressources, y compris les composants matériels, logiciels et réseau. Par exemple, les quotas peuvent limiter le nombre d'appels d'API à un service, le nombre d'équilibreurs de charge utilisés simultanément par votre projet ou le nombre de projets que vous pouvez créer. Les quotas protègent la communauté des utilisateurs de Google Cloud en empêchant la surcharge des services. Les quotas vous aident également à gérer vos propres ressources Google Cloud.
Le système Cloud Quotas effectue les opérations suivantes :
- Surveille votre consommation de produits et services Google Cloud
- Limite votre consommation de ces ressources
- Permet de demander des modifications de la valeur du quota
Dans la plupart des cas, lorsque vous tentez d'utiliser plus d'une ressource que son quota ne le permet, le système bloque l'accès à la ressource et la tâche que vous essayez d'effectuer échoue.
Les quotas s'appliquent généralement au niveau du projet Google Cloud. Votre utilisation d'une ressource dans un projet n'affecte pas votre quota disponible dans un autre projet. Dans un projet Google Cloud, les quotas sont partagés entre toutes les applications et adresses IP.
Pour ajuster la plupart des quotas, utilisez la console Google Cloud. Pour en savoir plus, consultez Demandez un ajustement de quota.
Des limites du système s'appliquent également aux ressources Monitoring. Les limites du système ne peuvent pas être modifiées.
Métriques définies par l'utilisateur
La page Gestion des métriques de Cloud Monitoring fournit des informations qui peuvent vous aider à contrôler les sommes que vous consacrez aux métriques facturables, sans affecter l'observabilité. La page Gestion des métriques fournit les informations suivantes :
- Les volumes d'ingestion pour la facturation à base d'octets et celle à base d'exemples, englobant les différents domaines de métriques et des métriques individuelles
- Les données sur les libellés et la cardinalité des métriques
- Nombre de lectures pour chaque métrique.
- L'utilisation de métriques dans les règles d'alerte et les tableaux de bord personnalisés
- Les taux d'erreurs d'écriture de métriques
Vous pouvez également utiliser la gestion des métriques pour exclure les métriques inutiles, ce qui élimine les coûts d'ingestion. Pour en savoir plus sur la Gestion des métriques, consultez la section Afficher et gérer l'utilisation des métriques.
| Catégorie | Valeur maximale |
|---|---|
| Descripteurs de métriques personnalisées par projet1 | 10 000 |
| Libellés par descripteur de métrique | 30 |
| Longueur de chaîne d'une clé de libellé | 100 |
| Longueur de chaîne d'une valeur de libellé | 1 024 |
| Séries temporelles incluses dans une requête d'écriture2 | 200 |
| Fréquence d'écriture des données dans une série temporelle unique3 | un point pour chaque tranche de 5 secondes |
| Buckets d'histogrammes par métrique de distribution personnalisée | 200 |
| Descripteurs de métriques de charge de travail, Prometheus et externes4 par projet | 25 000 |
| Séries temporelles actives des métriques personnalisées par ressource surveillée5 | 200 000 |
| Séries temporelles actives des métriques de charge de travail par ressource surveillée5 | 200 000 |
| Séries temporelles actives de Prometheus par ressource surveillée5 | 1 000 000 |
| Séries temporelles actives des métriques externes par ressource surveillée5 | 200 000 |
| Fréquence de création des descripteurs de métrique | 6 000 par minute et par projet |
1 Cette limite est imposée par Cloud Monitoring. Autres services
peut imposer des valeurs maximales inférieures. Les métriques personnalisées sont celles qui sont écrites
custom.googleapis.com.
2 Vous ne pouvez ajouter qu'un seul point de données pour chaque série temporelle d'une requête. Cette limite correspond donc également au nombre maximal de points pouvant être ajoutés par requête.
3
L'API Cloud Monitoring nécessite que les heures de fin des points écrits dans une série temporelle soit espacées d'au moins cinq secondes. Si les points de données sont écrits dans l'ordre, vous pouvez les écrire par lot dans une série temporelle.
<ph type="x-smartling-placeholder"></ph>
4.
Les métriques externes sont celles qui sont écrites dans external.googleapis.com.
<ph type="x-smartling-placeholder"></ph>
5.
Une série temporelle est active si vous y avez ajouté des points de données
au cours des dernières 24 heures.
La limite spécifiée dans la ligne correspond au nombre total de séries temporelles actives pour une seule ressource surveillée (par exemple, une seule VM gce_instance ou un seul conteneur k8s_container) sur l'ensemble des métriques définies par l'utilisateur de cette ligne (personnalisées, de charge de travail, Prometheus ou externes). Une
l'exception est la ressource surveillée global, pour laquelle la limite s'applique
chaque métrique définie par l'utilisateur séparément. Il s'agit d'une limite de sécurité à l'échelle du système et
n'est pas personnalisable.
Quotas et limites de l'API Monitoring
| Catégorie | Valeur maximale |
|---|---|
| Limites d'utilisation de l'API |
Pour connaître les quotas et les limites de l'API, effectuez l'une des opérations suivantes:
|
| Durée de vie des jetons de page de l'API | 24 heures |
À propos des quotas de l'API Monitoring
L'API Monitoring présente des limites de quota pour les taux de requêtes d'ingestion de séries temporelles et de requêtes de séries temporelles. Les requêtes d'ingestion sont des appels qui écrivent des données de séries temporelles, tandis que les requêtes de séries temporelles récupèrent des données de séries temporelles. Des limites internes s'appliquent également à d'autres points de terminaison de l'API Monitoring, car ceux-ci ne sont pas destinés à gérer des taux élevés de requêtes.
Pour réduire le nombre de requêtes API émises lorsque vos services écrivent des données de séries temporelles, utilisez une requête API pour écrire des données pour plusieurs séries temporelles.
Nous vous recommandons d'écrire au moins 10 objets par requête.
Pour en savoir plus sur le traitement des requêtes API par lot, consultez
timeSeries.create
Si vous avez toujours besoin d'augmenter les limites de quota de l'API Monitoring après avoir traité vos requêtes API par lots, contactez l'assistance Google Cloud.
Les autres limites sont fixes et sont détaillées sur cette page.
Pour en savoir plus, consultez la page Utiliser des quotas.
Conservation des données
Les points de données des métriques plus anciens que la durée de conservation sont supprimés de la série temporelle.
| Catégorie | Valeur |
|---|---|
Rétention des points de données des types de métriques personnalisées, externes et d'agents, y compris :
|
24 mois1 |
Rétention des points de données des types de métriques d'état de processus : agent.googleapis.com/processes, , à l'exception de count_by_state et fork_state, comme indiqué dans l'entrée précédente. |
24 heures |
| Rétention des points de données de tous les autres types de métriques, y compris : | 6 semaines |
| Durée de vie des jetons de page de l'API | 24 heures |
1 Pendant 6 semaines, les données de métriques sont stockées selon leur fréquence d'échantillonnage d'origine. Passé cette période, les données continuent d'être stockées, mais l'échantillonnage est réalisé moins souvent, par intervalles de 10 minutes.
2 Les données de métriques Google Cloud Managed Service pour Prometheus sont stockées
1 semaine à sa valeur d'origine
d'échantillonnage de la fréquence d'échantillonnage, il est sous-échantillonné à des intervalles d'une minute
pendant cinq semaines, puis les données sont sous-échantillonnées à des intervalles de 10 minutes pour le stockage étendu.
Groupes de ressources
| Catégorie | Valeur |
|---|---|
| Nombre de groupes de ressources par champ d'application des métriques | 500 |
| Nombre maximum de groupes inclus dans un rapport par e-mail1 | 10 |
1 Lorsque vous configurez les rapports Cloud Monitoring envoyés par e-mail, vous pouvez demander à recevoir des informations sur l'utilisation de vos groupes de ressources. En raison de limitations techniques liées à l'outil de génération de rapports par e-mail, seuls 10 groupes peuvent être inclus dans un même rapport.
Limites de projet surveillé
Cloud Monitoring est officiellement compatible avec 375 projets Google Cloud au maximum par champ d'application des métriques.
Vous pouvez ajouter jusqu'à 1 000 projets Google Cloud par champ d'application des métriques. mais vous risquez de rencontrer des problèmes de performances, en particulier lorsque vous interrogez des métriques ou des données historiques. Cloud Monitoring garantit des requêtes performantes et graphiques pour 375 projets Google Cloud par champ d'application des métriques .
Pour augmenter le quota de projets Google Cloud par champ d'application des métriques, vous pouvez demander une augmentation du quota "Projets surveillés/Champ d'application des métriques de surveillance". Pour en savoir plus, consultez la documentation sur la gestion de votre quota.
Limites concernant la création et la mise à jour des descripteurs de métrique
Cloud Monitoring applique une limite de débit par minute pour la création de métriques, l'ajout de nouveaux noms d'étiquettes aux métriques existantes et la suppression de métriques. Cette limite de débit n'est généralement atteinte que lors de la première intégration à Cloud Monitoring, par exemple lorsque vous migrer un déploiement Prometheus existant et mature vers Cloud Monitoring ; Il ne s'agit pas d'une limite de débit pour l'ingestion de points de données. Cette limite de débit s'applique uniquement à la création de métriques qui n'existaient pas auparavant ou à l'ajout de nouveaux noms de libellés aux métriques existantes.
Ce quota est fixe, mais les problèmes éventuels doivent être automatiquement résolus à mesure que de nouvelles métriques et de nouveaux libellés de métriques sont créés dans la limite définie par minute.
Limites d'alerte
| Catégorie | Valeur | Type de règle1 |
|---|---|---|
| Règles d'alerte (somme des métriques et des journaux) par champ d'application des métriques2 | 500 | Métrique, journal |
| Conditions par règle d'alerte basée sur les métriques | 6 | Métrique |
| Conditions par règle d'alerte basée sur SQL (version preview publique) | 1 | SQL |
| Période maximale qu'une condition d'absence de métrique évalue3 |
1 jour | Métrique |
| Période maximale qu'une condition de seuil de métrique évalue3 |
23 heures 30 minutes | Métrique |
| Longueur maximale du filtre utilisé dans une condition de seuil de métrique |
2 048 caractères Unicode | Métrique |
| Nombre maximal de séries temporelles surveillé par une condition de prévision |
64 | Métrique |
| Période de prévision minimale | 1 heure (3 600 secondes) | Métrique |
| Période de prévision maximale | 2,5 jours (216 000 secondes) | Métrique |
| Canaux de notification par règle d'alerte | 16 | Métrique, journal |
| Taux maximal de notifications4 | 1 notification toutes les 5 minutes pour chaque règle d'alerte basée sur les journaux | Journal |
| Nombre maximal de notifications | 20 notifications par jour pour chaque règle d'alerte basée sur les journaux | Journal |
| Nombre maximal d'incidents ouverts simultanément par règle d'alerte |
1 000 | Métrique |
| Période après laquelle un incident sans nouvelle donnée est automatiquement fermé |
7 jours | Métrique |
| Durée maximale d'un incident s'il n'est pas fermé manuellement | 7 jours | Journal |
| Conservation des incidents fermés | 13 mois | Non applicable |
| Conservation des incidents ouverts | Indéfiniment | Non applicable |
| Canaux de notification par champ d'application des métriques | 4 000 | Non applicable |
| Nombre maximal de règles d'alerte par mise en veille | 16 | Métrique, journal |
| Conservation d'une répétition | 13 mois | Non applicable |
2 Apigee et Apigee hybrid sont étroitement intégrés à Cloud Monitoring. La limite d'alerte pour tous les niveaux d'abonnements Apigee (Standard, Enterprise et Enterprise Plus) est la même que pour Cloud Monitoring : 500 par champ d'application de métriques.
3 La période maximale qu'une condition évalue est la somme de la période d'alignement et des valeurs d'intervalle de temps. Par exemple, si la période d'alignement est définie sur 15 heures et que l'intervalle de temps est défini sur 15 heures, 30 heures de données sont nécessaires pour évaluer la condition.
4 Si la requête de votre règle d'alerte basée sur les journaux extrait des valeurs d'étiquette, puis chaque combinaison de valeurs extraites représente sa propre chronologie de notification. Par exemple, supposons qu'une règle d'alerte basée sur les journaux extrait les valeurs d'un libellé. Supposons que le libellé puisse avoir deux valeurs. Avec cette configuration, vous pouvez recevoir deux notifications, une pour chaque valeur de libellé, dans le même 5 minutes
Limites pour la surveillance synthétique
| Catégorie | Valeur |
|---|---|
| Tests de disponibilité par champ d'application des métriques * | 100 |
| Nombre maximal de pings ICMP par test de disponibilité public | 3 |
| Surveillance synthétique par champ d'application des métriques | 100† |
†Pour savoir comment augmenter cette limite, consultez la section Gérer votre quota avec la console Google Cloud.
Limites concernant les graphiques
| Catégorie | Valeur |
|---|---|
| Tableaux de bord par champ d'application des métriques | 1000 |
| Graphiques sur un tableau de bord | 40 |
| Lignes sur un graphique | 50* |
| Lignes d'une table | 300 |
To improve performance, we've limited the time series displayed in this chart
Pour afficher toutes les séries temporelles, développez l'info-bulle et
sélectionnez le bouton Show All Time Series (Afficher toutes les séries temporelles).
Objectifs de niveau de service
| Catégorie | Valeur |
|---|---|
| Nombre de SLO par service | 500 |