Para obtener capacidades similares a las de Amazon Timestream, considere Amazon Timestream LiveAnalytics para InfluxDB. Ofrece una ingesta de datos simplificada y tiempos de respuesta a las consultas en milisegundos de un solo dígito para realizar análisis en tiempo real. Obtenga más información [aquí](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html).
Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Optimización de la supervisión y la configuración de Timestream para InfluxDB 2
## Descripción general de
La supervisión eficaz y la optimización de la configuración son fundamentales para mantener un rendimiento, una fiabilidad y una rentabilidad óptimos en su implementación de Timestream for InfluxDB. Esta guía proporciona una guía completa sobre CloudWatch las métricas, los umbrales de rendimiento y las estrategias de ajuste de la configuración para ayudarle a gestionar de forma proactiva sus instancias de InfluxDB.
## CloudWatch Referencia de métricas
Amazon CloudWatch proporciona métricas detalladas para monitorear su flujo temporal para las instancias de InfluxDB. Comprender estas métricas y sus umbrales es esencial para mantener el buen estado y el rendimiento del sistema.
### Métricas de utilización de recursos
| CloudWatch Nombre de métrica | Dimensiones | Description (Descripción) | Unidad | Umbrales recomendados |
| --- | --- | --- | --- | --- |
| CPUUtilization | DbInstanceName | Porcentaje de CPU que se utiliza | Porcentaje | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| MemoryUtilization | DbInstanceName | Porcentaje de memoria que se utiliza | Porcentaje | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| HeapMemoryUsage | DbInstanceName | Cantidad de memoria de pila en uso | Bytes | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| ActiveMemoryAllocation | DbInstanceName | Asignación de memoria activa actual | Bytes | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| DiskUtilization | DbInstanceName | Porcentaje de espacio en disco que se utiliza | Porcentaje | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Métricas de operaciones de E/S
| CloudWatch Nombre de métrica | Dimensiones | Description (Descripción) | Unidad | Umbrales recomendados |
| --- | --- | --- | --- | --- |
| ReadOpsPerSec | DbInstanceName | Número de operaciones de lectura por segundo | Recuento/segundo | Mantenga un margen de ampliación superior o igual al 30% por debajo de las IOPS aprovisionadasEjemplo: 12 000 IOPS → mantener < 8 400 IOPS en total |
| WriteOpsPerSec | DbInstanceName | Número de operaciones de escritura por segundo | Recuento/segundo | Mantenga un margen de maniobra superior o igual al 30% por debajo de las IOPS aprovisionadasEjemplo: 12 000 IOPS → mantener < 8 400 IOPS en total |
| Total IOps PerSec | DbInstanceName | Total I/O de operaciones por segundo (lectura y escritura) | Recuento/segundo | Mantenga un margen de ampliación de ≥ 30% por debajo de las IOPS aprovisionadasControle las capacidades de clase de instancia |
### Métricas de rendimiento
| CloudWatch Nombre de métrica | Dimensiones | Description (Descripción) | Unidad | Umbrales recomendados |
| --- | --- | --- | --- | --- |
| ReadThroughput | DbInstanceName | Rendimiento de lectura de datos | Bytes/segundo | Supervise los límites de rendimiento del almacenamiento |
| WriteThroughput | DbInstanceName | Rendimiento de escritura de datos | Bytes/segundo | Supervise los límites de rendimiento de almacenamiento |
### Métricas de rendimiento de las API
| CloudWatch Nombre de métrica | Dimensiones | Description (Descripción) | Unidad | Umbrales recomendados |
| --- | --- | --- | --- | --- |
| APIRequestTarifa | DbInstanceName, Punto final, estado | Porcentaje de solicitudes de API a puntos finales específicos con códigos de estado (2xx, 4xx, 5xx) | Recuento/segundo | Tasas de error: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| QueryResponseVolume | DbInstanceName, Punto final, estado | Volumen de respuestas a las consultas por punto final y código de estado | Bytes | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Métricas de ejecución de consultas
| CloudWatch Nombre de métrica | Dimensiones | Description (Descripción) | Unidad | Umbrales recomendados |
| --- | --- | --- | --- | --- |
| QueryRequestsTotal | DbInstanceName, Resultado | Recuento total de solicitudes de consulta por tipo de resultado (éxito, runtime\$1error, compile\$1error, queue\$1error) | Recuento | Tasa de éxito: > 99% Tasas de error: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Métricas de organización de datos
| CloudWatch Nombre de métrica | Dimensiones | Description (Descripción) | Unidad | Umbrales críticos |
| --- | --- | --- | --- | --- |
| SeriesCardinality | DbInstanceName, Bucket | Número de series temporales únicas en un cubo | Recuento | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| TotalBuckets | DbInstanceName | Número total de cubos de la instancia | Recuento | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Métricas de salud del sistema
| CloudWatch Nombre de métrica | Dimensiones | Description (Descripción) | Unidad | Umbrales recomendados |
| --- | --- | --- | --- | --- |
| EngineUptime | DbInstanceName | Tiempo de funcionamiento del motor InfluxDB | Segundos | Supervise los reinicios inesperadosAlerta: el tiempo de actividad se restablece inesperadamente |
| WriteTimeouts | DbInstanceName | Número de operaciones de escritura en las que se agotó el tiempo de espera | Recuento | Alerta: > 0,1% de las operaciones de escrituraCrítico: tendencia creciente |
### Métricas de gestión de tareas
| CloudWatch Nombre de métrica | Dimensiones | Description (Descripción) | Unidad | Umbrales recomendados |
| --- | --- | --- | --- | --- |
| ActiveTaskWorkers | DbInstanceName | Número de trabajadores activos | Recuento | Supervise el límite de trabajadores en tareas configuradoAlerta: Consistentemente al máximo |
| TaskExecutionFailures | DbInstanceName | Número de ejecuciones de tareas fallidas | Recuento | Alerta: más del 1% de las ejecuciones de tareasCrítico: aumentar la tasa de fallas |
### Comprensión de las relaciones métricas clave
#### Relación entre las IOPS y el rendimiento
**La regla del 30% de margen de maniobra:** mantenga siempre al menos **un 30% de margen** entre las operaciones sostenidas por segundo y las IOPS aprovisionadas. Esto proporciona un búfer para:
+ Operaciones de compactación (pueden aumentar las IOPS de forma significativa)
+ Cualquier base de datos se reinicia para que funcione sin problemas
+ Las consultas se interrumpen durante los picos de uso
+ Escribe los picos derivados de la ingestión de lotes
+ Operaciones de mantenimiento de índices
**Ejemplo de cálculo:**
+ IOPS aprovisionadas: 12 000
+ IOPS máxima sostenida objetivo (total IOpsPerSec): 8.400 (70% de utilización)
+ Espacio reservado: 3600 IOPS (30%)
Si el total supera IOps PerSec constantemente las 8.400: → Actualice el nivel de almacenamiento u optimice la carga de trabajo
**Fórmula de monitoreo:**
% de utilización de IOPS = (ReadOpsPerSec \$1 WriteOpsPerSec)/IOPS aprovisionadas × 100
+ Objetivo: mantener la utilización de las IOPS en un nivel inferior al 70%
+ Objetivo: mantener la utilización de IOPS en un 70%
+ Crítico: utilización de IOPS superior al 90%
### Comprensión del impacto en el rendimiento de la serie Cardinality
La cardinalidad de las series tiene un efecto multiplicador en los recursos del sistema:
| **Recuento de series** | **Impacto en la memoria** | **Impacto en el rendimiento de consultas** | **Impacto en el tamaño del índice** | **Recomendación** |
| --- | --- | --- | --- | --- |
| < 100 K | Minimal | Insignificante | Small | Configuración estándar |
| 100 K - 1 M | Moderado | 10-20% más lento | Medio | Ajuste la configuración de la memoria caché |
| 1 M - 5 M | Significativo | 30-50% más lento | Grande | Se requiere una optimización agresiva |
| 5 M - 10 M | Alto | 50-70% más lento | Muy grande | Ajuste máximo, considere rediseñarlo |
| > 10 M | Grave | Más de un 70% más lento | Excesivo | Migre a InfluxDB 3.0 |
**Por qué 10 M es el umbral crítico:**
+ La arquitectura InfluxDB 2.x utiliza la indexación en memoria
+ Más allá de la serie 10M, las operaciones de indexación se vuelven prohibitivamente caras
+ Los requisitos de memoria aumentan de forma no lineal
+ La sobrecarga de planificación de consultas aumenta drásticamente
+ InfluxDB 3.0 utiliza un motor de almacenamiento en columnas diseñado para una alta cardinalidad
## Pautas de tamaño y rendimiento de las instancias
La siguiente tabla proporciona orientación sobre el tamaño adecuado de las instancias en función de la cardinalidad de la serie y las características de la carga de trabajo:
| **Recuento máximo de series** | **Escribe (líneas/segundo)** | **Lecturas (consultas/segundo)** | **Instancia recomendada** | **Storage Type** | **Caso de uso** |
| --- | --- | --- | --- | --- | --- |
| < 100 K | \$150 000 | < 10 | db.influx.large | 3000 operaciones incluidas de E/S de Influx | Pequeños despliegues, desarrollo y pruebas |
| < 1 M | \$1150 000 | < 25 | db.influx.2xlarge | 3000 operaciones incluidas de E/S de Influx | Cargas de trabajo de producción pequeñas a medianas |
| \$11 MILLÓN | \$1200 000 | \$125 | db.influx.4xlarge | 3000 operaciones incluidas de E/S de Influx | Cargas de trabajo de producción medianas |
| < 5 M | \$1250 000 | \$135 | db.influx.4xlarge | 12 000 operaciones incluidas de E/S de Influx | Grandes cargas de trabajo de producción |
| < 10 M | \$1500 000 | \$150 | db.influx.8xlarge | 12 000 operaciones incluidas de E/S de Influx | Cargas de trabajo de producción muy grandes |
| \$1 10 MILLONES | < 750.000 | < 100 | db.influx.12xlarge | 12 000 operaciones incluidas de E/S de Influx | Capacidad máxima de InfluxDB 2.x |
| > 10 M | N/A | N/A | Migre a InfluxDB 3.0 | N/A | Más allá del rango óptimo de InfluxDB 2.x |
## Optimización de la configuración por métrica
### Utilización elevada de la CPU (CPUUtilization > 70%)
**Síntomas:**
+ **CPUUtilization**> 70% sostenido
+ **QueryRequestsTotal**(consultas lentas o de gran volumen)
+ **ActiveTaskWorkers**(carga de tareas elevada)
**Ajustes de configuración:**
**Prioridad 1: Controlar la simultaneidad de consultas**
+ query-concurrency: se establece en un 50-75% del recuento de vCPU
+ Ejemplo: 8 instancias de vCPU → concurrencia de consultas = 4-6
**Prioridad 2: limitar la complejidad de las consultas**
+ influxql-max-select-series: 10000 (evita consultas ilimitadas)
+ influxql-max-select-point: 100000000
+ query-queue-size: 2048 (evita la acumulación de colas)
**Prioridad 3: Habilitar el análisis de consultas**
+ flux-log-enabled: TRUE (temporalmente para la depuración)
+ nivel de registro: información (o depuración para un análisis detallado)
**Consideraciones importantes:**
La reducción `query-concurrency` limitará la cantidad de consultas que se pueden ejecutar simultáneamente, lo que puede aumentar las consultas en cola y provocar una mayor latencia de consultas durante los períodos de mayor actividad. Si la demanda de consultas supera el límite reducido de simultaneidad, es posible que los usuarios se carguen más lentamente en los paneles o se agote el tiempo de espera de los informes.
**Si se establecen límites de protección (`influxql-max-select-series`,`influxql-max-select-point`), se producirá un error en las consultas que superen estos umbrales con **compile\$1error** o runtime\$1error como valores. **QueryRequestsTotal**** Si bien esto protege al sistema del agotamiento de los recursos, puede interrumpir las consultas existentes que funcionaban anteriormente.
**Práctica recomendada:** Antes de aplicar estos cambios, analiza los patrones de consulta **QueryResponseVolume**y **QueryRequestsTotal**las métricas. Identifique y optimice primero las consultas más costosas: busque consultas sin filtros de intervalo de tiempo, consultas que abarquen series de alta cardinalidad o consultas que soliciten puntos de datos excesivos. Siempre es preferible optimizar las consultas a nivel de aplicación en lugar de imponer límites estrictos que podrían afectar a la funcionalidad.
**Acciones de hardware:**
+ Escale a la siguiente clase de instancia con más v CPUs
+ Revise los patrones de consulta para ver las oportunidades de optimización
### Alta utilización de memoria (MemoryUtilization > 70%)
**Síntomas:**
+ **MemoryUtilization**> 70% sostenido
+ **HeapMemoryUsage**con una tendencia al alza
+ **ActiveMemoryAllocation**mostrando picos
+ **SeriesCardinality**(la alta cardinalidad aumenta el uso de memoria)
**Ajustes de configuración:**
**Prioridad 1: Reducir la memoria caché**
+ storage-cache-max-memory-tamaño: establecido en un 10-15% de la RAM total
+ Ejemplo: 32 GB de RAM → 3.355.443.200 a 5.033.164.800 bytes
+ storage-cache-snapshot-memory-tamaño: 26.214.400 (25 MB)
**Prioridad 2: Limitar la memoria de consultas**
+ query-memory-bytes: establecido en un 60-70% de la RAM total
+ query-max-memory-bytes: Igual que query-memory-bytes
+ query-initial-memory-bytes: 10% de query-memory-bytes
**Prioridad 3: Optimizar la caché de la serie**
+ storage-series-id-set-tamaño de la memoria caché: reduzca si es alta la cardinalidad
+ Memoria alta: 100-200
+ Normal: 500-1000
**Consideraciones importantes:**
Si bien estos cambios reducirán la presión de la memoria, tendrán un impacto negativo directo en el rendimiento de las aplicaciones. Al `storage-cache-max-memory-size` reducirlos, se almacenan menos datos en caché en la memoria, lo que obliga a leer más discos y aumenta la latencia de las consultas. Es probable que los tiempos de **QueryResponseVolume**respuesta **ReadOpsPerSec**aumenten y disminuyan.
Si `query-memory-bytes` se limita, se producirán errores en las consultas con un uso intensivo de memoria y se incluirá **runtime\$1error **QueryRequestsTotal****, especialmente en las consultas que agregan conjuntos de datos de gran tamaño o devuelven conjuntos de resultados importantes. Los usuarios pueden encontrar errores de «falta de memoria» en consultas que anteriormente se realizaron correctamente.
La reducción `storage-series-id-set-cache-size` reduce el rendimiento de las consultas con datos de alta cardinalidad, ya que el sistema debe volver a calcular los resultados de las series con más frecuencia en lugar de recuperarlos de la memoria caché. Esto afecta especialmente a los cuadros de mando que consultan repetidamente las mismas combinaciones de series.
**Práctica recomendada:** antes de aplicar estos cambios restrictivos, analice primero sus patrones de consulta y optimícelos:
+ **QueryResponseVolume**Revíselas para identificar las consultas que devuelven datos excesivos
+ Se utiliza **QueryRequestsTotal**para encontrar consultas que se ejecutan con frecuencia y que podrían beneficiarse de una optimización
+ Añada filtros de intervalo de tiempo para reducir el escaneo de datos a lo necesario para su carga de trabajo
+ Implemente el almacenamiento en caché de los resultados de las consultas a nivel de aplicación
+ Considere la posibilidad de agregar previamente los datos mediante tareas de reducción de muestreo
+ Revise **SeriesCardinality**y optimice su modelo de datos para reducir las etiquetas innecesarias
La optimización de consultas siempre debe ser su primer enfoque; las restricciones de configuración deben ser el último recurso cuando la optimización no es suficiente.
**Acciones de hardware:**
+ Aumente el tamaño de la instancia para obtener más RAM
### Alta utilización del almacenamiento (DiskUtilization > 70%)
**CloudWatch Métricas a monitorear:**
+ **DiskUtilization**> 70%
+ **WriteThroughput**patrones
+ **TotalBuckets**(muchos cubos aumentan los gastos generales)
**Ajustes de configuración:**
**Prioridad 1: comprobar la configuración del registro**
+ nivel de registro: asegúrese de configurarlo en «información» (no en «depurar»)
+ flux-log-enabled: Establézcalo en FALSE a menos que se esté depurando activamente
**Prioridad 2: Retención agresiva**
+ storage-retention-check-interval: 150 ms (limpieza más frecuente)
**Prioridad 3: optimizar la compactación**
+ storage-compact-full-write-Duración en frío: 20 h (más frecuente)
+ storage-cache-snapshot-write-duración en frío: 50 m0s
**Prioridad 4: Reducir el tamaño del índice**
+ storage-max-index-log-tamaño del archivo: 524.288 (512 KB para una compactación más rápida)
**Consideraciones importantes:**
**Primer paso fundamental: compruebe la configuración de registro: antes de realizar cualquier otro cambio, compruebe la configuración** de registro. El **registro de depuración y los registros de consultas de Flux pueden consumir tanto o más espacio en disco que los datos reales de series temporales**, y esta es una de las causas más comunes de agotamiento inesperado del almacenamiento.
**Impacto en el registro:**
+ `log-level: debug`genera registros extremadamente detallados, potencialmente cientos de MB por hora
+ `flux-log-enabled: TRUE`registra cada ejecución de consultas de Flux con todos los detalles, creando enormes archivos de registro
+ Estos registros se acumulan rápidamente y, a menudo, se pasan por alto durante la planificación de la capacidad
+ Los archivos de registro pueden llenar el espacio en disco más rápido que la ingesta de datos, especialmente en instancias más pequeñas
+ A diferencia de los datos de series temporales, los registros se guardan en el almacenamiento local durante 24 horas antes de ser eliminados
**Acciones inmediatas si los registros son grandes:**
1. Establecer `log-level: info` (desde la depuración)
1. Establezca `flux-log-enabled: FALSE`
1. Supervise **DiskUtilization**para una mejora inmediata
**Ventajas y desventajas de la configuración de compactación:**
Estos cambios de configuración están diseñados específicamente para cargas de trabajo con un **alto rendimiento de ingesta y períodos de retención cortos**, en los que el uso del disco fluctúa considerablemente. Hacen que el motor de compactación funcione de forma más agresiva, lo que solo resulta beneficioso en situaciones específicas.
**Compensaciones fundamentales: el aumento de la frecuencia de** compactación aumentará significativamente el consumo de recursos:
+ **CPUUtilization**aumentará a medida que las operaciones de compactación consuman ciclos de CPU
+ **MemoryUtilization**aumentará durante la compactación a medida que se carguen y procesen los datos
+ **WriteOpsPerSec**y **WriteThroughput**se disparará durante las ventanas de compactación, lo que podría superar el margen de IOPS del 30%
+ **WriteTimeouts**puede aumentar si la compactación I/O compite con las escrituras de las aplicaciones
Estos cambios pueden crear un problema de rendimiento en cascada, ya que una compactación agresiva consume los recursos necesarios para las operaciones de consulta y escritura, lo que reduce el rendimiento general del sistema y, al mismo tiempo, reduce el uso del disco.
**Práctica recomendada:** antes de ajustar la configuración de compactación, concéntrese en la gestión de los datos y los registros:
1. **Compruebe primero el registro (problema más común):** compruebe que el nivel de registro es «informativo» y que sea FALSO flux-log-enabled
1. **Revise su modelo de datos:** ¿Está escribiendo datos que en realidad no necesita? ¿Puede reducir la granularidad de las mediciones o del campo?
1. **Optimice las políticas de retención:** compruebe **TotalBuckets**y revise la configuración de retención de cada segmento
1. **Supervise el impacto de la compactación: **CPUUtilization****evalúe **MemoryUtilization**sus cambios y **WriteOpsPerSec**antes
**Enfoques alternativos:**
+ Aumente la capacidad de almacenamiento (a menudo más simple y rentable)
+ Implemente estrategias de reducción de muestreo o agregación de datos
+ Consolide los cubos (reduzca **TotalBuckets**) para reducir los gastos generales
+ Revise y aplique las políticas de retención de manera más estricta
Aplica una configuración de compactación agresiva únicamente si has optimizado la administración de datos y has confirmado que la instancia tiene suficiente espacio de CPU, memoria e IOPS para soportar el aumento de carga.
**Acciones de hardware:**
+ Aumente la capacidad de almacenamiento
### Alta utilización de IOPS (más del 70% ReadIOPS/WriteIOPS/TotalOperationsPerSecond de las aprovisionadas)
**CloudWatch Métricas que se deben supervisar:**
+ **ReadOpsPerSec**\$1 **WriteOpsPerSec**= **Total IOps PerSec**
+ **ReadThroughput** y **WriteThroughput**
+ Compare con las IOPS aprovisionadas (3000, 12 000 o 16 000)
**Ajustes de configuración:**
**Prioridad 1: Controlar la compactación de E/S**
+ storage-max-concurrent-compactions: 2-3 (limitar las compactaciones simultáneas)
+ storage-compact-throughput-burst: Se ajusta en función de la capacidad del disco
+ 3000 IOPS: 25 165.824 (24 MB/s)
+ 12 000 IOPS: 50.331.648 (48 MB/s)
**Prioridad 2: optimizar las operaciones de escritura**
+ storage-wal-max-concurrent-escrituras: 8-12
+ storage-wal-max-write-retraso: 50 ms
**Prioridad 3: ajustar el tiempo de las instantáneas**
+ storage-cache-snapshot-write-Duración en frío: 150 ms (menos frecuente)
+ storage-compact-full-write-duración en frío: 60 horas (menos frecuente)
**Consideraciones importantes:**
Estos cambios crean importantes compensaciones entre la utilización y el rendimiento del sistema: I/O
**Limitar la E/S de compactación:**
+ La reducción `storage-max-concurrent-compactions` ralentizará las operaciones de compactación, lo que provocará que los archivos TSM se acumulen y **DiskUtilization**aumenten más rápidamente
+ Cuanto menor sea, `storage-compact-throughput-burst` prolonga la duración de la compactación, lo que mantiene el compactador activo durante más tiempo y, potencialmente, bloquea otras operaciones
+ Una compactación más lenta significa que el rendimiento de las consultas se deteriora con el tiempo, ya que el motor de almacenamiento debe leer más archivos TSM más pequeños en lugar de archivos consolidados
+ Es posible que vea que las tasas de **QueryRequestsTotal**runtime\$1error aumentan a medida que se agota el tiempo de espera de las consultas mientras esperan la E/S
**Reducir la frecuencia de las instantáneas:**
+ Al aumentar, `storage-cache-snapshot-write-cold-duration` `storage-compact-full-write-cold-duration` los datos permanecen más tiempo en el registro de escritura anticipada (WAL)
+ Esto aumenta a **MemoryUtilization**medida que se guardan más datos en la memoria caché antes de transferirlos al disco
+ El riesgo de pérdida de datos aumenta ligeramente si la instancia se bloquea antes de que se conserven los datos en caché
+ El tiempo de recuperación tras un reinicio aumenta a medida que se deben reproducir más datos de WAL
**Ajuste de la operación de escritura:**
+ Al reducir`storage-wal-max-concurrent-writes`, se serializarán más las operaciones de escritura, lo que podría aumentar **WriteTimeouts**durante los períodos de alto rendimiento
+ El aumento `storage-wal-max-write-delay` significa que las escrituras pueden esperar más tiempo antes de ser rechazadas, lo que puede ocultar problemas de capacidad pero frustrar a los usuarios con respuestas lentas
**Práctica recomendada:** el uso elevado de IOPS suele indicar que se ha superado el tamaño del nivel de almacenamiento y no se debe a un problema de configuración. Antes de restringir I/O, analyze I/O los patrones y optimice antes de restringirlos.
**Acciones de hardware:**
+ Actualice a un nivel de almacenamiento de IOPS superior (3000 → 12 000)
+ Asegúrese de mantener un margen de IOPS del 30%
### Cardinalidad de serie alta (> 1 M) SeriesCardinality
**CloudWatch Métricas a monitorear:**
+ **SeriesCardinality**por grupo y en total
+ **MemoryUtilization**(aumenta con la cardinalidad)
+ **CPUUtilization**(gastos generales de planificación de consultas)
+ **QueryRequestsTotal**(la tasa de errores de ejecución puede aumentar)
**Ajustes de configuración:**
**Prioridad 1: optimizar el manejo de la serie**
+ storage-series-id-set-tamaño de la caché: 1000-2000 (aumentar la caché)
+ storage-series-file-max-concurrent-snapshot-compactions: 4-8
**Prioridad 2: Establecer límites de protección**
+ influxql-max-select-series: 10000 (evita consultas descontroladas)
+ influxql-max-select-buckets: 1000
**Prioridad 3: Optimizar las operaciones de indexación**
+ storage-max-index-log-tamaño del archivo: 2.097.152 (2 MB)
**Consideraciones importantes:**
La alta cardinalidad de las series es fundamentalmente un problema de modelado de datos, no un problema de configuración. Los cambios de configuración solo pueden mitigar los síntomas, no pueden resolver el problema subyacente.
**Compensaciones y desventajas de la configuración:**
El aumento `storage-series-id-set-cache-size` mejorará el rendimiento de las consultas al almacenar en caché las búsquedas de series, pero a costa de aumentarlas. **MemoryUtilization** Cada entrada de la caché consume memoria y, con millones de series, esto puede ser considerable. Supervise **HeapMemoryUsage**y **ActiveMemoryAllocation**después de realizar este cambio.
Si se establecen límites de protección (`influxql-max-select-series`,`influxql-max-select-buckets`), las consultas legítimas fallarán con **compile\$1error** como valor **QueryRequestsTotal**si superan estos umbrales. Los cuadros de mando que antes funcionaban podrían estropearse y los usuarios deberán modificar sus consultas. Esto es particularmente problemático en el caso de:
+ Monitorear los paneles de control que se agregan en muchos hosts o servicios
+ Consultas de análisis que necesitan comparar varias entidades
+ Consultas de alertas que evalúan las condiciones de toda la flota
El ajuste `storage-max-index-log-file-size` a valores más pequeños aumenta la frecuencia de compactación del índice, que aumenta **CPUUtilization**a **WriteOpsPerSec**medida que el sistema realiza un mantenimiento del índice más frecuente.
**Comprensión crítica:**
Cuando **SeriesCardinality**supera los 5 millones, se acerca a los límites arquitectónicos de InfluxDB 2.x. En la serie 10M\$1, el rendimiento se degrada exponencialmente independientemente de la configuración:
+ La planificación de consultas se vuelve prohibitivamente costosa (elevada) **CPUUtilization**
+ Los requisitos de memoria aumentan de forma no lineal (altos) **MemoryUtilization**
+ Las operaciones de indexación dominan I/O (**ReadOpsPerSec**,) **WriteOpsPerSec**
+ **QueryRequestsTotal**Las tasas de runtime\$1error aumentan a medida que las consultas agotan la memoria o agotan la memoria
**Práctica recomendada: los cambios de configuración son** curitas temporales. Debe abordar la causa raíz:
1. **Analice su modelo de datos:**
+ **SeriesCardinality**Revíselo por grupo para identificar las áreas problemáticas
+ Identifique qué etiquetas tienen un alto número de valores únicos
+ Busque valores de etiqueta ilimitados (marcas de tiempoUUIDs, usuario, sesión) IDs IDs
+ En su lugar, busca etiquetas que deberían ser campos
**Acciones del modelo de datos:**
+ Revise el diseño de las etiquetas para reducir la cardinalidad innecesaria
+ Considere la posibilidad de consolidar series similares
+ **Si la serie es > 10M:** planifique la migración a InfluxDB 3.0
### Problemas de rendimiento de consultas
**CloudWatch Métricas a monitorear:**
+ **QueryRequestsTotal**por tipo de resultado (success, runtime\$1error, compile\$1error, queue\$1error)
+ **APIRequestTasa con un estado = 500 o un estado = 499**
+ **QueryResponseVolume**(las respuestas grandes indican consultas caras)
**Ajustes de configuración:**
**Prioridad 1: aumentar los recursos de consulta**
+ concurrencia de consultas: aumente al 75% de v CPUs
+ query-memory-bytes: Asigne el 70% de la RAM total
+ query-queue-size: 4096
**Prioridad 2: optimizar la ejecución de consultas**
+ storage-series-id-set-tamaño de la caché: 1000 (aumente para un mejor almacenamiento en caché)
+ http-read-timeout: 60 segundos (evita tiempos de espera prematuros)
**Prioridad 3: Establecer límites razonables**
+ influxql-max-select-point: 100000000
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
**Consideraciones importantes:**
El aumento de los recursos de consultas crea competencia por los recursos y una posible inestabilidad del sistema:
**Compensaciones y desventajas en la asignación de recursos:**
`query-concurrency`El aumento permite que se ejecuten más consultas simultáneamente, pero cada consulta compite por la CPU y la memoria:
+ **CPUUtilization**aumentará y podría llegar a saturarse durante los períodos de mayor cantidad de consultas
+ **MemoryUtilization**aumentará a medida que más consultas asignen memoria simultáneamente
+ Si aumentas la simultaneidad sin los recursos adecuados, todas las consultas se ralentizarán y no solo algunas se pondrán en cola
+ Existe el riesgo de que se produzcan errores en cascada si las consultas simultáneas agotan los recursos disponibles
Asignar más `query-memory-bytes` significa menos memoria disponible para el almacenamiento en caché y otras operaciones:
+ **HeapMemoryUsage**aumentará
+ `storage-cache-max-memory-size`puede que sea necesario reducirlo para compensar
+ Un menor número de visitas a la caché significa un rendimiento de consultas mayor **ReadOpsPerSec**y más lento
+ El sistema se vuelve más vulnerable al agotamiento de la memoria si las consultas utilizan su asignación completa
El aumento `query-queue-size` solo retrasa el problema, no resuelve los problemas de capacidad:
+ Las consultas esperan más tiempo en la cola, lo que aumenta la latencia end-to-end
+ Los usuarios perciben que el sistema es más lento, aunque el rendimiento no haya cambiado
+ Las colas grandes pueden ocultar los problemas de capacidad subyacentes
+ **QueryRequestsTotal**La tasa de errores de cola disminuye, pero es posible que la experiencia del usuario no mejore
Si se aumenta, `http-read-timeout` se evita la cancelación prematura de las consultas, pero:
+ Las consultas de larga duración consumen recursos durante más tiempo, lo que reduce la capacidad de otras consultas
+ Los usuarios esperan más tiempo antes de recibir errores de tiempo de espera
+ Puede ocultar consultas ineficientes que deberían optimizarse
+ Puede provocar el agotamiento de los recursos si se acumulan muchas consultas lentas
**Práctica recomendada:** los problemas de rendimiento de las consultas suelen deberse a consultas ineficientes, no a recursos insuficientes. Antes de aumentar la asignación de recursos:
1. **Analice los patrones de consulta:**
+ Revise **QueryResponseVolume**para identificar las consultas que devuelven un exceso de datos (> 1 MB)
+ Comprueba los patrones de **QueryRequestsTotal**runtime\$1error: ¿qué es lo que provoca los errores?
+ Busca **APIRequestRate** con un estado igual a 499 (tiempos de espera del cliente): las consultas son demasiado lentas
+ Identifique las consultas costosas que se ejecutan con frecuencia
1. **Optimice primero las consultas:**
Antipatrones de consultas comunes:
+ Faltan filtros de intervalo de tiempo → Añadir límites de tiempo explícitos
+ Consulta de todas las series → Añadir filtros de etiquetas específicos
+ Ventanas de agregación excesivas → Utilice los intervalos adecuados
+ Campos innecesarios en SELECT → Solicita solo los datos necesarios
+ Cláusulas sin LÍMITE → Añada límites razonables
1. **Soluciones a nivel de aplicación:**
+ Implemente el almacenamiento en caché de los resultados de las consultas (Redis, Memcached)
+ Utilice las tareas para agregar previamente patrones comunes
+ Añada paginación para conjuntos de resultados de gran tamaño
+ Implemente una limitación de la frecuencia de consultas por usuario o panel
+ Utilice datos submuestreados para consultas históricas
1. **Verificar la disponibilidad de los recursos:**
+ **CPUUtilization**Compruébelo: si ya es superior al 70%, aumentar la simultaneidad empeorará las cosas
+ Comprueba **MemoryUtilization**: si ya es superior al 70%, asignar más memoria de consultas provocará OOM
+ Comprueba que **Total IOps PerSec tenga un** 30% de margen de maniobra antes de aumentar la carga de consultas
**Enfoque recomendado:**
1. Comience por optimizar las 10 consultas más caras (por **QueryResponseVolume**)
1. Implemente el almacenamiento en caché de los resultados de las consultas a nivel de aplicación
1. Aumente la asignación de recursos únicamente si las consultas están optimizadas y las métricas muestran un margen de maniobra
1. Amplíe a una clase de instancia más grande si la carga de trabajo ha superado la capacidad actual
**Acciones de hardware:**
+ Amplíe su capacidad de cómputo, las consultas se benefician de una potencia de procesamiento adicional (vCPUs)
#### RegEx Problemas de rendimiento en las consultas de Flux
Cuando filtre datos en Flux, evite utilizar expresiones regulares para obtener coincidencias exactas o simples coincidencias de patrones, ya que esto supone importantes penalizaciones en el rendimiento. RegEx las operaciones en Flux son de **un solo subproceso y** omiten por **completo el índice TSM subyacente**. En lugar de aprovechar los índices de etiquetas optimizados de InfluxDB para realizar búsquedas rápidas, los RegEx filtros obligan al motor de consultas a recuperar del almacenamiento todas las series coincidentes y a realizar comparaciones de texto secuencialmente con cada valor. Esto se vuelve particularmente problemático cuando:
+ **Filtrar según los valores exactos de las etiquetas**: utilice el operador de igualdad (`==`) o la `contains()` función en lugar de RegEx patrones como `/^exact_value$/`
+ **Hacer coincidir varios valores específicos**: utilice el `in` operador con una matriz de valores en lugar de patrones de alternancia como `/(value1|value2|value3)/`
+ **Simple coincidencia de prefijos o sufijos**: considere usar `strings.hasSuffix()` funciones `strings.hasPrefix()` o, que son más eficientes que los anclajes RegEx
En los escenarios que requieran múltiples coincidencias de patrones, reestructure la consulta para utilizar varios predicados de filtro combinados con operadores lógicos, o bien, realice un filtrado previo utilizando la igualdad de etiquetas antes de aplicar operaciones de cadena más complejas. Reserve RegEx exclusivamente para los casos en los que se requiera una verdadera coincidencia de patrones que no se pueda expresar mediante operadores de comparación más simples.
### Escribe problemas de rendimiento
**CloudWatch Métricas a monitorear:**
+ **WriteTimeouts**(recuento creciente)
+ **WriteOpsPerSec** y **WriteThroughput**
+ **APIRequestVelocidad** con un estado igual a 500 para los puntos finales de escritura
+ **QueryRequestsTotal**con result=runtime\$1error durante las escrituras
**Ajustes de configuración:**
**Prioridad 1: optimizar las escrituras de WAL**
+ storage-wal-max-concurrent-escribe: 12-16
+ storage-wal-max-write-retardo: 100 ms
+ http-write-timeout: 60 s
**Prioridad 2: optimizar las instantáneas de la caché**
+ storage-cache-snapshot-memory-tamaño: 52.428.800 (50 MB)
+ storage-cache-snapshot-write-duración en frío: 100 ms
**Prioridad 3: Validación del campo de control**
+ storage-no-validate-field-size: TRUE (si la fuente de datos es de confianza)
**Consideraciones importantes:**
El ajuste del rendimiento de escritura implica un equilibrio cuidadoso entre el rendimiento, la confiabilidad y el consumo de recursos:
**Compensaciones y desventajas de la configuración de WAL:**
El aumento `storage-wal-max-concurrent-writes` permite más operaciones de escritura en paralelo, pero:
+ **CPUUtilization**aumenta a medida que más subprocesos de escritura compiten por la CPU
+ **MemoryUtilization**aumenta a medida que se almacenan más datos en la memoria antes de que WAL se vacíe
+ **WriteOpsPerSec**se disparará, lo que podría superar su margen de IOPS del 30%
+ De hecho, el aumento de la contención del disco I/O podría ralentizar las escrituras individuales
+ Si sobrepasa la I/O capacidad del disco, **WriteTimeouts**puede aumentar en lugar de disminuir
Aumentar `storage-wal-max-write-delay` significa que las escrituras deben esperar más tiempo antes de agotarse el tiempo de espera:
+ Enmascara los problemas de capacidad haciendo que las escrituras esperen en lugar de fallar rápidamente
+ Los usuarios experimentan tiempos de respuesta de escritura más lentos incluso cuando las escrituras finalmente se realizan correctamente
+ Puede provocar una acumulación de colas de escritura y una presión de memoria
+ En realidad, no aumenta la capacidad, solo retrasa el tiempo de espera
Un aumento `http-write-timeout` similar retrasa los errores de tiempo de espera:
+ Permite completar escrituras de lotes más grandes
+ Pero también permite que las escrituras lentas consuman recursos durante más tiempo
+ Puede ocultar los problemas de rendimiento subyacentes
+ Puede provocar el agotamiento de los recursos si se acumulan muchas escrituras lentas
**Ventajas y desventajas de las instantáneas de caché:**
Al aumentar`storage-cache-snapshot-memory-size`, se acumulan más datos en la memoria antes de vaciarlos:
+ **MemoryUtilization**aumenta significativamente
+ El riesgo de pérdida de datos aumenta si la instancia se bloquea antes que la instantánea
+ Las instantáneas más grandes tardan más en escribirse, lo que crea picos más grandes **WriteOpsPerSec**
+ Puede mejorar el rendimiento de escritura al agrupar más datos por lotes, pero a costa de la memoria y la confiabilidad
`storage-cache-snapshot-write-cold-duration`Retrasa cada vez más las instantáneas:
+ Aumenta aún más a **MemoryUtilization**medida que los datos permanecen en la memoria caché durante más tiempo
+ Aumenta el margen de riesgo de pérdida de datos
+ Reduce la **WriteOpsPerSec**frecuencia, pero crea picos más grandes cuando se producen instantáneas
+ El tiempo de recuperación después del reinicio aumenta a medida que se deben reproducir más WAL
**Compensación sobre la validación de campo:**
La configuración `storage-no-validate-field-size: TRUE` desactiva la validación del tamaño del campo:
+ Mejora el rendimiento de escritura al omitir las comprobaciones de validación
+ **Riesgo crítico:** permite escribir datos malformados o malintencionados
+ Puede provocar daños en los datos si las escrituras contienen tamaños de campo no válidos
+ Hace que la depuración de problemas de datos sea mucho más difícil
+ **Úselo solo si tiene el control total y la confianza en su fuente de datos**
**Práctica recomendada:** los problemas de rendimiento de escritura suelen indicar límites de capacidad o patrones de escritura ineficientes. Antes de ajustar la configuración:
1. **Analice los patrones de escritura:**
+ Revisión **WriteThroughput**y **WriteOpsPerSec**tendencias
+ Compruebe **WriteTimeouts**la correlación con la carga de escritura
+ Supervise **APIRequestla velocidad** de los puntos finales de escritura por código de estado
+ Identifique los tamaños y la frecuencia de los lotes de escritura
1. **Optimice primero las operaciones de escritura:**
Antipatrones de escritura comunes:
+ Escribir puntos individuales → Escrituras por lotes (5.000 a 10.000 puntos)
+ Escrituras demasiado frecuentes → Almacena en búfer y por lotes
+ Escrituras sincrónicas → Implemente colas de escritura asíncronas
+ Ráfagas de escritura ilimitadas → Implemente la limitación de velocidad
+ Escribir con precisión innecesaria → Redondea las marcas de tiempo de forma adecuada
1. **Verifique la capacidad I/O :**
+ Compruebe el **total IOps PerSec**: si ya es superior al 70%, aumentar la simultaneidad de la WAL empeorará las cosas
+ Revíselo **WriteOpsPerSec**durante los períodos de mayor actividad
+ Asegúrese de que haya un margen de IOPS del 30% antes de ajustar la configuración de escritura
+ Considere si son suficientes 3000 IOPS o si se necesita un nivel de 12 000 IOPS
1. **Mejoras a nivel de aplicación:**
+ Implemente el almacenamiento en búfer de escritura con tamaños de lote configurables
+ Agregue lógica de reintento de escritura con retroceso exponencial
+ Utilice operaciones de escritura asíncronas
+ Implemente la limitación de la velocidad de escritura durante los períodos de máxima
+ Supervise la profundidad de la cola de escritura y aplique contrapresión
**Enfoque recomendado:**
1. Comience por optimizar los tamaños de los lotes de escritura a nivel de aplicación (procure obtener entre 5.000 y 10.000 puntos por lote)
1. Implemente operaciones asíncronas y de almacenamiento en búfer de escritura
1. **Compruebe que Total tenga el margen de maniobra adecuado IOps PerSec**
1. Actualice al siguiente nivel de almacenamiento (3000 IOPS → 12 000 IOPS → 16 000 IOPS) si se utiliza constantemente por encima del 70%
1. Ajuste la configuración de WAL únicamente si las escrituras están optimizadas y la capacidad es adecuada I/O
1. **Nunca** desactive la validación de campo a menos que tenga el control total de las fuentes de datos
**Acciones de hardware:**
+ Actualice a un almacenamiento de IOPS superior (3 K → 12 K → 16 K)
+ Asegúrese de que el espacio libre sea adecuado I/O
+ Escale a una clase de instancia más grande si la CPU o la memoria tienen limitaciones
## Mejores prácticas de supervisión
### CloudWatch Configuración de alarmas
**Alarmas críticas (se requiere una acción inmediata):**
**CPUUtilization:**
+ Umbral: > 90% durante 5 minutos
+ Acción: Implemente medidas de remediación del tráfico o escalamiento informático
**MemoryUtilization:**
+ Umbral: > 90% durante 5 minutos
+ Acción: Implemente medidas de remediación del tráfico o escalamiento informático
**DiskUtilization:**
+ Umbral: > 85%
+ Acción: Intente liberar espacio eliminando los depósitos antiguos, actualizando las configuraciones de retención o escalando el almacenamiento
**Total IOpsPerSec:**
+ Umbral: > 90% del aprovisionamiento durante 10 minutos
+ Acción: Implemente medidas de corrección del tráfico o aumente las IOPS
**SeriesCardinality:**
+ Umbral: > 10 000 000
+ Acción: revise su modelo de datos y, si no es posible realizar cambios, explore la posibilidad de migrar a InfluxDB 3 o fragmentar sus datos
**EngineUptime:**
+ Umbral: restablecimiento inesperado (< 300 segundos)
+ Acción: compruebe si coincide con un período de mantenimiento y, de lo contrario, cree un ticket de asistencia de Timestream.
**Alarmas de advertencia (es necesario investigarlas):**
**CPUUtilization:**
+ Umbral: > 70% durante 15 minutos
+ Acción: revise los cambios en la carga de trabajo o el tráfico
**MemoryUtilization:**
+ Umbral: > 70% durante 15 minutos
+ Acción: revise los cambios en la carga de trabajo o el tráfico
**DiskUtilization:**
+ Umbral: > 70%
+ Acción: revise las políticas de retención
**Total IOpsPerSec:**
+ Umbral: más del 70% del aprovisionamiento durante 15 minutos
+ Acción: revise los cambios en la carga de trabajo o el tráfico
**QueryRequestsTotal (runtime\$1error):**
+ Umbral: > 1% del total de consultas
+ Acción: revise los cambios en la carga de trabajo o el tráfico
**WriteTimeouts:**
+ Umbral: > 1% de las operaciones de escritura
+ Acción: revise los cambios en la carga de trabajo o el tráfico
**SeriesCardinality:**
+ Umbral: > 5 000 000
+ Acción: revisar la optimización del modelo de datos
### Lista de verificación de monitoreo proactivo
**Todos los días:**
+ APIRequestTasa de revisión de picos de error (400, 404, 499, 500)
+ Compruebe las tasas QueryRequestsTotal de runtime\$1error y queue\$1error
+ WriteTimeouts Compruebe que el recuento sea mínimo
+ Compruebe si hay alguna alarma crítica
+ Verifica EngineUptime (sin reinicios inesperados)
**Semanalmente:**
+ Revisión CPUUtilization MemoryUtilization y DiskUtilization tendencias
+ Analice QueryRequestsTotal los patrones por tipo de resultado
+ Compruebe la tasa de SeriesCardinality crecimiento por cubo
+ Revise las tendencias IOps PerSec de utilización total
+ Compruebe que los parámetros de configuración sean óptimos
+ Revise TaskExecutionFailures los patrones
**Mensualmente:**
+ Revisión de la planificación de la capacidad (proyecto con 3 a 6 meses de antelación)
+ Compare las métricas actuales con la tabla de tallas
+ Revise y optimice las políticas de retención
+ Analice los patrones de consulta de APIRequest Rate y QueryResponseVolume
+ Eficiencia de SeriesCardinality la revisión y del modelo de datos
+ Evalúe la necesidad, por ejemplo, de cambios de escalado o configuración
+ Oportunidades de revisión TotalBuckets y consolidación
## Guía para solucionar problemas
### Escenario: Degradación repentina del rendimiento
**Pasos de la investigación:**
**Compruebe los cambios recientes:**
+ Modificaciones de los parámetros de configuración en la consola AWS de administración
+ Cambios en la implementación de la aplicación
+ Cambios en el patrón de consultas
+ Modificaciones del modelo de datos
+ Cambios en la infraestructura (tipo de instancia, almacenamiento)
**Revise CloudWatch las métricas:**
+ **¿Pico de CPU?** → Compruebe CPUUtilization, QueryRequestsTotal
+ **¿Presión de memoria?** → Comprobar MemoryUtilization HeapMemoryUsage, ActiveMemoryAllocation
+ **¿Saturación de IOPS?** → Compruebe el total IOpsPerSec, ReadOpsPerSec WriteOpsPerSec
+ **¿Salto de cardinalidad de la serie?** → Compruebe el crecimiento SeriesCardinality
+ **¿Aumento de la tasa de error?** → Compruebe QueryRequestsTotal (runtime\$1error), APIRequest velocidad (estado = 500)
+ **¿Reinicio inesperado?** → Comprobar EngineUptime
**Habilitar el registro detallado:**
Cambios de configuración:
+ nivel de registro: depuración
+ flux-log-enabled: VERDADERO
Supervise durante 1 a 2 horas y, a continuación, revise los registros
Volver al nivel de registro: información tras la investigación
**Pasos de resolución:**
+ Aplique los cambios de configuración adecuados en función de los hallazgos
+ Escale los recursos si se alcanzan los límites
+ Optimice las consultas o el modelo de datos si es necesario
+ Implemente una limitación de velocidad si la carga aumenta repentinamente
### Escenario: agotamiento de la memoria
**Síntomas:**
+ MemoryUtilization > 90%
+ HeapMemoryUsage acercándose al máximo
+ QueryRequestsTotal mostrando runtime\$1error (memoria insuficiente)
+ APIRequestVelocidad que muestra el estado = 500
**Pasos de resolución:**
Acciones inmediatas (si son críticas):
1. Reinicie la instancia para borrar la memoria (si es seguro hacerlo)
1. Reduzca temporalmente la simultaneidad de consultas
1. Elimine las consultas de larga duración si es posible
Cambios de configuración:
**Prioridad 1: Reducir la memoria caché**
+ storage-cache-max-memory-tamaño: reducir al 10% de la RAM
+ Ejemplo: 32 GB → 3.355.443.200 bytes
+ storage-cache-snapshot-memory-tamaño: 26.214.400 (25 MB)
**Prioridad 2: limitar la memoria de consultas**
+ query-memory-bytes: establecido en el 60% de la RAM total
+ query-max-memory-bytes: Partido query-memory-bytes
+ query-initial-memory-bytes: 10% de descuento query-memory-bytes
**Prioridad 3: Establecer límites de protección**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
+ concurrencia de consultas: reducir al 50% de v CPUs
**Soluciones a largo plazo:**
+ Optimice el modelo de datos para reducir **SeriesCardinality**
+ Implemente límites de tamaño de los resultados de las consultas a nivel de aplicación
+ Agregue el cumplimiento del tiempo de espera de las consultas
+ Revise las consultas más comunes para asegurarse de que siguen las prácticas recomendadas mencionadas en la sección [Problemas de rendimiento de consultas](#query-performance-issues)
### Escenario: Impacto de cardinalidad en series altas
**Revise las CloudWatch métricas:**
+ **SeriesCardinality**> 5 millones
+ **MemoryUtilization**alto
+ **QueryRequestsTotal**mostrando un aumento de runtime\$1error
+ **CPUUtilization**elevado debido a la sobrecarga de planificación de consultas
**Pasos de investigación:**
**Analice el crecimiento de la cardinalidad:**
+ SeriesCardinality tasa de crecimiento (diaria/semanal)
+ Proyección hasta el umbral de 10 millones
+ Identifique las fuentes de alta cardinalidad
+ Revise el diseño y el uso de las etiquetas
**Evalúe el impacto en el rendimiento:**
+ Compare **QueryRequestsTotal**el aumento de before/after cardinalidad de la tasa de éxito
+ Revise **MemoryUtilization**la correlación
+ Compruebe **CPUUtilization**los patrones
+ Analiza **QueryResponseVolume**las tendencias
**Identifique las fuentes de cardinalidad:**
Revise el modelo de datos:
+ ¿Qué cubos tienen el nivel más alto? SeriesCardinality
+ ¿Qué etiquetas tienen recuentos de valores únicos altos?
+ ¿Hay etiquetas innecesarias?
+ ¿Los valores de las etiquetas son ilimitados (UUIDs, marcas de tiempo, etc.)?
**Revise la configuración actual:**
Compruebe los parámetros de optimización:
+ storage-series-id-set-cache-size: ¿Valor actual?
+ influxql-max-select-series: ¿Está limitando las consultas descontroladas?
+ storage-max-index-log-file-size: ¿Apropiado para la cardinalidad?
**Pasos de resolución:**
Cambios de configuración inmediatos:
**Prioridad 1: optimizar el manejo de la serie**
+ storage-series-id-set-tamaño de la memoria caché: 1500-2000
+ storage-series-file-max-concurrent-snapshot-compactions: 6-8
+ storage-max-index-log-tamaño del archivo: 2.097.152 (2 MB)
**Prioridad 2: Establecer límites de protección**
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
+ concurrencia de consultas: se reduce si la memoria está limitada
**Prioridad 3: aumentar los recursos**
+ Escale al siguiente nivel de instancia
+ Aumente la asignación de memoria
+ Considere un nivel de almacenamiento de 12 000 IOPS
**Planificación de la migración (si la serie es superior a 10 M):**
+ **InfluxDB 3.0 ofrece un rendimiento superior de alta cardinalidad**
+ Planifique el cronograma de migración (de 2 a 3 meses)
+ Pruebe primero con un subconjunto de datos
+ Prepare la aplicación para la migración
+ InfluxDB 3.0 utiliza un almacenamiento en columnas optimizado para miles de millones de series
### Escenario: acumulación de colas de consultas
**Revise CloudWatch las métricas:**
+ **QueryRequestsTotal**con result=queue\$1error aumentando (se rechazan las consultas)
+ **APIRequestTarifa** con un estado = 429 o un estado = 503 (atiende muchas solicitudes) unavailable/too
+ **CPUUtilization**puede estar elevada (> 70%), lo que indica una saturación de recursos
+ **MemoryUtilization**puede ser alto (> 70%), lo que limita la capacidad de consulta
+ **QueryResponseVolume**muestran un tamaño de respuesta grande (las consultas consumen recursos excesivos)
**Pasos de investigación:**
**Analice las métricas de colas y simultaneidad:**
+ Revisa el **QueryRequestsTotal**desglose por tipo de resultado:
+ Un número elevado de errores de cola indica que se están rechazando las consultas
+ Compare la tasa de éxito con la línea base: ¿está disminuyendo?
+ Comprueba si el runtime\$1error aumenta (las consultas fallan después de empezar)
+ **Monitoree los patrones de velocidadAPIRequest:**
+ Busca Status=429 (demasiadas solicitudes) o Status=503 (servicio no disponible)
+ Identifique qué puntos finales están siendo rechazados
+ Compruebe las tendencias de las tasas de solicitudes a lo largo del tiempo
**Revise la utilización de los recursos:**
+ **CPUUtilization**durante los períodos de alta cola:
+ Si es superior al 70%, las consultas están vinculadas a la CPU y no se pueden ejecutar más rápido
+ Si es inferior al 50%, los límites de cola pueden ser demasiado restrictivos
+ **MemoryUtilization**correlación:
+ El exceso de memoria puede estar limitando la simultaneidad de las consultas
+ Compruebe **HeapMemoryUsage**y compruebe la presión **ActiveMemoryAllocation**de la memoria
+ IOpsPerSecPatrones **totales**:
+ Un nivel alto I/O puede estar ralentizando la ejecución de las consultas
+ Compruebe si las consultas están I/O enlazadas
**Identifique los patrones de consulta:**
+ Reseña **QueryResponseVolume**:
+ ¿Las consultas devuelven datos excesivos (> 1 MB)?
+ Identifique los puntos finales con mayores volúmenes de respuesta
+ Busque patrones en consultas costosas
+ Analiza **QueryRequestsTotal**la tasa:
+ ¿Cuál es la tasa de consultas por segundo?
+ ¿Hay patrones de ráfaga o una carga elevada sostenida?
+ Compárela con la capacidad de la instancia según la tabla de tamaños
+ Compruebe la **APIRequesttasa** por punto final:
+ ¿Qué puntos finales de consulta tienen el tráfico más alto?
+ ¿Hay consultas duplicadas o redundantes?
**Compruebe la disponibilidad de los recursos:**
+ Compara las métricas actuales con las recomendaciones de la tabla de tallas:
+ **SeriesCardinality**frente a la capacidad de la clase de instancia
+ Tasa de consultas en comparación con las consultas recomendadas por segundo
+ **CPUUtilization**y **MemoryUtilization**margen de maniobra
+ Verifique la capacidad de IOPS:
+ **El total IOps PerSec debe tener un** margen de maniobra del 30%
+ Compruebe si las consultas están esperando en la E/S del disco
**Pasos de resolución:**
Cambios de configuración:
**Prioridad 1: aumentar la capacidad de las colas**
+ query-queue-size: 4096 (desde 1024 por defecto)
**Prioridad 2: aumentar la simultaneidad (si los recursos lo permiten)**
+ concurrencia de consultas: aumente al 75% de v CPUs
+ Ejemplo: 16 vCPU → concurrencia de consultas = 12
+ Compruebe que las CPUUtilization estancias sean inferiores al 80% después del cambio
+ Verifica que las MemoryUtilization estancias sean inferiores al 80% después del cambio
**Prioridad 3: optimizar la ejecución de las consultas**
+ query-memory-bytes: Garantice una asignación adecuada
+ storage-series-id-set-tamaño de la caché: 1000-1500
+ http-read-timeout: 120 segundos (evita tiempos de espera prematuros)
**Prioridad 4: Establecer límites de protección**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
**Soluciones a nivel de aplicación:**
+ **Implemente el almacenamiento en caché de los resultados de las consultas (Redis, Memcached**)
+ Guarda en caché los resultados de las consultas que se ejecutan con frecuencia
+ Configure lo apropiado TTLs en función de los requisitos de actualización de los datos
+ Monitorizar la tasa de aciertos de caché
+ **Utilice consultas continuas** para agregar previamente los patrones comunes
+ Calcule previamente las agregaciones comunes
+ Consulte datos preagregados en lugar de datos sin procesar
+ **Añada paginación para conjuntos** de resultados de gran tamaño
+ Limite el tamaño inicial de la consulta
+ Cargue datos adicionales a pedido
+ **Implemente una limitación de la frecuencia de consultas** por usuario o panel
+ Evite que los usuarios individuales sobrecarguen el sistema
+ Establezca cuotas de uso justo
+ **Utilice datos de muestreo reducido** para consultas históricas
+ Consulte datos de menor resolución para intervalos de tiempo más antiguos
+ Reserve consultas de resolución completa para datos recientes
**Decisión de escalado:**
+ Si se CPUUtilization mantiene en más del 70%: escale a una instancia más grande
+ Si se mantiene MemoryUtilization en un nivel superior al 70%: escale a una instancia optimizada para la memoria
+ Si la tasa de consultas supera la capacidad de la instancia: escale al siguiente nivel según la tabla de tamaños