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
El mecanismo de recopilación de registros recupera STDOUT/STDERR los registros de los pods de Kubernetes. A DaemonSet
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-twryrqywpuede 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(); } }