View a markdown version of this page

Registro - Amazon EKS

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Registro

Las aplicaciones en contenedores suelen dirigir los registros de las aplicaciones a STDOUT. El tiempo de ejecución del contenedor captura estos registros y hace algo con ellos; por lo general, los escribe en un archivo. El lugar donde se almacenan estos archivos depende del tiempo de ejecución y la configuración del contenedor.

Una diferencia fundamental con los pods de Windows es que no generan STDOUT. Puedes ejecutar LogMonitor para recuperar el ETW (seguimiento de eventos para Windows), los registros de eventos de Windows y otros registros específicos de la aplicación desde los contenedores de Windows en ejecución y canalizar la salida de los registros formateados a STDOUT. Luego, estos registros se pueden transmitir mediante fluent-bit o fluentd al destino que desees, como Amazon. CloudWatch

El mecanismo de recopilación de registros recupera STDOUT/STDERR los registros de los pods de Kubernetes. A DaemonSet es una forma habitual de recopilar registros de los contenedores. Permite administrar el registro y el routing/filtering enriquecimiento de forma independiente de la aplicación. Se DaemonSet puede usar un fluentd para transmitir estos registros y cualquier otro registro generado por la aplicación al agregador de registros deseado.

Aquí encontrará información más detallada sobre la transmisión de registros desde las cargas de trabajo de Windows a CloudWatch https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/

Recomendaciones de registro

Las prácticas recomendadas generales de registro no son diferentes cuando se operan cargas de trabajo de Windows en Kubernetes.

  • Registre siempre las entradas de registro estructuradas (JSON/SYSLOG), lo que facilita la gestión de las entradas de registro, ya que hay muchos analizadores preescritos para dichos formatos estructurados.

  • Centralice los registros: los contenedores de registro dedicados se pueden usar específicamente para recopilar y reenviar los mensajes de registro de todos los contenedores a un destino

  • Reduce el nivel de detalle de los registros, excepto durante la depuración. La verbosidad ejerce mucha presión sobre la infraestructura de registro y los eventos importantes pueden perderse entre el ruido.

  • Registre siempre la información de la aplicación junto con la transaction/request identificación para garantizar la trazabilidad. Los objetos de Kubernetes no llevan el nombre de la aplicación, por lo que, por ejemplo, el nombre de un pod windows-twryrqyw puede no tener ningún significado al depurar los registros. Esto contribuye a la trazabilidad y a la resolución de problemas de las aplicaciones con los registros agregados.

    La forma de generar estos transaction/correlation identificadores depende de la construcción de programación. Sin embargo, un patrón muy común es usar un registro Aspect/Interceptor, que puede usar el MDC (contexto de diagnóstico mapeado) para inyectar un transaction/correlation identificador único a cada solicitud entrante, de la siguiente manera:

import org.slf4j.MDC; import java.util.UUID; Class LoggingAspect { //interceptor @Before(value = "execution(* *.*(..))") func before(...) { transactionId = generateTransactionId(); MDC.put(CORRELATION_ID, transactionId); } func generateTransactionId() { return UUID.randomUUID().toString(); } }