View a markdown version of this page

Monitoramento e otimização de configuração para Timestream para InfluxDB 2 - Amazon Timestream
Visão geral doCloudWatch Referência de métricasDiretrizes de dimensionamento e desempenho de instânciasOtimização de configuração por métricaPráticas recomendadas de monitoramentoGuia de solução de problemas

Para recursos semelhantes aos do Amazon Timestream para, considere o Amazon Timestream LiveAnalytics para InfluxDB. Ele oferece ingestão de dados simplificada e tempos de resposta de consulta de um dígito em milissegundos para análises em tempo real. Saiba mais aqui.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Monitoramento e otimização de configuração para Timestream para InfluxDB 2

Visão geral do

O monitoramento eficaz e a otimização da configuração são essenciais para manter o desempenho, a confiabilidade e a economia ideais em sua implantação do Timestream for InfluxDB. Este guia fornece orientação abrangente sobre CloudWatch métricas, limites de desempenho e estratégias de ajuste de configuração para ajudá-lo a gerenciar proativamente suas instâncias do InfluxDB.

CloudWatch Referência de métricas

CloudWatch A Amazon fornece métricas detalhadas para monitorar seu Timestream para instâncias do InfluxDB. Compreender essas métricas e seus limites é essencial para manter a integridade e o desempenho do sistema.

Métricas de utilização de recursos

CloudWatch Nome da métrica Dimensões Description Unidade Limites recomendados
CPUUtilization DbInstanceName Porcentagem de CPU sendo usada Percentual

  • Desenvolvimento/Crescimento: < 70%

  • Produção: < 80%

  • Alerta crítico: > 90% por mais de 5 minutos
MemoryUtilization DbInstanceName Porcentagem de memória sendo usada Percentual

  • Desenvolvimento/Crescimento: < 70%

  • Produção: < 80%

  • Alerta crítico: > 90%
HeapMemoryUsage DbInstanceName Quantidade de memória de pilha em uso Bytes

  • Monitore o crescimento constante ou picos

  • Alerta: Aproximando-se do tamanho máximo da pilha
ActiveMemoryAllocation DbInstanceName Alocação atual de memória ativa Bytes

  • Monitore picos inesperados

  • Compare com a memória total disponível
DiskUtilization DbInstanceName Porcentagem de espaço em disco sendo usado Percentual

  • Desenvolvimento/Crescimento: < 70%

  • Produção: < 75%

  • Alerta crítico: > 85%

Métricas de operações de E/S

CloudWatch Nome da métrica Dimensões Description Unidade Limites recomendados
ReadOpsPerSec DbInstanceName Número de operações de leitura por segundo Contagem/segundo

Mantenha ≥ 30% de espaço livre abaixo do IOPS provisionado

Exemplo: 12K IOPS → mantenha < 8.400 IOPS no total
WriteOpsPerSec DbInstanceName Número de operações de gravação por segundo Contagem/segundo

Mantenha ≥ 30% de espaço livre abaixo do IOPS provisionado

Exemplo: 12K IOPS → mantenha < 8.400 IOPS no total
Total IOps PerSec DbInstanceName Total de I/O operações por segundo (leitura+gravação) Contagem/segundo

Mantenha ≥ 30% de espaço livre abaixo do IOPS provisionado

Monitore os recursos da classe de instância

Métricas de produtividade

CloudWatch Nome da métrica Dimensões Description Unidade Limites recomendados
ReadThroughput DbInstanceName Taxa de transferência de leitura de dados Bytes/segundo Monitore os limites de taxa de transferência de armazenamento
WriteThroughput DbInstanceName Taxa de transferência de gravação de dados Bytes/segundo Monitore os limites de taxa de transferência de armazenamento

Métricas de desempenho da API

CloudWatch Nome da métrica Dimensões Description Unidade Limites recomendados
APIRequestTarifa DbInstanceName, Endpoint, Status Taxa de solicitações de API para endpoints específicos com códigos de status (2xx, 4xx, 5xx) Contagem/segundo

Taxas de erro:

  • 4xx erros: < 1% das solicitações

  • 5xx erros: < 0,1% das solicitações

  • Alerta: picos repentinos nas taxas de erro
QueryResponseVolume DbInstanceName, Endpoint, Status Volume de respostas de consulta por endpoint e código de status Bytes

  • Monitore respostas invulgarmente grandes

  • Alerta: respostas > 10 MB de forma consistente

Métricas de execução de consultas

CloudWatch Nome da métrica Dimensões Description Unidade Limites recomendados
QueryRequestsTotal DbInstanceName, Resultado Contagem total de solicitações de consulta por tipo de resultado (sucesso, runtime_error, compile_error, queue_error) Contagem

Taxa de sucesso: > 99%

Taxas de erro:

  • erro_tempo de execução: < 0,5%

  • erro de compilação: < 0,1%

  • erro de fila: < 0,1%

Métricas de organização de dados

CloudWatch Nome da métrica Dimensões Description Unidade Limites críticos
SeriesCardinality DbInstanceName, Balde Número de séries temporais exclusivas em um bucket Contagem

  • < 100K: Excelente desempenho

  • < 1M: Bom desempenho

  • 1M - 5M: impacto moderado, requer ajuste

  • 5M - 10M: impacto significativo, é necessária uma otimização cuidadosa

  • > 10M: CRÍTICO - Considere o InfluxDB 3.0
TotalBuckets DbInstanceName Número total de buckets na instância Contagem

  • Monitore o crescimento ao longo do tempo

  • Considere a consolidação se tiver mais de 100 buckets

Métricas de saúde do sistema

CloudWatch Nome da métrica Dimensões Description Unidade Limites recomendados
EngineUptime DbInstanceName Hora em que o mecanismo InfluxDB está funcionando Segundos

Monitore reinicializações inesperadas

Alerta: o tempo de atividade é reiniciado inesperadamente
WriteTimeouts DbInstanceName Número de operações de gravação que atingiram o tempo limite Contagem

Alerta: > 0,1% das operações de gravação

Crítico: tendência crescente

Métricas de gerenciamento de tarefas

CloudWatch Nome da métrica Dimensões Description Unidade Limites recomendados
ActiveTaskWorkers DbInstanceName Número de trabalhadores ativos Contagem

Monitore em relação ao limite configurado de trabalhadores de tarefas

Alerta: Consistentemente no máximo
TaskExecutionFailures DbInstanceName Número de execuções de tarefas com falha Contagem

Alerta: > 1% das execuções de tarefas

Crítico: aumento da taxa de falhas

Entendendo os principais relacionamentos métricos

Relação entre IOPS e taxa de transferência

A regra de 30% de espaço livre: sempre mantenha pelo menos 30% de espaço livre entre suas operações sustentadas por segundo e seu IOPS provisionado. Isso fornece um buffer para:

  • Operações de compactação (podem aumentar significativamente o IOPS)

  • Qualquer reinicialização do banco de dados para funcionar sem problemas

  • Intermitências de consultas durante o pico de uso

  • Grave picos decorrentes da ingestão em lote

  • Operações de manutenção de índices

Exemplo de cálculo:

  • IOPS provisionado: 12.000

  • Meta máxima de IOPS sustentada (total IOpsPerSec): 8.400 (70% de utilização)

  • Espaço livre reservado: 3.600 IOPS (30%)

Se o total exceder IOps PerSec consistentemente 8.400: → Atualize o nível de armazenamento ou otimize a carga de trabalho

Fórmula de monitoramento:

% de utilização de IOPS = (ReadOpsPerSec + WriteOpsPerSec) /IOPS provisionado × 100

  • Meta: manter a utilização de IOPS < 70%

  • Aviso: Utilização de IOPS > 70%

  • Crítico: utilização de IOPS > 90%

Compreendendo o impacto no desempenho da cardinalidade da série

A cardinalidade da série tem um efeito multiplicativo nos recursos do sistema:

Contagem de séries Impacto na memória Impacto no desempenho da consulta Impacto do tamanho do índice Recomendação
< 100K Mínimo Insignificante Small Configuração padrão
100K - 1M Moderada 10-20% mais lento Médio Ajuste as configurações de cache
1M - 5M Significativo 30-50% mais lento Grande É necessária uma otimização agressiva
5M - 10M Alto 50-70% mais lento Muito grande Ajuste máximo, considere o redesenho
> 10M Grave 70% + mais lento Excesso Migre para o InfluxDB 3.0

Por que 10 milhões é o limite crítico:

  • A arquitetura InfluxDB 2.x usa indexação na memória

  • Além da série 10M, as operações de indexação se tornam proibitivamente caras

  • Os requisitos de memória crescem de forma não linear

  • A sobrecarga de planejamento de consultas aumenta drasticamente

  • O InfluxDB 3.0 usa um mecanismo de armazenamento colunar projetado para alta cardinalidade

Diretrizes de dimensionamento e desempenho de instâncias

A tabela a seguir fornece orientação sobre o dimensionamento adequado da instância com base na cardinalidade da série e nas características da carga de trabalho:

Contagem máxima de séries Escreve (linhas/seg) Leituras (consultas/seg) Instância recomendada Tipo de armazenamento Caso de uso
< 100K ~50.000 < 10 db.influx.large Influx IO incluído 3K Pequenas implantações, desenvolvimento e testes
< 1 M ~150.000 < 25 db.influx.2xlarge Influx IO incluído 3K Cargas de trabalho de produção de pequeno a médio porte
~ 1 M ~200.000 ~25 db.influx.4xlarge Influx IO incluído 3K Cargas de trabalho de produção médias
< 5 M ~250.000 ~35 db.influx.4xlarge Influx IO incluído 12K Grandes cargas de trabalho de produção
< 10 M ~500.000 ~50 db.influx.8xlarge Influx IO incluído 12K Cargas de trabalho de produção muito grandes
~ 10 M < 750.000 < 100 db.influx.12xlarge Influx IO incluído 12K Capacidade máxima do InfluxDB 2.x
> 10 M N/D N/D Migre para o InfluxDB 3.0 N/D Além do alcance ideal do InfluxDB 2.x

Otimização de configuração por métrica

Alta utilização da CPU (CPUUtilization > 70%)

Sintomas:

  • CPUUtilization> 70% sustentado

  • QueryRequestsTotal(consultas de alto volume ou lentas)

  • ActiveTaskWorkers(alta carga de tarefas)

Ajustes de configuração:

Prioridade 1: Controlar a simultaneidade de consultas

  • simultaneidade de consultas: definida como 50-75% da contagem de vCPUs

  • Exemplo: 8 instâncias de vCPU → simultaneidade de consultas = 4-6

Prioridade 2: limitar a complexidade da consulta

  • influxql-max-select-series: 10000 (evite consultas ilimitadas)

  • influxql-max-select-point: 100000000

  • query-queue-size: 2048 (evitar o acúmulo de filas)

Prioridade 3: Ativar análise de consultas

  • flux-log-enabled: TRUE (temporariamente para depuração)

  • nível de registro: informações (ou depuração para análise detalhada)

Considerações importantes:

A redução query-concurrency limitará o número de consultas que podem ser executadas simultaneamente, o que pode aumentar as consultas em fila e levar a uma maior latência durante os períodos de pico. Os usuários podem experimentar cargas de painel ou tempos limite de relatórios mais lentos se a demanda de consultas exceder o limite reduzido de simultaneidade.

Definir limites de proteção (influxql-max-select-series,influxql-max-select-point) fará com que as consultas que excedam esses limites falhem com compile_error ou runtime_error em. QueryRequestsTotal Embora isso proteja o sistema da exaustão de recursos, pode interromper as consultas existentes que funcionavam anteriormente.

Prática recomendada: antes de aplicar essas alterações, analise seus padrões de consulta usando QueryResponseVolumeQueryRequestsTotalmétricas. Identifique e otimize primeiro as consultas mais caras — procure consultas sem filtros de intervalo de tempo, consultas que abranjam séries de alta cardinalidade ou consultas que solicitem pontos de dados excessivos. É sempre preferível otimizar as consultas no nível do aplicativo do que impor limites rígidos que podem prejudicar a funcionalidade.

Ações de hardware:

  • Escale para a próxima classe de instância com mais v CPUs

  • Analise os padrões de consulta para oportunidades de otimização

Alta utilização de memória (MemoryUtilization > 70%)

Sintomas:

  • MemoryUtilization> 70% sustentado

  • HeapMemoryUsagetendendo para cima

  • ActiveMemoryAllocationmostrando picos

  • SeriesCardinality(a alta cardinalidade aumenta o uso da memória)

Ajustes de configuração:

Prioridade 1: Reduzir a memória cache

  • storage-cache-max-memory-tamanho: definido para 10-15% da RAM total

  • Exemplo: 32 GB de RAM → 3.355.443.200 a 5.033.164.800 bytes

  • storage-cache-snapshot-memory-tamanho: 26.214.400 (25 MB)

Prioridade 2: Limitar a memória de consulta

  • query-memory-bytes: Definido para 60-70% da RAM total

  • query-max-memory-bytes: O mesmo que query-memory-bytes

  • query-initial-memory-bytes: 10% de query-memory-bytes

Prioridade 3: otimizar o cache da série

  • storage-series-id-set-cache-size: Reduz se houver alta cardinalidade

  • Memória alta: 100-200

  • Normal: 500-1000

Considerações importantes:

Embora essas mudanças reduzam a pressão da memória, elas terão um impacto negativo direto no desempenho do aplicativo. Reduzir storage-cache-max-memory-size significa que menos dados são armazenados em cache na memória, forçando mais leituras de disco e aumentando a latência da consulta. Você provavelmente verá um ReadOpsPerSecaumento e os tempos de QueryResponseVolumeresposta diminuirão.

A limitação query-memory-bytes fará com que consultas com uso intensivo de memória falhem com runtime_error in QueryRequestsTotal, especialmente consultas que agregam grandes conjuntos de dados ou retornam conjuntos de resultados substanciais. Os usuários podem encontrar erros de “falta de memória” em consultas que foram bem-sucedidas anteriormente.

A redução reduz storage-series-id-set-cache-size o desempenho das consultas em dados de alta cardinalidade, pois o sistema precisa recalcular os resultados da série com mais frequência em vez de recuperá-los do cache. Isso afeta particularmente os painéis que consultam repetidamente as mesmas combinações de séries.

Prática recomendada: antes de aplicar essas alterações restritivas, analise seus padrões de consulta e otimize-os primeiro:

  • QueryResponseVolumeRevise para identificar consultas que retornam dados excessivos

  • Use QueryRequestsTotalpara encontrar consultas executadas com frequência que poderiam se beneficiar da otimização

  • Adicione filtros de intervalo de tempo para reduzir a digitalização de dados ao que é necessário para sua carga de trabalho

  • Implemente o armazenamento em cache dos resultados da consulta no nível do aplicativo

  • Considere a pré-agregação de dados usando tarefas de redução da resolução

  • Revise SeriesCardinalitye otimize seu modelo de dados para reduzir tags desnecessárias

A otimização de consultas deve sempre ser sua primeira abordagem. As restrições de configuração devem ser o último recurso quando a otimização não é suficiente.

Ações de hardware:

  • Aumente o tamanho da instância para obter mais RAM

Alta utilização do armazenamento (DiskUtilization > 70%)

CloudWatch Métricas a serem monitoradas:

  • DiskUtilization> 70%

  • WriteThroughputpadrões

  • TotalBuckets(muitos baldes aumentam a sobrecarga)

Ajustes de configuração:

Prioridade 1: Verificar a configuração do registro

  • nível de registro: certifique-se de definir como “informações” (não “depurar”)

  • flux-log-enabled: Defina como FALSE, a menos que esteja depurando ativamente

Prioridade 2: Retenção agressiva

  • storage-retention-check-interval: 15m0s (limpeza mais frequente)

Prioridade 3: otimizar a compactação

  • storage-compact-full-write-duração do frio: 20h0m0s (mais frequente)

  • storage-cache-snapshot-write-duração do frio: 50m0s

Prioridade 4: Reduzir o tamanho do índice

  • storage-max-index-log-tamanho do arquivo: 524.288 (512 KB para compactação mais rápida)

Considerações importantes:

Primeira etapa crítica - Verifique sua configuração de registro: antes de fazer qualquer outra alteração, verifique suas configurações de registro. O registro de depuração e os registros de consulta do Flux podem consumir tanto ou mais espaço em disco do que os dados reais da série temporal, e essa é uma das causas mais comuns de esgotamento inesperado do armazenamento.

Impacto do registro:

  • log-level: debuggera registros extremamente detalhados, potencialmente centenas de MB por hora

  • flux-log-enabled: TRUEregistra cada execução de consulta do Flux com detalhes completos, criando arquivos de log enormes

  • Esses registros se acumulam rapidamente e geralmente são ignorados durante o planejamento da capacidade.

  • Os arquivos de log podem preencher o espaço em disco mais rapidamente do que a ingestão de dados, especialmente em instâncias menores

  • Ao contrário dos dados de séries temporais, os registros são mantidos no armazenamento local por 24 horas antes da exclusão

Ações imediatas se os registros forem grandes:

  1. Definir log-level: info (a partir da depuração)

  2. Definir flux-log-enabled: FALSE

  3. Monitore DiskUtilizationpara melhoria imediata

Compensações da configuração de compactação:

Essas alterações de configuração foram projetadas especificamente para cargas de trabalho com alta taxa de transferência de ingestão e janelas curtas de retenção, nas quais o uso do disco flutua substancialmente. Eles forçam o motor de compactação a trabalhar de forma mais agressiva, o que só é benéfico em cenários específicos.

Compensações críticas: o aumento da frequência de compactação aumentará significativamente o consumo de recursos:

  • CPUUtilizationaumentarão à medida que as operações de compactação consomem ciclos de CPU

  • MemoryUtilizationaumentará durante a compactação à medida que os dados forem carregados e processados

  • WriteOpsPerSece WriteThroughputaumentará durante as janelas de compactação, potencialmente excedendo seu espaço livre de 30% de IOPS

  • WriteTimeoutspode aumentar se a I/O compactação competir com as gravações do aplicativo

Essas mudanças podem criar um problema de desempenho em cascata em que a compactação agressiva consome os recursos necessários para operações de consulta e gravação, degradando o desempenho geral do sistema e, ao mesmo tempo, reduzindo o uso do disco.

Prática recomendada: antes de ajustar as configurações de compactação, concentre-se no gerenciamento de dados e registros:

  1. Verifique primeiro o registro (problema mais comum): verifique se o nível do registro é “informação” e flux-log-enabled é FALSO

  2. Revise seu modelo de dados: você está escrevendo dados dos quais realmente não precisa? Você pode reduzir a granularidade da medição ou do campo?

  3. Otimize as políticas de retenção: verifique TotalBucketse revise as configurações de retenção para cada bucket

  4. Monitore o impacto da compactação: defina suas CPUUtilizationalterações MemoryUtilization, e WriteOpsPerSecantes

Abordagens alternativas:

  • Aumentar a capacidade de armazenamento (geralmente mais simples e econômica)

  • Implemente estratégias de redução da resolução ou agregação de dados

  • Consolide os buckets (reduza TotalBuckets) para diminuir a sobrecarga

  • Revise e aplique as políticas de retenção com mais rigor

Aplique configurações agressivas de compactação somente se você tiver otimizado o gerenciamento de dados e confirmado que sua instância tem CPU, memória e espaço livre de IOPS suficientes para lidar com o aumento da carga.

Ações de hardware:

  • Aumentar a capacidade de armazenamento

Alta utilização de IOPS (ReadIOPS/WriteIOPS/TotalOperationsPerSecond> 70% do provisionado)

CloudWatch Métricas a serem monitoradas:

  • ReadOpsPerSec+ WriteOpsPerSec= Total IOps PerSec

  • ReadThroughput e WriteThroughput

  • Compare com IOPS provisionadas (3K, 12K ou 16K)

Ajustes de configuração:

Prioridade 1: Controle de E/S de compactação

  • storage-max-concurrent-compactions: 2-3 (limite de compactações simultâneas)

  • storage-compact-throughput-burst: ajuste com base na capacidade do disco

  • 3K IOPS: 25.165.824 (24 MB/s)

  • IOPS de 12 K: 50.331.648 (48 MB/s)

Prioridade 2: otimizar as operações de gravação

  • storage-wal-max-concurrent-escreve: 8-12

  • storage-wal-max-write-atraso: 50m0s

Prioridade 3: ajustar o tempo de captura

  • storage-cache-snapshot-write-duração do frio: 15m0s (menos frequente)

  • storage-compact-full-write-duração do frio: 60h00ms (menos frequente)

Considerações importantes:

Essas mudanças criam compensações significativas entre a I/O utilização e o desempenho do sistema:

Limitando a E/S de compactação:

  • A redução storage-max-concurrent-compactions diminuirá a velocidade das operações de compactação, fazendo com que os arquivos TSM se acumulem e aumentem DiskUtilizationmais rapidamente

  • Lower storage-compact-throughput-burst estende a duração da compactação, mantendo o compactador ativo por mais tempo e potencialmente bloqueando outras operações

  • A compactação mais lenta significa que o desempenho das consultas diminui com o tempo, pois o mecanismo de armazenamento precisa ler mais arquivos TSM menores em vez de arquivos consolidados

  • Você pode ver as taxas de QueryRequestsTotalruntime_error aumentarem à medida que as consultas atingem o tempo limite enquanto aguarda a E/S

Reduzindo a frequência de capturas instantâneas:

  • Aumento storage-cache-snapshot-write-cold-duration e storage-compact-full-write-cold-duration significa que os dados permanecem no registro de gravação antecipada (WAL) por mais tempo

  • Isso aumenta MemoryUtilizationà medida que mais dados são mantidos no cache antes de serem transferidos para o disco.

  • O risco de perda de dados aumenta ligeiramente se a instância falhar antes da persistência dos dados em cache

  • O tempo de recuperação após uma reinicialização aumenta à medida que mais dados do WAL devem ser reproduzidos

Ajuste da operação de gravação:

  • A redução storage-wal-max-concurrent-writes serializará mais as operações de gravação, aumentando potencialmente WriteTimeoutsdurante períodos de alta taxa de transferência

  • Aumentar storage-wal-max-write-delay significa que as gravações podem esperar mais tempo antes de serem rejeitadas, o que pode mascarar problemas de capacidade, mas frustrar os usuários com respostas lentas

Prática recomendada: a alta utilização de IOPS geralmente indica que você superou seu nível de armazenamento e não um problema de configuração. Antes de restringir I/O, analyze I/O os padrões e otimizar antes de restringir.

Ações de hardware:

  • Atualize para um nível de armazenamento IOPS mais alto (3K → 12K)

  • Garanta que 30% do espaço livre de IOPS seja mantido

Cardinalidade de alta série (SeriesCardinality > 1M)

CloudWatch Métricas a serem monitoradas:

  • SeriesCardinalitypor balde e total

  • MemoryUtilization(aumenta com a cardinalidade)

  • CPUUtilization(despesas gerais de planejamento de consultas)

  • QueryRequestsTotal(a taxa de runtime_error pode aumentar)

Ajustes de configuração:

Prioridade 1: otimizar o manuseio em série

  • storage-series-id-set-tamanho do cache: 1000-2000 (aumentar o cache)

  • storage-series-file-max-concurrent-snapshot-compactions: 4-8

Prioridade 2: definir limites de proteção

  • influxql-max-select-series: 10000 (evite consultas descontroladas)

  • influxql-max-select-buckets: 1000

Prioridade 3: otimizar as operações de indexação

  • storage-max-index-log-tamanho do arquivo: 2.097.152 (2 MB)

Considerações importantes:

A alta cardinalidade de séries é fundamentalmente um problema de modelagem de dados, não um problema de configuração. As alterações na configuração só podem atenuar os sintomas — elas não podem resolver o problema subjacente.

Compensações de configuração:

storage-series-id-set-cache-sizeO aumento melhorará o desempenho das consultas armazenando em cache as pesquisas em série, mas à custa de um aumento. MemoryUtilization Cada entrada de cache consome memória e, com milhões de séries, isso pode ser substancial. Monitore HeapMemoryUsagee ActiveMemoryAllocationdepois de fazer essa alteração.

Definir limites de proteção (influxql-max-select-series,influxql-max-select-buckets) fará com que consultas legítimas falhem com compile_error in QueryRequestsTotalse excederem esses limites. Os painéis que funcionavam anteriormente podem falhar e os usuários precisarão modificar suas consultas. Isso é particularmente problemático para:

  • Painéis de monitoramento que se agregam em vários hosts/serviços

  • Consultas de análise que precisam comparar várias entidades

  • Consultas de alerta que avaliam as condições de toda a frota

O ajuste storage-max-index-log-file-size para valores menores aumenta a frequência de compactação do índice, que aumenta CPUUtilizatione à WriteOpsPerSecmedida que o sistema realiza uma manutenção mais frequente do índice.

Compreensão crítica:

Quando SeriesCardinalityexcede 5M, você está se aproximando dos limites arquitetônicos do InfluxDB 2.x. Na série 10M+, o desempenho diminui exponencialmente, independentemente da configuração:

  • O planejamento de consultas se torna proibitivamente caro (alto) CPUUtilization

  • Os requisitos de memória crescem de forma não linear (altos) MemoryUtilization

  • As operações de índice dominam I/O (ReadOpsPerSec, WriteOpsPerSec)

  • QueryRequestsTotalas taxas de runtime_error aumentam à medida que as consultas atingem o tempo limite ou esgotam a memória

Prática recomendada: as alterações na configuração são curativos temporários. Você deve abordar a causa raiz:

  1. Analise seu modelo de dados:

    • Análise SeriesCardinalitypor compartimento para identificar áreas problemáticas

    • Identifique quais tags têm altas contagens de valores exclusivos

    • Procure valores de tag ilimitados (UUIDs, carimbos de data/hora, usuário, sessão) IDs IDs

    • Encontre tags que deveriam ser campos em vez disso

Ações do modelo de dados:

  • Revise o design da tag para reduzir a cardinalidade desnecessária

  • Considere a consolidação de séries similares

  • Série If > 10M: Planeje a migração para o InfluxDB 3.0

Problemas de desempenho de consultas

CloudWatch Métricas a serem monitoradas:

  • QueryRequestsTotalpor tipo de resultado (sucesso, runtime_error, compile_error, queue_error)

  • APIRequestTarifa com status = 500 ou status = 499

  • QueryResponseVolume(respostas grandes indicam consultas caras)

Ajustes de configuração:

Prioridade 1: aumentar os recursos de consulta

  • simultaneidade de consultas: aumente para 75% de v CPUs

  • query-memory-bytes: Aloque 70% do total de RAM

  • query-queue-size: 4096

Prioridade 2: otimizar a execução da consulta

  • storage-series-id-set-cache-size: 1000 (aumento para melhor armazenamento em cache)

  • http-read-timeout: 60s (evite tempos limite prematuros)

Prioridade 3: Estabeleça limites razoáveis

  • influxql-max-select-point: 100000000

  • influxql-max-select-series: 10000

  • influxql-max-select-buckets: 1000

Considerações importantes:

O aumento dos recursos de consulta cria competição de recursos e potencial instabilidade do sistema:

Compensações de alocação de recursos:

query-concurrencyO aumento permite que mais consultas sejam executadas simultaneamente, mas cada consulta compete por CPU e memória:

  • CPUUtilizationaumentará, potencialmente atingindo a saturação durante os períodos de pico de consulta

  • MemoryUtilizationaumentará à medida que mais consultas alocarem memória simultaneamente

  • Se você aumentar a simultaneidade sem recursos adequados, todas as consultas ficam mais lentas em vez de apenas algumas filas

  • Risco de falha em cascata se consultas simultâneas esgotarem os recursos disponíveis

Alocar mais query-memory-bytes significa menos memória disponível para armazenamento em cache e outras operações:

  • HeapMemoryUsagevai aumentar

  • storage-cache-max-memory-sizepode precisar ser reduzido para compensar

  • Menos acessos ao cache significam um desempenho de consulta maior ReadOpsPerSece mais lento

  • O sistema se torna mais vulnerável à exaustão de memória se as consultas usarem sua alocação total

Aumentar query-queue-size apenas atrasa o problema — não resolve problemas de capacidade:

  • As consultas esperam mais tempo na fila, aumentando a latência end-to-end

  • Os usuários percebem o sistema como mais lento, mesmo que a taxa de transferência possa permanecer inalterada

  • Filas grandes podem mascarar problemas de capacidade subjacentes

  • QueryRequestsTotalA taxa de queue_error diminui, mas a experiência do usuário pode não melhorar

O aumento http-read-timeout evita o cancelamento prematuro da consulta, mas:

  • Consultas de longa duração consomem recursos por mais tempo, reduzindo a capacidade de outras consultas

  • Os usuários esperam mais tempo antes de receber erros de tempo limite

  • Pode ocultar consultas ineficientes que devem ser otimizadas

  • Pode levar à exaustão de recursos se muitas consultas lentas se acumularem

Prática recomendada: os problemas de desempenho das consultas geralmente são causados por consultas ineficientes, não por recursos insuficientes. Antes de aumentar a alocação de recursos:

  1. Analise os padrões de consulta:

    • Análise QueryResponseVolumepara identificar consultas que retornam dados excessivos (> 1 MB)

    • Verifique os padrões de QueryRequestsTotalruntime_error - o que está causando falhas?

    • Procure APIRequestTaxa com Status=499 (tempos limite do cliente) - as consultas são muito lentas

    • Identifique consultas caras executadas com frequência

  2. Otimize as consultas primeiro:

    Antipadrões de consulta comuns:

    • Filtros de intervalo de tempo ausentes → Adicionar limites de tempo explícitos

    • Consultando todas as séries → Adicionar filtros de tag específicos

    • Janelas de agregação excessiva → Use intervalos apropriados

    • Campos desnecessários em SELECT → Solicitar somente os dados necessários

    • Sem cláusulas LIMIT → Adicione limites razoáveis

  3. Soluções em nível de aplicativo:

    • Implemente o armazenamento em cache dos resultados da consulta (Redis, Memcached)

    • Use tarefas para pré-agregar padrões comuns

    • Adicione paginação para grandes conjuntos de resultados

    • Implemente a limitação da taxa de consulta por usuário/painel

    • Use dados com resolução reduzida para consultas históricas

  4. Verifique a disponibilidade dos recursos:

    • Verifique CPUUtilization: se já for > 70%, aumentar a simultaneidade piorará as coisas

    • Verifique MemoryUtilization- se já for > 70%, alocar mais memória de consulta causará OOM

    • Verifique se o Total IOps PerSec tem 30% de espaço livre antes de aumentar a carga de consultas

Abordagem recomendada:

  1. Comece otimizando as 10 consultas mais caras (por) QueryResponseVolume

  2. Implemente o armazenamento em cache dos resultados da consulta no nível do aplicativo

  3. Aumente a alocação de recursos somente se as consultas forem otimizadas e as métricas mostrarem espaço livre

  4. Escale para uma classe de instância maior se a carga de trabalho ultrapassar a capacidade atual

Ações de hardware:

  • Dimensione sua capacidade de computação, as consultas se beneficiam de maior poder de processamento (v) CPUs

RegEx Armadilhas de desempenho em consultas de fluxo

Ao filtrar dados no Flux, evite usar expressões regulares para correspondências exatas ou correspondência simples de padrões, pois isso acarreta penalidades significativas de desempenho. RegEx as operações no Flux são de um único encadeamento e ignoram totalmente o índice TSM subjacente. Em vez de aproveitar os índices de tags otimizados do InfluxDB para pesquisas rápidas, os RegEx filtros forçam o mecanismo de consulta a recuperar todas as séries correspondentes do armazenamento e realizar comparações de texto sequencialmente em relação a cada valor. Isso se torna particularmente problemático quando:

  • Filtragem com base nos valores exatos da tag - Use o operador de igualdade (==) ou a contains() função em vez de RegEx padrões como /^exact_value$/

  • Combinando vários valores específicos - Use o in operador com uma matriz de valores em vez de padrões de alternância, como /(value1|value2|value3)/

  • Correspondência simples de prefixo ou sufixo - Considere o uso strings.hasPrefix() de nossas strings.hasSuffix() funções, que são mais eficientes do que âncoras RegEx

Para cenários que exigem várias correspondências de padrões, reestruture sua consulta para usar vários predicados de filtro combinados com operadores lógicos ou pré-filtre usando igualdade de tag antes de aplicar operações de string mais complexas. Reserve RegEx exclusivamente para casos que exigem uma correspondência verdadeira de padrões que não podem ser expressos por meio de operadores de comparação mais simples.

Problemas de desempenho de gravação

CloudWatch Métricas a serem monitoradas:

  • WriteTimeouts(contagem crescente)

  • WriteOpsPerSec e WriteThroughput

  • APIRequestClassifique com Status=500 para endpoints de gravação

  • QueryRequestsTotalcom result=runtime_error durante as gravações

Ajustes de configuração:

Prioridade 1: otimizar gravações WAL

  • storage-wal-max-concurrent-escreve: 12-16

  • storage-wal-max-write-atraso: 10m0s

  • http-write-timeout: Anos 60

Prioridade 2: otimizar instantâneos de cache

  • storage-cache-snapshot-memory-tamanho: 52.428.800 (50 MB)

  • storage-cache-snapshot-write-duração do frio: 100m

Prioridade 3: Validação do campo de controle

  • storage-no-validate-field-size: VERDADEIRO (se a fonte de dados for confiável)

Considerações importantes:

O ajuste do desempenho de gravação envolve compensações cuidadosas entre taxa de transferência, confiabilidade e consumo de recursos:

Compensações de configuração do WAL:

storage-wal-max-concurrent-writesO aumento permite mais operações de gravação paralelas, mas:

  • CPUUtilizationaumenta à medida que mais threads de gravação competem pela CPU

  • MemoryUtilizationaumenta à medida que mais dados são armazenados em buffer na memória antes da descarga do WAL

  • WriteOpsPerSecaumentará, potencialmente excedendo seu espaço livre de 30% de IOPS

  • O aumento da contenção por disco I/O pode, na verdade, diminuir a velocidade de gravações individuais

  • Se você exceder a I/O capacidade do disco, WriteTimeoutspode aumentar em vez de diminuir

Aumentar storage-wal-max-write-delay significa que as gravações esperam mais tempo antes de expirar:

  • Mascara problemas de capacidade fazendo com que as gravações esperem em vez de falharem rapidamente

  • Os usuários experimentam tempos de resposta de gravação mais lentos, mesmo quando as gravações acabam sendo bem-sucedidas

  • Pode levar ao acúmulo de filas de gravação e à pressão da memória

  • Na verdade, não aumenta a capacidade - apenas atrasa o tempo limite

Aumentar de http-write-timeout forma semelhante atrasa os erros de tempo limite:

  • Permite que gravações em lotes maiores sejam concluídas

  • Mas também permite que gravações lentas consumam recursos por mais tempo

  • Pode ocultar problemas de desempenho subjacentes

  • Pode levar à exaustão de recursos se muitas gravações lentas se acumularem

Compensações do Cache Snapshot:

Aumentar storage-cache-snapshot-memory-size significa que mais dados se acumulam na memória antes da descarga:

  • MemoryUtilizationaumenta significativamente

  • O risco de perda de dados aumenta se a instância falhar antes do snapshot

  • Instantâneos maiores demoram mais para serem gravados, criando picos maiores WriteOpsPerSec

  • Pode melhorar a taxa de transferência de gravação agrupando mais dados em lotes, mas com custo de memória e confiabilidade

Aumento dos storage-cache-snapshot-write-cold-duration atrasos nas capturas instantâneas:

  • Aumenta ainda mais MemoryUtilizationà medida que os dados permanecem no cache por mais tempo

  • Aumenta a janela de risco de perda de dados

  • Reduz a WriteOpsPerSecfrequência, mas cria picos maiores quando ocorrem instantâneos

  • O tempo de recuperação após a reinicialização aumenta à medida que mais WAL deve ser repetido

Compensação da validação de campo:

A configuração storage-no-validate-field-size: TRUE desativa a validação do tamanho do campo:

  • Melhora a produtividade de gravação ignorando as verificações de validação

  • Risco crítico: permite que dados malformados ou maliciosos sejam gravados

  • Pode levar à corrupção de dados se as gravações contiverem tamanhos de campo inválidos

  • Torna muito mais difícil a depuração de problemas de dados

  • Use somente se você tiver total controle e confiança em sua fonte de dados

Prática recomendada: problemas de desempenho de gravação geralmente indicam limites de capacidade ou padrões de gravação ineficientes. Antes de ajustar a configuração:

  1. Analise os padrões de gravação:

    • Análise WriteThroughpute WriteOpsPerSectendências

    • Verifique a WriteTimeoutscorrelação com a carga de gravação

    • APIRequestTaxa de monitoramento para terminais de gravação por código de status

    • Identifique os tamanhos e a frequência dos lotes de gravação

  2. Otimize primeiro as operações de gravação:

    Antipadrões comuns de gravação:

    • Escrevendo pontos individuais → Gravações em lote (5.000 a 10.000 pontos)

    • Gravações muito frequentes → Buffer e lote

    • Gravações síncronas → Implementar filas de gravação assíncronas

    • Explosões de gravação ilimitadas → Implementar limitação de taxa

    • Escrevendo com precisão desnecessária → Arredonde os carimbos de data e hora de forma adequada

  3. Verifique a I/O capacidade:

    • Verifique o total IOps PerSec - se já for > 70%, aumentar a simultaneidade do WAL piorará as coisas

    • Revise WriteOpsPerSecdurante os períodos de pico

    • Garanta que exista 30% de espaço livre de IOPS antes de ajustar as configurações de gravação

    • Considere se 3K IOPS são suficientes ou se é necessário um nível de IOPS de 12K

  4. Melhorias no nível do aplicativo:

    • Implemente o buffer de gravação com tamanhos de lote configuráveis

    • Adicione lógica de repetição de gravação com recuo exponencial

    • Use operações de gravação assíncrona

    • Implemente a limitação da taxa de gravação durante os períodos de pico

    • Monitore a profundidade da fila de gravação e aplique contrapressão

Abordagem recomendada:

  1. Comece otimizando os tamanhos dos lotes de gravação no nível do aplicativo (almeje 5.000 a 10.000 pontos por lote)

  2. Implemente buffer de gravação e operações assíncronas

  3. Verifique se o Total IOps PerSec tem espaço livre adequado

  4. Atualize para o próximo nível de armazenamento (3K IOPS → 12K IOPS → 16K IOPS) se estiver consistentemente acima de 70% de utilização

  5. Ajuste as configurações de WAL somente se as gravações forem otimizadas e a I/O capacidade for adequada

  6. Nunca desative a validação de campo, a menos que você tenha controle total das fontes de dados

Ações de hardware:

  • Atualize para um armazenamento de IOPS mais alto (3K → 12K → 16K)

  • Garanta que I/O o espaço livre seja adequado

  • Dimensione para uma classe de instância maior se houver restrição de CPU ou memória

Práticas recomendadas de monitoramento

CloudWatch Configuração de alarmes

Alarmes críticos (ação imediata necessária):

CPUUtilization:

  • Limite: > 90% por 5 minutos

  • Ação: implementar medidas de remediação de tráfego ou escalabilidade computacional

MemoryUtilization:

  • Limite: > 90% por 5 minutos

  • Ação: implementar medidas de remediação de tráfego ou escalabilidade computacional

DiskUtilization:

  • Limite: > 85%

  • Ação: tente liberar espaço excluindo buckets antigos, atualizando as configurações de retenção ou o escalonamento de armazenamento

Total IOpsPerSec:

  • Limite: > 90% do provisionamento por 10 minutos

  • Ação: implementar medidas de remediação de tráfego ou aumentar o IOPS

SeriesCardinality:

  • Limite: > 10.000.000

  • Ação: revise seu modelo de dados, se nenhuma alteração for possível, explore a migração para o InfluxDB 3 ou fragmente seus dados

EngineUptime:

  • Limite: reinicialização inesperada (< 300 segundos)

  • Ação: Verifique se coincide com uma janela de manutenção; caso contrário, crie um ticket para o suporte do Timestream.

Alarmes de aviso (investigação necessária):

CPUUtilization:

  • Limite: > 70% por 15 minutos

  • Ação: analisar as mudanças na carga de trabalho ou no tráfego

MemoryUtilization:

  • Limite: > 70% por 15 minutos

  • Ação: analisar as mudanças na carga de trabalho ou no tráfego

DiskUtilization:

  • Limite: > 70%

  • Ação: revisar as políticas de retenção

Total IOpsPerSec:

  • Limite: > 70% do provisionamento por 15 minutos

  • Ação: analisar as mudanças na carga de trabalho ou no tráfego

QueryRequestsTotal (erro_tempo de execução):

  • Limite: > 1% do total de consultas

  • Ação: analisar as mudanças na carga de trabalho ou no tráfego

WriteTimeouts:

  • Limite: > 1% das operações de gravação

  • Ação: analisar as mudanças na carga de trabalho ou no tráfego

SeriesCardinality:

  • Limite: > 5.000.000

  • Ação: revisar a otimização do modelo de dados

Lista de verificação de monitoramento proativo

Diariamente:

  • APIRequestTaxa de revisão de picos de erro (400, 404, 499, 500)

  • Verifique as taxas QueryRequestsTotal de runtime_error e queue_error

  • Verifique se a WriteTimeouts contagem é mínima

  • Verifique se há algum alarme crítico

  • Verifique EngineUptime (sem reinicializações inesperadas)

Semanalmente:

  • Análise CPUUtilization MemoryUtilization e DiskUtilization tendências

  • Analise QueryRequestsTotal padrões por tipo de resultado

  • Verifique a taxa de SeriesCardinality crescimento por balde

  • Analise as tendências IOps PerSec de utilização total

  • Verifique se os parâmetros de configuração são ideais

  • Revise TaskExecutionFailures os padrões

Mensalmente:

  • Revisão do planejamento de capacidade (projeto com 3 a 6 meses de antecedência)

  • Compare as métricas atuais com a tabela de tamanhos

  • Revise e otimize as políticas de retenção

  • Analise os padrões de consulta de APIRequest Rate e QueryResponseVolume

  • Revisão SeriesCardinality e eficiência do modelo de dados

  • Avalie a necessidade de mudanças de escalabilidade ou configuração da instância

  • Oportunidades TotalBuckets de análise e consolidação

Guia de solução de problemas

Cenário: degradação repentina do desempenho

Etapas da investigação:

Confira as mudanças recentes:

  • Modificações dos parâmetros de configuração no AWS Management Console

  • Alterações na implantação de aplicativos

  • Alterações no padrão de consulta

  • Modificações do modelo de dados

  • Mudanças na infraestrutura (tipo de instância, armazenamento)

CloudWatch Métricas de revisão:

  • Pico de CPU? → Verifique CPUUtilization, QueryRequestsTotal

  • Pressão de memória? → Verifique MemoryUtilization HeapMemoryUsage, ActiveMemoryAllocation

  • Saturação de IOPS? → Verifique o total IOpsPerSec, ReadOpsPerSec, WriteOpsPerSec

  • Salto de cardinalidade da série? → Verifique o SeriesCardinality crescimento

  • Aumento da taxa de erro? → Verificar QueryRequestsTotal (runtime_error), APIRequest Taxa (Status=500)

  • Reinício inesperado? → Verificar EngineUptime

Ativar registro detalhado:

Alterações na configuração:

  • nível de registro: depuração

  • flux-log-enabled: VERDADEIRO

Monitore por 1 a 2 horas e, em seguida, revise os registros

Retornar ao nível do registro: informações após a investigação

Etapas de resolução:

  • Aplique as alterações de configuração apropriadas com base nas descobertas

  • Dimensione os recursos se os limites forem atingidos

  • Otimize consultas ou modelo de dados, se necessário

  • Implemente a limitação de taxa se a carga aumentar repentinamente

Cenário: Exaustão de memória

Sintomas:

  • MemoryUtilization > 90%

  • HeapMemoryUsage aproximando-se do máximo

  • QueryRequestsTotal mostrando runtime_error (sem memória)

  • APIRequestTaxa mostrando o status = 500

Etapas de resolução:

Ações imediatas (se críticas):

  1. Reinicie a instância para limpar a memória (se for seguro fazer isso)

  2. Reduza temporariamente a simultaneidade de consultas

  3. Elimine consultas de longa duração, se possível

Alterações na configuração:

Prioridade 1: Reduzir a memória cache

  • storage-cache-max-memory-tamanho: reduza para 10% da RAM

  • Exemplo: 32GB → 3.355.443.200 bytes

  • storage-cache-snapshot-memory-tamanho: 26.214.400 (25 MB)

Prioridade 2: Limitar a memória de consulta

  • query-memory-bytes: Definido para 60% da RAM total

  • query-max-memory-bytes: Partida query-memory-bytes

  • query-initial-memory-bytes: 10% de query-memory-bytes

Prioridade 3: definir limites de proteção

  • influxql-max-select-series: 10000

  • influxql-max-select-point: 100000000

  • simultaneidade de consultas: reduza para 50% de v CPUs

Soluções de longo prazo:

  • Otimize o modelo de dados para reduzir SeriesCardinality

  • Implemente limites de tamanho dos resultados da consulta no nível do aplicativo

  • Adicionar imposição de tempo limite de consulta

  • Analise as consultas mais comuns para garantir que elas estejam seguindo as melhores práticas mencionadas na seção Problemas de desempenho de consultas

Cenário: Impacto de cardinalidade de alta série

CloudWatch Métricas de análise:

  • SeriesCardinality> 5 M

  • MemoryUtilizationalto

  • QueryRequestsTotalmostrando um aumento no runtime_error

  • CPUUtilizationelevado devido à sobrecarga de planejamento de consultas

Etapas da investigação:

Analise o crescimento da cardinalidade:

  • SeriesCardinality taxa de crescimento (diária/semanal)

  • Projeção até o limite de 10M

  • Identifique fontes de alta cardinalidade

  • Revise o design e o uso da tag

Avalie o impacto no desempenho:

  • Compare QueryRequestsTotalo aumento da before/after cardinalidade da taxa de sucesso

  • Revise a MemoryUtilizationcorrelação

  • Verifique CPUUtilizationos padrões

  • Analise QueryResponseVolumetendências

Identifique as fontes de cardinalidade:

Revise o modelo de dados:

  • Quais baldes são os mais altos SeriesCardinality?

  • Quais tags têm altas contagens de valores exclusivos?

  • Existem etiquetas desnecessárias?

  • Os valores das tags são ilimitados (UUIDs, carimbos de data/hora etc.)?

Revise a configuração atual:

Verifique os parâmetros de otimização:

  • storage-series-id-set-cache-size: valor atual?

  • influxql-max-select-series: Isso está limitando as consultas descontroladas?

  • storage-max-index-log-file-size: apropriado para cardinalidade?

Etapas de resolução:

Alterações imediatas na configuração:

Prioridade 1: otimizar o manuseio em série

  • storage-series-id-set-tamanho do cache: 1500-2000

  • storage-series-file-max-concurrent-snapshot-compactions: 6-8

  • storage-max-index-log-tamanho do arquivo: 2.097.152 (2 MB)

Prioridade 2: definir limites de proteção

  • influxql-max-select-series: 10000

  • influxql-max-select-buckets: 1000

  • simultaneidade de consultas: reduza se houver restrição de memória

Prioridade 3: aumentar os recursos

  • Escale para o próximo nível de instância

  • Aumente a alocação de memória

  • Considere o nível de armazenamento de IOPS de 12K

Planejamento de migração (se > série 10M):

  • O InfluxDB 3.0 oferece desempenho superior de alta cardinalidade

  • Cronograma de migração do plano (2 a 3 meses)

  • Teste primeiro com um subconjunto de dados

  • Preparar o aplicativo para migração

  • O InfluxDB 3.0 usa armazenamento colunar otimizado para bilhões de séries

Cenário: acúmulo de filas de consultas

CloudWatch Métricas de análise:

  • QueryRequestsTotalcom result=queue_error aumentando (consultas sendo rejeitadas)

  • APIRequestTarifa com Status=429 ou Status=503 (atende a muitas solicitações) unavailable/too

  • CPUUtilizationpode estar elevado (> 70%) indicando saturação de recursos

  • MemoryUtilizationpode ser alto (> 70%), limitando a capacidade de consulta

  • QueryResponseVolumemostrando grandes tamanhos de resposta (consultas que consomem recursos excessivos)

Etapas da investigação:

Analise as métricas de fila e simultaneidade:

  • Análise QueryRequestsTotaldetalhada por tipo de resultado:

    • A alta contagem de queue_error indica que as consultas estão sendo rejeitadas

    • Compare a taxa de sucesso com a linha de base - ela está caindo?

    • Verifique se há aumentos de runtime_error (as consultas falham após o início)

  • Monitore os padrões de APIRequesttaxa:

    • Procure Status=429 (muitas solicitações) ou Status=503 (serviço indisponível)

    • Identifique quais endpoints estão sofrendo rejeições

    • Verifique as tendências das taxas de solicitação ao longo do tempo

Revise a utilização de recursos:

  • CPUUtilizationdurante períodos de alta fila:

    • Se > 70%, as consultas estão vinculadas à CPU e não podem ser executadas mais rapidamente

    • Se < 50%, os limites da fila podem ser muito restritivos

  • MemoryUtilizationcorrelação:

    • Memória alta pode estar limitando a simultaneidade de consultas

    • Verifique HeapMemoryUsagee verifique ActiveMemoryAllocationa pressão da memória

  • IOpsPerSecPadrões totais:

    • Alto I/O pode estar retardando a execução da consulta

    • Verifique se as consultas estão vinculadas I/O

Identifique padrões de consulta:

  • Resenha QueryResponseVolume:

    • As consultas estão retornando dados excessivos (> 1 MB)?

    • Identifique endpoints com maiores volumes de resposta

    • Procure padrões em consultas caras

  • Analise QueryRequestsTotala taxa:

    • Qual é a taxa de consultas por segundo?

    • Há padrões de ruptura ou alta carga sustentada?

    • Compare com a capacidade da instância na tabela de tamanhos

  • Verifique a APIRequesttaxa por endpoint:

    • Quais endpoints de consulta têm maior tráfego?

    • Há consultas duplicadas ou redundantes?

Verifique a disponibilidade do recurso:

  • Compare as métricas atuais com as recomendações da tabela de tamanhos:

    • SeriesCardinalityversus capacidade da classe de instância

    • Taxa de consulta versus consultas recomendadas por segundo

    • CPUUtilizatione altura MemoryUtilizationlivre

  • Verifique a capacidade de IOPS:

    • O total IOps PerSec deve ter 30% de altura livre

    • Verifique se as consultas estão aguardando a E/S do disco

Etapas de resolução:

Alterações na configuração:

Prioridade 1: aumentar a capacidade da fila

  • query-queue-size: 4096 (do padrão 1024)

Prioridade 2: Aumentar a simultaneidade (se os recursos permitirem)

  • simultaneidade de consultas: aumente para 75% de v CPUs

  • Exemplo: 16 vCPU → simultaneidade de consultas = 12

  • Verifique se CPUUtilization permanece < 80% após a alteração

  • Verifique se MemoryUtilization permanece < 80% após a alteração

Prioridade 3: otimizar a execução da consulta

  • query-memory-bytes: Garantir uma alocação adequada

  • storage-series-id-set-tamanho do cache: 1000-1500

  • http-read-timeout: 120s (evite tempos limite prematuros)

Prioridade 4: definir limites de proteção

  • influxql-max-select-series: 10000

  • influxql-max-select-point: 100000000

Soluções em nível de aplicativo:

  • Implemente o armazenamento em cache dos resultados da consulta (Redis, Memcached)

    • Resultados de cache para consultas executadas com frequência

    • Defina de forma adequada TTLs com base nos requisitos de atualização de dados

    • Monitorar taxas de acerto do cache

  • Use consultas contínuas para pré-agregar padrões comuns

    • Pré-calcule agregações comuns

    • Consulte dados pré-agregados em vez de dados brutos

  • Adicione paginação para grandes conjuntos de resultados

    • Limitar o tamanho inicial da consulta

    • Carregue dados adicionais sob demanda

  • Implemente a limitação da taxa de consulta por usuário/painel

    • Evite que usuários individuais sobrecarreguem o sistema

    • Defina cotas de uso justo

  • Use dados com resolução reduzida para consultas históricas

    • Consulte dados de baixa resolução para intervalos de tempo mais antigos

    • Reserve consultas de resolução total para dados recentes

Decisão de escalonamento:

  • Se CPUUtilization > 70% for sustentado: escale para uma instância maior

  • Se MemoryUtilization > 70% for sustentado: escale para uma instância otimizada para memória

  • Se a taxa de consulta exceder a capacidade da instância: escale para o próximo nível por tabela de dimensionamento