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 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 |
|
| MemoryUtilization | DbInstanceName | Percentuale di memoria utilizzata | Percentuale |
|
| HeapMemoryUsage | DbInstanceName | Quantità di memoria heap in uso | Byte |
|
| ActiveMemoryAllocation | DbInstanceName | Allocazione attuale della memoria attiva | Byte |
|
| DiskUtilization | DbInstanceName | Percentuale di spazio su disco utilizzato | Percentuale |
|
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:
|
| QueryResponseVolume | DbInstanceName, Endpoint, Stato | Volume di risposte alle interrogazioni per endpoint e codice di stato | Byte |
|
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% Percentuali di errore:
|
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 |
|
| TotalBuckets | DbInstanceName | Numero totale di bucket nell'istanza | Conteggio |
|
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 query 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à)
Modifiche alla 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 caricamento più lento della dashboard o dei timeout dei report se la richiesta di query supera il limite di concorrenza 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 QueryResponseVolumee 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
Utilizzo elevato della memoria (MemoryUtilization > 70%)
Caratteristiche:
MemoryUtilization> 70% sostenuto
HeapMemoryUsagetendenza al rialzo
ActiveMemoryAllocationmostrando 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 interrogazioni
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 ReadOpsPerSecaumento e un peggioramento dei tempi di QueryResponseVolumerisposta.
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 QueryRequestsTotalrisultati sostanziali. Gli utenti possono riscontrare errori di «memoria insufficiente» per le query eseguite in precedenza.
storage-series-id-set-cache-sizeLa 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 QueryResponseVolumeper identificare le query che restituiscono dati eccessivi
Utilizzalo QueryRequestsTotalper 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 SeriesCardinalitye 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%
WriteThroughputmodelli
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: debuggenera log estremamente dettagliati, potenzialmente centinaia di MB all'oraflux-log-enabled: TRUEregistra ogni esecuzione di query Flux con tutti i dettagli, creando enormi file di registroQuesti 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:
Set
log-level: info(da debug)Imposta
flux-log-enabled: FALSEMonitoraggio DiskUtilizationper 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:
CPUUtilizationaumenterà man mano che le operazioni di compattazione consumeranno i cicli della CPU
MemoryUtilizationaumenterà durante la compattazione man mano che i dati vengono caricati ed elaborati
WriteOpsPerSece WriteThroughputaumenterà durante le finestre di compattazione, superando potenzialmente il margine di crescita del 30% in IOPS
WriteTimeoutspuò 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:
Verifica prima la registrazione (problema più comune): verifica che il livello di registro sia «info» e sia FALSO flux-log-enabled
Rivedi il tuo modello di dati: stai scrivendo dati che in realtà non ti servono? È possibile ridurre la granularità delle misurazioni o del campo?
Ottimizza le politiche di conservazione: controlla TotalBucketse rivedi le impostazioni di conservazione per ogni bucket
Monitora l'impatto sulla compattazione: elabora le modifiche apportate CPUUtilizatione prima di MemoryUtilizationesse 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-compactionsLa riduzione rallenterà le operazioni di compattazione, provocando l'accumulo e l'aumento più rapido dei file TSM DiskUtilizationLower
storage-compact-throughput-burstestende la durata della compattazione, mantenendo il compattatore attivo più a lungo e potenzialmente bloccando altre operazioniUna 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 QueryRequestsTotalruntime_error aumentino man mano che le query scadono in attesa dell'I/O
Riduzione della frequenza delle istantanee:
Aumenta
storage-cache-snapshot-write-cold-durationestorage-compact-full-write-cold-durationsignifica che i dati rimangono più a lungo nel write-ahead log (WAL)Ciò aumenta man MemoryUtilizationmano 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-writesLa riduzione consentirà di serializzare maggiormente le operazioni di scrittura, con un potenziale aumento WriteTimeoutsdurante i periodi di elevata produttivitàL'aumento
storage-wal-max-write-delaysignifica 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:
SeriesCardinalityper 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 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 HeapMemoryUsagee ActiveMemoryAllocationdopo 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 QueryRequestsTotalse 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 WriteOpsPerSecman mano che il sistema esegue una manutenzione più CPUUtilizationfrequente dell'indice.
Comprensione critica:
Quando SeriesCardinalitysupera 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 ) ReadOpsPerSecWriteOpsPerSec
QueryRequestsTotalLe 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:
Analizza il tuo modello di dati:
Revisione SeriesCardinalityper 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 i 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:
QueryRequestsTotalper 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:
CPUUtilizationaumenterà, raggiungendo potenzialmente la saturazione durante i periodi di picco delle query
MemoryUtilizationaumenterà 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:
HeapMemoryUsageaumenterà
storage-cache-max-memory-sizepotrebbe dover essere ridotto per compensareUn minor numero di accessi alla cache significa prestazioni di query più elevate ReadOpsPerSece 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
QueryRequestsTotalIl 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:
Analizza i modelli di interrogazione:
Esamina QueryResponseVolumeper identificare le query che restituiscono dati eccessivi (> 1 MB)
Controlla i pattern QueryRequestsTotalruntime_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
Ottimizza innanzitutto le query:
Anti-pattern comuni per le interrogazioni:
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
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 dati sottocampionati per le query storiche
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:
Inizia ottimizzando le 10 query più costose (per) QueryResponseVolume
Implementa la memorizzazione nella cache dei risultati delle query a livello di applicazione
Aumentate l'allocazione delle risorse solo se le query sono ottimizzate e le metriche mostrano margini di manovra
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 lacontains()funzione anziché RegEx modelli come/^exact_value$/Corrispondenza a più valori specifici: utilizza l'
inoperatore 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 nostrestrings.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
QueryRequestsTotalcon 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:
CPUUtilizationaumenta man mano che più thread di scrittura competono per la CPU
MemoryUtilizationaumenta man mano che più dati vengono bufferizzati nella memoria prima del lavaggio del WAL
WriteOpsPerSecaumenterà, 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, WriteTimeoutspuò 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:
MemoryUtilizationaumenta 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 MemoryUtilizationmano che i dati rimangono nella cache più a lungo
Aumenta la finestra di rischio di perdita dei dati
Riduce la WriteOpsPerSecfrequenza 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:
Analizza i modelli di scrittura:
Revisione WriteThroughpute WriteOpsPerSectendenze
Verifica la WriteTimeoutscorrelazione 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
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
Verifica la capacità: I/O
Controlla Total IOps PerSec: se già supera il 70%, l'aumento della concorrenza WAL peggiorerà le cose
Rivedi WriteOpsPerSecdurante 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
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:
Inizia ottimizzando le dimensioni dei batch di scrittura a livello di applicazione (obiettivo a 5.000-10.000 punti per batch)
Implementa operazioni asincrone e di buffering di scrittura
Verifica che IOpsPerSecTotal disponga di un margine di crescita adeguato
Passa al livello di storage successivo (3.000 IOPS → 12.000 IOPS → 16.000 IOPS) se l'utilizzo è costantemente superiore al 70%
Ottimizza le impostazioni WAL solo se le scritture sono ottimizzate e la capacità è adeguata I/O
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):
Riavvia l'istanza per cancellare la memoria (se è sicuro farlo)
Riduci temporaneamente la concorrenza tra le query
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 interrogazioni
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
Scenario: High Series Cardinality Impact
CloudWatch Metriche di revisione:
SeriesCardinality> 5 M
MemoryUtilizationalto
QueryRequestsTotalmostrando un runtime_error aumentato
CPUUtilizationelevato 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 QueryRequestsTotalil tasso di successo, l'aumento before/after della cardinalità
Rivedi la correlazione MemoryUtilization
Controlla i modelli CPUUtilization
Analizza QueryResponseVolumele 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
QueryRequestsTotalcon result=queue_error in aumento (le query vengono rifiutate)
APIRequestValuta con Status=429 o Status=503 (servizio per molte richieste) unavailable/too
CPUUtilizationpuò essere elevato (> 70%) a indicare la saturazione delle risorse
MemoryUtilizationpuò essere elevato (> 70%) e limita la capacità di interrogazione
QueryResponseVolumemostrare dimensioni di risposta elevate (le query richiedono risorse eccessive)
Fasi dell'indagine:
Analizza le metriche relative alla coda e alla concorrenza:
QueryRequestsTotalRipartizione 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:
CPUUtilizationdurante 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
MemoryUtilizationcorrelazione:
L'elevata quantità di memoria può limitare la concorrenza delle query
Verifica HeapMemoryUsagee verifica la pressione della ActiveMemoryAllocationmemoria
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 QueryRequestsTotalvelocità:
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
Verifica la APIRequestfrequenza 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:
SeriesCardinalityrispetto alla capacità della classe di istanza
Frequenza di query rispetto alle query consigliate al secondo
CPUUtilizatione 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: impostare 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
