Per funzionalità simili a Amazon Timestream for, prendi in considerazione Amazon Timestream LiveAnalytics per InfluxDB. Offre un'acquisizione semplificata dei dati e tempi di risposta alle query di una sola cifra di millisecondi per analisi in tempo reale. [Scopri](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html) di più qui.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Monitoraggio e ottimizzazione della configurazione per Timestream for InfluxDB 2
## Panoramica di
Un monitoraggio e un'ottimizzazione della configurazione efficaci sono fondamentali per mantenere prestazioni, affidabilità ed efficienza dei costi ottimali nella distribuzione di Timestream for InfluxDB. Questa guida fornisce una guida completa su CloudWatch metriche, soglie di prestazioni e strategie di ottimizzazione della configurazione per aiutarvi a gestire in modo proattivo le vostre istanze InfluxDB.
## CloudWatch Riferimento alle metriche
Amazon CloudWatch fornisce metriche dettagliate per il monitoraggio di Timestream per le istanze InfluxDB. La comprensione di questi parametri e delle relative soglie è essenziale per mantenere l'integrità e le prestazioni del sistema.
### Metriche di utilizzo delle risorse
| CloudWatch Nome parametro | Dimensioni | Description | Unità | Soglie consigliate |
| --- | --- | --- | --- | --- |
| CPUUtilization | DbInstanceName | Percentuale di CPU utilizzata | Percentuale | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| MemoryUtilization | DbInstanceName | Percentuale di memoria utilizzata | Percentuale | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| HeapMemoryUsage | DbInstanceName | Quantità di memoria heap in uso | Byte | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| ActiveMemoryAllocation | DbInstanceName | Allocazione attuale della memoria attiva | Byte | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| DiskUtilization | DbInstanceName | Percentuale di spazio su disco utilizzato | Percentuale | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metriche delle operazioni di I/O
| CloudWatch Nome parametro | Dimensioni | Description | Unità | Soglie consigliate |
| --- | --- | --- | --- | --- |
| ReadOpsPerSec | DbInstanceName | Numero di operazioni di lettura al secondo | Numero/secondo | Mantieni un margine di crescita di ≥ 30% al di sotto degli IOPS assegnati
Esempio: 12.000 IOPS → mantieni un totale di < 8.400 IOPS |
| WriteOpsPerSec | DbInstanceName | Numero di operazioni di scrittura al secondo | Numero/secondo | Mantieni un margine di crescita di ≥ 30% al di sotto degli IOPS assegnati
Esempio: 12.000 IOPS → mantieni un totale di < 8.400 IOPS |
| Totale IOps PerSec | DbInstanceName | I/O Operazioni totali al secondo (lettura\+scrittura) | Numero/secondo | Mantieni un margine di crescita pari o superiore al 30% al di sotto degli IOPS assegnati
Monitora le funzionalità delle classi di istanze |
### Metriche del throughput
| CloudWatch Nome parametro | Dimensioni | Description | Unità | Soglie consigliate |
| --- | --- | --- | --- | --- |
| ReadThroughput | DbInstanceName | Velocità effettiva di lettura dei dati | Byte/secondo | Monitora i limiti di velocità di storage |
| WriteThroughput | DbInstanceName | Velocità effettiva di scrittura dei dati | Byte/secondo | Monitora i limiti di velocità di archiviazione |
### Metriche delle prestazioni delle API
| CloudWatch Nome parametro | Dimensioni | Description | Unità | Soglie consigliate |
| --- | --- | --- | --- | --- |
| APIRequestTasso | DbInstanceName, Endpoint, Stato | Frequenza di richieste API verso endpoint specifici con codici di stato (2xx, 4xx, 5xx) | Numero/secondo | Tassi di errore:[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| QueryResponseVolume | DbInstanceName, Endpoint, Stato | Volume di risposte alle interrogazioni per endpoint e codice di stato | Byte | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metriche di esecuzione delle query
| CloudWatch Nome parametro | Dimensioni | Description | Unità | Soglie consigliate |
| --- | --- | --- | --- | --- |
| QueryRequestsTotal | DbInstanceName, Risultato | Numero totale di richieste di query per tipo di risultato (success, runtime\_error, compile\_error, queue\_error) | Conteggio | Percentuale di successo: > 99%
Tassi di errore:[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metriche sull'organizzazione dei dati
| CloudWatch Nome parametro | Dimensioni | Description | Unità | Soglie critiche |
| --- | --- | --- | --- | --- |
| SeriesCardinality | DbInstanceName, Secchio | Numero di serie temporali uniche in un bucket | Conteggio | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| TotalBuckets | DbInstanceName | Numero totale di bucket nell'istanza | Conteggio | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metriche di System Health
| CloudWatch Nome parametro | Dimensioni | Description | Unità | Soglie consigliate |
| --- | --- | --- | --- | --- |
| EngineUptime | DbInstanceName | Ora in cui il motore InfluxDB è in funzione | Secondi | Monitora i riavvii imprevisti
Avviso: l'uptime viene ripristinato in modo imprevisto |
| WriteTimeouts | DbInstanceName | Numero di operazioni di scrittura scadute | Conteggio | Avviso: > 0,1% delle operazioni di scrittura
Critico: tendenza al rialzo |
### Metriche di gestione delle attività
| CloudWatch Nome parametro | Dimensioni | Description | Unità | Soglie consigliate |
| --- | --- | --- | --- | --- |
| ActiveTaskWorkers | DbInstanceName | Numero di task worker attivi | Conteggio | Monitoraggio rispetto al limite configurato per i task worker
Avviso: costantemente al massimo |
| TaskExecutionFailures | DbInstanceName | Numero di esecuzioni di attività non riuscite | Conteggio | Avviso: > 1% delle esecuzioni di attività
Critico: aumento del tasso di fallimento |
### Comprensione delle relazioni metriche chiave
#### Relazione tra IOPS e throughput
**La regola del 30%:** mantenete sempre almeno il **30% di margine** tra le operazioni sostenute al secondo e gli IOPS assegnati. Ciò fornisce un buffer per:
+ Operazioni di compattazione (possono aumentare notevolmente gli IOPS)
+ Qualsiasi database viene riavviato per funzionare senza problemi
+ Le query si interrompono durante i picchi di utilizzo
+ Scrivi i picchi dovuti all'ingestione in batch
+ Indicizza le operazioni di manutenzione
**Esempio di calcolo:**
+ IOPS assegnati: 12.000
+ Obiettivo di IOPS sostenuti massimi (totale IOpsPerSec): 8.400 (utilizzo del 70%)
+ Headroom riservato: 3.600 IOPS (30%)
Se il totale supera IOps PerSec costantemente gli 8.400: → Aggiorna il livello di storage o ottimizza il carico di lavoro
**Formula di monitoraggio:**
Utilizzo IOPS% = (ReadOpsPerSec \+ WriteOpsPerSec)/IOPS assegnato × 100
+ Obiettivo: mantenere l'utilizzo degli IOPS < 70%
+ Obiettivo: mantenere l'utilizzo degli IOPS al 70%
+ Critico: utilizzo IOPS > 90%
### Comprensione dell'impatto sulle prestazioni di Series Cardinality
La cardinalità delle serie ha un effetto moltiplicativo sulle risorse di sistema:
| **Numero di serie** | **Impatto sulla memoria** | **Impatto sulle prestazioni delle query** | **Impatto sulla dimensione dell'indice** | **Raccomandazione** |
| --- | --- | --- | --- | --- |
| < 100K | Minima | Trascurabile | Small | Configurazione standard |
| 100K - 1 M | Moderata | 10-20% più lento | Media | Ottimizza le impostazioni della cache |
| 1 M - 5 M | Significativo | Più lento del 30-50% | Large | È richiesta un'ottimizzazione aggressiva |
| 5 M - 10 M | Elevata | 50-70% più lento | Molto grande | Ottimizzazione massima, considera la riprogettazione |
| > 10 M | Grave | Oltre il 70% più lento | Eccessivo | Migrazione a InfluxDB 3.0 |
**Perché 10M è la soglia critica:**
+ L'architettura InfluxDB 2.x utilizza l'indicizzazione in memoria
+ Oltre la serie 10M, le operazioni sugli indici diventano proibitivamente costose
+ I requisiti di memoria crescono in modo non lineare
+ Il sovraccarico di pianificazione delle interrogazioni aumenta notevolmente
+ InfluxDB 3.0 utilizza un motore di archiviazione colonnare progettato per un'elevata cardinalità
## Linee guida per il dimensionamento e le prestazioni delle istanze
La tabella seguente fornisce indicazioni sul dimensionamento appropriato delle istanze in base alla cardinalità della serie e alle caratteristiche del carico di lavoro:
| **Numero massimo di serie** | **Scrive (linee/sec)** | **Letture (interrogazioni/sec)** | **Istanza consigliata** | **Storage Type (Tipo di storage)** | **Caso d'uso** |
| --- | --- | --- | --- | --- | --- |
| < 100K | \~50.000 | < 10 | db.influx.large | Influx IO incluso 3K | Implementazioni, sviluppo e test di piccole dimensioni |
| < 1 M | \~150.000 | < 25 | db.influx.2xlarge | Influx IO incluso 3K | Carichi di lavoro di produzione di piccole e medie dimensioni |
| \~1 M | \~200.000 | \~25 | db.influx.4xlarge | Influx IO incluso 3K | Carichi di lavoro di produzione medi |
| < 5 M | \~250.000 | \~35 | db.influx.4xlarge | Influx IO incluso 12K | Grandi carichi di lavoro di produzione |
| < 10 M | \~500.000 | \~50 | db.influx.8xlarge | Influx IO incluso 12K | Carichi di lavoro di produzione molto grandi |
| \~ 10 M | < 750.000 | < 100 | db.influx.12xlarge | Influx IO incluso 12K | Capacità massima di InfluxDB 2.x |
| > 10 M | N/D | N/D | Migrazione a InfluxDB 3.0 | N/D | Oltre l'intervallo ottimale di InfluxDB 2.x |
## Ottimizzazione della configurazione tramite metrica
### Utilizzo elevato della CPU (CPUUtilization > 70%)
**Caratteristiche:**
+ **CPUUtilization**> 70% sostenuto
+ **QueryRequestsTotal**(richieste ad alto volume o lente)
+ **ActiveTaskWorkers**(elevato carico di attività)
**Regolazioni della configurazione:**
**Priorità 1: controllo della concorrenza delle interrogazioni**
+ query-concurrency: impostata sul 50-75% del numero di vCPU
+ Esempio: 8 istanze vCPU → query-concurrency = 4-6
**Priorità 2: Limita la complessità delle interrogazioni**
+ influxql-max-select-series: 10000 (evita interrogazioni illimitate)
+ influxql-max-select-point: 100000000
+ query-queue-size: 2048 (impedisce l'accumulo di code)
**Priorità 3: abilitare l'analisi delle interrogazioni**
+ flux-log-enabled: TRUE (temporaneamente per il debug)
+ log-level: info (o debug per un'analisi dettagliata)
**Considerazioni importanti:**
La riduzione `query-concurrency` limiterà il numero di query che possono essere eseguite contemporaneamente, il che potrebbe aumentare le query in coda e portare a una maggiore latenza delle query durante i periodi di punta. Gli utenti potrebbero riscontrare un rallentamento del caricamento della dashboard o dei timeout dei report se la richiesta di query supera il limite di contemporaneità ridotto.
****L'impostazione dei limiti di protezione (`influxql-max-select-series`,`influxql-max-select-point`) causerà l'esito negativo delle query che superano queste soglie con compile\_error o runtime\_error in. **QueryRequestsTotal****** Sebbene ciò protegga il sistema dall'esaurimento delle risorse, potrebbe interrompere le query esistenti che funzionavano in precedenza.
**Procedura consigliata:** prima di applicare queste modifiche, analizza i modelli di query utilizzando le metriche **QueryResponseVolume**e **QueryRequestsTotal**. Identifica e ottimizza innanzitutto le query più costose: cerca le query senza filtri per intervallo di tempo, le query che coprono serie ad alta cardinalità o le query che richiedono punti dati eccessivi. L'ottimizzazione delle query a livello di applicazione è sempre preferibile all'imposizione di limiti rigidi che potrebbero compromettere la funzionalità.
**Azioni hardware:**
+ Passa alla classe di istanza successiva con più v CPUs
+ Esamina i modelli di query per individuare opportunità di ottimizzazione
### Elevato utilizzo della memoria (MemoryUtilization > 70%)
**Caratteristiche:**
+ **MemoryUtilization**> 70% sostenuto
+ **HeapMemoryUsage**tendenza al rialzo
+ **ActiveMemoryAllocation**mostrando punte
+ **SeriesCardinality**(una cardinalità elevata aumenta l'utilizzo della memoria)
**Regolazioni della configurazione:**
**Priorità 1: ridurre la memoria cache**
+ storage-cache-max-memory-size: impostato sul 10-15% della RAM totale
+ Esempio: 32 GB di RAM → da 3.355.443.200 a 5.033.164.800 byte
+ storage-cache-snapshot-memory- dimensione: 26.214.400 (25 MB)
**Priorità 2: Limita la memoria delle query**
+ query-memory-bytes: Impostato sul 60-70% della RAM totale
+ query-max-memory-bytes: Uguale a query-memory-bytes
+ query-initial-memory-bytes: 10% di query-memory-bytes
**Priorità 3: ottimizzazione della cache della serie**
+ storage-series-id-set-cache-size: riduce la cardinalità se elevata
+ Memoria elevata: 100-200
+ Normale: 500-1000
**Considerazioni importanti:**
Sebbene queste modifiche ridurranno la pressione sulla memoria, avranno un impatto negativo diretto sulle prestazioni delle applicazioni. La riduzione `storage-cache-max-memory-size` comporta una minore quantità di dati nella cache, una maggiore frequenza di letture su disco e un aumento della latenza delle query: è probabile che si verifichi un **ReadOpsPerSec**aumento e un peggioramento dei tempi di **QueryResponseVolume**risposta.
La limitazione `query-memory-bytes` causerà l'esito negativo delle query che richiedono un uso intensivo della memoria con **runtime\_error**, in particolare le query che aggregano set di dati di grandi dimensioni o restituiscono set di **QueryRequestsTotal**risultati sostanziali. Gli utenti possono riscontrare errori di «memoria insufficiente» per le query eseguite in precedenza.
`storage-series-id-set-cache-size`La riduzione riduce le prestazioni per le interrogazioni su dati ad alta cardinalità, in quanto il sistema deve ricalcolare i risultati delle serie più frequentemente anziché recuperarli dalla cache. Ciò influisce in particolare sui dashboard che interrogano ripetutamente le stesse combinazioni di serie.
**Procedura consigliata:** prima di applicare queste modifiche restrittive, analizza i modelli di query e ottimizzali innanzitutto:
+ Esamina **QueryResponseVolume**per identificare le query che restituiscono dati eccessivi
+ Utilizzalo **QueryRequestsTotal**per trovare le query eseguite di frequente che potrebbero trarre vantaggio dall'ottimizzazione
+ Aggiungi filtri per intervallo di tempo per ridurre la scansione dei dati a quanto necessario per il tuo carico di lavoro
+ Implementa la memorizzazione nella cache dei risultati delle query a livello di applicazione
+ Valuta la possibilità di preaggregare i dati utilizzando attività di downsampling
+ Rivedi **SeriesCardinality**e ottimizza il tuo modello di dati per ridurre i tag non necessari
L'ottimizzazione delle query dovrebbe sempre essere il primo approccio: le restrizioni di configurazione dovrebbero essere l'ultima risorsa quando l'ottimizzazione non è sufficiente.
**Azioni hardware:**
+ Aumenta le dimensioni dell'istanza per aumentare la RAM
### Elevato utilizzo dello storage (DiskUtilization > 70%)
**CloudWatch Metriche da monitorare:**
+ **DiskUtilization**> 70%
+ **WriteThroughput**modelli
+ **TotalBuckets**(molti secchi aumentano il sovraccarico)
**Regolazioni della configurazione:**
**Priorità 1: verificare la configurazione della registrazione**
+ log-level: assicurati che sia impostato su «info» (non su «debug»)
+ flux-log-enabled: Impostato su FALSE a meno che non si esegua attivamente il debug
**Priorità 2: Conservazione aggressiva**
+ storage-retention-check-interval: 150 ms (pulizia più frequente)
**Priorità 3: ottimizzare la compattazione**
+ storage-compact-full-write-durata a freddo: 20 ore (più frequente)
+ storage-cache-snapshot-write-durata a freddo: 50ms
**Priorità 4: Ridurre le dimensioni dell'indice**
+ storage-max-index-log-dimensione del file: 524.288 (512 KB per una compattazione più rapida)
**Considerazioni importanti:**
**Primo passaggio fondamentale: verifica la configurazione della registrazione:** prima di apportare altre modifiche, verifica le impostazioni di registrazione. La **registrazione di debug e i log delle query Flux possono occupare tanto o più spazio su disco rispetto ai dati delle serie temporali effettive**, e questa è una delle cause più comuni di esaurimento imprevisto dello storage.
**Impatto sulla registrazione:**
+ `log-level: debug`genera log estremamente dettagliati, potenzialmente centinaia di MB all'ora
+ `flux-log-enabled: TRUE`registra ogni esecuzione di query Flux con tutti i dettagli, creando file di registro di grandi dimensioni
+ Questi log si accumulano rapidamente e vengono spesso trascurati durante la pianificazione della capacità
+ I file di registro possono occupare lo spazio su disco più velocemente dell'inserimento dei dati, specialmente su istanze più piccole
+ A differenza dei dati delle serie temporali, i log vengono conservati nella memoria locale per 24 ore prima dell'eliminazione
**Azioni immediate se i log sono di grandi dimensioni:**
1. Set `log-level: info` (da debug)
1. Imposta `flux-log-enabled: FALSE`
1. Monitoraggio **DiskUtilization**per un miglioramento immediato
**Compromessi relativi alla configurazione di compattazione:**
Queste modifiche alla configurazione sono progettate specificamente per carichi di lavoro con un **elevato throughput di ingestione e finestre di conservazione brevi**, in cui l'utilizzo del disco varia notevolmente. Costringono il motore di compattazione a funzionare in modo più aggressivo, il che è vantaggioso solo in scenari specifici.
**Compromessi critici:** l'aumento della frequenza di compattazione aumenterà in modo significativo il consumo di risorse:
+ **CPUUtilization**aumenterà man mano che le operazioni di compattazione consumeranno i cicli della CPU
+ **MemoryUtilization**aumenterà durante la compattazione man mano che i dati vengono caricati ed elaborati
+ **WriteOpsPerSec**e **WriteThroughput**aumenterà durante le finestre di compattazione, superando potenzialmente il margine di crescita del 30% in IOPS
+ **WriteTimeouts**può aumentare se la compattazione è in concorrenza con la scrittura delle applicazioni I/O
Queste modifiche possono creare un problema di prestazioni a cascata in quanto una compattazione aggressiva consuma le risorse necessarie per le operazioni di query e scrittura, peggiorando le prestazioni complessive del sistema e riducendo al contempo l'utilizzo del disco.
Procedura **ottimale:** prima di modificare le impostazioni di compattazione, concentrati sulla gestione dei dati e dei log:
1. **Verifica prima la registrazione (problema più comune):** verifica che il livello di registro sia «info» e sia FALSO flux-log-enabled
1. **Rivedi il tuo modello di dati:** stai scrivendo dati che in realtà non ti servono? È possibile ridurre la granularità della misurazione o del campo?
1. **Ottimizza le politiche di conservazione:** controlla **TotalBuckets**e rivedi le impostazioni di conservazione per ogni bucket
1. **Monitora l'impatto sulla compattazione:** elabora le modifiche apportate **CPUUtilization**e prima di **MemoryUtilization**esse **WriteOpsPerSec**
**Approcci alternativi:**
+ Aumentare la capacità di archiviazione (spesso più semplice ed economica)
+ Implementa strategie di downsampling o aggregazione dei dati
+ Consolida i bucket (riduci) per ridurre i costi generali **TotalBuckets**
+ Rivedi e applica le politiche di conservazione in modo più rigoroso
Applica impostazioni di compattazione aggressive solo se hai ottimizzato la gestione dei dati e hai verificato che l'istanza dispone di CPU, memoria e margini di IOPS sufficienti per gestire l'aumento del carico.
**Azioni hardware:**
+ Aumentare la capacità di archiviazione
### Elevato utilizzo degli IOPS (ReadIOPS/WriteIOPS/TotalOperationsPerSecond> 70% del provisioning)
**CloudWatch Metriche da monitorare:**
+ **ReadOpsPerSec****\+ **WriteOpsPerSec**= Totale IOps PerSec**
+ **ReadThroughput** e **WriteThroughput**
+ Confronta con gli IOPS assegnati (3K, 12K o 16K)
**Regolazioni della configurazione:**
**Priorità 1: Control Compaction I/O**
+ storage-max-concurrent-compactions: 2-3 (limita le compattazioni simultanee)
+ storage-compact-throughput-burst: regolazione in base alla capacità del disco
+ 3.000 IOPS: 25.165.824 (24 MB/s)
+ 12.000 IOPS: 50.331.648 (48 MB/s)
**Priorità 2: ottimizzare le operazioni di scrittura**
+ storage-wal-max-concurrent-scrive: 8-12
+ storage-wal-max-write-ritardo: 50 ms
**Priorità 3: Regola la tempistica delle istantanee**
+ storage-cache-snapshot-write-durata a freddo: 150 ms (meno frequente)
+ storage-compact-full-write-durata a freddo: 60 ore (meno frequente)
**Considerazioni importanti:**
Queste modifiche creano compromessi significativi tra I/O utilizzo e prestazioni del sistema:
**Limitazione degli I/O di compattazione:**
+ `storage-max-concurrent-compactions`La riduzione rallenterà le operazioni di compattazione, provocando l'accumulo e l'aumento più rapido dei file TSM **DiskUtilization**
+ Lower `storage-compact-throughput-burst` estende la durata della compattazione, mantenendo il compattatore attivo più a lungo e potenzialmente bloccando altre operazioni
+ Una compattazione più lenta comporta un peggioramento delle prestazioni delle query nel tempo, poiché il motore di storage deve leggere file TSM più numerosi e più piccoli anziché da file consolidati
+ È possibile che le percentuali di **QueryRequestsTotal**runtime\_error aumentino man mano che le query scadono in attesa dell'I/O
**Riduzione della frequenza delle istantanee:**
+ Aumenta `storage-cache-snapshot-write-cold-duration` e `storage-compact-full-write-cold-duration` significa che i dati rimangono più a lungo nel write-ahead log (WAL)
+ Ciò aumenta man **MemoryUtilization**mano che più dati vengono conservati nella cache prima di essere scaricati su disco
+ Il rischio di perdita dei dati aumenta leggermente se l'istanza si blocca prima che i dati memorizzati nella cache vengano mantenuti
+ Il tempo di ripristino dopo un riavvio aumenta man mano che è necessario riprodurre più dati WAL
**Write Operation Tuning:**
+ `storage-wal-max-concurrent-writes`La riduzione consentirà di serializzare maggiormente le operazioni di scrittura, con un potenziale aumento **WriteTimeouts**durante i periodi di elevata produttività
+ L'aumento `storage-wal-max-write-delay` significa che le scritture possono attendere più a lungo prima di essere rifiutate, il che può mascherare problemi di capacità ma frustrare gli utenti con risposte lente
**Best practice:** un elevato utilizzo di IOPS in genere indica che il livello di storage è troppo elevato e non un problema di configurazione. Prima di limitare i I/O, analyze I/O modelli e ottimizzare prima di limitare.
**Azioni hardware:**
+ Aggiornamento a un livello di storage IOPS superiore (3K → 12K)
+ Assicurati che venga mantenuto un margine di crescita IOPS del 30%
### Cardinalità della serie High (> 1M) SeriesCardinality
**CloudWatch Metriche da monitorare:**
+ **SeriesCardinality**per secchio e in totale
+ **MemoryUtilization**(aumenta con la cardinalità)
+ **CPUUtilization**(sovraccarico di pianificazione delle interrogazioni)
+ **QueryRequestsTotal**(il tasso di runtime\_error potrebbe aumentare)
**Regolazioni della configurazione:**
**Priorità 1: ottimizzare la gestione delle serie**
+ storage-series-id-set-cache-size: 1000-2000 (aumenta la cache)
+ storage-series-file-max-concurrent-snapshot-compactions: 4-8
**Priorità 2: impostare limiti di protezione**
+ influxql-max-select-series: 10000 (evita le interrogazioni indesiderate)
+ influxql-max-select-buckets: 1000
**Priorità 3: ottimizzare le operazioni relative agli indici**
+ storage-max-index-log- dimensione del file: 2.097.152 (2 MB)
**Considerazioni importanti:**
La cardinalità di serie elevata è fondamentalmente un problema di modellazione dei dati, non un problema di configurazione. Le modifiche alla configurazione possono solo mitigare i sintomi, non possono risolvere il problema di fondo.
**Compromessi di configurazione:**
L'aumento `storage-series-id-set-cache-size` migliorerà le prestazioni delle query memorizzando nella cache le ricerche di serie, ma a costo di un aumento. **MemoryUtilization** Ogni voce della cache consuma memoria e, con milioni di serie, questo può essere notevole. Monitora **HeapMemoryUsage**e **ActiveMemoryAllocation**dopo aver apportato questa modifica.
L'impostazione dei limiti di protezione (`influxql-max-select-series`,`influxql-max-select-buckets`) causerà il fallimento delle query legittime con **compile\_error** in **QueryRequestsTotal**se superano queste soglie. I dashboard che in precedenza funzionavano potrebbero non funzionare e gli utenti dovranno modificare le proprie query. Ciò è particolarmente problematico per:
+ Dashboard di monitoraggio che si aggregano su molti host/servizi
+ Query di analisi che devono confrontare più entità
+ Interrogazioni di avviso che valutano le condizioni dell'intero parco veicoli
L'adattamento `storage-max-index-log-file-size` a valori più bassi aumenta la frequenza di compattazione dell'indice, il che aumenta **WriteOpsPerSec**man mano che il sistema esegue una manutenzione più **CPUUtilization**frequente dell'indice.
**Comprensione critica:**
Quando **SeriesCardinality**supera i 5 milioni, ti stai avvicinando ai limiti architettonici di InfluxDB 2.x. Nella serie 10M\+, le prestazioni diminuiscono in modo esponenziale indipendentemente dalla configurazione:
+ La pianificazione delle interrogazioni diventa proibitivamente costosa (elevata) **CPUUtilization**
+ I requisiti di memoria aumentano in modo non lineare (elevato) **MemoryUtilization**
+ Le operazioni di indicizzazione dominano (, I/O ) **ReadOpsPerSec**WriteOpsPerSec****
+ **QueryRequestsTotal**Le percentuali di runtime\_error aumentano man mano che le query scadono o esauriscono la memoria
**Procedura consigliata**: le modifiche alla configurazione sono cerotti temporanei. È necessario risolvere la causa principale:
1. **Analizza il tuo modello di dati:**
+ Revisione **SeriesCardinality**per bucket per identificare le aree problematiche
+ Identifica quali tag hanno un numero elevato di valori unici
+ Cerca valori di tag illimitati (UUIDs, timestamp, utente, sessione) IDs IDs
+ Trova invece tag che dovrebbero essere campi
**Azioni del modello di dati:**
+ Rivedi il design dei tag per ridurre la cardinalità non necessaria
+ Prendi in considerazione il consolidamento di serie simili
+ **Serie If > 10M:** pianifica la migrazione a InfluxDB 3.0
### Problemi relativi alle prestazioni delle query
**CloudWatch Metriche da monitorare:**
+ **QueryRequestsTotal**per tipo di risultato (success, runtime\_error, compile\_error, queue\_error)
+ **APIRequestValuta** con Status=500 o Status=499
+ **QueryResponseVolume**(le risposte di grandi dimensioni indicano domande costose)
**Regolazioni della configurazione:**
**Priorità 1: aumentare le risorse di interrogazione**
+ query-concurrency: aumento al 75% di v CPUs
+ query-memory-bytes: Alloca il 70% della RAM totale
+ query-queue-size: 4096
**Priorità 2: ottimizzare l'esecuzione delle query**
+ storage-series-id-set-cache-size: 1000 (aumenta per una migliore memorizzazione nella cache)
+ http-read-timeout: 60s (evita timeout prematuri)
**Priorità 3: stabilire limiti ragionevoli**
+ influxql-max-select-point: 100000000
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
**Considerazioni importanti:**
L'aumento delle risorse di interrogazione crea concorrenza tra le risorse e potenziale instabilità del sistema:
**Compromessi per l'allocazione delle risorse:**
L'aumento `query-concurrency` consente l'esecuzione simultanea di più query, ma ogni query compete per CPU e memoria:
+ **CPUUtilization**aumenterà, raggiungendo potenzialmente la saturazione durante i periodi di picco delle query
+ **MemoryUtilization**aumenterà man mano che più query allocano memoria contemporaneamente
+ Se si aumenta la concorrenza senza risorse adeguate, tutte le query rallentano invece di limitarsi ad accodarsi
+ Rischio di errori a cascata se le query simultanee esauriscono le risorse disponibili
Allocare di più `query-memory-bytes` significa meno memoria disponibile per la memorizzazione nella cache e altre operazioni:
+ **HeapMemoryUsage**aumenterà
+ `storage-cache-max-memory-size`potrebbe dover essere ridotto per compensare
+ Un minor numero di accessi alla cache significa prestazioni di query più elevate **ReadOpsPerSec**e più lente
+ Il sistema diventa più vulnerabile all'esaurimento della memoria se le query utilizzano la loro allocazione completa
L'aumento `query-queue-size` non fa che ritardare il problema, ma non risolve i problemi di capacità:
+ Le interrogazioni attendono più a lungo in coda, con conseguente aumento della latenza end-to-end
+ Gli utenti percepiscono il sistema come più lento anche se la velocità effettiva potrebbe rimanere invariata
+ Le code di grandi dimensioni possono mascherare i problemi di capacità sottostanti
+ **QueryRequestsTotal**Il tasso di queue\_error diminuisce, ma l'esperienza utente potrebbe non migliorare
L'aumento `http-read-timeout` impedisce l'annullamento prematuro delle query, ma:
+ Le interrogazioni a esecuzione prolungata consumano risorse più a lungo, riducendo la capacità per altre interrogazioni
+ Gli utenti attendono più a lungo prima di ricevere errori di timeout
+ Può nascondere interrogazioni inefficienti che devono essere ottimizzate
+ Può portare all'esaurimento delle risorse se si accumulano molte query lente
**Procedura consigliata:** i problemi di prestazioni delle query sono in genere causati da query inefficienti, non da risorse insufficienti. Prima di aumentare l'allocazione delle risorse:
1. **Analizza i modelli di interrogazione:**
+ Esamina **QueryResponseVolume**per identificare le query che restituiscono dati eccessivi (> 1 MB)
+ Controlla i pattern **QueryRequestsTotal**runtime\_error: cosa causa gli errori?
+ Cerca **APIRequestRate** with Status=499 (timeout del client): le query sono troppo lente
+ Identifica le query costose eseguite di frequente
1. **Ottimizza innanzitutto le query:**
Anti-pattern di query comuni:
+ Filtri per intervallo di tempo mancanti → Aggiungi limiti di tempo espliciti
+ Interrogazione di tutte le serie → Aggiungi filtri di tag specifici
+ Finestre di aggregazione eccessive → Usa intervalli appropriati
+ Campi non necessari in SELEZIONA → Richiedi solo i dati necessari
+ Clausole No LIMIT → Aggiungi limiti ragionevoli
1. **Soluzioni a livello di applicazione:**
+ Implementa la memorizzazione nella cache dei risultati delle query (Redis, Memcached)
+ Utilizza le attività per preaggregare modelli comuni
+ Aggiungi l'impaginazione per set di risultati di grandi dimensioni
+ Implementa la limitazione della frequenza di query per utente/dashboard
+ Utilizza i dati sottocampionati per le query cronologiche
1. **Verifica la disponibilità delle risorse:**
+ Verifica **CPUUtilization**: se già supera il 70%, l'aumento della concorrenza peggiorerà le cose
+ Verifica **MemoryUtilization**: se è già superiore al 70%, l'allocazione di più memoria per le query causerà l'OOM
+ Verifica che **Total IOps PerSec** abbia un margine di crescita del 30% prima di aumentare il carico delle query
**Approccio consigliato:**
1. Inizia ottimizzando le 10 query più costose (per) **QueryResponseVolume**
1. Implementa la memorizzazione nella cache dei risultati delle query a livello di applicazione
1. Aumentate l'allocazione delle risorse solo se le query sono ottimizzate e le metriche mostrano margini di manovra
1. Passa a una classe di istanze più ampia se il carico di lavoro ha superato la capacità attuale
**Azioni hardware:**
+ Scalate la vostra capacità di elaborazione, le query traggono vantaggio da una maggiore potenza di elaborazione (v) CPUs
#### RegEx Insidie prestazionali nelle query Flux
Quando filtrate i dati in Flux, evitate di usare espressioni regolari per corrispondenze esatte o semplici corrispondenze di pattern, poiché ciò comporta notevoli penalizzazioni in termini di prestazioni. RegEx **le operazioni in Flux sono a **thread singolo** e aggirano completamente l'indice TSM sottostante.** Invece di sfruttare gli indici di tag ottimizzati di InfluxDB per ricerche rapide, i RegEx filtri costringono il motore di query a recuperare tutte le serie corrispondenti dall'archivio ed eseguire confronti di testo in sequenza per ogni valore. Ciò diventa particolarmente problematico quando:
+ **Filtraggio in base ai valori esatti dei tag**: utilizza l'operatore di uguaglianza (`==`) o la `contains()` funzione anziché RegEx modelli come `/^exact_value$/`
+ **Corrispondenza a più valori specifici**: utilizza l'`in`operatore con una matrice di valori anziché schemi di alternanza come `/(value1|value2|value3)/`
+ **Semplice abbinamento di prefissi o suffissi**: valuta la possibilità di utilizzare `strings.hasPrefix()` le nostre `strings.hasSuffix()` funzioni, che sono più efficienti degli ancoraggi RegEx
Per scenari che richiedono più corrispondenze di pattern, ristruttura la query per utilizzare più predicati di filtro combinati con operatori logici oppure prefiltra utilizzando l'uguaglianza dei tag prima di applicare operazioni sulle stringhe più complesse. Riserva RegEx esclusivamente ai casi che richiedono una vera corrispondenza di modelli che non può essere espressa tramite operatori di confronto più semplici.
### Problemi di prestazioni di scrittura
**CloudWatch Metriche da monitorare:**
+ **WriteTimeouts**(conteggio crescente)
+ **WriteOpsPerSec** e **WriteThroughput**
+ **APIRequestFrequenza** con Status=500 per gli endpoint di scrittura
+ **QueryRequestsTotal**con result=runtime\_error durante le scritture
**Regolazioni della configurazione:**
**Priorità 1: ottimizzazione delle scritture WAL**
+ storage-wal-max-concurrent-scrive: 12-16
+ storage-wal-max-write-ritardo: 100 ms
+ http-write-timeout: anni '60
**Priorità 2: ottimizzazione delle istantanee della cache**
+ storage-cache-snapshot-memory- dimensione: 52.428.800 (50 MB)
+ storage-cache-snapshot-write-durata a freddo: 100 ms
**Priorità 3: convalida del campo di controllo**
+ storage-no-validate-field-size: TRUE (se l'origine dati è attendibile)
**Considerazioni importanti:**
L'ottimizzazione delle prestazioni di scrittura implica un attento compromesso tra velocità effettiva, affidabilità e consumo di risorse:
**Compromessi relativi alla configurazione WAL:**
L'aumento `storage-wal-max-concurrent-writes` consente più operazioni di scrittura parallele, ma:
+ **CPUUtilization**aumenta man mano che più thread di scrittura competono per la CPU
+ **MemoryUtilization**aumenta man mano che più dati vengono bufferizzati nella memoria prima del lavaggio del WAL
+ **WriteOpsPerSec**aumenterà, superando potenzialmente il margine di crescita di IOPS del 30%
+ L'aumento del conflitto su disco I/O può effettivamente rallentare le singole scritture
+ Se si supera la I/O capacità del disco, **WriteTimeouts**può aumentare anziché diminuire
Aumentare `storage-wal-max-write-delay` significa che le scritture attendono più a lungo prima del timeout:
+ Maschera i problemi di capacità facendo attendere le scritture anziché fallire rapidamente
+ Gli utenti riscontrano tempi di risposta in scrittura più lenti anche quando le scritture alla fine hanno esito positivo
+ Può portare all'accumulo di code di scrittura e alla pressione della memoria
+ In realtà non aumenta la capacità, ritarda solo il timeout
L'aumento dei ritardi in `http-write-timeout` modo simile ritarda gli errori di timeout:
+ Consente il completamento di scritture in batch più grandi
+ Ma consente anche che le scritture lente consumino risorse più a lungo
+ Può nascondere i problemi di prestazioni sottostanti
+ Può portare all'esaurimento delle risorse se si accumulano molte scritture lente
**Compromessi relativi a Cache Snapshot:**
L'aumento `storage-cache-snapshot-memory-size` significa che più dati si accumulano nella memoria prima del flushing:
+ **MemoryUtilization**aumenta in modo significativo
+ Il rischio di perdita dei dati aumenta se l'istanza si blocca prima dell'istantanea
+ Le istantanee più grandi richiedono più tempo per essere scritte, creando picchi più grandi **WriteOpsPerSec**
+ Può migliorare la velocità di scrittura raggruppando più dati in batch, ma a scapito della memoria e dell'affidabilità
Istantanee con `storage-cache-snapshot-write-cold-duration` ritardi crescenti:
+ Aumenta ulteriormente man **MemoryUtilization**mano che i dati rimangono nella cache più a lungo
+ Aumenta la finestra di rischio di perdita dei dati
+ Riduce la **WriteOpsPerSec**frequenza ma crea picchi più grandi quando si verificano istantanee
+ Il tempo di ripristino dopo il riavvio aumenta man mano che è necessario ripetere più WAL
**Compromesso per la convalida del campo:**
L'impostazione `storage-no-validate-field-size: TRUE` disabilita la convalida della dimensione del campo:
+ Migliora la velocità di scrittura saltando i controlli di convalida
+ **Rischio critico:** consente la scrittura di dati malformati o dannosi
+ Può causare il danneggiamento dei dati se le scritture contengono dimensioni di campo non valide
+ Rende molto più difficili i problemi di debug dei dati
+ **Utilizzalo solo se hai il controllo completo e la fiducia della tua fonte di dati**
**Procedura ottimale:** i problemi di prestazioni di scrittura in genere indicano limiti di capacità o modelli di scrittura inefficienti. Prima di ottimizzare la configurazione:
1. **Analizza i modelli di scrittura:**
+ Revisione **WriteThroughput**e **WriteOpsPerSec**tendenze
+ Verifica la **WriteTimeouts**correlazione con il carico di scrittura
+ Monitora la **APIRequestfrequenza di** scrittura degli endpoint in base al codice di stato
+ Identifica le dimensioni e la frequenza dei batch di scrittura
1. **Ottimizza innanzitutto le operazioni di scrittura:**
Anti-pattern di scrittura comuni:
+ Scrittura di punti individuali → Scritture in batch (5.000-10.000 punti)
+ Scritture troppo frequenti → Buffer e batch
+ Scritture sincrone → Implementa code di scrittura asincrone
+ Burst di scrittura illimitati → Implementa la limitazione della velocità
+ Scrittura con precisione non necessaria → Arrotonda i timestamp in modo appropriato
1. **Verifica la capacità: I/O **
+ Controlla **Total IOps PerSec**: se già supera il 70%, l'aumento della concorrenza WAL peggiorerà le cose
+ Rivedi **WriteOpsPerSec**durante i periodi di punta
+ Assicurati che esista un margine IOPS del 30% prima di ottimizzare le impostazioni di scrittura
+ Valuta se 3.000 IOPS sono sufficienti o se è necessario un livello di 12.000 IOPS
1. **Miglioramenti a livello di applicazione:**
+ Implementa il buffering di scrittura con dimensioni di batch configurabili
+ Aggiungi una logica di ripetizione dei tentativi di scrittura con backoff esponenziale
+ Utilizza operazioni di scrittura asincrone
+ Implementa la limitazione della velocità di scrittura durante i periodi di punta
+ Monitora la profondità della coda di scrittura e applica la contropressione
**Approccio consigliato:**
1. Inizia ottimizzando le dimensioni dei batch di scrittura a livello di applicazione (obiettivo a 5.000-10.000 punti per batch)
1. Implementa operazioni asincrone e di buffering di scrittura
1. Verifica che **IOpsPerSecTotal** disponga di un margine di crescita adeguato
1. Passa al livello di storage successivo (3.000 IOPS → 12.000 IOPS → 16.000 IOPS) se l'utilizzo è costantemente superiore al 70%
1. Ottimizza le impostazioni WAL solo se le scritture sono ottimizzate e la capacità è adeguata I/O
1. **Non disabilitate mai** la convalida dei campi a meno che non abbiate il controllo completo delle fonti di dati
**Azioni hardware:**
+ Aggiornamento a uno storage IOPS superiore (3K → 12K → 16K)
+ Assicurati che lo spazio per la testa sia adeguato I/O
+ Scala a una classe di istanza più ampia se la CPU o la memoria sono limitate
## Le migliori pratiche di monitoraggio
### CloudWatch Configurazione degli allarmi
**Allarmi critici (è richiesta un'azione immediata):**
**CPUUtilization:**
+ Soglia: > 90% per 5 minuti
+ Azione: implementare misure di ripristino del traffico o scalabilità di calcolo
**MemoryUtilization:**
+ Soglia: > 90% per 5 minuti
+ Azione: implementare misure di ripristino del traffico o scalabilità di calcolo
**DiskUtilization:**
+ Soglia: > 85%
+ Azione: prova a liberare spazio eliminando i vecchi bucket, aggiornando le configurazioni di conservazione o lo storage scaling
**Totale IOpsPerSec:**
+ Soglia: > 90% del quantitativo fornito per 10 minuti
+ Azione: implementare misure di ripristino del traffico o aumentare gli IOPS
**SeriesCardinality:**
+ Soglia: > 10.000.000
+ Azione: rivedi il tuo modello di dati, se non sono possibili modifiche esplora, migra a InfluxDB 3 o condividi i tuoi dati
**EngineUptime:**
+ Soglia: ripristino imprevisto (< 300 secondi)
+ Azione: verifica che coincida con una finestra di manutenzione, altrimenti crea un ticket per l'assistenza Timestream.
**Allarmi di avviso (è richiesta un'indagine):**
**CPUUtilization:**
+ Soglia: > 70% per 15 minuti
+ Azione: rivedere le modifiche al carico di lavoro o al traffico
**MemoryUtilization:**
+ Soglia: > 70% per 15 minuti
+ Azione: rivedere le modifiche al carico di lavoro o al traffico
**DiskUtilization:**
+ Soglia: > 70%
+ Azione: rivedere le politiche di conservazione
**Totale IOpsPerSec:**
+ Soglia: > 70% del quantitativo fornito per 15 minuti
+ Azione: rivedere le modifiche al carico di lavoro o al traffico
**QueryRequestsTotal (runtime\_error):**
+ Soglia: > 1% del totale delle interrogazioni
+ Azione: rivedere le modifiche al carico di lavoro o al traffico
**WriteTimeouts:**
+ Soglia: > 1% delle operazioni di scrittura
+ Azione: rivedere le modifiche al carico di lavoro o al traffico
**SeriesCardinality:**
+ Soglia: > 5.000.000
+ Azione: rivedere l'ottimizzazione del modello di dati
### Lista di controllo per il monitoraggio proattivo
**Quotidiano:**
+ APIRequestFrequenza di revisione dei picchi di errore (400, 404, 499, 500)
+ Controlla le percentuali di QueryRequestsTotal runtime\_error e queue\_error
+ Il numero di verifiche è minimo WriteTimeouts
+ Verifica la presenza di eventuali allarmi critici
+ Verifica EngineUptime (nessun riavvio imprevisto)
**Settimanale:**
+ MemoryUtilizationRevisione CPUUtilization e DiskUtilization tendenze
+ Analizza QueryRequestsTotal i modelli per tipo di risultato
+ Controlla il tasso di SeriesCardinality crescita per secchio
+ Esamina le tendenze di IOps PerSec utilizzo totale
+ Verifica che i parametri di configurazione siano ottimali
+ TaskExecutionFailures Schemi di revisione
**Mensile:**
+ Revisione della pianificazione della capacità (progetto con 3-6 mesi di anticipo)
+ Confronta le metriche attuali con la tabella di dimensionamento
+ Rivedi e ottimizza le politiche di conservazione
+ Analizza i modelli di query di APIRequest Rate and QueryResponseVolume
+ Revisione SeriesCardinality ed efficienza del modello di dati
+ Valuta la necessità, ad esempio, di scalabilità o modifiche alla configurazione
+ Opportunità di revisione TotalBuckets e consolidamento
## Risoluzione dei problemi
### Scenario: peggioramento improvviso delle prestazioni
**Fasi dell'indagine:**
**Controlla le modifiche recenti:**
+ Modifiche ai parametri di configurazione nella console di AWS gestione
+ Modifiche alla distribuzione delle applicazioni
+ Modifiche al modello di query
+ Modifiche al modello di dati
+ Modifiche all'infrastruttura (tipo di istanza, archiviazione)
**Esamina le CloudWatch metriche:**
+ **Picco della CPU?** → Controlla CPUUtilization, QueryRequestsTotal
+ **Pressione della memoria?** → Controlla MemoryUtilization HeapMemoryUsage, ActiveMemoryAllocation
+ **Saturazione IOPS?** → Controlla il totale IOpsPerSec, ReadOpsPerSec WriteOpsPerSec
+ **Salto di cardinalità nella serie?** → Controlla la crescita SeriesCardinality
+ **Aumento del tasso di errore?** → Verifica QueryRequestsTotal (runtime\_error), APIRequest Frequenza (Status=500)
+ **Riavvio imprevisto?** → Controlla EngineUptime
**Abilita la registrazione dettagliata:**
Modifiche alla configurazione:
+ log-level: debug
+ flux-log-enabled: VERO
Monitora per 1-2 ore, quindi rivedi i registri
Ritorna al livello di registro: informazioni dopo l'indagine
**Fasi di risoluzione:**
+ Applica le modifiche di configurazione appropriate in base ai risultati
+ Ridimensiona le risorse se vengono raggiunti i limiti
+ Ottimizza le query o il modello di dati, se necessario
+ Implementa la limitazione della velocità in caso di aumento improvviso del carico
### Scenario: esaurimento della memoria
**Caratteristiche:**
+ MemoryUtilization > 90%
+ HeapMemoryUsage si avvicina al massimo
+ QueryRequestsTotal visualizzazione di runtime\_error (memoria esaurita)
+ APIRequestFrequenza di visualizzazione dello status=500
**Fasi di risoluzione:**
Azioni immediate (se critiche):
1. Riavvia l'istanza per cancellare la memoria (se è sicuro farlo)
1. Riduci temporaneamente la concorrenza tra le query
1. Se possibile, elimina le query di lunga durata
Modifiche alla configurazione:
**Priorità 1: ridurre la memoria cache**
+ storage-cache-max-memory-dimensione: riduzione al 10% della RAM
+ Esempio: 32 GB → 3.355.443.200 byte
+ storage-cache-snapshot-memory- dimensione: 26.214.400 (25 MB)
**Priorità 2: Limita la memoria delle query**
+ query-memory-bytes: impostato sul 60% della RAM totale
+ query-max-memory-bytes: Incontro query-memory-bytes
+ query-initial-memory-bytes: 10% di query-memory-bytes
**Priorità 3: stabilire limiti di protezione**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
+ query-concurrency: riduzione al 50% di v CPUs
**Soluzioni a lungo termine:**
+ Ottimizza il modello di dati per ridurre **SeriesCardinality**
+ Implementa i limiti delle dimensioni dei risultati delle query a livello di applicazione
+ Aggiungi l'applicazione del timeout delle query
+ Esamina le query più comuni per assicurarti che seguano le migliori pratiche menzionate nella sezione [Problemi relativi alle prestazioni delle query](#query-performance-issues)
### Scenario: High Series Cardinality Impact
** CloudWatch Metriche di revisione:**
+ **SeriesCardinality**> 5 M
+ **MemoryUtilization**alto
+ **QueryRequestsTotal**mostrando un runtime\_error aumentato
+ **CPUUtilization**elevato a causa del sovraccarico di pianificazione delle query
**Fasi dell'indagine:**
**Analizza la crescita della cardinalità:**
+ SeriesCardinality tasso di crescita (giornaliero/settimanale)
+ Proiezione fino alla soglia dei 10 M
+ Identifica le fonti di elevata cardinalità
+ Rivedi il design e l'utilizzo dei tag
**Valuta l'impatto sulle prestazioni:**
+ Confronta **QueryRequestsTotal**il tasso di successo, l'aumento before/after della cardinalità
+ Rivedi la correlazione **MemoryUtilization**
+ Controlla i modelli **CPUUtilization**
+ Analizza **QueryResponseVolume**le tendenze
**Identifica le fonti di cardinalità:**
Rivedi il modello di dati:
+ Quali secchi hanno il valore più alto SeriesCardinality?
+ Quali tag hanno un numero elevato di valori unici?
+ Esistono tag non necessari?
+ I valori dei tag sono illimitati (UUIDs, timestamp, ecc.)?
**Rivedi la configurazione attuale:**
Controlla i parametri di ottimizzazione:
+ storage-series-id-set-cache-size: valore attuale?
+ influxql-max-select-series: Sta limitando le interrogazioni in corso?
+ storage-max-index-log-file-size: appropriato per la cardinalità?
**Fasi di risoluzione:**
Modifiche immediate alla configurazione:
**Priorità 1: ottimizzare la gestione delle serie**
+ storage-series-id-set-dimensione della cache: 1500-2000
+ storage-series-file-max-concurrent-snapshot-compactions: 6-8
+ storage-max-index-log- dimensione del file: 2.097.152 (2 MB)
**Priorità 2: Impostazione dei limiti di protezione**
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
+ query-concurrency: Riduce se la memoria è limitata
**Priorità 3: aumentare le risorse**
+ Passa al livello di istanza successivo
+ Aumenta l'allocazione della memoria
+ Prendi in considerazione un livello di storage da 12.000 IOPS
**Pianificazione della migrazione (se serie > 10M):**
+ **InfluxDB 3.0 offre prestazioni superiori ad alta cardinalità**
+ Pianifica la tempistica della migrazione (2-3 mesi)
+ Esegui prima il test con un sottoinsieme di dati
+ Preparare l'applicazione per la migrazione
+ InfluxDB 3.0 utilizza lo storage colonnare ottimizzato per miliardi di serie
### Scenario: Query Queue Buildup
**Esamina le metriche: CloudWatch **
+ **QueryRequestsTotal**con result=queue\_error in aumento (le query vengono rifiutate)
+ **APIRequestValuta** con Status=429 o Status=503 (servizio per molte richieste) unavailable/too
+ **CPUUtilization**può essere elevato (> 70%) a indicare la saturazione delle risorse
+ **MemoryUtilization**può essere elevato (> 70%) e limita la capacità di interrogazione
+ **QueryResponseVolume**mostrare dimensioni di risposta elevate (le query richiedono risorse eccessive)
**Fasi dell'indagine:**
**Analizza le metriche relative alla coda e alla concorrenza:**
+ **QueryRequestsTotal**Ripartizione delle recensioni per tipo di risultato:
+ Un numero elevato di queue\_error indica che le query vengono rifiutate
+ Confronta la percentuale di successo con quella di base: è in calo?
+ Controlla gli aumenti di runtime\_error (le query falliscono dopo l'avvio)
+ **APIRequestMonitora** i modelli di frequenza:
+ Cerca Status=429 (troppe richieste) o Status=503 (servizio non disponibile)
+ Identifica quali endpoint sono stati respinti
+ Controlla l'andamento del tasso di richiesta nel tempo
**Esamina l'utilizzo delle risorse:**
+ **CPUUtilization**durante i periodi di coda elevati:
+ Se > 70%, le query sono legate alla CPU e non possono essere eseguite più velocemente
+ Se < 50%, i limiti di coda potrebbero essere troppo restrittivi
+ **MemoryUtilization**correlazione:
+ L'elevata quantità di memoria può limitare la concorrenza delle query
+ Verifica **HeapMemoryUsage**e verifica la pressione della **ActiveMemoryAllocation**memoria
+ IOpsPerSecSchemi **totali**:
+ Un valore elevato I/O potrebbe rallentare l'esecuzione delle query
+ Controlla se le query sono associate I/O
**Identifica i modelli di interrogazione:**
+ Revisione **QueryResponseVolume**:
+ Le query restituiscono dati eccessivi (> 1 MB)?
+ Identifica gli endpoint con i maggiori volumi di risposta
+ Cerca schemi ricorrenti nelle query più costose
+ Analizza la **QueryRequestsTotal**velocità:
+ Qual è la frequenza delle interrogazioni al secondo?
+ Esistono modelli di raffica o carichi elevati sostenuti?
+ Confrontate la capacità delle istanze indicata nella tabella di dimensionamento
+ **APIRequestFrequenza di** verifica per endpoint:
+ Quali endpoint di query hanno il traffico più elevato?
+ Esistono query duplicate o ridondanti?
**Verifica la disponibilità delle risorse:**
+ Confronta le metriche attuali con le raccomandazioni della tabella di dimensionamento:
+ **SeriesCardinality**rispetto alla capacità della classe di istanza
+ Frequenza di query rispetto alle query consigliate al secondo
+ **CPUUtilization**e spazio per la testa **MemoryUtilization**
+ Verifica la capacità IOPS:
+ **Il totale IOps PerSec** dovrebbe avere un margine di crescita del 30%
+ Controlla se le query sono in attesa sull'I/O del disco
**Fasi di risoluzione:**
Modifiche alla configurazione:
**Priorità 1: aumentare la capacità della coda**
+ query-queue-size: 4096 (dal valore predefinito 1024)
**Priorità 2: aumentare la concorrenza (se le risorse lo consentono)**
+ query-concurrency: aumento al 75% di v CPUs
+ Esempio: 16 vCPU → query-concurrency = 12
+ Verify CPUUtilization rimane < 80% dopo la modifica
+ Verifica MemoryUtilization i soggiorni < 80% dopo la modifica
**Priorità 3: ottimizzare l'esecuzione delle query**
+ query-memory-bytes: Garantire un'allocazione adeguata
+ storage-series-id-set-dimensione della cache: 1000-1500
+ http-read-timeout: 120 secondi (previene i timeout prematuri)
**Priorità 4: Impostazione dei limiti di protezione**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
**Soluzioni a livello di applicazione:**
+ **Implementa la memorizzazione nella cache dei risultati delle query (Redis, Memcached**)
+ Memorizza i risultati della cache per le query eseguite di frequente
+ Imposta in modo appropriato TTLs in base ai requisiti di freschezza dei dati
+ Monitora l'hit rate della cache
+ **Utilizza interrogazioni continue per preaggregare** modelli comuni
+ Precalcola le aggregazioni comuni
+ Interroga i dati preaggregati anziché i dati grezzi
+ **Aggiungi l'impaginazione** per set di risultati di grandi dimensioni
+ Limita la dimensione iniziale della query
+ Carica dati aggiuntivi su richiesta
+ **Implementa la limitazione della frequenza delle query per utente/dashboard**
+ Impedisci ai singoli utenti di sovraccaricare il sistema
+ Imposta quote di utilizzo equo
+ **Utilizza dati sottocampionati per le query storiche**
+ Esegui una query su dati a bassa risoluzione per intervalli di tempo precedenti
+ Riserva le interrogazioni a piena risoluzione per i dati recenti
**Decisione sulla scalabilità:**
+ Se sostenuta CPUUtilization per più del 70%: scalabile fino a un'istanza più grande
+ Se sostenuta per MemoryUtilization > 70%: scala fino a un'istanza ottimizzata per la memoria
+ Se la frequenza di query supera la capacità dell'istanza: passa al livello successivo per tabella di dimensionamento