Monitoreo de aptime y heartbeat

1) Por qué es necesario

Detección temprana de downtime en el perímetro y en el interior (edge ↔ core).
Confirmación de la disponibilidad del usuario (y no solo «si las podas están vivas»).
Informes contractuales sobre SLA/SLO y obligaciones legales.
Control de los procesos de fondo (cron, ETL, azul de pago) a través de heartbeat.

Metodologías: Señales de oro (latency/traffic/errors/saturation), RED, enlace a SLO y presupuesto erróneo.

2) Tipos de comprobaciones (synthetics)

ICMP: red básica/disponibilidad IP.
TCP: puerto vivo/handshake (por ejemplo, 443/5432).
TLS: validez/término/cadena de certificados.
HTTP (S): código de respuesta, latencia, encabezados, subcadenas clave en el cuerpo.
DNS: resolve, TTL, NXDOMAIN/SERVFAIL.
Navegador principal (ruta de usuario): login → acción → logout.
Probes personalizados: autorización de pago en sandbox PSP, sintética de negocio interna (simulación de depósito).

Consejos: echa un vistazo tanto al edge como a los endpoints privados (desde dentro del VPC/K8s) son dominios de riesgo diferentes.

3) Arquitectura de monitoreo de aptime

Agentes de prueba por región (mínimo de 3 puntos geográficos).
Exportador de blackbox para HTTP/TCP/TLS/DNS.
Sintética por caminos (pasos sequentiales) por separado; guarde los scripts.
Prometheus/Mimir/Thanos: recogida de métricas, regla SLO/alertas.
Alertmanager/Pager: enrutamiento de P1/P2, escalamiento.
Status Page: actualizaciones transparentes para empresas/clientes.
Logs/tracks: drilldown por 'trace _ id '/correlación.

4) Endpoints de salud: diseño

/ healthz (liveness) - «si el proceso está vivo».
/ readyz (readiness) - «listo para recibir tráfico» (dependencias con umbrales).
/ startupz - «ha pasado la inicialización».
/ check - Salud de negocio avanzada (comprobaciones fáciles de BD/caché con temporizadores y circuit-breaker).
Salud Semántica: código 200 sólo cuando las dependencias críticas están activas; degradación → 503.

Reglas: tiempo de espera ≤ 2-3c, bajo control limitado, sin PII en las respuestas, almacenamiento en caché de piezas pesadas.

5) Heartbeat para job y workers

El modelo Dead Man's Switch: si el «tic» no llegó a tiempo es una alerta.
Uso: cron/ETL/facture-jobs, cheques de pago fuera de cadena, workers de fondo.

• Push-heartbeat HTTP: joba cuando se completa hace 'POST/heartbeat/< job>'.
• Metrics-pull: exponga 'last _ success _ timestamp' y alerte por 'más de N minutos'.
• Watchdog: señal constante del agente; Falta una alerta de «acantilado de vigilancia».

6) Ejemplos de configuraciones

6. 1 Blackbox-exporter (HTTP + TLS + DNS)

yaml modules:
http_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"
fail_if_not_ssl: true valid_http_versions: ["HTTP/1. 1","HTTP/2"]
tls_config:
insecure_skip_verify: false headers:
User-Agent: "uptime-probe"
body: ""
ip_protocol_fallback: false

tls_cert:
prober: tcp tcp:
query_response: []
tls: true tls_config:
insecure_skip_verify: false

dns:
prober: dns dns:
query_name: "api. example. com"
valid_rcodes: ["NOERROR"]
preferred_ip_protocol: "ip4"

6. 2 Prometheus: targets y jobs

yaml scrape_configs:
- job_name: 'blackbox-http'
metrics_path: /probe params:
module: [http_2xx]
static_configs:
- targets:
- https://api. example. com/healthz
- https://pay. example. com/readyz relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- target_label: __address__
replacement: blackbox-exporter:9115
- source_labels: [__param_target]
target_label: instance

6. 3 métricas de Heartbeat para joba (Prometheus exporter)

job_last_success_timestamp_seconds{job="settlement"} 1. 730000e+09

promql
(time() - job_last_success_timestamp_seconds{job="settlement"}) > 900

6. 4 Watchdog (Dead Man’s Switch)

En Alertmanager, habilita la ruta para la alerta 'Watchdog' (siempre firing) → si no llega la alerta - el monitoreo está roto.

7) Ejemplos de PromQL para aptime

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0. 95, sum by (le, instance) (rate(probe_http_duration_seconds_bucket[5m])))

promql
(min_over_time(probe_ssl_earliest_cert_expiry[5m]) - time()) < 7243600

promql rate(probe_dns_rcode{rcode!="NOERROR"}[5m]) > 0

promql sum_over_time((probe_success==1)[28d]) / (28246060)

8) Alerting: umbrales y anti-ruido

Multi-región quorum: se dispara si ≥2 regiones ven una caída.
Multi-ventana: 1-5 min (canal rápido) + 30-60 min (tendencia constante).
Sensibilidad: debounce/for: 2-5 minutos contra flapping.
Correlación: asocie la alerta de aptime con métricas de leyer (edge, DNS, WAF, origin).
Mantenimiento de Windows: suprimir alertas en las etiquetas 'mantenimiento = verdadero'.

promql
≥2 regions simultaneously failed sum by (target) (max_over_time (probe _ success = = 0) [3m]))> = 2

9) Muchos controles-regionales y muchos-vendedores

Mínimo de 3 geografías (EU/NA/APAC) y diferentes ASN.
Duplique: sus propias muestras + proveedor de aptime externo.
IPv4/IPv6, HTTP/2/3, diferentes perfiles ROR CDN y WAF.

10) Inspecciones de seguridad

Allowlist IP rangos de muestra en WAF/LB.
Rate-limits y capcha-baipás para endpoints health/muestreos.
Title Signature (HMAC) para la salud privada.
Dominios separados: muestras públicas y privadas (/internal/health).
No devuelva versiones/confecciones internas a/healthz; sólo los estados.

11) SLO e informes de aptime

SLI Disponibilidad: proporción de muestras HTTP de 2xx/3xx exitosas.
SLO ejemplo: ≥ 99. 95% en 28 días para la mayoría de las regiones.
Presupuesto erróneo: '1 − SLO' → administra las versiones.
Alertas Burn-rate: canal rápido/lento para la proporción de fallas de muestras.

12) Heartbeat para pagos y job crítico

Jobs «alrededor del dinero» (transferencias, registros) - doble control: heartbeat + contadores de negocios (cuántas entradas se procesan).
Alertas por «silencio» (no hay novedades> N minutos) y por laguna (rezago del tiempo real).

13) Estado de la página

Separe los componentes (API, pagos, respaldo, CDN).
Apdates automáticos de alertas, comentarios manuales a través del rol Comms.
Historial de incidentes, enlaces post mortem, obras programadas.

14) Integración con el proceso de incidente

Alerta SEV según reglas de quorum + duración.
Auto-creación de la tarjeta de incidente, war-room, asignación IC.
Plantillas de comunicación (interna/externa), Legal Hold si es necesario.
Post-verificación: sintética verde ≥ X minutos a «Resolved».

15) Rendimiento y costo

Frecuencia de muestreo: crítico - cada 30-60s; secundarias - 1-5 minutos.
Almacenamiento: downsampling/recording rules para ventanas largas.
Presupuesto de proveedores externos: limite las secuencias de comandos avanzadas del navegador según lo programado.

16) Check-list de calidad

• Hay/healthz ,/readyz ,/startupz con una semántica clara.
• Muestras de ≥3 regiones/ASN, IPv4/IPv6.
• Comprobaciones TLS/DNS y alertas de T-30/T-7/T-1 días.
• Heartbeat de todos los job críticos (y business - «silencio»).
• Multi-window + quorum, sin flapping.
• Drilldown: botones a logs/pistas/dashboards.
• Status page y plantillas de comunicación.
• Documentación de SLO/métricas y propietarios.

17) Plan de implementación (3 iteraciones)

1. Semana 1: muestras de blackbox HTTP/TLS/DNS por dominios críticos, página de estado, alertas básicas.
2. Semana 2: mucha-regionalidad, reglas de quorum, heartbeat top job, Watchdog.
3. Semana 3: scripts sin cabeza (login/deposite), reporting SLO, integración con el proceso de incidente.

18) Mini preguntas frecuentes

¿Cuáles son las muestras externas mejores que las internas?
Los externos ven la ruta real del usuario (DNS/CDN/WAF), los internos el estado de origen. Necesitamos a ambos.

¿Es necesario revisar los PSP pagados?
Sí: sintética en sandbox y monitoreo de páginas de estado; cuando se degradan: enrutamiento inteligente automático.

¿Cómo puedo reducir el ruido?
Quorum, multi-window, for-late, suppression on maintenance, nítidos umbrales SLO y propiedad.

El monitoreo de Aptime no es solo ping. Es un sistema: sintéticos multi-regionales + endpoints de salud de calidad + heartbeat job + SLO/alerting + status page. Estandarice las inspecciones, reduzca el ruido, proteja las muestras y asocie todo al proceso de incidentes, por lo que reducirá el MTTR y mantendrá un presupuesto erróneo.