No puedes arreglar lo que no puedes ver. Kubernetes genera una cantidad enorme de señales; lo difícil es elegir cuáles importan.

Observabilidad tiene tres pilares:

Pilar	Pregunta	Herramientas
Métricas	“¿cuánto/qué?”	Prometheus, Grafana
Logs	“¿por qué?”	Loki, Elasticsearch
Traces	“¿dónde?”	OpenTelemetry, Jaeger

Sello del curso: probado en Kubernetes 1.35 con kube-prometheus-stack.

metrics-server: el kubectl top

El metrics-server recolecta CPU/memoria de los pods y nodos mediante la API de métricas. Es lo que alimenta kubectl top y el HPA por CPU/memoria.

kubectl top nodes
kubectl top pods -A --sort-by=memory | head

Si devuelve error: Metrics API not available, el metrics-server no está instalado o tiene un problema de TLS/RBAC.

Importante: metrics-server no es almacenamiento a largo plazo. Sirve métricas recientes para el HPA. Para histórico, Prometheus.

Prometheus: el estándar de facto

Prometheus hace scrape (extrae métricas) por HTTP en intervalos regulares, almacena en TSDB y permite consultas en PromQL.

Componentes comunes:

• Prometheus: recolecta y almacena.
• node-exporter: métricas del nodo (CPU, memoria, disco, red).
• kube-state-metrics: estado de los objetos (pods, deployments, PDB).
• Alertmanager: agrupa, silencia y enruta alertas.
• Grafana: visualización.

Instalación vía Helm (lab):

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm upgrade --install kps prometheus-community/kube-prometheus-stack \
  -n monitoring --create-namespace \
  --set grafana.adminPassword='troque-isto'

Valida:

kubectl -n monitoring get pods
kubectl -n monitoring get servicemonitors

Qué medir primero

No intentes medir todo. Empieza por lo que duele:

Señal	Ejemplo de métrica
Nodos saludables	up{job="node-exporter"}
Pods listos	kube_pod_status_ready
Reinicios	kube_pod_container_status_restarts_total
CPU/memoria	container_cpu_usage_seconds_total, container_memory_working_set_bytes
Disco	node_filesystem_avail_bytes
API server	apiserver_request_duration_seconds
Errores HTTP	http_server_requests_seconds_count{status=~"5.."}

Consultas útiles:

# nós down
up == 0

# pods que reiniciaram mais de 3 vezes na última hora
increase(kube_pod_container_status_restarts_total[1h]) > 3

# memória dos pods por namespace
sum by (namespace, pod) (container_memory_working_set_bytes{container!=""})

Grafana: dashboards que responden preguntas

Un buen dashboard responde:

• ¿El clúster está saludable?
• ¿Qué cambió en las últimas 24h?
• ¿Qué servicio está degradado?
• ¿Estamos dentro del SLO?

Evita dashboards de 200 paneles. Empieza con:

1. Visión general: nodos, pods, CPU, memoria, disco.
2. Namespace/aplicación: réplicas, reinicios, latencia, errores.
3. SLO: disponibilidad y presupuesto de error.

Alertas: qué debe despertarte

Una buena alerta es accionable. Ejemplos:

- alert: NodeDown
  expr: up{job="node-exporter"} == 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "Nó {{ $labels.instance }} down"

- alert: PodCrashLooping
  expr: increase(kube_pod_container_status_restarts_total[10m]) > 3
  for: 5m
  labels:
    severity: warning

Reglas:

• Toda alerta tiene runbook.
• for evita ruido.
• La severidad define el canal (crítico despierta; warning espera).
• Alertmanager agrupa y silencia durante el mantenimiento.

Logs y traces

• Logs: estructurados (JSON), con traceId/requestId, retención definida. Loki es una opción ligera.
• Traces: OpenTelemetry en la app, collector y backend (Jaeger/Tempo). Sin muestreo, el costo explota; empieza con 10%.

Errores comunes

Síntoma	Causa
kubectl top indisponible	metrics-server caído/TLS
Target down en Prometheus	ServiceMonitor/puerto/labels incorrectos
Dashboard vacío	datasource incorrecto o métrica renombrada
Prometheus sin disco	retención/TSDB sin PVC
Alertas en bucle	for demasiado corto o regla sin histéresis
Cardinalidad explotando	labels de alta cardinalidad (pod, request id)

Lista de verificación

• [ ] metrics-server funcionando (kubectl top).
• [ ] Prometheus con retención y PVC.
• [ ] node-exporter y kube-state-metrics.
• [ ] Dashboards de clúster y aplicación.
• [ ] Alertas con severidad y runbook.
• [ ] Logs estructurados con correlación.
• [ ] Tracing con muestreo definido.

Glosario

• scrape: recolección periódica de métricas.
• TSDB: base de datos de series temporales.
• PromQL: lenguaje de consulta.
• ServiceMonitor: CRD del Prometheus Operator.
• SLO: objetivo de nivel de servicio.
• cardinalidad: número de combinaciones de labels.

Siguiente

Ahora que ves el clúster, vamos a entender los operadores: qué hacen, cuándo usarlos y por qué cambian la forma de operar datos.

Siguiente: Curso Kubernetes 14 — Operadores: qué son y por qué usarlos