Respuesta.

La organización de la supervisión y el registro en arquitecturas de TI distribuidas es clave para asegurar la resiliencia, identificar y analizar errores, así como evaluar el rendimiento de los servicios. Es importante implementar un registro centralizado y un sistema de métricas para todos los servicios, para obtener una imagen completa de lo que está sucediendo en el sistema.

Pasos generales:

1. Registro centralizado — todos los servicios escriben registros en un sistema único (por ejemplo, ELK stack: Elasticsearch, Logstash, Kibana, o Grafana Loki).
2. Trazado de solicitudes — uso de sistemas de trazado distribuido (por ejemplo, Jaeger, Zipkin) para rastrear el “camino” de la solicitud entre los servicios.
3. Supervisión y alerta — uso de Prometheus, Grafana para la recopilación y visualización de métricas y configuración de alertas.

Ejemplo de configuración de registro en Python:

import logging
from pythonjsonlogger import jsonlogger

logger = logging.getLogger()
logHandler = logging.StreamHandler()
formatter = jsonlogger.JsonFormatter()
logHandler.setFormatter(formatter)
logger.addHandler(logHandler)
logger.setLevel(logging.INFO)

logger.info('Servicio iniciado', extra={'service': 'orders', 'env': 'prod'})

Características clave:

• Permite obtener una única ventana de transparencia para toda la infraestructura.
• Simplifica la búsqueda y el análisis de incidentes en un entorno múltiple.
• Permite una rápida reacción ante degradaciones o fallos de componentes.

Preguntas trampa.

¿Siempre se debe registrar todas las acciones del servicio a nivel INFO?

Respuesta: No, ya que esto puede llevar rápidamente a un aumento en el volumen de registros, disminuir el rendimiento y complicar la búsqueda de errores reales. Es mejor seguir la semántica de los niveles de registro (DEBUG para depuración, ERROR para problemas críticos, INFO para eventos importantes).

---

¿Se pueden recopilar métricas solo a nivel de infraestructura (CPU, RAM) e ignorar métricas a nivel de aplicación?

Respuesta: No. Las métricas a nivel de aplicación (por ejemplo, tiempo de respuesta, número de errores) son críticas para la analítica empresarial y la respuesta operativa, ayudan a ver los “cuellos de botella” específicamente en la lógica de los servicios, y no solo en el “hardware”.

---

¿En un sistema distribuido es suficiente con el trazado estándar de solicitudes HTTP a través del servidor web?

Respuesta: Incorrecto. Para escenarios complejos que abarcan cadenas de servicios, se necesita un trazado distribuido completo con un Trace-Id único, para ver el camino y el tiempo de procesamiento de la solicitud en todas las etapas.