Pour des fonctionnalités similaires à celles d'Amazon Timestream pour, pensez à Amazon Timestream LiveAnalytics pour InfluxDB. Il permet une ingestion simplifiée des données et des temps de réponse aux requêtes à un chiffre en millisecondes pour des analyses en temps réel. Pour en savoir plus, cliquez ici.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Surveillance et optimisation de la configuration pour Timestream pour InfluxDB 2
Présentation de
Une surveillance et une optimisation de la configuration efficaces sont essentielles pour maintenir des performances, une fiabilité et une rentabilité optimales dans votre déploiement Timestream for InfluxDB. Ce guide fournit des conseils complets sur CloudWatch les métriques, les seuils de performance et les stratégies de réglage de la configuration pour vous aider à gérer de manière proactive vos instances InfluxDB.
CloudWatch Référence des métriques
Amazon CloudWatch fournit des métriques détaillées pour surveiller votre flux temporel pour les instances InfluxDB. Il est essentiel de comprendre ces indicateurs et leurs seuils pour maintenir la santé et les performances du système.
Mesures d'utilisation des ressources
| CloudWatch Nom de la métrique | Dimensions | Description | Unit | Seuils recommandés |
|---|---|---|---|---|
| CPUUtilization | DbInstanceName | Pourcentage de CPU utilisé | Pourcentage |
|
| MemoryUtilization | DbInstanceName | Pourcentage de mémoire utilisée | Pourcentage |
|
| HeapMemoryUsage | DbInstanceName | Quantité de mémoire en tas utilisée | Octets |
|
| ActiveMemoryAllocation | DbInstanceName | Allocation de mémoire active actuelle | Octets |
|
| DiskUtilization | DbInstanceName | Pourcentage d'espace disque utilisé | Pourcentage |
|
Métriques des opérations d'E/S
| CloudWatch Nom de la métrique | Dimensions | Description | Unit | Seuils recommandés |
|---|---|---|---|---|
| ReadOpsPerSec | DbInstanceName | Nombre d'opérations de lecture par seconde | Nombre/seconde | Maintenir une marge de manœuvre supérieure ou égale à 30 % en dessous des IOPS provisionnées Exemple : 12 000 IOPS → conserver un total inférieur à 8 400 IOPS |
| WriteOpsPerSec | DbInstanceName | Nombre d'opérations d'écriture par seconde | Nombre/seconde | Maintenir une marge de manœuvre supérieure ou égale à 30 % en dessous des IOPS provisionnées Exemple : 12 000 IOPS → conserver un total inférieur à 8 400 IOPS |
| Total IOps PerSec | DbInstanceName | Nombre total I/O d'opérations par seconde (lecture et écriture) | Nombre/seconde | Maintenir une marge de manœuvre supérieure ou égale à 30 % en dessous des IOPS provisionnées Surveillance par rapport aux capacités des classes d'instances |
Métriques de débit
| CloudWatch Nom de la métrique | Dimensions | Description | Unit | Seuils recommandés |
|---|---|---|---|---|
| ReadThroughput | DbInstanceName | Débit de lecture des données | Octets/seconde | Surveillance par rapport aux limites de débit de stockage |
| WriteThroughput | DbInstanceName | Débit d'écriture des données | Octets/seconde | Surveillance par rapport aux limites de débit de stockage |
Mesures de performance des API
| CloudWatch Nom de la métrique | Dimensions | Description | Unit | Seuils recommandés |
|---|---|---|---|---|
| APIRequestTaux | DbInstanceName, point de terminaison, statut | Taux de demandes d'API adressées à des points de terminaison spécifiques avec des codes d'état (2xx, 4xx, 5xx) | Nombre/seconde |
Taux d'erreur :
|
| QueryResponseVolume | DbInstanceName, point de terminaison, statut | Volume de réponses aux requêtes par point de terminaison et code d'état | Octets |
|
Métriques d'exécution des requêtes
| CloudWatch Nom de la métrique | Dimensions | Description | Unit | Seuils recommandés |
|---|---|---|---|---|
| QueryRequestsTotal | DbInstanceName, Résultat | Nombre total de requêtes par type de résultat (success, runtime_error, compile_error, queue_error) | Nombre |
Taux de réussite : > 99 % Taux d'erreur :
|
Mesures relatives à l'organisation des données
| CloudWatch Nom de la métrique | Dimensions | Description | Unit | Seuils critiques |
|---|---|---|---|---|
| SeriesCardinality | DbInstanceName, Seau | Nombre de séries chronologiques uniques dans un compartiment | Nombre |
|
| TotalBuckets | DbInstanceName | Nombre total de compartiments dans l'instance | Nombre |
|
Mesures de santé du système
| CloudWatch Nom de la métrique | Dimensions | Description | Unit | Seuils recommandés |
|---|---|---|---|---|
| EngineUptime | DbInstanceName | Durée d'exécution du moteur InfluxDB | Secondes | Surveillez les redémarrages inattendus Alerte : le temps de disponibilité est réinitialisé de façon inattendue |
| WriteTimeouts | DbInstanceName | Nombre d'opérations d'écriture dont le délai a expiré | Nombre | Alerte : > 0,1 % des opérations d'écriture Critique : tendance à la hausse |
Métriques de gestion des tâches
| CloudWatch Nom de la métrique | Dimensions | Description | Unit | Seuils recommandés |
|---|---|---|---|---|
| ActiveTaskWorkers | DbInstanceName | Nombre de travailleurs actifs | Nombre | Surveiller par rapport à la limite de tâches configurée Alerte : Toujours au maximum |
| TaskExecutionFailures | DbInstanceName | Nombre d'exécutions de tâches ayant échoué | Nombre | Alerte : > 1 % des exécutions de tâches Critique : augmentation du taux d'échec |
Comprendre les principales relations entre les métriques
Relation entre les IOPS et le débit
La règle des 30 % de marge de manœuvre : maintenez toujours une marge de manœuvre d'au moins 30 % entre vos opérations soutenues par seconde et vos IOPS provisionnées. Cela fournit une mémoire tampon pour :
Opérations de compactage (peuvent augmenter considérablement le nombre d'IOPS)
Tout redémarrage de base de données pour un fonctionnement fluide
Nombre de requêtes en rafale pendant les pics d'utilisation
Écrire les pics dus à l'ingestion par lots
Opérations de maintenance de l'index
Exemple de calcul :
IOPS provisionnées : 12 000
Nombre maximal d'IOPS soutenues cible (total IOpsPerSec) : 8 400 (70 % d'utilisation)
marge de manœuvre réservée : 3 600 IOPS (30 %)
Si le total dépasse IOps PerSec régulièrement 8 400 : → Améliorez le niveau de stockage ou optimisez la charge de travail
Formule de surveillance :
% d'utilisation des IOPS = (ReadOpsPerSec + WriteOpsPerSec)/IOPS provisionnées × 100
Objectif : maintenir le taux d'utilisation des IOPS à moins de 70 %
Avertissement : utilisation des IOPS > 70 %
Critique : utilisation des IOPS > 90 %
Comprendre l'impact de la cardinalité des séries sur les performances
La cardinalité des séries a un effet multiplicatif sur les ressources du système :
| Nombre de séries | Impact sur la mémoire | Impact sur les performances des requêtes | Impact de la taille de l'indice | Recommandation |
|---|---|---|---|---|
| < 100 000 | Minimale | Négligeable | Petit | Configuration standard |
| 100 KM - 1 M | Modérée | 10 à 20 % plus lent | Moyenne | Régler les paramètres du cache |
| 1 M À 5 M | Important | 30 à 50 % plus lent | Grand | Optimisation agressive requise |
| 5 M À 10 M | Élevée | 50 à 70 % plus lent | Très grand | Réglage maximal, pensez à une refonte |
| > 10 M | Sévère | 70 % plus lent | Excessif | Migrer vers InfluxDB 3.0 |
Pourquoi 10 millions de dollars sont le seuil critique :
L'architecture InfluxDB 2.x utilise l'indexation en mémoire
Au-delà de la série 10M, les opérations indicielles deviennent d'un coût prohibitif
Les besoins en mémoire augmentent de manière non linéaire
La charge de planification des requêtes augmente considérablement
InfluxDB 3.0 utilise un moteur de stockage en colonnes conçu pour une cardinalité élevée
Directives relatives au dimensionnement et aux performances des instances
Le tableau suivant fournit des conseils sur le dimensionnement d'instance approprié en fonction de la cardinalité de votre série et des caractéristiques de charge de travail :
| Nombre maximum de séries | Écritures (lignes/sec) | Lectures (requêtes/sec) | Instance recommandée | Type de stockage | Cas d'utilisation |
|---|---|---|---|---|---|
| < 100 000 | ~50 000 | < 10 | db.influx.large | Influx IO inclus 3K | Petits déploiements, développement, tests |
| < 1 M | ~150 000 | < 25 | db.influx.2xlarge | Influx IO inclus 3K | Charges de travail de production petites à moyennes |
| ~1 M | ~200 000 | ~25 | db.influx.4xlarge | Influx IO inclus 3K | Charges de travail de production moyennes |
| < 5 M | ~250 000 | ~35 | db.influx.4xlarge | Influx IO inclus 12K | Charges de travail de production importantes |
| < 10 M | ~500 000 | ~50 | db.influx x 8 x large | Influx IO inclus 12K | Charges de travail de production très importantes |
| ~10 M | < 750 000 | < 100 | db.influx 12 x large | Influx IO inclus 12K | Capacité maximale d'InfluxDB 2.x |
| > 10 M | N/A | N/A | Migrer vers InfluxDB 3.0 | N/A | Au-delà de la plage optimale d'InfluxDB 2.x |
Optimisation de la configuration par métrique
Taux d'utilisation élevé du processeur (CPUUtilization > 70 %)
Symptômes :
CPUUtilization> 70 % soutenu
QueryRequestsTotal(volume élevé ou requêtes lentes)
ActiveTaskWorkers(charge de travail élevée)
Ajustements de configuration :
Priorité 1 : contrôler la simultanéité des requêtes
simultanéité des requêtes : définie sur 50 à 75 % du nombre de vCPU
Exemple : instance de 8 vCPU → query-concurrency = 4-6
Priorité 2 : Limiter la complexité des requêtes
influxql-max-select-series: 10000 (empêche les requêtes illimitées)
influxql-max-select-point: 100 000 000
query-queue-size: 2048 (empêche l'accumulation de files d'attente)
Priorité 3 : Activer l'analyse des requêtes
flux-log-enabled: TRUE (temporairement pour le débogage)
log-level : info (ou debug pour une analyse détaillée)
Considérations importantes :
La réduction query-concurrency limitera le nombre de requêtes pouvant être exécutées simultanément, ce qui peut augmenter le nombre de requêtes en file d'attente et augmenter la latence des requêtes pendant les périodes de pointe. Les utilisateurs peuvent être confrontés à des chargements de tableau de bord plus lents ou à des délais d'expiration des rapports si la demande de requêtes dépasse la limite de simultanéité réduite.
La définition de limites de protection (influxql-max-select-series,influxql-max-select-point) entraînera l'échec des requêtes dépassant ces seuils lorsque compile_error ou runtime_error sont insérés. QueryRequestsTotal Bien que cela protège le système contre l'épuisement des ressources, cela peut interrompre les requêtes existantes qui fonctionnaient auparavant.
Bonne pratique : Avant d'appliquer ces modifications, analysez vos modèles de requêtes à l'aide QueryResponseVolumede QueryRequestsTotalmétriques. Identifiez et optimisez d'abord les requêtes les plus coûteuses : recherchez les requêtes sans filtres temporels, les requêtes couvrant des séries à cardinalité élevée ou les requêtes demandant un nombre excessif de points de données. Il est toujours préférable d'optimiser les requêtes au niveau de l'application plutôt que d'imposer des limites strictes susceptibles de perturber les fonctionnalités.
Actions relatives au matériel :
Passez à la classe d'instance suivante avec plus de v CPUs
Passez en revue les modèles de requêtes pour identifier les opportunités d'optimisation
Utilisation élevée de la mémoire (MemoryUtilization > 70 %)
Symptômes :
MemoryUtilization> 70 % soutenu
HeapMemoryUsagetendance à la hausse
ActiveMemoryAllocationmontrant des pointes
SeriesCardinality(une cardinalité élevée augmente l'utilisation de la mémoire)
Ajustements de configuration :
Priorité 1 : réduire la mémoire cache
storage-cache-max-memory-taille : définie sur 10 à 15 % de la RAM totale
Exemple : 32 Go de RAM → 3 355 443 200 à 5 033 164 800 octets
storage-cache-snapshot-memory-taille : 26 214 400 (25 MB)
Priorité 2 : Limiter la mémoire des requêtes
query-memory-bytes: défini sur 60 à 70 % de la RAM totale
query-max-memory-bytes: Identique à query-memory-bytes
query-initial-memory-bytes: 10 % des query-memory-bytes
Priorité 3 : optimiser le cache de la série
storage-series-id-set-cache-size : réduit en cas de cardinalité élevée
Mémoire élevée : 100-200
Normale : 500-1000
Considérations importantes :
Bien que ces modifications réduisent la pression sur la mémoire, elles auront un impact négatif direct sur les performances des applications. La réduction storage-cache-max-memory-size signifie que moins de données sont mises en cache dans la mémoire, ce qui entraîne une augmentation du nombre de lectures sur le disque et une augmentation de la latence des requêtes. Vous constaterez probablement une ReadOpsPerSecaugmentation et QueryResponseVolumeune baisse des temps de réponse.
La limitation query-memory-bytes entraînera l'échec des requêtes gourmandes en mémoire lorsque runtime_error est activé QueryRequestsTotal, en particulier les requêtes qui regroupent de grands ensembles de données ou renvoient des ensembles de résultats substantiels. Les utilisateurs peuvent rencontrer des erreurs « mémoire insuffisante » pour les requêtes qui ont déjà abouti.
La réduction storage-series-id-set-cache-size réduit les performances des requêtes portant sur des données à cardinalité élevée, car le système doit recalculer les résultats des séries plus fréquemment au lieu de les récupérer du cache. Cela concerne particulièrement les tableaux de bord qui interrogent de manière répétée les mêmes combinaisons de séries.
Bonne pratique : Avant d'appliquer ces modifications restrictives, analysez vos modèles de requêtes et optimisez-les d'abord :
Révision QueryResponseVolumepour identifier les requêtes renvoyant des données excessives
QueryRequestsTotalÀ utiliser pour rechercher les requêtes fréquemment exécutées qui pourraient bénéficier d'une optimisation
Ajoutez des filtres de plage de temps pour réduire l'analyse des données à ce qui est nécessaire pour votre charge de travail
Implémenter la mise en cache des résultats des requêtes au niveau de l'application
Envisagez de pré-agréger les données à l'aide de tâches de sous-échantillonnage
Passez en revue SeriesCardinalityet optimisez votre modèle de données afin de réduire le nombre de balises inutiles
L'optimisation des requêtes doit toujours être votre première approche. Les restrictions de configuration doivent être utilisées en dernier recours lorsque l'optimisation n'est pas suffisante.
Actions relatives au matériel :
Augmenter la taille de l'instance pour augmenter la mémoire vive
Taux d'utilisation élevé du stockage (DiskUtilization > 70 %)
CloudWatch Indicateurs à surveiller :
DiskUtilization> 70 %
WriteThroughputmotifs
TotalBuckets(de nombreux seaux augmentent les frais généraux)
Ajustements de configuration :
Priorité 1 : vérifier la configuration de journalisation
log-level : Assurez-vous que le paramètre est défini sur « info » (et non sur « debug »)
flux-log-enabled: défini sur FALSE sauf en cas de débogage actif
Priorité 2 : rétention agressive
storage-retention-check-interval: 150 ms (nettoyage plus fréquent)
Priorité 3 : optimiser le compactage
storage-compact-full-write-durée du froid : 2h0m0s (plus fréquent)
storage-cache-snapshot-write- durée du froid : 50 ms
Priorité 4 : Réduire la taille de l'index
storage-max-index-log-taille du fichier : 524 288 (512 Ko pour un compactage plus rapide)
Considérations importantes :
Première étape essentielle - Vérifiez votre configuration de journalisation : avant d'apporter d'autres modifications, vérifiez vos paramètres de journalisation. La journalisation du débogage et les journaux de requêtes Flux peuvent consommer autant ou plus d'espace disque que vos données chronologiques réelles, ce qui constitue l'une des causes les plus fréquentes d'épuisement inattendu du stockage.
Impact sur la journalisation :
log-level: debuggénère des journaux extrêmement détaillés, pouvant atteindre des centaines de Mo par heureflux-log-enabled: TRUEenregistre chaque exécution de requête Flux avec tous les détails, créant ainsi des fichiers journaux volumineuxCes journaux s'accumulent rapidement et sont souvent négligés lors de la planification des capacités
Les fichiers journaux peuvent remplir l'espace disque plus rapidement que l'ingestion de données, en particulier sur les petites instances
Contrairement aux données de séries chronologiques, les journaux sont conservés dans le stockage local pendant 24 heures avant d'être supprimés
Actions immédiates si les journaux sont volumineux :
Set
log-level: info(à partir du débogage)Définir
flux-log-enabled: FALSESurveillez DiskUtilizationpour une amélioration immédiate
Compromis en matière de configuration de compactage :
Ces modifications de configuration sont spécifiquement conçues pour les charges de travail présentant un débit d'ingestion élevé et des fenêtres de rétention courtes où l'utilisation du disque fluctue considérablement. Ils obligent le moteur de compactage à fonctionner de manière plus agressive, ce qui n'est bénéfique que dans des scénarios spécifiques.
Compromis essentiels : l'augmentation de la fréquence de compactage augmentera considérablement la consommation de ressources :
CPUUtilizationaugmentera à mesure que les opérations de compactage consomment des cycles du processeur
MemoryUtilizationaugmentera pendant le compactage à mesure que les données sont chargées et traitées
WriteOpsPerSecet WriteThroughputaugmentera pendant les fenêtres de compactage, dépassant potentiellement votre marge de 30 % d'IOPS
WriteTimeoutspeut augmenter si le compactage entre en I/O concurrence avec les écritures de l'application
Ces modifications peuvent créer un problème de performance en cascade : le compactage agressif consomme les ressources nécessaires aux opérations de requête et d'écriture, dégradant ainsi les performances globales du système tout en réduisant l'utilisation du disque.
Bonne pratique : Avant de régler les paramètres de compactage, concentrez-vous sur la gestion des données et de la journalisation :
Vérifiez d'abord la journalisation (problème le plus courant) : vérifiez que le niveau du journal est « info » et flux-log-enabled qu'il est FAUX
Passez en revue votre modèle de données : écrivez-vous des données dont vous n'avez pas réellement besoin ? Pouvez-vous réduire la granularité des mesures ou des champs ?
Optimisation des politiques de rétention : vérifiez TotalBucketset passez en revue les paramètres de rétention pour chaque compartiment
Surveillez l'impact du compactage : établissez CPUUtilizationune base de référence pour et WriteOpsPerSecavant les modifications MemoryUtilization
Approches alternatives :
Augmenter la capacité de stockage (souvent plus simple et plus rentable)
Mettre en œuvre des stratégies de sous-échantillonnage ou d'agrégation des données
Consolider les compartiments (réduire TotalBuckets) pour réduire les frais généraux
Réviser et appliquer les politiques de rétention de manière plus stricte
N'appliquez des paramètres de compactage agressifs que si vous avez optimisé la gestion des données et confirmé que votre instance dispose d'un processeur, d'une mémoire et d'une marge d'IOPS suffisants pour faire face à l'augmentation de la charge.
Actions relatives au matériel :
Augmenter la capacité de stockage
Taux d'utilisation élevé des IOPS (ReadIOPS/WriteIOPS/TotalOperationsPerSecond> 70 % des opérations provisionnées)
CloudWatch Indicateurs à surveiller :
ReadOpsPerSec+ WriteOpsPerSec= Total IOps PerSec
ReadThroughput et WriteThroughput
Comparaison avec les IOPS provisionnées (3 000, 12 000 ou 16 000 unités)
Ajustements de configuration :
Priorité 1 : Contrôler le compactage des E/S
storage-max-concurrent-compactions: 2-3 (limite les compactages simultanés)
storage-compact-throughput-burst: Ajustez en fonction de la capacité du disque
3 000 IOPS : 25 165 824 (24 Mo/s)
12 000 IOPS : 50 331 648 (48 Mo/s)
Priorité 2 : optimiser les opérations d'écriture
storage-wal-max-concurrent-écrit : 8-12
storage-wal-max-write- délai : 50 ms
Priorité 3 : ajuster la synchronisation des instantanés
storage-cache-snapshot-write-durée du froid : 150 ms (moins fréquent)
storage-compact-full-write-durée du froid : 6h00m0s (moins fréquent)
Considérations importantes :
Ces modifications créent des compromis importants entre I/O l'utilisation et les performances du système :
Limitation des E/S de compactage :
La réduction
storage-max-concurrent-compactionsralentira les opérations de compactage, ce qui entraînera une accumulation et DiskUtilizationune augmentation plus rapides des fichiers TSMLower
storage-compact-throughput-burstprolonge la durée de compactage, ce qui permet au compacteur de rester actif plus longtemps et de bloquer potentiellement d'autres opérationsLe ralentissement du compactage entraîne une dégradation des performances des requêtes au fil du temps, car le moteur de stockage doit lire des fichiers TSM plus nombreux et plus petits au lieu de fichiers consolidés
Vous pouvez voir les taux d'QueryRequestsTotalerreur d'exécution augmenter à mesure que les requêtes expirent pendant l'attente des E/S
Réduction de la fréquence des instantanés :
Augmentation
storage-cache-snapshot-write-cold-durationet prolongation destorage-compact-full-write-cold-durationla durée de conservation des données dans le journal d'écriture anticipée (WAL)Cela augmente à MemoryUtilizationmesure que davantage de données sont conservées dans le cache avant d'être vidées sur le disque.
Le risque de perte de données augmente légèrement si l'instance se bloque avant que les données mises en cache ne soient conservées
Le temps de restauration après un redémarrage augmente à mesure que davantage de données WAL doivent être rejouées
Réglage des opérations d'écriture :
La réduction
storage-wal-max-concurrent-writespermettra de sérialiser davantage les opérations d'écriture, ce qui pourrait augmenter WriteTimeoutspendant les périodes de haut débitL'augmentation
storage-wal-max-write-delaysignifie que les écritures peuvent attendre plus longtemps avant d'être rejetées, ce qui peut masquer les problèmes de capacité mais frustrer les utilisateurs en raison de la lenteur des réponses
Bonne pratique : une utilisation élevée des IOPS indique généralement que vous avez dépassé votre niveau de stockage plutôt qu'un problème de configuration. Avant de restreindre I/O, analyze I/O les modèles et optimiser avant de restreindre.
Actions relatives au matériel :
Passez à un niveau de stockage IOPS supérieur (3K → 12K)
Garantir le maintien d'une marge de 30 % d'IOPS
Cardinalité en haute série (SeriesCardinality > 1M)
CloudWatch Indicateurs à surveiller :
SeriesCardinalitypar seau et au total
MemoryUtilization(augmente avec la cardinalité)
CPUUtilization(frais généraux liés à la planification des requêtes)
QueryRequestsTotal(le taux d'erreur d'exécution peut augmenter)
Ajustements de configuration :
Priorité 1 : optimiser la gestion des séries
storage-series-id-set-taille du cache : 1000-2000 (augmentation du cache)
storage-series-file-max- concurrent-snapshot-compactions : 4 à 8
Priorité 2 : définir des limites de protection
influxql-max-select-series: 10000 (empêche les requêtes intempestives)
influxql-max-select-buckets: 1000
Priorité 3 : optimiser les opérations d'indexation
storage-max-index-log- taille du fichier : 2 097 152 (2 Mo)
Considérations importantes :
La cardinalité élevée des séries est fondamentalement un problème de modélisation des données, et non un problème de configuration. Les modifications de configuration ne peuvent qu'atténuer les symptômes ; elles ne peuvent pas résoudre le problème sous-jacent.
Compromis en matière de configuration :
L'augmentation storage-series-id-set-cache-size améliorera les performances des requêtes en mettant en cache les recherches de séries, mais au prix d'une augmentation. MemoryUtilization Chaque entrée de cache consomme de la mémoire, ce qui peut être considérable avec des millions de séries. Surveillez HeapMemoryUsageet ActiveMemoryAllocationaprès avoir effectué cette modification.
La définition de limites de protection (influxql-max-select-series,influxql-max-select-buckets) entraînera l'échec des requêtes légitimes avec compile_error in QueryRequestsTotalsi elles dépassent ces seuils. Les tableaux de bord qui fonctionnaient auparavant risquent de ne plus fonctionner et les utilisateurs devront modifier leurs requêtes. Cela est particulièrement problématique pour :
Tableaux de bord de surveillance regroupés sur de nombreux hôtes/services
Requêtes d'analyse qui doivent comparer plusieurs entités
Requêtes d'alerte qui évaluent les conditions de l'ensemble de la flotte
L'ajustement storage-max-index-log-file-size à des valeurs plus faibles augmente la fréquence de compactage de l'indice, qui augmente au WriteOpsPerSecfur CPUUtilizationet à mesure que le système effectue une maintenance de l'index plus fréquente.
Compréhension critique :
Lorsque vous SeriesCardinalitydépassez 5 millions de dollars, vous approchez des limites architecturales d'InfluxDB 2.x. Sur les séries 10M+, les performances se dégradent de façon exponentielle, quelle que soit la configuration :
Le coût de la planification des requêtes devient prohibitif (élevé CPUUtilization)
Les besoins en mémoire augmentent de manière non linéaire (élevés) MemoryUtilization
Les opérations indicielles dominent I/O (ReadOpsPerSec, WriteOpsPerSec)
QueryRequestsTotalles taux d'erreur d'exécution augmentent à mesure que les requêtes expirent ou qu'elles épuisent la mémoire
Bonne pratique : les modifications de configuration sont des pansements temporaires. Vous devez vous attaquer à la cause première :
Analysez votre modèle de données :
Révision SeriesCardinalitypar compartiment pour identifier les zones problématiques
Identifiez les balises dont le nombre de valeurs uniques est élevé
Recherchez des valeurs de balises illimitées (horodatageUUIDs, utilisateur, session) IDs IDs
Trouvez des balises qui devraient plutôt être des champs
Actions relatives au modèle de données :
Passez en revue la conception des balises pour réduire la cardinalité inutile
Envisagez de consolider des séries similaires
Si > Série 10M : planifiez la migration vers InfluxDB 3.0
Problèmes de performances des requêtes
CloudWatch Indicateurs à surveiller :
QueryRequestsTotalpar type de résultat (success, runtime_error, compile_error, queue_error)
APIRequestTarif avec statut = 500 ou statut = 499
QueryResponseVolume(les réponses importantes indiquent des requêtes coûteuses)
Ajustements de configuration :
Priorité 1 : augmenter les ressources de requête
simultanéité des requêtes : augmentation à 75 % de v CPUs
query-memory-bytes: alloue 70 % de la RAM totale
query-queue-size: 4096
Priorité 2 : optimiser l'exécution des requêtes
storage-series-id-set-cache-size : 1000 (augmentation pour une meilleure mise en cache)
http-read-timeout: 60s (éviter les délais d'attente prématurés)
Priorité 3 : Fixer des limites raisonnables
influxql-max-select-point: 100 000 000
influxql-max-select-series: 10000
influxql-max-select-buckets: 1000
Considérations importantes :
L'augmentation des ressources de requêtes crée une concurrence entre les ressources et une instabilité potentielle du système :
Compromis en matière d'allocation des ressources :
L'augmentation query-concurrency permet à un plus grand nombre de requêtes de s'exécuter simultanément, mais chaque requête est en concurrence pour le processeur et la mémoire :
CPUUtilizationaugmentera, atteignant potentiellement la saturation pendant les périodes de pointe des requêtes
MemoryUtilizationaugmentera à mesure que de nouvelles requêtes alloueront de la mémoire simultanément
Si vous augmentez la simultanéité sans ressources adéquates, toutes les requêtes sont ralenties au lieu de se contenter de quelques files d'attente
Risque d'échec en cascade si les requêtes simultanées épuisent les ressources disponibles
Allouer plus query-memory-bytes signifie moins de mémoire disponible pour la mise en cache et les autres opérations :
HeapMemoryUsageaugmentera
storage-cache-max-memory-sizepeut avoir besoin d'être réduit pour compenserMoins d'accès au cache se traduisent par des performances de requête plus élevées ReadOpsPerSecet plus lentes
Le système devient plus vulnérable à l'épuisement de la mémoire si les requêtes utilisent leur allocation complète
L'augmentation query-queue-size ne fait que retarder le problème ; elle ne résout pas les problèmes de capacité :
Les requêtes attendent plus longtemps dans la file d'attente, ce qui augmente la end-to-end latence
Les utilisateurs perçoivent le système comme étant plus lent, même si le débit peut rester inchangé
Les longues files d'attente peuvent masquer des problèmes de capacité sous-jacents
QueryRequestsTotalle taux d'erreur de file d'attente diminue, mais l'expérience utilisateur risque de ne pas s'améliorer
L'augmentation http-read-timeout empêche l'annulation prématurée des requêtes, mais :
Les requêtes de longue durée consomment plus de ressources, ce qui réduit la capacité pour les autres requêtes
Les utilisateurs attendent plus longtemps avant de recevoir des erreurs de délai
Peut masquer les requêtes inefficaces qui devraient être optimisées
Peut entraîner l'épuisement des ressources si de nombreuses requêtes lentes s'accumulent
Bonne pratique : les problèmes de performance des requêtes sont généralement dus à des requêtes inefficaces, et non à des ressources insuffisantes. Avant d'augmenter l'allocation des ressources :
Analysez les modèles de requêtes :
Vérifiez QueryResponseVolumepour identifier les requêtes renvoyant trop de données (> 1 Mo)
Vérifiez les modèles QueryRequestsTotald'erreur d'exécution : qu'est-ce qui cause les échecs ?
Recherchez APIRequestRate with Status=499 (délais d'expiration du client) : les requêtes sont trop lentes
Identifiez les requêtes coûteuses fréquemment exécutées
Optimisez d'abord les requêtes :
Anti-modèles de requêtes courants :
Filtres de plage de temps manquants → Ajouter des limites de temps explicites
Interrogation de toutes les séries → Ajouter des filtres de balises spécifiques
Fenêtres d'agrégation excessives → Utiliser des intervalles appropriés
Champs inutiles dans SELECT → Demander uniquement les données nécessaires
Clauses sans limite → Ajouter des limites raisonnables
Solutions au niveau de l'application :
Implémenter la mise en cache des résultats des requêtes (Redis, Memcached)
Utilisez des tâches pour pré-agréger des modèles courants
Ajouter de la pagination pour les grands ensembles de résultats
Implémenter une limitation du taux de requêtes par utilisateur/tableau de bord
Utiliser des données sous-échantillonnées pour les requêtes historiques
Vérifiez la disponibilité des ressources :
Vérifiez CPUUtilization: si vous êtes déjà supérieur à 70 %, l'augmentation de la simultanéité ne fera qu'empirer les choses
Vérifiez MemoryUtilization: si vous êtes déjà supérieur à 70 %, l'allocation d'une plus grande quantité de mémoire de requête provoquera l'OOM
Vérifiez que Total IOps PerSec dispose d'une marge de 30 % avant d'augmenter le chargement des requêtes
Approche recommandée :
Commencez par optimiser les 10 requêtes les plus coûteuses (par QueryResponseVolume)
Implémenter la mise en cache des résultats des requêtes au niveau de l'application
N'augmentez l'allocation des ressources que si les requêtes sont optimisées et que les indicateurs indiquent la marge de manœuvre
Passez à une classe d'instance plus grande si la charge de travail dépasse la capacité actuelle
Actions relatives au matériel :
Augmentez votre capacité de calcul, les requêtes bénéficient d'une puissance de traitement supplémentaire (vCPUs)
RegEx Problèmes de performance liés aux requêtes de flux
Lorsque vous filtrez des données dans Flux, évitez d'utiliser des expressions régulières pour des correspondances exactes ou une simple correspondance de modèles, car cela entraîne des pénalités importantes en termes de performances. RegEx les opérations dans Flux sont mono-thread et contournent complètement l'indice TSM sous-jacent. Au lieu de tirer parti des index de balises optimisés d'InfluxDB pour des recherches rapides, les RegEx filtres obligent le moteur de requête à récupérer toutes les séries correspondantes du stockage et à effectuer des comparaisons de texte séquentiellement par rapport à chaque valeur. Cela devient particulièrement problématique lorsque :
Filtrage sur les valeurs exactes des balises : utilisez l'opérateur d'égalité (
==) ou lacontains()fonction au lieu de RegEx modèles tels que/^exact_value$/Correspondance de plusieurs valeurs spécifiques : utilisez l'
inopérateur avec un tableau de valeurs plutôt que des modèles d'alternance tels que/(value1|value2|value3)/Correspondance simple de préfixes ou de suffixes : pensez à utiliser des
strings.hasSuffix()fonctionsstrings.hasPrefix()ou, qui sont plus efficaces que les ancres RegEx
Pour les scénarios nécessitant plusieurs correspondances de modèles, restructurez votre requête pour utiliser plusieurs prédicats de filtre combinés à des opérateurs logiques, ou préfiltrez en utilisant l'égalité des balises avant d'appliquer des opérations de chaîne plus complexes. Ne réservez RegEx que pour les cas nécessitant une véritable correspondance de modèles qui ne peuvent pas être exprimés par des opérateurs de comparaison plus simples.
Rédiger des problèmes de performance
CloudWatch Indicateurs à surveiller :
WriteTimeouts(nombre croissant)
WriteOpsPerSec et WriteThroughput
APIRequestTaux avec un statut = 500 pour les points de terminaison d'écriture
QueryRequestsTotalavec result=runtime_error pendant les écritures
Ajustements de configuration :
Priorité 1 : optimiser les écritures WAL
storage-wal-max-concurrent-écrit : 12-16
storage-wal-max-write- délai : 100 ms
http-write-timeout: Années 60
Priorité 2 : optimiser les instantanés du cache
storage-cache-snapshot-memory- taille : 52 428 800 (50 Mo)
storage-cache-snapshot-write- durée du froid : 100 ms
Priorité 3 : Validation du champ de contrôle
storage-no-validate-field-size : VRAI (si la source de données est fiable)
Considérations importantes :
L'optimisation des performances d'écriture implique des compromis judicieux entre débit, fiabilité et consommation de ressources :
Compromis en matière de configuration WAL :
L'augmentation storage-wal-max-concurrent-writes permet d'effectuer davantage d'opérations d'écriture parallèles, mais :
CPUUtilizationaugmente à mesure que de plus en plus de threads d'écriture se disputent le processeur
MemoryUtilizationaugmente à mesure que davantage de données sont mises en mémoire tampon avant le vidage du WAL
WriteOpsPerSecaugmentera, dépassant potentiellement votre marge de 30 % d'IOPS
L'augmentation de la contention sur le disque I/O peut en fait ralentir les écritures individuelles
Si vous dépassez la I/O capacité du disque, vous WriteTimeoutspouvez augmenter plutôt que diminuer
L'augmentation storage-wal-max-write-delay signifie que les écritures attendent plus longtemps avant d'expirer :
Masque les problèmes de capacité en faisant attendre les écritures au lieu d'échouer rapidement
Les utilisateurs rencontrent des temps de réponse d'écriture plus lents, même lorsque les écritures finissent par réussir
Peut entraîner une accumulation de files d'attente d'écriture et une pression sur la mémoire
N'augmente pas réellement la capacité, mais retarde simplement le délai d'expiration
L'augmentation des retards http-write-timeout similaires retarde les erreurs de temporisation :
Permet de terminer des écritures par lots plus importantes
Mais permet également aux écritures lentes de consommer des ressources plus longtemps
Peut masquer les problèmes de performance sous-jacents
Peut entraîner l'épuisement des ressources si de nombreuses écritures lentes s'accumulent
Compromis entre les instantanés du cache :
L'augmentation storage-cache-snapshot-memory-size signifie que davantage de données s'accumulent dans la mémoire avant d'être vidées :
MemoryUtilizationaugmente de manière significative
Le risque de perte de données augmente si l'instance se bloque avant le snapshot
Les instantanés plus volumineux prennent plus de temps à écrire, ce qui crée des pointes plus importantes WriteOpsPerSec
Peut améliorer le débit d'écriture en regroupant davantage de données, mais au détriment de la mémoire et de la fiabilité
Instantanés storage-cache-snapshot-write-cold-duration présentant des délais croissants :
Augmentations supplémentaires à MemoryUtilizationmesure que les données restent plus longtemps dans le cache
Augmente la fenêtre de risque de perte de données
Réduit WriteOpsPerSecla fréquence mais crée des pics plus importants lorsque des instantanés apparaissent
Le temps de récupération après le redémarrage augmente à mesure que davantage de WAL doivent être rejoués
Compromis pour la validation sur le terrain :
Le réglage storage-no-validate-field-size: TRUE désactive la validation de la taille des champs :
Améliore le débit d'écriture en omettant les contrôles de validation
Risque critique : permet l'écriture de données malformées ou malveillantes
Peut entraîner une corruption des données si les écritures contiennent des tailles de champ non valides
Rend le débogage des problèmes de données beaucoup plus difficile
À utiliser uniquement si vous avez le contrôle total et la fiabilité de votre source de données
Bonne pratique : les problèmes de performances d'écriture indiquent généralement des limites de capacité ou des modèles d'écriture inefficaces. Avant de régler la configuration :
Analyser les modèles d'écriture :
WriteThroughputBilan et WriteOpsPerSectendances
Vérifier la WriteTimeoutscorrélation avec la charge d'écriture
Surveillez APIRequestle taux des points de terminaison d'écriture par code d'état
Identification de la taille et de la fréquence des lots d'écriture
Optimisez d'abord les opérations d'écriture :
Anti-modèles d'écriture courants :
Écrire des points individuels → Écritures par lots (5 000 à 10 000 points)
Écritures trop fréquentes → Mémoire tampon et traitement par lots
écritures synchrones → Implémenter des files d'écriture asynchrones
rafales d'écriture illimitées → Implémenter la limitation du débit
Écriture d'une précision inutile → Arrondir les horodatages de manière appropriée
Vérifiez I/O la capacité :
Vérifiez le total IOps PerSec : si vous êtes déjà supérieur à 70 %, l'augmentation de la simultanéité des WAL ne fera qu'empirer les choses
Révision WriteOpsPerSecpendant les périodes de pointe
Assurez-vous qu'il existe une marge de 30 % d'IOPS avant de régler les paramètres d'écriture
Déterminez si 3 000 IOPS sont suffisants ou si un niveau de 12 000 IOPS est nécessaire
Améliorations au niveau de l'application :
Mettre en œuvre la mise en mémoire tampon d'écriture avec des tailles de lots configurables
Ajout d'une logique de nouvelle tentative d'écriture avec retard exponentiel
Utiliser des opérations d'écriture asynchrones
Implémenter une limitation du taux d'écriture pendant les périodes de pointe
Surveillez la profondeur de la file d'écriture et appliquez une contre-pression
Approche recommandée :
Commencez par optimiser la taille des lots d'écriture au niveau de l'application (visez 5 000 à 10 000 points par lot)
Implémenter la mise en mémoire tampon d'écriture et les opérations asynchrones
Vérifiez que Total IOps PerSec dispose d'une marge de manœuvre suffisante
Passez au niveau de stockage suivant (3 000 IOPS → 12 000 IOPS → 16 000 IOPS) si le taux d'utilisation est constamment supérieur à 70 %
Ne réglez les paramètres WAL que si les écritures sont optimisées et que I/O la capacité est adéquate
Ne désactivez jamais la validation des champs si vous ne contrôlez pas totalement les sources de données
Actions relatives au matériel :
Passez à un stockage IOPS supérieur (3 K → 12 K → 16 K)
Assurez-vous que l' I/O espace libre est adéquat
Passez à une classe d'instance plus grande si le processeur ou la mémoire sont limités
Meilleures pratiques en matière de surveillance
CloudWatch Configuration des alarmes
Alarmes critiques (action immédiate requise) :
CPUUtilization:
Seuil : > 90 % pendant 5 minutes
Action : mettre en œuvre des mesures de correction du trafic ou de mise à l'échelle du calcul
MemoryUtilization:
Seuil : > 90 % pendant 5 minutes
Action : mettre en œuvre des mesures de correction du trafic ou de mise à l'échelle du calcul
DiskUtilization:
Seuil : > 85 %
Action : essayez de libérer de l'espace en supprimant les anciens compartiments, en mettant à jour les configurations de rétention ou en dimensionnant le stockage
Au total IOps PerSec :
Seuil : > 90 % du montant provisionné pendant 10 minutes
Action : mettre en œuvre des mesures de correction du trafic ou augmenter le nombre d'IOPS
SeriesCardinality:
Seuil : > 10 000 000
Action : passez en revue votre modèle de données, si aucune modification n'est possible, explorez, migrez vers InfluxDB 3 ou partagez vos données
EngineUptime:
Seuil : réinitialisation inattendue (< 300 secondes)
Action : Vérifiez si cela coïncide avec une fenêtre de maintenance, sinon créez un ticket pour le support Timestream.
Alarmes d'avertissement (enquête requise) :
CPUUtilization:
Seuil : > 70 % pendant 15 minutes
Action : examiner les modifications de la charge de travail ou du trafic
MemoryUtilization:
Seuil : > 70 % pendant 15 minutes
Action : examiner les modifications de la charge de travail ou du trafic
DiskUtilization:
Seuil : > 70 %
Action : revoir les politiques de rétention
Au total IOps PerSec :
Seuil : > 70 % du montant provisionné pendant 15 minutes
Action : examiner les modifications de la charge de travail ou du trafic
QueryRequestsTotal (erreur_d'exécution) :
Seuil : > 1 % du total des requêtes
Action : examiner les modifications de la charge de travail ou du trafic
WriteTimeouts:
Seuil : > 1 % des opérations d'écriture
Action : examiner les modifications de la charge de travail ou du trafic
SeriesCardinality:
Seuil : > 5 000 000
Action : passer en revue l'optimisation du modèle de données
Liste de contrôle pour la surveillance proactive
Quotidien :
APIRequestTaux de révision pour les pics d'erreur (400, 404, 499, 500)
Vérifiez les taux QueryRequestsTotal d'erreur d'exécution et de erreur de file d'attente
Vérifiez que WriteTimeouts le nombre est minimal
Vérifiez les alarmes critiques
Vérifier EngineUptime (pas de redémarrages inattendus)
Hebdomadaire :
CPUUtilizationBilan MemoryUtilization et DiskUtilization tendances
Analyser QueryRequestsTotal les modèles par type de résultat
Vérifiez le taux de SeriesCardinality croissance par seau
Examiner les tendances IOps PerSec d'utilisation totale
Vérifiez que les paramètres de configuration sont optimaux
TaskExecutionFailures Modèles de révision
Mensuel :
Examen de la planification des capacités (projet 3 à 6 mois à l'avance)
Comparez les mesures actuelles avec le tableau des tailles
Passez en revue et optimisez les politiques de rétention
Analysez les modèles de requêtes à partir de APIRequest Rate et QueryResponseVolume
Révision SeriesCardinality et efficacité du modèle de données
Évaluer le besoin de mise à l'échelle de l'instance ou de modifications de configuration
Opportunités TotalBuckets de révision et de consolidation
Guide de dépannage
Scénario : dégradation soudaine des performances
Étapes de l'enquête :
Vérifiez les modifications récentes :
Modifications des paramètres de configuration dans la console AWS de gestion
Modifications apportées au déploiement des applications
Modifications du modèle de requête
Modifications du modèle de données
Modifications de l'infrastructure (type d'instance, stockage)
CloudWatch Métriques de révision :
Pic du processeur ? → Vérifiez CPUUtilization, QueryRequestsTotal
Pression de mémoire ? → Vérifiez MemoryUtilization HeapMemoryUsage, ActiveMemoryAllocation
Saturation des IOPS ? → Vérifiez le total IOps PerSec ReadOpsPerSec, WriteOpsPerSec
Saut de cardinalité en série ? → Contrôler SeriesCardinality la croissance
Augmentation du taux d'erreur ? → Vérification QueryRequestsTotal (erreur d'exécution), APIRequest taux (statut = 500)
Redémarrage inattendu ? → Vérifier EngineUptime
Activez la journalisation détaillée :
Changements de configuration :
niveau du journal : debug
flux-log-enabled: VRAI
Surveillez pendant 1 à 2 heures, puis examinez les journaux
Retour au niveau du journal : informations après enquête
Étapes de résolution :
Appliquer les modifications de configuration appropriées en fonction des résultats
Dimensionner les ressources si les limites sont atteintes
Optimisez les requêtes ou le modèle de données si nécessaire
Mettre en œuvre une limitation de débit en cas d'augmentation soudaine de la charge
Scénario : épuisement de la mémoire
Symptômes :
MemoryUtilization > 90 %
HeapMemoryUsage approche du maximum
QueryRequestsTotal affichage de l'erreur d'exécution (mémoire insuffisante)
APIRequestTaux indiquant le statut = 500
Étapes de résolution :
Actions immédiates (si elles sont critiques) :
Redémarrez l'instance pour vider la mémoire (si vous pouvez le faire en toute sécurité)
Réduisez temporairement la simultanéité des requêtes
Éliminez les requêtes de longue durée si possible
Changements de configuration :
Priorité 1 : réduire la mémoire cache
storage-cache-max-memory-taille : réduire à 10 % de la RAM
Exemple : 32 Go → 3 355 443 200 octets
storage-cache-snapshot-memory-taille : 26 214 400 (25 MB)
Priorité 2 : Limiter la mémoire des requêtes
query-memory-bytes: défini sur 60 % de la RAM totale
query-max-memory-bytes: Correspondance query-memory-bytes
query-initial-memory-bytes: 10 % des query-memory-bytes
Priorité 3 : définir des limites de protection
influxql-max-select-series: 10000
influxql-max-select-point: 100 000 000
simultanéité des requêtes : réduire à 50 % de v CPUs
Solutions à long terme :
Optimisez le modèle de données pour réduire SeriesCardinality
Implémenter les limites de taille des résultats de requête au niveau de l'application
Ajouter l'application du délai d'expiration des requêtes
Passez en revue les requêtes les plus courantes pour vous assurer qu'elles respectent les meilleures pratiques mentionnées dans la section Problèmes de performances des requêtes
Scénario : impact sur la cardinalité des séries élevées
CloudWatch Métriques de révision :
SeriesCardinality> 5 M
MemoryUtilizationhaut
QueryRequestsTotalaffichage d'une augmentation de l'erreur d'exécution
CPUUtilizationélevé en raison de la surcharge de planification des requêtes
Étapes de l'enquête :
Analysez la croissance de la cardinalité :
SeriesCardinality taux de croissance (jour/semaine)
Projection jusqu'au seuil de 10 M
Identifier les sources de haute cardinalité
Revoir la conception et l'utilisation des balises
Évaluez l'impact sur les performances :
Comparez le taux de QueryRequestsTotalréussite et l'augmentation de before/after la cardinalité
MemoryUtilizationCorrélation des revues
Vérifiez les CPUUtilizationmodèles
Analyser QueryResponseVolumeles tendances
Identifiez les sources de cardinalité :
Modèle de données de révision :
Quels sont les seaux les plus hauts ? SeriesCardinality
Quelles balises ont un nombre de valeurs uniques élevé ?
Y a-t-il des tags inutiles ?
Les valeurs des balises sont-elles illimitées (horodatagesUUIDs, etc.) ?
Vérifiez la configuration actuelle :
Vérifiez les paramètres d'optimisation :
storage-series-id-set-cache-size : valeur actuelle ?
influxql-max-select-series: Est-ce que cela limite les requêtes incontrôlables ?
storage-max-index-log-file-size : approprié pour la cardinalité ?
Étapes de résolution :
Changements de configuration immédiats :
Priorité 1 : optimiser la gestion des séries
storage-series-id-set-taille du cache : 1500-2000
storage-series-file-max- concurrent-snapshot-compactions : 6 à 8
storage-max-index-log- taille du fichier : 2 097 152 (2 Mo)
Priorité 2 : définir des limites de protection
influxql-max-select-series: 10000
influxql-max-select-buckets: 1000
simultanéité des requêtes : réduire si la mémoire est limitée
Priorité 3 : augmenter les ressources
Passez au niveau d'instance suivant
Augmenter l'allocation de mémoire
Envisagez un niveau de stockage à 12 000 IOPS
Planification de la migration (si la série est supérieure à 10M) :
InfluxDB 3.0 offre des performances supérieures à haute cardinalité
Calendrier de migration du plan (2 à 3 mois)
Testez d'abord avec un sous-ensemble de données
Préparation de la demande de migration
InfluxDB 3.0 utilise un stockage en colonnes optimisé pour des milliards de séries
Scénario : accumulation de files d'attente de requêtes
CloudWatch Métriques de révision :
QueryRequestsTotalavec result=queue_error croissant (requêtes rejetées)
APIRequestTarif avec statut = 429 ou statut = 503 (réponse à de nombreuses demandes) unavailable/too
CPUUtilizationpeut être élevé (> 70 %) indiquant une saturation des ressources
MemoryUtilizationpeut être élevé (> 70 %) limitant la capacité de requête
QueryResponseVolumeaffichage de réponses de grande taille (requêtes consommant trop de ressources)
Étapes de l'enquête :
Analysez les métriques de file d'attente et de simultanéité :
QueryRequestsTotalRépartition des révisions par type de résultat :
Un nombre élevé d'erreurs de file d'attente indique que les requêtes sont rejetées
Comparez le taux de réussite au taux de référence : est-ce qu'il est en baisse ?
Vérifiez les augmentations de runtime_error (les requêtes échouent après le démarrage)
Surveillez les modèles de APIRequesttaux :
Recherchez Status=429 (trop de demandes) ou Status=503 (service non disponible)
Identifiez les terminaux qui sont rejetés
Vérifiez l'évolution du taux de demandes au fil du temps
Passez en revue l'utilisation des ressources :
CPUUtilizationpendant les périodes de file d'attente élevées :
Si > 70 %, les requêtes sont liées au processeur et ne peuvent pas être exécutées plus rapidement
Si < 50 %, les limites de file d'attente peuvent être trop restrictives
MemoryUtilizationcorrélation :
La mémoire élevée peut limiter la simultanéité des requêtes
Vérifier HeapMemoryUsageet vérifier ActiveMemoryAllocationla pression de la mémoire
Nombre total IOps PerSec de modèles :
Un niveau élevé I/O peut ralentir l'exécution des requêtes
Vérifiez si les requêtes sont I/O liées
Identifiez les modèles de requêtes :
Révision QueryResponseVolume:
Les requêtes renvoient-elles trop de données (> 1 Mo) ?
Identifiez les points de terminaison présentant les volumes de réponses les plus importants
Recherchez des modèles dans les requêtes coûteuses
Analyser QueryRequestsTotalle taux :
Quel est le taux de requêtes par seconde ?
Y a-t-il des modèles d'éclatement ou une charge élevée soutenue ?
Comparaison avec la capacité de l'instance indiquée dans le tableau des tailles
APIRequestTaux de vérification par point de terminaison :
Quels sont les points de terminaison des requêtes qui génèrent le plus de trafic ?
Y a-t-il des requêtes dupliquées ou redondantes ?
Vérifiez la disponibilité des ressources :
Comparez les mesures actuelles aux recommandations du tableau des tailles :
SeriesCardinalitypar rapport à la capacité de classe d'instance
Taux de requêtes par seconde par rapport aux requêtes recommandées
CPUUtilizationet hauteur MemoryUtilizationlibre
Vérifiez la capacité IOPS :
Le total IOps PerSec devrait avoir une marge de 30 %
Vérifiez si les requêtes sont en attente sur les E/S du disque
Étapes de résolution :
Changements de configuration :
Priorité 1 : augmenter la capacité de la file d'attente
query-queue-size: 4096 (à partir de 1024 par défaut)
Priorité 2 : augmenter la simultanéité (si les ressources le permettent)
simultanéité des requêtes : augmentation à 75 % de v CPUs
Exemple : 16 vCPU → simultanéité des requêtes = 12
Vérifiez que les CPUUtilization séjours restent inférieurs à 80 % après le changement
Vérifiez que les MemoryUtilization séjours restent inférieurs à 80 % après le changement
Priorité 3 : optimiser l'exécution des requêtes
query-memory-bytes: Garantir une allocation adéquate
storage-series-id-set-taille du cache : 1000-1500
http-read-timeout: 120 s (éviter les délais d'attente prématurés)
Priorité 4 : définir des limites de protection
influxql-max-select-series: 10000
influxql-max-select-point: 100 000 000
Solutions au niveau de l'application :
Implémenter la mise en cache des résultats des requêtes (Redis, Memcached)
Résultats du cache pour les requêtes fréquemment exécutées
Définissez les paramètres appropriés TTLs en fonction des exigences de fraîcheur des données
Surveiller le taux d’accès au cache
Utilisez des requêtes continues pour pré-agréger les modèles courants
Pré-calculez les agrégations communes
Interrogez des données pré-agrégées plutôt que des données brutes
Ajouter de la pagination pour les grands ensembles de résultats
Limiter la taille initiale de la requête
Charger des données supplémentaires à la demande
Implémenter une limitation du taux de requêtes par utilisateur/tableau de bord
Empêchez les utilisateurs individuels de surcharger le système
Fixez des quotas d'utilisation équitable
Utiliser des données sous-échantillonnées pour les requêtes historiques
Interrogez des données à faible résolution pour des plages de temps plus anciennes
Réservez des requêtes en pleine résolution pour les données récentes
Décision de mise à l'échelle :
Si le CPUUtilization taux de durabilité est supérieur à 70 % : passer à une instance plus grande
Si le taux de MemoryUtilization durabilité est supérieur à 70 % : mise à l'échelle vers une instance optimisée pour la mémoire
Si le taux de requêtes dépasse la capacité de l'instance : passez au niveau suivant par table de dimensionnement
