Monitoreo de infraestructura

Monitoreo de

1) Objetivos y marco

• Avisar de fallos antes que el usuario (detección temprana).
• Dar diagnóstico de causa de origen (de symptom a causa).
• Soporta lanzamientos de juego SLO y giros automáticos.
• Alimentar análisis post-incidente (evidence as data).

Principios básicos: Observable por diseño, menos ruido - más señales, automatización de reacciones, un único panel de verdad.

2) Tríada de la observabilidad

Métricas (timeseries): velocidad/demanda/errores/saturación (USE/RED).
Registros: detalle de eventos con contexto; no contienen secretos/PII.
Tracks: tratamientos distribuidos de causalidad.

• Perfiles (CPU/heap/lock/io), eBPF para el nivel del sistema.
• Eventos/auditorías (K8s Eventos, cambios en las configuraciones/secretos).

3) SLI/SLO/SLA - lenguaje de calidad

SLI (indicador): 'disponibilidad', 'error _ rate', 'p95 _ latency', 'queue _ lag'.
SLO (objetivo): "solicitudes exitosas ≥ 99. 9% en 30 días".
Error Budget: desviación válida; se utiliza para los lanzamientos auto-parada.

yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4) Mapa de capas de monitoreo

1. Hosts/VM/nodos: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Red/LB/DNS: RTT, paquetes/drops, backklog, SYN/Timeout, probes de salud.
3. Kubernetes/Orchestrator: servidor API, etcd, controladores, scheduler; pods/nodos, pending/evicted, throttling, kube-events.
4. Servicios/contenedores: RED (Rate/Errors/Duration), readiness/liveness.
5. Bases de datos/cachés: QPS, bloqueo wait, replication lag, buffer hit, slow queries.
6. Colas/buses: consumer lag, requeue/dead-letter, throughput.
7. Almacenamiento/nube: S3/Blob errores y latencia, 429/503 de los proveedores.
8. Límites perimetrales: WAF/Rate Limits, 4xx/5xx en rutas, CDN.
9. Sintética: comprobación HTTP de scripts (depósito/retiro), TLS/certificados.
10. Economía/capacidad: costo por servicio, utilidad, sala de estar.

5) Whitebox и Blackbox

Whitebox: exportadores/SDK dentro de los servicios (Prometheus, OpenTelemetry).
Blackbox: muestras externas de diferentes regiones (availability, latency, TLS expiry).
Combinar: «signo exterior» + «diagnóstico interior».

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernetes: señales clave

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Pods: Pending/CrashLoopBackOff, OOMKilled, restarts.
Planes/límites: Requests vs Limits, PodDisruptionBudget, HPA/VPA.
Red: NetworkPolicy drops, conntrack exhaustion.

Дашборды: «Cluster health», «Workload saturation», «Top erroring services».

7) DB y colas

PostgreSQL/MySQL: replication lag, deadlocks, slow query %, checkpoint I/O.
Redis/Memcached: hit ratio, evictions, rejected connections.
Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, disk usage.

8) Métricas de RED/USE y correlación de negocios

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USE (para recursos): Utilization, Saturation, Errors.
Vincule con el producto: los depósitos/pagos son un éxito, las banderas de Frod, la conversión son «guardas» en la liberación de Canarias.

9) Estructura de alerting

Tier-1 (page): incidentes que afectan a SLO (disponibilidad, 5xx, latencia, falla de componentes críticos de clúster).
Tier-2 (ticket): degradación de la capacidad, aumento de errores sin afectar el SLO.
Tier-3 (inform): tendencias, capacidad predictiva, certificados caducados.

Reglas de escalamiento: tiempo de silencio/compresión de duplicados, rotación on-call, «follow-the-sun».

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Ejemplos de reglas Prometheus

10. 1 Errores 5xx con umbral SLO

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10. 2 Quema de error-budget (burn multi-window)

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10. 3 Saturación del sistema (CPU Throttling)

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11) Registros: recolección, normalización, retiro

Estandarización: registros JSON: 'ts',' level ',' service ',' trace _ id ',' user/tenant '.
Pipeline: agente (Fluent Bit/Vector) → búfer → índice/almacenamiento.
Revisión: enmascarar PII/secretos en el borde.
Retiro: almacenamiento de clase rápida (7-14 días), archivo «frío» (30-180 días).
Semántica: error budgets/deprecates - canales separados.

12) Senderos y OpenTelemetry

Utilice puntos de entrada (gateway), llamadas kliyent→servis, DB/caché/colas.
Vincule las métricas a los atributos de trais (Exemplars) para una navegación rápida.
OTel Collector como puerta de enlace central: filtrado, muestreo, exportación a las becendas seleccionadas.

yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13) Sintética y comprobaciones externas

Huecos HTTP de los escenarios empresariales (inicio de sesión, depósito, retirada, compra).
TLS/Domain: duración de los certificados/CAA/DNS health.
Regionalidad: muestras de países clave/proveedores (enrutamiento/hojas de flujo).
La sintética debe alertarse si no está disponible para el usuario, incluso con telemetría interna verde.

14) Perfiles y eBPF

Perfil continuo: identificar funciones calientes, bloqueos.
eBPF: eventos del sistema (syscalls, retransmisiones TCP), en venta con un mínimo overhead.
Alertas de perfil sin estraticing (tickets), y para regresiones después de la liberación, como señal de retroceso.

15) Dashboards y «panel de la verdad»

1. Platform Overview: SLI/SLO por servicios clave, error-budget, alertas.

2. API RED: RPS/ERRORS/DURATION a lo largo de las rutas.

3. K8s Cluster: control-plane, узлы, capacity headroom.

4. DB/Cache: lag/locks/slow query %, hit ratio.

5. Queues: backlog/lag, fallidos/repetidos.

6. Per-release: comparación de métricas antes/después (ventanas canarias).

7. FinOps: cost per namespace/service, idle/oversized ресурсы.

16) Incidentes, ruido de alerta y escaladas

Deduplicación: agrupación por servicio/causa, supresión de cascadas.
Silencio/mantenimiento: los lanzamientos/migraciones no deben «pintar» todo en rojo.
Runbooks: cada alerta crítica con pasos de diagnóstico y un «botón» de retroceso.
Postmortem: línea de tiempo, qué aprendieron, qué señales agregaron/limpiaron.

17) Seguridad en el monitoreo

RBAC para leer/editar reglas/datasors.
Secretos: tokens exportadores/agentes - a través de Secret Manager.
Aislamiento: métricas de clientes/tenantes - en espacios/leibs separados.
Integridad: la firma de agentes/builds, las confecciones a través de GitOps (merge-ruge).

18) Finanzas y capacidad (FinOps)

Cuotas y presupuestos; alertas para un crecimiento anormal.
Right-sizing: análisis de consultas/límites, eliminación de CPU/RAM, spot-instance para tareas no críticas.
«Coste per request/tenant» como KPI de eficiencia.

19) Anti-patrones

Sólo métricas de infraestructura sin SLIs personalizados.
100 + alertas «sobre todo» → ceguera on-call.
Los logs como única fuente (sin métricas ni treysing).
Dashboards mutables sin versionar/rugir.
Falta de sintética: «todo es verde», pero el frente no está disponible.
No hay ligamento con los lanzamientos: no se puede responder «qué cambió en el momento X».

20) Lista de verificación de implementación (0-60 días)

0-15 días

Identificar SLI/SLO para 3-5 servicios clave.
Habilitar exportadores/agentes básicos, estandarizar registros JSON.
Configurar alertas Tier-1 (availabilidad, 5xx, p95).

16-30 días

Agregue sintética en escenarios críticos.
Habilitar los tracks (OTel) en los servicios de entrada/crítica.
Los dashboards «Per-release» y error-budget burn-rules.

31-60 días

Cubrir el BD/colas/caché con señales avanzadas.
Implementar eBPF/perfilado para servicios de alta CPU.
GitOps para reglas/dashboards/alertas, limpieza regular del ruido.

21) Métricas de madurez

Cobertura SLO de servicios clave ≥ 95%.
MTTA/MTTR (objetivo: min/docenas de minutos).
Proporción de alertas Tier-1 cerradas por acción automática o por eliminación rápida.
Relación de alertas «útiles «/» ruidosas »> 3:1.
Cobertura sintética de todas las rutas «monetarias» = 100%.

22) Aplicaciones: mini plantillas

Prometheus - Disponibilidad por clase de estado

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana - Consejos para canarios

expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m])) by (le,version))

Alertmanager - Servicio y silencio

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) Conclusión

El monitoreo no es un conjunto de gráficos, sino un sistema operativo SRE: SLI/SLO como contrato de calidad, métricas/tracks/logs como fuentes de verdad, alertas como señal controlada, sintética como «voz de usuario», GitOps como disciplina de cambio. Construya un único bucle desde el host hasta la API, enlazarlo en lanzamientos y revisiones, y la plataforma será predecible, rápida y económica.