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í.
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 |
|
| MemoryUtilization | DbInstanceName | Porcentaje de memoria que se utiliza | Porcentaje |
|
| HeapMemoryUsage | DbInstanceName | Cantidad de memoria de pila en uso | Bytes |
|
| ActiveMemoryAllocation | DbInstanceName | Asignación de memoria activa actual | Bytes |
|
| DiskUtilization | DbInstanceName | Porcentaje de espacio en disco que se utiliza | Porcentaje |
|
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 aprovisionadas Ejemplo: 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 aprovisionadas Ejemplo: 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 aprovisionadas Controle 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:
|
| QueryResponseVolume | DbInstanceName, Punto final, estado | Volumen de respuestas a las consultas por punto final y código de estado | Bytes |
|
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_error, compile_error, queue_error) | Recuento |
Tasa de éxito: > 99% Tasas de error:
|
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 |
|
| TotalBuckets | DbInstanceName | Número total de cubos de la instancia | Recuento |
|
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 inesperados Alerta: 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 escritura Crí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 configurado Alerta: Consistentemente al máximo |
| TaskExecutionFailures | DbInstanceName | Número de ejecuciones de tareas fallidas | Recuento | Alerta: más del 1% de las ejecuciones de tareas Crí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 + 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 | ~50 000 | < 10 | db.influx.large | 3000 operaciones incluidas de E/S de Influx | Pequeños despliegues, desarrollo y pruebas |
| < 1 M | ~150 000 | < 25 | db.influx.2xlarge | 3000 operaciones incluidas de E/S de Influx | Cargas de trabajo de producción pequeñas a medianas |
| ~1 MILLÓN | ~200 000 | ~25 | db.influx.4xlarge | 3000 operaciones incluidas de E/S de Influx | Cargas de trabajo de producción medianas |
| < 5 M | ~250 000 | ~35 | db.influx.4xlarge | 12 000 operaciones incluidas de E/S de Influx | Grandes cargas de trabajo de producción |
| < 10 M | ~500 000 | ~50 | db.influx.8xlarge | 12 000 operaciones incluidas de E/S de Influx | Cargas de trabajo de producción muy grandes |
| ~ 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_error o runtime_error 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 QueryResponseVolumey QueryRequestsTotallas 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
HeapMemoryUsagecon una tendencia al alza
ActiveMemoryAllocationmostrando 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 QueryResponseVolumerespuesta ReadOpsPerSecaumenten 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_error 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:
QueryResponseVolumeRevíselas para identificar las consultas que devuelven datos excesivos
Se utiliza QueryRequestsTotalpara 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 SeriesCardinalityy 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%
WriteThroughputpatrones
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: debuggenera registros extremadamente detallados, potencialmente cientos de MB por horaflux-log-enabled: TRUEregistra cada ejecución de consultas de Flux con todos los detalles, creando enormes archivos de registroEstos 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:
Establecer
log-level: info(desde la depuración)Establezca
flux-log-enabled: FALSESupervise DiskUtilizationpara 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:
CPUUtilizationaumentará a medida que las operaciones de compactación consuman ciclos de CPU
MemoryUtilizationaumentará durante la compactación a medida que se carguen y procesen los datos
WriteOpsPerSecy WriteThroughputse disparará durante las ventanas de compactación, lo que podría superar el margen de IOPS del 30%
WriteTimeoutspuede 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:
Compruebe primero el registro (problema más común): compruebe que el nivel de registro es «informativo» y que sea FALSO flux-log-enabled
Revise su modelo de datos: ¿Está escribiendo datos que en realidad no necesita? ¿Puede reducir la granularidad de las mediciones o del campo?
Optimice las políticas de retención: compruebe TotalBucketsy revise la configuración de retención de cada segmento
Supervise el impacto de la compactación: CPUUtilizationevalúe MemoryUtilizationsus cambios y WriteOpsPerSecantes
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+ 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-compactionsralentizará las operaciones de compactación, lo que provocará que los archivos TSM se acumulen y DiskUtilizationaumenten más rápidamenteCuanto menor sea,
storage-compact-throughput-burstprolonga la duración de la compactación, lo que mantiene el compactador activo durante más tiempo y, potencialmente, bloquea otras operacionesUna 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 QueryRequestsTotalruntime_error 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-durationstorage-compact-full-write-cold-durationlos datos permanecen más tiempo en el registro de escritura anticipada (WAL)Esto aumenta a MemoryUtilizationmedida 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 WriteTimeoutsdurante los períodos de alto rendimientoEl aumento
storage-wal-max-write-delaysignifica 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:
SeriesCardinalitypor 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 HeapMemoryUsagey ActiveMemoryAllocationdespué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_error como valor QueryRequestsTotalsi 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 CPUUtilizationa WriteOpsPerSecmedida que el sistema realiza un mantenimiento del índice más frecuente.
Comprensión crítica:
Cuando SeriesCardinalitysupera los 5 millones, se acerca a los límites arquitectónicos de InfluxDB 2.x. En la serie 10M+, 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
QueryRequestsTotalLas tasas de runtime_error 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:
Analice su modelo de datos:
SeriesCardinalityReví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:
QueryRequestsTotalpor tipo de resultado (success, runtime_error, compile_error, queue_error)
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-concurrencyEl aumento permite que se ejecuten más consultas simultáneamente, pero cada consulta compite por la CPU y la memoria:
CPUUtilizationaumentará y podría llegar a saturarse durante los períodos de mayor cantidad de consultas
MemoryUtilizationaumentará 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:
HeapMemoryUsageaumentará
storage-cache-max-memory-sizepuede que sea necesario reducirlo para compensarUn menor número de visitas a la caché significa un rendimiento de consultas mayor ReadOpsPerSecy 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
QueryRequestsTotalLa 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:
Analice los patrones de consulta:
Revise QueryResponseVolumepara identificar las consultas que devuelven un exceso de datos (> 1 MB)
Comprueba los patrones de QueryRequestsTotalruntime_error: ¿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
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
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
Verificar la disponibilidad de los recursos:
CPUUtilizationComprué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:
Comience por optimizar las 10 consultas más caras (por QueryResponseVolume)
Implemente el almacenamiento en caché de los resultados de las consultas a nivel de aplicación
Aumente la asignación de recursos únicamente si las consultas están optimizadas y las métricas muestran un margen de maniobra
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 lacontains()función en lugar de RegEx patrones como/^exact_value$/Hacer coincidir varios valores específicos: utilice el
inoperador 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()funcionesstrings.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
QueryRequestsTotalcon result=runtime_error 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:
CPUUtilizationaumenta a medida que más subprocesos de escritura compiten por la CPU
MemoryUtilizationaumenta a medida que se almacenan más datos en la memoria antes de que WAL se vacíe
WriteOpsPerSecse 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, WriteTimeoutspuede 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 aumentarstorage-cache-snapshot-memory-size, se acumulan más datos en la memoria antes de vaciarlos:
MemoryUtilizationaumenta 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-durationRetrasa cada vez más las instantáneas:
Aumenta aún más a MemoryUtilizationmedida que los datos permanecen en la memoria caché durante más tiempo
Aumenta el margen de riesgo de pérdida de datos
Reduce la WriteOpsPerSecfrecuencia, 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:
Analice los patrones de escritura:
Revisión WriteThroughputy WriteOpsPerSectendencias
Compruebe WriteTimeoutsla 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
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
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 WriteOpsPerSecdurante 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
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:
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)
Implemente operaciones asíncronas y de almacenamiento en búfer de escritura
Compruebe que Total tenga el margen de maniobra adecuado IOps PerSec
Actualice al siguiente nivel de almacenamiento (3000 IOPS → 12 000 IOPS → 16 000 IOPS) si se utiliza constantemente por encima del 70%
Ajuste la configuración de WAL únicamente si las escrituras están optimizadas y la capacidad es adecuada I/O
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_error):
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_error y queue_error
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_error), 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_error (memoria insuficiente)
APIRequestVelocidad que muestra el estado = 500
Pasos de resolución:
Acciones inmediatas (si son críticas):
Reinicie la instancia para borrar la memoria (si es seguro hacerlo)
Reduzca temporalmente la simultaneidad de consultas
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
Escenario: Impacto de cardinalidad en series altas
Revise las CloudWatch métricas:
SeriesCardinality> 5 millones
MemoryUtilizationalto
QueryRequestsTotalmostrando un aumento de runtime_error
CPUUtilizationelevado 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 QueryRequestsTotalel aumento de before/after cardinalidad de la tasa de éxito
Revise MemoryUtilizationla correlación
Compruebe CPUUtilizationlos patrones
Analiza QueryResponseVolumelas 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:
QueryRequestsTotalcon result=queue_error aumentando (se rechazan las consultas)
APIRequestTarifa con un estado = 429 o un estado = 503 (atiende muchas solicitudes) unavailable/too
CPUUtilizationpuede estar elevada (> 70%), lo que indica una saturación de recursos
MemoryUtilizationpuede ser alto (> 70%), lo que limita la capacidad de consulta
QueryResponseVolumemuestran 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 QueryRequestsTotaldesglose 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_error 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:
CPUUtilizationdurante 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
MemoryUtilizationcorrelación:
El exceso de memoria puede estar limitando la simultaneidad de las consultas
Compruebe HeapMemoryUsagey compruebe la presión ActiveMemoryAllocationde 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 QueryRequestsTotalla 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:
SeriesCardinalityfrente a la capacidad de la clase de instancia
Tasa de consultas en comparación con las consultas recomendadas por segundo
CPUUtilizationy MemoryUtilizationmargen 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
