本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 日志记录
<a name="windows-logging"></a>

容器化应用程序通常将应用程序日志定向到 STDOUT。容器运行时会捕获这些日志并对其进行处理，通常是写入文件。这些文件的存储位置取决于容器的运行时和配置。

Windows 容器的一个根本区别是它们不生成 STDOUT。你可以运行从正在运行的 Windows 容器和管道格式化日志输出[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)到 STDOUT 中检索 ETW（Windows 事件跟踪）、Windows 事件日志和其他应用程序特定日志。然后，可以使用 fluent-bit 或 fluentd 将这些日志流式传输到所需的目的地，例如亚马逊。 CloudWatch

日志收集机制从 Kubernetes pod 中检索 STDOUT/STDERR 日志。A [ DaemonSet ](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) 是从容器收集日志的常用方法。它使您能够独立于应用程序管理日志 routing/filtering /充实。fluentd DaemonSet 可用于将这些日志和任何其他应用程序生成的日志流式传输到所需的日志聚合器。

[此处解释了有关从 Windows 工作负载流向的日志 CloudWatch 的更多详细信息 ](https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/) 

## 记录建议
<a name="_logging_recomendations"></a>

在 Kubernetes 中操作 Windows 工作负载时，一般的日志记录最佳实践也不例外。
+ 始终记录**结构化日志条目 ** (JSON/SYSLOG)，这样可以更轻松地处理日志条目，因为有许多针对此类结构化格式的预先编写的解析器。
+  **集中**日志-专用的日志容器可以专门用于收集所有容器的日志消息并将其转发到目的地
+ 除非**调试，否则应降低**日志的详细程度。冗长会给日志基础设施带来很大压力，重大事件可能会在噪音中丢失。
+ 请务必记录**应用程序信息**以及 ** transaction/request ID 以实现可**追溯性。Kubernetes 对象不带有应用程序名称，因此例如，在调试日志时，容器名称`windows-twryrqyw`可能没有任何意义。这有助于使用聚合日志进行可追溯性和对应用程序进行故障排除。

  如何生成这些 transaction/correlation ID 取决于编程结构。但是一个非常常见的模式是使用日志记录 Aspect/Interceptor，它可以使用 [ MDC](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html)（映射的诊断上下文）为每个传入的请求注入唯一的 transaction/correlation ID，如下所示：

```
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();
    }
}
```