RED / USE
SLO / SLI
Prometheus
Series temporales: CPU, memoria, latencia, ratio de errores, colas. En K8s suele entrar metrics-server (HPA, kubectl top) y stacks tipo Prometheus + Grafana para dashboards y alertas.
Pregunta clave: ¿el nodo o el Pod se queda sin CPU/RAM? ¿subió la latencia p95 a la vez que un rollout?
stdout/stderr
agregación
Por convención, todo va a stdout/stderr; el runtime y el kubelet redirigen. Los agentes (DaemonSet o sidecar) envían líneas a Loki, OpenSearch, CloudWatch, etc. Correlaciona con timestamp y trace-id si existe.
Ojo: rotación y nivel de log en producción; un Pod en crash loop puede llenar disco si no hay límites en el nodo.
OpenTelemetry
W3C traceparent
Sigue una petición a través de microservicios. Requiere instrumentación (SDK OTel) y un backend (Tempo, Jaeger, X-Ray). En entornos service-mesh, el mesh puede inyectar trazas; sin eso, tú propagas cabeceras.
Útil cuando: métricas y logs se ven “bien” por servicio pero el usuario ve timeouts — la traza muestra el cuello de botella inter-servicio.
Flujo típico — del Pod al backend de observabilidad
PODS
Procesos exponen métricas (endpoint /metrics), escriben logs y (opcional) emiten spans OTel.
→
RECOLECCIÓN EN NODO
kubelet + cAdvisor exponen uso de contenedor. DaemonSets (node-exporter, Fluent Bit, OTel Collector) scrapean o leen logs del filesystem del contenedor.
→
BACKENDS
Prometheus, Thanos · Loki / ELK · Tempo / Jaeger. Alertmanager o reglas equivalentes para paging.
Métricas
ServiceMonitor/PodMonitor (operator), anotaciones scrape, HPA con metrics-server
Prometheus, Grafana, Datadog agent, CloudWatch Container Insights
“¿Está saturado o lento el workload?”
Logs
Logs por contenedor vía kubelet; labels pod, namespace, container
Loki, OpenSearch, Splunk, CloudWatch Logs
“¿Qué excepción o mensaje hubo justo antes del fallo?”
Trazas
Sidecars o SDK en app; mallas (Istio/Linkerd) pueden generar spans
Tempo, Jaeger, Zipkin, X-Ray
“¿En qué hop se fue el presupuesto de latencia?”
kubectl get pods -n prod -o wide
kubectl get events -n prod --sort-by=.lastTimestamp | tail -n 25
kubectl describe pod mi-app-7d4f9c6b5-xxxxx -n prod
kubectl logs -f deployment/mi-app -n prod --tail=200
kubectl logs mi-app-xxx -n prod -c sidecar --previous
kubectl top pods -n prod --sort-by=memory
kubectl top nodes
kubectl exec -it mi-app-xxx -n prod -- sh
kubectl debug mi-app-xxx -n prod -it --image=busybox --target=mi-app
HTTP / TCP / exec
Readiness: el Service no enruta tráfico hasta que pase — útil durante arranque o dependencias no listas. Liveness: si falla, kubelet mata y reinicia el contenedor; mal calibrada puede reiniciar en bucle mientras la app aún arranca. Startup (1.16+): da margen largo al boot antes de evaluar liveness.
Error típico: readiness igual que health “profundo” que llama a la DB — si la DB tarda, sacas todos los endpoints del balanceo.
describe
Last State
CrashLoopBackOff: el contenedor sale con código ≠ 0 — mira kubectl logs --previous. OOMKilled: límite de memoria bajo; sube limit o perfila fugas. ImagePullBackOff: tag incorrecto, credenciales del registry o rate limit. CreateContainerConfigError: Secret/ConfigMap montado que no existe o key mal nombrada.
Pending: a menudo scheduling (recursos, affinities, taints) o volumen aún no adjuntado — describe pod muestra el mensaje del scheduler o del attach de volumen.
🔗
Correlación antes que más dashboards
Une deployment.revision, hora del rollout, picos en métricas y primera línea de error en logs. Muchos incidentes son un despliegue + condición de carrera, no “misterio del cluster”.
⏱️
Los eventos caducan
kubectl get events solo muestra ventana reciente. Para post-mortem usa el historial del proveedor, logs del control plane (según permisos) o exportación a SIEM.
🧪
Staging con misma forma que prod
Mismos probes, mismos requests/limits de orden de magnitud y misma ruta de logs. Si solo en prod falla, compara variables de entorno, versión de imagen y políticas de red.