Los equipos de operaciones de Kubernetes necesitan algo más que paneles que muestren el consumo de CPU y memoria y las tasas de error. La complejidad de los entornos nativos de la nube hace que una sola solicitud pase por una puerta de entrada, servicios, colas, almacenamiento y procesos en segundo plano, mientras las cargas de trabajo se desplazan y las versiones cambian continuamente. Por ello, un despliegue puede parecer saludable a nivel de Deployment, mientras una dependencia posterior, un bucle de reintentos o la presión sobre una ruta en el plano de control provocan un aumento de la latencia.
En un material publicado en el blog de la CNCF, Neel Shah, de Stackgen, explica que la monitorización tradicional responde a preguntas predefinidas, como: ¿ha superado el uso de CPU un umbral determinado? ¿Están aumentando los errores? En cambio, la observabilidad, según el planteamiento del material, busca ayudar al equipo a investigar un problema que no esperaba y pasar de observar el síntoma a comprender la causa y el alcance.
Las métricas abren la investigación, pero no la terminan
Las métricas siguen siendo el punto de partida natural porque son numéricas, eficientes para almacenar y consultar, y adecuadas para las alertas y el análisis de tendencias. En Kubernetes pueden mostrar la presión sobre los nodos, los reinicios de los contenedores, el aumento de la latencia de las solicitudes, la ralentización del servidor API o la acumulación de elementos en las colas.
El material propone aprovechar los patrones RED para los servicios —tasa de solicitudes, errores y duración— y el patrón USE para la infraestructura —uso, saturación y errores—. Estos indicadores ayudan a trazar la imagen inicial del incidente: un aumento de la tasa de solicitudes con una latencia estable es diferente de un aumento de la duración y la saturación con un tráfico constante.
Sin embargo, convertir cada detalle en una etiqueta dentro de la métrica crea un problema de cardinalidad, ya que el gran número de combinaciones únicas aumenta los costes y ralentiza las consultas. El material advierte específicamente contra incluir identificadores de solicitudes o usuarios, o valores casi únicos, en las métricas; estos detalles son más adecuados para los registros o las trazas.
Cada señal responde a una pregunta diferente
Los registros añaden el contexto local que los gráficos normalmente no conservan. Cuando están estructurados y utilizan campos coherentes como la hora, el nivel de gravedad, el nombre del servicio, el ámbito, la identidad del contenedor, la ruta de la solicitud y el contexto de trazabilidad, resulta más fácil vincular un evento concreto con el servicio o proceso que lo produjo. La métrica puede indicar que el servicio de pagos está afectado, mientras que el registro revela un tiempo de espera agotado, una excepción o un fallo en una dependencia.
Por su parte, las trazas distribuidas responden a una pregunta diferente: ¿cómo se desplazó una sola solicitud por el sistema y dónde se consumió el tiempo? Su importancia destaca en Kubernetes porque la falla puede estar distribuida entre varios servicios, reintentos, límites de las colas o llamadas a la base de datos. La propagación del contexto de trazabilidad permite vincular los distintos segmentos dentro del contexto de una sola solicitud, mientras que los estándares semánticos comunes ayudan a unificar los nombres de los campos y atributos entre las métricas, los registros y las trazas.
El material también incorpora el perfilado en la imagen. Después de que las métricas identifiquen el servicio lento, la trazabilidad determine la ruta de la solicitud afectada y los registros aclaren el evento local, los datos de profiling pueden ayudar a identificar la función o la ruta de código que consume CPU o memoria.
¿Qué cambia en la práctica durante el incidente?
El material presenta el ejemplo de un servicio de checkout que, después de un nuevo despliegue, comienza a superar el objetivo de latencia, mientras los indicadores de CPU y memoria permanecen normales. Las métricas revelan la existencia del problema; después, una traza de una solicitud lenta muestra que la mayor parte del retraso se produce en el paso de autorización del pago. A continuación, los registros muestran mensajes de tiempo de espera repetidos vinculados al mismo contexto de solicitud.
Esta secuencia lleva al equipo de una pregunta general —por qué se ha vuelto lento el servicio de pagos— a opciones operativas más concretas, como revertir un cambio en una dependencia, reducir la amplificación de los reintentos o desviar temporalmente el tráfico durante la investigación. El material también confirma que la mejor alerta es la que refleja un riesgo para la calidad del servicio o para su objetivo de fiabilidad, no una mera señal bruta de presión sobre los recursos de la infraestructura; ofrece como ejemplo una alerta vinculada a un aumento del valor p99 de la latencia por encima de un segundo durante diez minutos.
Reglas de diseño aplicables
- Comenzar con las métricas y los registros disponibles y ampliar gradualmente la cobertura, en lugar de recopilarlo todo sin un objetivo.
- Preferir las dimensiones relacionadas con el servicio y la carga de trabajo frente a las etiquetas de alta unicidad dentro de las métricas.
- Utilizar una estructura coherente de metadatos entre las métricas, los registros y las trazas.
- Añadir identificadores de solicitud o de trazabilidad a los registros para facilitar el tránsito entre las señales.
- Construir las alertas en torno a los riesgos de fiabilidad y la calidad del servicio, y no únicamente en torno a la presión de los recursos.
- Considerar la observabilidad como parte del diseño de la aplicación y la plataforma, no como un añadido posterior al despliegue.
Lectura editorial de certi.news: el valor fundamental aquí no es recomendar la compra de una herramienta ni adoptar una única implementación, sino redefinir el objetivo de la observabilidad. Lo que realmente cambia es la forma de utilizar los datos: la métrica captura la desviación, la trazabilidad determina el recorrido, el registro explica el evento y el perfilado puede identificar la causa a nivel del código. Siguen existiendo limitaciones prácticas claras: recopilar más señales no garantiza una mejor comprensión, y la ausencia de nombres y campos unificados puede hacer frágil la correlación, mientras que los detalles únicos pueden elevar el coste de las métricas y perjudicar el rendimiento de las consultas. Por ello, el beneficio depende de la calidad del diseño y de la vinculación entre las señales, no del número de paneles.