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](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html).
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á.
# Gerenciar instâncias de banco de dados
Esta seção aborda vários aspectos do gerenciamento da instância Amazon Timestream para InfluxDB para garantir desempenho, disponibilidade e recursos de monitoramento ideais. Ela fornece orientação sobre como atualizar as configurações de suas instâncias de banco de dados, lidar com implantações Multi-AZ e processos de failover. Também explica como excluir instâncias de banco de dados e configurar a visualização de registros para suas instâncias do InfluxDB.
**Topics**
+ [Atualizar instâncias de banco de dados](timestream-for-influx-managing-modifying-db.md)
+ [Manutenção de uma instância de banco de dados](timestream-for-influx-managing-maintaining-db.md)
+ [Excluir uma instância de banco de dados](timestream-for-influx-managing-deleting-db.md)
+ [Reinicializar uma instância de banco de dados](timestream-for-influx-managing-rebooting-db.md)
+ [Implantações de instâncias de banco de dados Multi-AZ](timestream-for-influx-managing-multi-az-instance-deployments.md)
+ [Configuração para visualizar logs do InfluxDB em instâncias do Timestream Influxdb](timestream-for-influx-managing-view-influx-logs.md)
+ [Monitoramento e otimização de configuração para Timestream para InfluxDB 2](timestream-for-influx-monitoring-configuration-optimization.md)
# Atualizar instâncias de banco de dados
É possível atualizar os seguintes parâmetros de configuração da instância do Timestream para InfluxDB:
+ Classe de instância
+ Tipo de armazenamento
+ Armazenamento alocado (somente aumentar)
+ Tipo de implantação
+ Grupo de parâmetros
+ Configuração de entrega de logs
**Importante**
Recomendamos que você teste todas as alterações em uma instância de teste antes de modificar a instância de produção para entender seu impacto, especialmente ao atualizar as versões do banco de dados. Analise o impacto sobre o banco de dados e as aplicativos antes de atualizar as configurações. Algumas modificações exigem a reinicialização da instância de banco de dados, resultando em tempo de inatividade.
**Usando o Console de gerenciamento da AWS**
1. Faça login Console de gerenciamento da AWS e abra o console [Amazon Timestream](https://console.aws.amazon.com/timestream/) for InfluxDB.
1. No painel de navegação, escolha **Bancos de dados InfluxDB** e a instância de banco de dados que você deseja modificar.
1. Escolha **Modificar**.
1. Na página **Modificar instância de banco de dados**, faça as alterações desejadas.
1. Escolha **Continuar** e verifique o resumo de modificações.
1. Escolha **Próximo**.
1. Revise suas alterações.
1. Selecione **Modificar instância** para aplicar suas alterações.
**nota**
Essas modificações exigem uma reinicialização da instância de banco de dados Influx e podem causar uma interrupção em alguns casos.
**Usando o AWS Command Line Interface**
Para atualizar uma instância de banco de dados usando o AWS Command Line Interface, chame o `update-db-instance` comando. Especifique o identificador da instância de banco de dados e os valores para as configurações que deseja modificar. Para obter mais informações sobre cada opção, consulte [Configurações para instâncias de banco de dados](timestream-for-influx-configuring.md#timestream-for-influx-configuring-create-db-settings).
**Example Exemplo**
O código a seguir é *my-db-instance* modificado definindo um diferente`db-parameter-group-name`. Substitua cada *user input placeholder* por suas próprias informações. As alterações são aplicadas imediatamente.
Para Linux, macOS ou Unix:
```
aws timestream-influxdb update-db-instance \
--identifier my-db-instance \
--db-storage-type desired-storage-type \
--allocated-storage desired-allocated-storage \
--db-instance-type desired-instance-type \
--deployment-type desired-deployment-type \
--db-parameter-group-name new-param-group \
--port 8086
```
Para Windows:
```
aws timestream-influxdb update-db-instance ^
--identifier my-db-instance ^
--db-storage-type desired-storage-type ^
--allocated-storage desired-allocated-storage ^
--db-instance-type desired-instance-type ^
--deployment-type desired-deployment-type ^
--db-parameter-group-name new-param-group
--port 8086
```
# Manutenção de uma instância de banco de dados
Periodicamente, o Amazon Timestream para InfluxDB realiza manutenção nos recursos do Amazon Timestream para InfluxDB. A manutenção geralmente envolve atualizações dos seguintes atributos na instância de banco de dados:
+ Hardware subjacente
+ Sistema operacional subjacente
+ Versão do mecanismo de banco de dados
As atualizações no sistema operacional geralmente ocorrem para problemas de segurança.
Alguns itens de manutenção exigem que o Amazon Timestream para InfluxDB coloque a instância offline por um curto período. Entre os itens de manutenção que exigem um recurso esteja offline estão sistema operacional obrigatório ou patches de banco de dados. A aplicação obrigatória de patches é automaticamente programada somente para patches relacionados à segurança e à confiabilidade da instância. Essa correção ocorre com pouca frequência, normalmente uma vez a cada poucos meses. Raramente requer mais do que uma fração de sua janela de manutenção.
+ As janelas de manutenção são configuradas para ocorrer todos os dias, entre 12h e 4h, horário local, para a região em que sua instância está hospedada.
+ Os recursos do cliente podem ser corrigidos uma vez por semana em qualquer uma das sete janelas de manutenção da semana.
# Excluir uma instância de banco de dados
A exclusão de uma instância de banco de dados afeta a capacidade de recuperação da instância e a disponibilidade de instantâneos. Considere os seguintes problemas:
+ Se você quiser excluir todos os recursos do Timestream para InfluxDB, observe que os recursos da instância de banco de dados geram cobranças.
+ Quando o status de uma instância de banco de dados for excluída, seu valor de certificado CA não será exibido no console do Timestream para InfluxDB nem na saída de comandos AWS Command Line Interface ou de operações de API do Timestream.
+ O tempo necessário para excluir uma instância de banco de dados varia dependendo da quantidade de dados excluídos e se um instantâneo final será criado.
Você pode excluir uma instância de banco de dados usando a API Console de gerenciamento da AWS AWS Command Line Interface, the ou Timestream. Você deve fornecer o nome da instância de banco de dados:
**Usando o Console de gerenciamento da AWS**
1. Faça login Console de gerenciamento da AWS e abra o console [Amazon Timestream](https://console.aws.amazon.com/timestream/) for InfluxDB.
1. No painel de navegação, escolha **Bancos de dados do InfluxDB** e a instância de banco de dados que você deseja excluir.
1. Escolha **Excluir**.
1. Digite *confirm* na caixa.
1. Escolha **Excluir**.
**Usando o AWS Command Line Interface**
Para encontrar a instância IDs das instâncias de banco de dados em sua conta, chame o `list-db-instances` comando:
```
aws timestream-influxdb list-db-instances \
--endpoint-url YOUR_ENDPOINT \
--region YOUR_REGION
```
Para excluir uma instância de banco de dados usando a AWS CLI, chame o `delete-db-instance` comando com as seguintes opções:
```
aws timestream-influxdb list-db-instances \
--identifier YOUR_DB_INSTANCE \
```
**Example Exemplo**
Para Linux, macOS ou Unix:
```
aws timestream-influxdb delete-db-instance \
--identifier mydbinstance
```
Para Windows:
```
aws timestream-influxdb delete-db-instance ^
--identifier mydbinstance
```
# Reinicializar uma instância de banco de dados
Você pode reinicializar uma instância de banco de dados usando a API Console de gerenciamento da AWS AWS Command Line Interface, the ou Timestream. Você deve fornecer o ID da instância de banco de dados:
**Usando o Console de gerenciamento da AWS**
1. Faça login Console de gerenciamento da AWS e abra o console [Amazon Timestream](https://console.aws.amazon.com/timestream/) for InfluxDB.
1. No painel de navegação, escolha **Bancos de dados InfluxDB** e, em seguida, escolha a instância de banco de dados que você deseja reinicializar.
1. Escolha **Reiniciar banco de dados**.
1. Escolha **Confirmar e reiniciar**.
**Usando o AWS Command Line Interface**
Para reinicializar uma instância de banco de dados usando a AWS CLI, chame `reboot-db-instance` o comando com as seguintes opções:
**Example Comandos**
Para Linux, macOS ou Unix:
```
aws timestream-influxdb reboot-db-instance \
--region YOUR_REGION \
--identifier YOUR_INSTANCE_ID
```
Para Windows:
```
aws timestream-influxdb reboot-db-instance ^
--region YOUR_REGION ^
--identifier YOUR_INSTANCE_ID
```
# Implantações de instâncias de banco de dados Multi-AZ
O Amazon Timestream para InfluxDB oferece alta disponibilidade e suporte para failover em instâncias de banco de dados utilizando implantações multi-AZ com uma única instâncias de banco de dados em espera. Esse tipo de implantação é chamado de implantação de instância de banco de dados multi-AZ. O Amazon Timestream para InfluxDB usa a tecnologia de failover da Amazon.
Em uma implantação de instância de banco de dados multi-AZ, o Amazon Timestream provisiona e mantém automaticamente uma réplica em espera síncrona em outra zona de disponibilidade. A instância de banco de dados primária é sincronicamente replicada nas zonas de disponibilidade para uma réplica em espera a fim de oferecer redundância de dados. Executar uma instância de banco de dados com alta disponibilidade pode aumentar a disponibilidade durante falhas na instância do banco de dados e interrupção na zona de disponibilidade. Para obter mais informações sobre, consulte[Regiões da AWS e zonas de disponibilidade](timestream-for-influxdb.md#timestream-for-influx-dbi-regions).
**nota**
A opção de alta disponibilidade não é uma solução de escalabilidade para cenários somente leitura. Não é possível utilizar uma réplica em espera para servir tráfego de leitura.
Com o console do Amazon Timestream, é possível criar uma implantação de instância de banco de dados multi-AZ. Basta especificar a opção **Criar instância em espera** na seção **Configuração de disponibilidade e durabilidade** ao criar essa instância de banco de dados. Você também pode especificar a implantação de uma instância de banco de dados Multi-AZ com a AWS Command Line Interface API Amazon Timestream. Use `create-db-instance` ou o comando da CLI, ou a operação da API `CreateDBInstance`.
Instâncias de banco de dados que usam implantações de instância de banco de dados multi-AZ podem ter maior latência de gravação e confirmação em comparação com uma implantação single-AZ. Isso pode acontecer devido à replicação de dados síncrona que ocorre. Você pode ter uma alteração na latência se sua implantação passar para a réplica em espera, embora tenha sido AWS projetada com conectividade de rede de baixa latência entre elas. Para workloads de produção, recomendamos usar IOPS Included Storage 12K ou 16K IOPS para obter um desempenho rápido e consistente. Para ter mais informações sobre classes de instância de banco de dados, consulte [Classes da instância de banco de dados](timestream-for-influxdb.md#timestream-for-influx-dbi-classes).
# Configurar e gerenciar uma implantação multi-AZ
O Timestream para InfluxDB pode ter apenas um modo de espera. Quando a implantação tem uma instância de banco de dados em espera, ela é chamada de implantação de instância de banco de dados Multi-AZ. Uma implantação de instância de banco de dados Multi-AZ tem uma instância de banco de dados em espera que fornece suporte para failover, mas não serve tráfego de leitura.
**Importante**
Sua instância deve ter pelo menos duas sub-redes associadas a ela para executar atualizações de AZ único a multi-AZ. Depois que a instância é criada, não é possível modificar o modo de implantação do AZ único a multi-AZ.
Você pode usar o Console de gerenciamento da AWS para determinar se sua instância de banco de dados é uma implantação Single-AZ ou Multi-AZ.
**Usando o Console de gerenciamento da AWS**
1. Faça login Console de gerenciamento da AWS e abra o console [Amazon Timestream](https://console.aws.amazon.com/timestream/) for InfluxDB.
1. No painel de navegação, escolha **Bancos de dados do InfluxDB** e **Identificador de banco de dados**.
Uma implantação de instância de banco de dados multi-AZ tem as seguintes características:
+ Há apenas uma linha para a instância de banco de dados.
+ O valor de Role (Função) é Instance (Instância) ou Primary (Principal).
+ O valor de multi-AZ é Yes (Sim).
# Processo de failover para Amazon Timestream
Se uma interrupção planejada ou não planejada da sua instância de banco de dados for resultante de um defeito de infraestrutura, o Amazon Timestream para InfluxDB alternará automaticamente para uma réplica em espera em outra zona de disponibilidade se você tiver ativado o multi-AZ. O tempo de conclusão do failover depende da atividade do banco de dados e de outras condições no momento em que a instância de banco de dados primária se tornou indisponível. Em geral, os tempos de failover variam de 60 a 120 segundos. No entanto, transações grandes ou um processo de recuperação longo podem aumentar o tempo de failover. Quando o failover é concluído, o console do Timestream pode levar mais um tempo para refletir a nova zona de disponibilidade.
**nota**
O Amazon Timestream processa os failovers automaticamente para que você possa retomar as operações de banco de dados o mais rápido possível e sem intervenção administrativa. A instância de banco de dados principal muda automaticamente para a réplica em espera se alguma das condições descritas na tabela a seguir ocorrer.
****
| Motivo do failover | Description |
| --- | --- |
| O sistema operacional subjacente à instância de banco de dados do Timestream está sendo corrigido em uma operação offline. | Um failover foi acionado durante a janela de manutenção para um patch de SO ou uma atualização de segurança. |
| O host principal da instância Timestream multi-AZ não está íntegro. | A implantação de instância de banco de dados multi-AZ detectou uma instância de banco de dados primária danificada e executou failover. |
| O host principal da instância Timestream multi-AZ está inacessível devido à perda de conectividade de rede. | O monitoramento do Timestream detectou uma falha de alcançabilidade de rede na instância de banco de dados principal e acionou um failover. |
| A instância do Timestream foi modificada pelo cliente. | Uma modificação da instância de banco de dados do Timestream para InfluxDB acionou um failover. Para obter mais informações, consulte [Atualizar instâncias de banco de dados](timestream-for-influx-managing-modifying-db.md). |
| A instância primária do Timestream multi-AZ está ocupada e não responde. | A instância de banco de dados principal não responde. Recomendamos que você faça o seguinte: examine o evento quanto ao uso excessivo de CPU, memória ou espaço de troca. \$1 Avalie seu workload para determinar se você está usando a classe de instância de banco de dados apropriada. Para obter mais informações, consulte Classes de instância de banco de dados. |
| O volume de armazenamento subjacente ao host principal da instância multi-AZ do Timestream sofreu uma falha. | A implantação de instância de banco de dados multi-AZ detectou um problema de armazenamento na instância de banco de dados primária e executou o failover. |
# Definir o JVM TTL para pesquisas de nome DNS
O mecanismo de failover modifica automaticamente o registro de Domain Name System (DNS) da instância de banco de dados para apontar para a instância de banco de dados em espera. Como resultado, você precisará restabelecer todas as conexões existentes para sua instância de banco de dados. Em um ambiente de máquina virtual Java (JVM), devido à forma como o mecanismo de cache DNS do Java funciona, talvez seja necessário reconfigurar as configurações da JVM.
A JVM armazena em cache pesquisas de nome DNS. Quando a JVM resolve um nome de host para um endereço IP, ela armazena o endereço IP em cache por um período de tempo especificado, conhecido como (TTL). *time-to-live*
Como AWS os recursos usam entradas de nome DNS que mudam ocasionalmente, recomendamos que você configure sua JVM com um valor TTL de no máximo 60 segundos. Isso garante que quando o endereço IP de um recurso mudar, seu aplicativo poderá receber e usar o novo endereço IP do recurso, consultando novamente o DNS.
Em algumas configurações do Java, o TTL padrão da JVM é definido de maneira que jamais atualiza entradas DNS até a JVM ser reiniciada. Portanto, se o endereço IP de um AWS recurso mudar enquanto seu aplicativo ainda estiver em execução, ele não poderá usar esse recurso até que você reinicie manualmente a JVM e as informações IP em cache sejam atualizadas. Nesse caso, é crucial definir o TTL da JVM, de forma que ele atualize periodicamente as informações de IP armazenadas em cache.
Você pode obter o TTL padrão da JVM recuperando o valor da propriedade `networkaddress.cache.ttl`:
```
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
```
**nota**
O TTL padrão pode variar de acordo com a versão da JVM e a possibilidade de um gerenciador de segurança estar instalado. Muitos JVMs fornecem um TTL padrão de menos de 60 segundos. Se estiver usando uma JVM como essa, e não um gerenciador de segurança, será possível ignorar o restante deste tópico.
Para modificar o TTL da JVM, defina o valor da propriedade networkaddress.cache.ttl. Use um dos seguintes métodos, dependendo das necessidades:
Para definir o valor da propriedade globalmente para todos os aplicativos que usam a JVM, defina `networkaddress.cache.ttl` no arquivo `$JAVA_HOME/jre/lib/security/java.security`.
```
networkaddress.cache.ttl=60
```
Para definir a propriedade localmente somente para seu aplicativo, defina `networkaddress.cache.ttl` no código de inicialização do aplicativo antes de quaisquer conexões de rede serem estabelecidas.
```
java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
```
# Configuração para visualizar logs do InfluxDB em instâncias do Timestream Influxdb
Por padrão, o InfluxDB gera logs que vão para stdout. Para obter mais informações, consulte [Gerenciar logs do InfluxDB](https://docs.influxdata.com/influxdb/v2/admin/logs).
Para visualizar os logs do InfluxDB gerados a partir da instância que você criou por meio do Timestream InfluxDB, oferecemos a oportunidade de fornecer logs por hora. Esses logs irão para um bucket S3 específico que você deve criar antes de criar sua instância.
+ Antes de criar a instância, o bucket Amazon S3 fornecido também deve dar permissão ao Timestream-InfluxDB para enviar registros para esse bucket fornecendo uma política de bucket com o Timestream InfluxDB Service Principal da seguinte forma (substitua pelo nome real do seu bucket do Amazon S3): *\$1BUCKET\$1NAME\$1*
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PolicyForInfluxLogs",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "timestream-influxdb.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::{BUCKET_NAME}/InfluxLogs/*"
}
]
}
```
------
+ O bucket fornecido deve estar na mesma conta e na mesma região da instância criada do Timestream InfluxDB
Aqui está o comando que você pode chamar para criar uma instância para receber logs de influxo:
```
aws timestream-influxdb create-db-instance \
--name myinfluxDbinstance \
--allocated-storage 400 \
--db-instance-type db.influx.4xlarge \
--vpc-subnet-ids subnetid1 subnetid2
--vpc-security-group-ids mysecuritygroup \
--username masterawsuser \
--password \
--db-storage-type InfluxIOIncludedT2
```
Aqui está o formato desse parâmetro.
```
-- log-delivery-configuration
{
"S3Configuration": {
"BucketName": "string",
"Enabled": true|false
}
}
```
+ Esse campo não é obrigatório e o registro em log não é habilitado por padrão.
+ Não definir esse campo é o mesmo que não ter os logs habilitados.
+ Os logs serão enviados para o bucket especificado com um prefixo `InfluxLogs/`.
+ Depois de criar a instância, você pode modificar a configuração de entrega de registros com o comando da `update-db-instance` API.
O InfluxDB oferece diferentes tipos de logs. Eles podem ser configurados definindo os parâmetros do InfluxDB. Use os parâmetros flux-log-enabled e em nível de log para configurar o tipo de registros emitidos pela instância. Para obter mais informações, consulte [Parâmetros e valores de parâmetros compatíveis](timestream-for-influx-db-connecting.md#timestream-for-influx-parameter-groups-overview-supported-parameters).
# 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 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| MemoryUtilization | DbInstanceName | Porcentagem de memória sendo usada | Percentual | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| HeapMemoryUsage | DbInstanceName | Quantidade de memória de pilha em uso | Bytes | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| ActiveMemoryAllocation | DbInstanceName | Alocação atual de memória ativa | Bytes | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| DiskUtilization | DbInstanceName | Porcentagem de espaço em disco sendo usado | Percentual | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 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 provisionadoExemplo: 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 provisionadoExemplo: 12K IOPS → mantenha < 8.400 IOPS no total |
| Total IOps PerSec | DbInstanceName | Total de I/O operações por segundo (leitura\$1gravação) | Contagem/segundo | Mantenha ≥ 30% de espaço livre abaixo do IOPS provisionadoMonitore 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: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| QueryResponseVolume | DbInstanceName, Endpoint, Status | Volume de respostas de consulta por endpoint e código de status | Bytes | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 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\$1error, compile\$1error, queue\$1error) | Contagem | Taxa de sucesso: > 99% Taxas de erro: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 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 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| TotalBuckets | DbInstanceName | Número total de buckets na instância | Contagem | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 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 inesperadasAlerta: 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çãoCrí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 tarefasAlerta: Consistentemente no máximo |
| TaskExecutionFailures | DbInstanceName | Número de execuções de tarefas com falha | Contagem | Alerta: > 1% das execuções de tarefasCrítico: aumento da taxa de falhas |
### Compreendendo 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 \$1 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% \$1 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 | \$150.000 | < 10 | db.influx.large | Influx IO incluído 3K | Pequenas implantações, desenvolvimento e testes |
| < 1 M | \$1150.000 | < 25 | db.influx.2xlarge | Influx IO incluído 3K | Cargas de trabalho de produção de pequeno a médio porte |
| \$1 1 M | \$1200.000 | \$125 | db.influx.4xlarge | Influx IO incluído 3K | Cargas de trabalho de produção médias |
| < 5 M | \$1250.000 | \$135 | db.influx.4xlarge | Influx IO incluído 12K | Grandes cargas de trabalho de produção |
| < 10 M | \$1500.000 | \$150 | db.influx.8xlarge | Influx IO incluído 12K | Cargas de trabalho de produção muito grandes |
| \$1 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\$1error ou runtime\$1error** 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 **QueryResponseVolume**QueryRequestsTotal****mé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
+ **HeapMemoryUsage**tendendo para cima
+ **ActiveMemoryAllocation**mostrando 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 **ReadOpsPerSec**aumento e os tempos de **QueryResponseVolume**resposta diminuirão.
A limitação `query-memory-bytes` fará com que consultas com uso intensivo de memória falhem com **runtime\$1error** 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:
+ **QueryResponseVolume**Revise para identificar consultas que retornam dados excessivos
+ Use **QueryRequestsTotal**para 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 **SeriesCardinality**e 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%
+ **WriteThroughput**padrõ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: debug`gera registros extremamente detalhados, potencialmente centenas de MB por hora
+ `flux-log-enabled: TRUE`registra cada execução de consulta do Flux com detalhes completos, criando arquivos de log massivos
+ 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)
1. Definir `flux-log-enabled: FALSE`
1. Monitore **DiskUtilization**para 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:
+ **CPUUtilization**aumentarão à medida que as operações de compactação consomem ciclos de CPU
+ **MemoryUtilization**aumentará durante a compactação à medida que os dados forem carregados e processados
+ **WriteOpsPerSec**e **WriteThroughput**aumentará durante as janelas de compactação, potencialmente excedendo seu espaço livre de 30% de IOPS
+ **WriteTimeouts**pode 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
1. **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?
1. **Otimize as políticas de retenção:** verifique **TotalBuckets**e revise as configurações de retenção para cada bucket
1. **Monitore o impacto da compactação:** defina suas **CPUUtilization**alterações **MemoryUtilization**, e **WriteOpsPerSec**antes
**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**\$1 **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 **DiskUtilization**mais 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 **QueryRequestsTotal**runtime\$1error 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 **WriteTimeouts**durante 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:**
+ **SeriesCardinality**por balde e total
+ **MemoryUtilization**(aumenta com a cardinalidade)
+ **CPUUtilization**(despesas gerais de planejamento de consultas)
+ **QueryRequestsTotal**(a taxa de runtime\$1error 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-size`O 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 **HeapMemoryUsage**e **ActiveMemoryAllocation**depois 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\$1error** in **QueryRequestsTotal**se 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 **CPUUtilization**e à **WriteOpsPerSec**medida que o sistema realiza uma manutenção mais frequente do índice.
**Compreensão crítica:**
Quando **SeriesCardinality**excede 5M, você está se aproximando dos limites arquitetônicos do InfluxDB 2.x. Na série 10M\$1, 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**)
+ **QueryRequestsTotal**as taxas de runtime\$1error 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 **SeriesCardinality**por 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:**
+ **QueryRequestsTotal**por tipo de resultado (sucesso, runtime\$1error, compile\$1error, queue\$1error)
+ **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-concurrency`O aumento permite que mais consultas sejam executadas simultaneamente, mas cada consulta compete por CPU e memória:
+ **CPUUtilization**aumentará, potencialmente atingindo a saturação durante os períodos de pico de consulta
+ **MemoryUtilization**aumentará à 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:
+ **HeapMemoryUsage**vai aumentar
+ `storage-cache-max-memory-size`pode precisar ser reduzido para compensar
+ Menos acessos ao cache significam um desempenho de consulta maior **ReadOpsPerSec**e 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
+ **QueryRequestsTotal**A taxa de queue\$1error 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 **QueryResponseVolume**para identificar consultas que retornam dados excessivos (> 1 MB)
+ Verifique os padrões de **QueryRequestsTotal**runtime\$1error - 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
1. **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
1. **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
1. **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**
1. Implemente o armazenamento em cache dos resultados da consulta no nível do aplicativo
1. Aumente a alocação de recursos somente se as consultas forem otimizadas e as métricas mostrarem espaço livre
1. 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
+ **QueryRequestsTotal**com result=runtime\$1error 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: 10m0s
**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-writes`O aumento permite mais operações de gravação paralelas, mas:
+ **CPUUtilization**aumenta à medida que mais threads de gravação competem pela CPU
+ **MemoryUtilization**aumenta à medida que mais dados são armazenados em buffer na memória antes da descarga do WAL
+ **WriteOpsPerSec**aumentará, 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, **WriteTimeouts**pode 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:
+ **MemoryUtilization**aumenta 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 **WriteOpsPerSec**frequê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 **WriteThroughput**e **WriteOpsPerSec**tendências
+ Verifique a **WriteTimeouts**correlaçã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
1. **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
1. **Verifique a I/O capacidade:**
+ Verifique o **total IOps PerSec** - se já for > 70%, aumentar a simultaneidade do WAL piorará as coisas
+ Revise **WriteOpsPerSec**durante 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
1. **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)
1. Implemente buffer de gravação e operações assíncronas
1. Verifique se o **Total IOps PerSec** tem espaço livre adequado
1. Atualize para o próximo nível de armazenamento (3K IOPS → 12K IOPS → 16K IOPS) se estiver consistentemente acima de 70% de utilização
1. Ajuste as configurações de WAL somente se as gravações forem otimizadas e a I/O capacidade for adequada
1. **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\$1tempo 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\$1error e queue\$1error
+ 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 IOps PerSec ReadOpsPerSec, WriteOpsPerSec
+ **Salto de cardinalidade da série?** → Verifique o SeriesCardinality crescimento
+ **Aumento da taxa de erro?** → Verificar QueryRequestsTotal (runtime\$1error), 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 as consultas ou o 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\$1error (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)
1. Reduza temporariamente a simultaneidade de consultas
1. 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](#query-performance-issues)
### Cenário: Impacto de cardinalidade de alta série
** CloudWatch Métricas de análise:**
+ **SeriesCardinality**> 5 M
+ **MemoryUtilization**alto
+ **QueryRequestsTotal**mostrando um aumento no runtime\$1error
+ **CPUUtilization**elevado 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 **QueryRequestsTotal**o aumento da before/after cardinalidade da taxa de sucesso
+ Revise a **MemoryUtilization**correlação
+ Verifique **CPUUtilization**os padrões
+ Analise **QueryResponseVolume**tendê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:**
+ **QueryRequestsTotal**com result=queue\$1error aumentando (consultas sendo rejeitadas)
+ **APIRequestTarifa** com Status=429 ou Status=503 (atende a muitas solicitações) unavailable/too
+ **CPUUtilization**pode estar elevado (> 70%) indicando saturação de recursos
+ **MemoryUtilization**pode ser alto (> 70%), limitando a capacidade de consulta
+ **QueryResponseVolume**mostrando grandes tamanhos de resposta (consultas que consomem recursos excessivos)
**Etapas da investigação:**
**Analise métricas de fila e simultaneidade:**
+ Revise o **QueryRequestsTotal**detalhamento por tipo de resultado:
+ A alta contagem de queue\$1error 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\$1error (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:**
+ **CPUUtilization**durante 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
+ **MemoryUtilization**correlação:
+ Memória alta pode estar limitando a simultaneidade de consultas
+ Verifique **HeapMemoryUsage**e verifique **ActiveMemoryAllocation**a 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 **QueryRequestsTotal**a 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:
+ **SeriesCardinality**versus capacidade da classe de instância
+ Taxa de consulta versus consultas recomendadas por segundo
+ **CPUUtilization**e altura **MemoryUtilization**livre
+ 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