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](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html).
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 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| MemoryUtilization | DbInstanceName | Pourcentage de mémoire utilisée | Pourcentage | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| HeapMemoryUsage | DbInstanceName | Quantité de mémoire en tas utilisée | Octets | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| ActiveMemoryAllocation | DbInstanceName | Allocation de mémoire active actuelle | Octets | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| DiskUtilization | DbInstanceName | Pourcentage d'espace disque utilisé | Pourcentage | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 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éesExemple : 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éesExemple : 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éesSurveillance 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 : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| QueryResponseVolume | DbInstanceName, point de terminaison, statut | Volume de réponses aux requêtes par point de terminaison et code d'état | Octets | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 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\$1error, compile\$1error, queue\$1error) | Nombre | Taux de réussite : > 99 % Taux d'erreur : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 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 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| TotalBuckets | DbInstanceName | Nombre total de compartiments dans l'instance | Nombre | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 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 inattendusAlerte : 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'écritureCritique : 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éeAlerte : Toujours au maximum |
| TaskExecutionFailures | DbInstanceName | Nombre d'exécutions de tâches ayant échoué | Nombre | Alerte : > 1 % des exécutions de tâchesCritique : 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 \$1 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 | \$150 000 | < 10 | db.influx.large | Influx IO inclus 3K | Petits déploiements, développement, tests |
| < 1 M | \$1150 000 | < 25 | db.influx.2xlarge | Influx IO inclus 3K | Charges de travail de production petites à moyennes |
| \$11 M | \$1200 000 | \$125 | db.influx.4xlarge | Influx IO inclus 3K | Charges de travail de production moyennes |
| < 5 M | \$1250 000 | \$135 | db.influx.4xlarge | Influx IO inclus 12K | Charges de travail de production importantes |
| < 10 M | \$1500 000 | \$150 | db.influx x 8 x large | Influx IO inclus 12K | Charges de travail de production très importantes |
| \$110 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\$1error ou **runtime\$1error**** 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 **QueryResponseVolume**de **QueryRequestsTotal**mé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
+ **HeapMemoryUsage**tendance à la hausse
+ **ActiveMemoryAllocation**montrant 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 **ReadOpsPerSec**augmentation et **QueryResponseVolume**une baisse des temps de réponse.
La limitation `query-memory-bytes` entraînera l'échec des requêtes gourmandes en mémoire lorsque **runtime\$1error** 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 **QueryResponseVolume**pour 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 **SeriesCardinality**et 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 %
+ **WriteThroughput**motifs
+ **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: debug`génère des journaux extrêmement détaillés, pouvant atteindre des centaines de Mo par heure
+ `flux-log-enabled: TRUE`enregistre chaque exécution de requête Flux avec tous les détails, créant ainsi des fichiers journaux volumineux
+ Ces 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 :**
1. Set `log-level: info` (à partir du débogage)
1. Définir `flux-log-enabled: FALSE`
1. Surveillez **DiskUtilization**pour 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 :
+ **CPUUtilization**augmentera à mesure que les opérations de compactage consomment des cycles du processeur
+ **MemoryUtilization**augmentera pendant le compactage à mesure que les données sont chargées et traitées
+ **WriteOpsPerSec**et **WriteThroughput**augmentera pendant les fenêtres de compactage, dépassant potentiellement votre marge de 30 % d'IOPS
+ **WriteTimeouts**peut 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 :
1. **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
1. 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 ?
1. **Optimisation des politiques de rétention :** vérifiez **TotalBuckets**et passez en revue les paramètres de rétention pour chaque compartiment
1. **Surveillez l'impact du compactage : établissez **CPUUtilization****une base de référence pour et **WriteOpsPerSec**avant 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**\$1 **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-compactions` ralentira les opérations de compactage, ce qui entraînera une accumulation et **DiskUtilization**une augmentation plus rapides des fichiers TSM
+ Lower `storage-compact-throughput-burst` prolonge la durée de compactage, ce qui permet au compacteur de rester actif plus longtemps et de bloquer potentiellement d'autres opérations
+ Le 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'**QueryRequestsTotal**erreur 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-duration` et prolongation de `storage-compact-full-write-cold-duration` la durée de conservation des données dans le journal d'écriture anticipée (WAL)
+ Cela augmente à **MemoryUtilization**mesure 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-writes` permettra de sérialiser davantage les opérations d'écriture, ce qui pourrait augmenter **WriteTimeouts**pendant les périodes de haut débit
+ L'augmentation `storage-wal-max-write-delay` signifie 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 :**
+ **SeriesCardinality**par 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 **HeapMemoryUsage**et **ActiveMemoryAllocation**aprè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\$1error** in **QueryRequestsTotal**si 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 **WriteOpsPerSec**fur **CPUUtilization**et à mesure que le système effectue une maintenance de l'index plus fréquente.
**Compréhension critique :**
Lorsque vous **SeriesCardinality**dépassez 5 millions de dollars, vous approchez des limites architecturales d'InfluxDB 2.x. Sur les séries 10M\$1, 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**)
+ **QueryRequestsTotal**les 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 :
1. **Analysez votre modèle de données :**
+ Révision **SeriesCardinality**par 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 :**
+ **QueryRequestsTotal**par type de résultat (success, runtime\$1error, compile\$1error, queue\$1error)
+ **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 :
+ **CPUUtilization**augmentera, atteignant potentiellement la saturation pendant les périodes de pointe des requêtes
+ **MemoryUtilization**augmentera à 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 :
+ **HeapMemoryUsage**augmentera
+ `storage-cache-max-memory-size`peut avoir besoin d'être réduit pour compenser
+ Moins d'accès au cache se traduisent par des performances de requête plus élevées **ReadOpsPerSec**et 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
+ **QueryRequestsTotal**le 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 :
1. **Analysez les modèles de requêtes :**
+ Vérifiez **QueryResponseVolume**pour identifier les requêtes renvoyant trop de données (> 1 Mo)
+ Vérifiez les modèles **QueryRequestsTotal**d'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
1. **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
1. **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
1. **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 :**
1. Commencez par optimiser les 10 requêtes les plus coûteuses (par **QueryResponseVolume**)
1. Implémenter la mise en cache des résultats des requêtes au niveau de l'application
1. N'augmentez l'allocation des ressources que si les requêtes sont optimisées et que les indicateurs indiquent la marge de manœuvre
1. 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 la `contains()` fonction au lieu de RegEx modèles tels que `/^exact_value$/`
+ **Correspondance de plusieurs valeurs spécifiques** : utilisez l'`in`opé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()` fonctions `strings.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
+ **QueryRequestsTotal**avec result=runtime\$1error 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 :
+ **CPUUtilization**augmente à mesure que de plus en plus de threads d'écriture se disputent le processeur
+ **MemoryUtilization**augmente à mesure que davantage de données sont mises en mémoire tampon avant le vidage du WAL
+ **WriteOpsPerSec**augmentera, 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 **WriteTimeouts**pouvez 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 :
+ **MemoryUtilization**augmente 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 à **MemoryUtilization**mesure que les données restent plus longtemps dans le cache
+ Augmente la fenêtre de risque de perte de données
+ Réduit **WriteOpsPerSec**la 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 :
1. **Analyser les modèles d'écriture :**
+ **WriteThroughput**Bilan et **WriteOpsPerSec**tendances
+ Vérifier la **WriteTimeouts**corré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
1. **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
1. **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 **WriteOpsPerSec**pendant 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
1. **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 :**
1. Commencez par optimiser la taille des lots d'écriture au niveau de l'application (visez 5 000 à 10 000 points par lot)
1. Implémenter la mise en mémoire tampon d'écriture et les opérations asynchrones
1. Vérifiez que **Total IOps PerSec** dispose d'une marge de manœuvre suffisante
1. 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 %
1. Ne réglez les paramètres WAL que si les écritures sont optimisées et que I/O la capacité est adéquate
1. **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\$1d'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) :
1. Redémarrez l'instance pour vider la mémoire (si vous pouvez le faire en toute sécurité)
1. Réduisez temporairement la simultanéité des requêtes
1. É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](#query-performance-issues)
### Scénario : impact sur la cardinalité des séries élevées
** CloudWatch Métriques de révision :**
+ **SeriesCardinality**> 5 M
+ **MemoryUtilization**haut
+ **QueryRequestsTotal**affichage 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 **QueryRequestsTotal**réussite et l'augmentation de before/after la cardinalité
+ **MemoryUtilization**Corrélation des revues
+ Vérifiez les **CPUUtilization**modèles
+ Analyser **QueryResponseVolume**les 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 :**
+ **QueryRequestsTotal**avec result=queue\$1error croissant (requêtes rejetées)
+ **APIRequestTarif** avec statut = 429 ou statut = 503 (réponse à de nombreuses demandes) unavailable/too
+ **CPUUtilization**peut être élevé (> 70 %) indiquant une saturation des ressources
+ **MemoryUtilization**peut être élevé (> 70 %) limitant la capacité de requête
+ **QueryResponseVolume**affichage 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é :**
+ **QueryRequestsTotal**Ré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\$1error (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 :**
+ **CPUUtilization**pendant 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
+ **MemoryUtilization**corrélation :
+ La mémoire élevée peut limiter la simultanéité des requêtes
+ Vérifier **HeapMemoryUsage**et vérifier **ActiveMemoryAllocation**la 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 **QueryRequestsTotal**le 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 :
+ **SeriesCardinality**par rapport à la capacité de classe d'instance
+ Taux de requêtes par seconde par rapport aux requêtes recommandées
+ **CPUUtilization**et hauteur **MemoryUtilization**libre
+ 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