日志记录 - Amazon EKS
记录建议

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

日志记录

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

与 Windows pod 的一个根本区别是它们不会生成 STDOUT。你可以运行从正在运行LogMonitor的 Windows 容器中检索 ETW（适用于 Windows 的事件跟踪）、Windows 事件日志和其他特定于应用程序的日志，并将格式化的日志输出传输到 STDOUT。然后，可以使用 fluent-bit 或 fluentd 将这些日志流式传输到你想要的目的地，例如亚马逊。 CloudWatch

日志收集机制从 Kubernetes 容器中检索 STDOUT/STDERR 日志。A DaemonSet是从容器收集日志的常用方法。它使您能够routing/filtering/enrichment独立于应用程序管理日志。fluentd DaemonSet 可用于将这些日志和任何其他应用程序生成的日志流式传输到所需的日志聚合器。

有关从 Windows 工作负载流向的日志流式传输的更多详细信息 CloudWatch ，请参阅此处

记录建议

在 Kubernetes 中操作 Windows 工作负载时，一般的日志记录最佳实践没有什么不同。

  • 始终记录结构化日志条目 (JSON/SYSLOG)，这样可以更轻松地处理日志条目，因为此类结构化格式有许多预先编写的解析器。

  • 集中日志-专用的日志容器专门用于收集来自所有容器的日志消息并将其转发到目的地

  • 除非调试，否则请降低日志的详细程度。Verbosity 给日志基础架构带来了很大的压力，重大事件可能会在噪音中丢失。

  • 务必记录应用程序信息以及交易/请求编号，以实现可追溯性。Kubernetes 对象不带有应用程序名称，因此例如，在调试日志时，pod 名称windows-twryrqyw可能没有任何意义。这有助于使用聚合日志对应用程序进行可追溯性和故障排除。

    如何生成这些 transaction/correlation ID 取决于编程结构。但是一种非常常见的模式是使用日志 Aspect/Interceptor，它可以使用 MDC（映射的诊断上下文）为每个传入的请求注入一个唯一的 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();
    }
}