Operaciones y gestión de → de Alerta sobre capacidad de sistemas

Alertas de capacidad de sistemas

1) Por qué es necesario

Las alertas capacitivas advierten de una aproximación a los límites técnicos mucho antes del incidente: «estamos al 80% del techo... es hora de escalar». Para los negocios de productos, esto es directamente sobre el dinero: apuestas perdidas/depósitos, drops de sesiones, retrasos en los juegos en vivo y fallos de proveedores = ingresos perdidos, reputación, multas y retrocesos.

• Previsiblemente para soportar las cargas máximas (eventos, torneos, streams, grandes campañas).
• Incluya auto-skaling a tiempo y planifique capacity uplift.
• Reducir el ruido y despertar «en el caso» cuando los SLO/dinero están en riesgo.
• Dar a los ingenieros recomendaciones precisas a través del runbook.

2) Conceptos básicos

Capacidad (Capacity): ancho de banda máximo sostenible (RPS/TPS, connects, IOPS, throughput).
Headroom: stock entre la carga actual y los límites.
SLO/SLA: niveles de disponibilidad/tiempo de respuesta objetivo; las alertas deben ser «SLO-aware».
Burn-rate: tasa de «quema» de SLO-presupuesto de error/latencia.
High/Low Watermark: niveles superiores/inferiores para activaciones y recuperación automática.

3) Arquitectura de señales y fuentes de datos

Teleemetría: métricas (Prometheus/OTel), registros (ELK/ClickHouse), rastreos (OTel/Jaeger).
Enfoque por capas: alertas por capas (Edge → API → servicios empresariales → cola/stream → DB/caché → almacenamiento de archivos/objetos → proveedores externos).
Contexto: fichflags, lanzamientos, campañas de marketing, torneos, alineación geo.
Bus de incidente: Alertmanager/PagerDuty/Opsgenie/Slack; enlazando con el runbook y la matriz de escalamiento.

4) Métricas clave por capas (qué monitorear y por qué)

Edge / L7

RPS, 95-/99-percentil latency, error rate (5xx/4xx), conexiones abiertas.
Rate-limits/quotas, drops на CDN/WAF/Firewall.

API-шлюз / Backend-for-Frontend

Saturación por workers/work pool, cola de consultas, timeouts a downstrim.
Proporción de degradación (fallbacks, circuit-breakers).

Colas/streaming (Kafka/Rabbit/Pulsar)

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (para Kafka), retrai/abuelo leiter.

Workers asincrónicos

Tiempo de espera de las tareas, longitud de la cola, porcentaje de tareas SLA caducadas.
Saturation CPU/Memory/FD en las agrupaciones.

Caché (Redis/Memcached)

Hit ratio, latency, evictions, used memory, clientes conectados/ops/s.
Clústeres: ranuras/réplicas, eventos falleros.

БД (PostgreSQL/MySQL/ClickHouse)

Active connections vs max, lock waits, replication lag, buffer/cache hit.
IOPS, read/write latency, checkpoint/flush, bloat/fragmentation.

Almacenamiento de objetos/archivos

PUT/GET latency, 4xx/5xx, egresos, consultas/sec, límites de proveedor.

Proveedores externos (pagos/CUS/proveedores de juegos)

Límites TPS, ventanas QPS, error rate/timeout, cola de retrés, «costo por llamada».

Infraestructura

CPU/Memory/FD/IOPS/Network saturation on nodos/pods/ASG.
Eventos HPA/VPA, pods pending, contenedores OOM/Throttling.

5) Tipos de alertas capacitivas

1. Umbrales estáticos

Simple y claro: 'db _ connections> 80% max'. Bueno como «señal de baliza».

2. Umbrales adaptativos (dinámicos)

Se basan en la estacionalidad y la tendencia (windows rolling, descomposición STL). Permiten la captura «inusualmente alta para esta hora/día de la semana».

3. Orientado a SLO (burn-rate)

Se activan cuando la velocidad de alimentación del error-budget pone a SLO en el horizonte de las horas X.

4. Predictivo (forecast-alerts)

«En 20 minutos, con la tendencia actual, la cola alcanzará el 90%». Utilizan un pronóstico lineal/Robust/Prophet-similar en ventanas cortas.

5. Compuesto (multi-signal)

Se desencadenan con la combinación: 'queue _ lag ↑' + 'consumer _ cpu 85%' + 'autoscaling at max' → «se necesita intervención manual».

6) Políticas de umbral y anti-ruido

• Arriba: aviso 70-75%, rollo 85-90%. Abajo: histéresis 5-10 p.p. Para no «pelar por el umbral».

• 'for: 5m' para los cretenses, 'for: 10-15m' para las advertencias. Modo noche: enrutar lo no crítico en el chat sin paginación.

• Agrupar por servicio/clúster/geo para no dar como resultado tarjetas de incidentes.

• Si el proveedor KYC está fuera y el error API es una consecuencia es la pagina del propietario de la integración, no de todos los consumidores.

• Durante el periodo bursátil, elevar los umbrales de ruido para el «crecimiento esperado», pero dejar las alertas de SLO intactas.

7) Ejemplos de reglas (pseudo-Prometheus)

ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) Enfoque de SLO y prioridad empresarial

De la señal a la exposición empresarial: las alertas de capacidad deben referirse a risk to SLO (juegos específicos/geo/métricas GGR, conversión de depósito).
Multinivel: advertencias para el servicio on-call; Page de creta del propietario del dominio; La caída de SLO es un incidente mayor y un canal «consolidado» de mando.
Fichflags de degradación: reducción automática de la carga (solo lectura parcial, corte de fijas pesadas, reducción de la frecuencia de jackpot broadcasts, apagado de animaciones «pesadas» en juegos en vivo).

9) Auto-Skaling y los disparadores «correctos»

HPA/VPA: objetivo no solo de CPU/Memory, sino también de métricas de negocio (RPS, queue lag, p99 latency).
Tiempos de espera: tenga en cuenta el inicio frío y los límites del proveedor (ASG spin-up, builders de contenedores, caché de calentamiento).
Guardrails: condiciones de parada en el crecimiento de errores en forma de avalancha; protección contra el «problema de patinaje».
Capacity-playbooks: dónde y cómo agregar shard/lote/réplica, cómo redistribuir el tráfico por regiones.

10) Proceso: desde el diseño hasta la operación

1. Mapeo de límites: recopilar los límites «verdaderos» de bottleneck para cada capa (max conns, IOPS, TPS, quotas proveedores).
2. Selección de métricas predictoras: qué señales antes indican «reprobemos en N minutos».
3. El diseño de los umbrales: alto/bajo + SLO-burn + compuesto.
4. Runbook por cada rollo: pasos de diagnóstico («qué abrir», «qué comandos», «dónde escalar»), tres opciones de acción: bypass rápido, zoom, degradación.
5. Pruebas: simulaciones de carga (días de chaos/game), alertas de «arranque seco», comprobación anti-ruido.
6. Rugir y adopción: propietario de la señal = propietario del servicio. Sin dueño, no hay pagina.
7. Retrospectivas y afinación: análisis semanal de falsos/omitidos; métricas «MTTA (ack), MTTD, MTTR, Noise/Signal ratio».

11) Anti-patrones

CPU> 90% ⇒ pánico: sin correlación con latency/queues puede ser normal.
«Un umbral para todos»: diferentes regiones/zonas de tiempo - diferentes perfiles de tráfico.
Alerta sin runbook: page sin acción clara drena on-call.
Ceguera a los proveedores: las cuotas/límites externos a menudo son los primeros en «romper» escenarios (PSP, KYC, antifraude, proveedores de juegos).
No hay histéresis: «aserrado» en la frontera 80 %/79%.

12) Características de iGaming/Finplatform

Los picos en el horario son: prime time, finales de torneos, partidos importantes; mejorar las réplicas de destino de antemano y llenar las cachés.
Streams en vivo y jackpots: ráfagas de eventos de difusión → límites en corredores/sitios web.
Pagos y KYC: ventanas de proveedores, puntuación antifraude; mantener las rutas de repuesto y el «modo grace» de los depósitos.
Geo-balance: proveedores locales - llevar el tráfico a la región vecina, donde hay una sala de cabecera.
Responsabilidad: con riesgo de pérdida de apuestas/botes - page instantáneo al equipo de dominio + alerta empresarial.

13) Dashboards (conjunto mínimo)

Capacity Overview: headroom por capas, top 3 sitios de riesgo, burn-rate SLO.
Stream & Queues: lag, backlog growth, consumer saturation, HPA state.
DB & Cache: connects, repl-lag, p95/p99 latency, hit ratio, evictions.
Proveedores: TPS/ventanas/cuotas, timeouts/errors, costo de llamadas.
Release/Feature context: lanzamientos/fichflags junto a las curvas.

14) Lista de verificación de implementación

• Lista de «verdaderos» límites y propietarios.
• Mapa de métricas predictoras + relaciones entre capas.
• Umbrales estáticos + histéresis.
• SLO-burn-alertas en rutas críticas (depósito, apuesta, lanzamiento de juegos en vivo).
• Alertas predictivas en cola/streams/connects.
• Suppression/mantenimiento de ventana; anti-ruido de la política.
• Runbook 'y con equipos, gráficos, fichflags de degradación.
• Análisis semanal de falsos positivos y afinación.
• Contabilidad de campañas de marketing y calendario de eventos.

15) Plantilla de ejemplo runbook (abreviado)

Señal: 'StreamBacklogAtRisk'

Objetivo: Evitar que aumente el log> 10 millones y retrasos en los tratamientos> 5 min.

1. Comprobar 'hpa _ desired/max', throttle/oom en las podas.

2. Ver 'rate (lag)', distribución por lotes (skew).

3. Comprobar el corredor (ISR, under-replicated, network).

• Aumentar consumer-replicas en + N, elevar max-in-flight.
• Incluir un grupo prioritario en «topics críticos».
• Reducir temporalmente la frecuencia de los tratamientos secundarios/enrichment.
• Si 'ASG at max' es solicitar una uplift temporal a la nube; paralelamente - habilitar la degradación de las funciones pesadas.
• Retroceso: volver al perfil de «tráfico normal» después de 'lag <1 millón' 15 minutos.
• Escalada: propietario del clúster Kafka, luego plataforma SRE.

16) KPI y calidad de señal

Coverage:% de rutas críticas cerradas por alertas capacitivas.
Noise/Signal: no más de 1 pagina falsa por llamada on-call/semana.
MTTD/MTTR: se detectan incidentes capacitivos ≤5 minutos antes de los ataques SLO.
Saves proactivas: cole-in incidentes prevenidos (por post mortem).

17) Inicio rápido (impagos conservadores)

DB: advertencia del 75% de los connects/IOPS/lat; rollo 85%, histéresis 8-10 p.p.
Caché: 'hit <0. 9 'Y' evictions> 0 '> 5 min - advertencia;' used _ amb> 85% '- rollo.
Las colas son: 'lag' crecimiento> 3 σ del promedio por 30d + 'hpa at max' - rollo.
API: `p99 > SLO1. 3 '10 min - advertencia;' burn-rate> 4 '15 min - rollo.
Proveedores: 'throughput> 90% de cuota' - advertencia; 'timeouts> 5%' - rollo.

18) FAQ

P: ¿Por qué no alertar simplemente «CPU> 80%»?
R: Sin contexto latency/colas es ruido. La CPU en sí misma no es igual al riesgo.

P: ¿Se necesitan umbrales adaptativos?
R: Sí, por estacionalidad diaria/semanal - reducir los falsos positivos.

P: ¿Cómo considerar el marketing/eventos?
R: Calendario de campañas → anotaciones en gráficos + ajuste temporal anti-ruido, pero SLO-alertas no tocar.