日誌 - Amazon EKS
記錄建議

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

日誌

容器化應用程式通常會將應用程式日誌導向 STDOUT。容器執行期會捕捉這些日誌，並對其執行一些操作 - 通常寫入檔案。這些檔案的儲存位置取決於容器執行時間和組態。

與 Windows Pod 的一個基本差異是它們不會產生 STDOUT。您可以執行 LogMonitor，從執行 Windows 容器和管道格式化日誌輸出擷取 ETW （適用於 Windows 的事件追蹤）、Windows 事件日誌和其他應用程式特定日誌到 STDOUT。然後，您可以使用 fluent-bit 或 fluentd 將這些日誌串流到所需的目的地，例如 Amazon CloudWatch。

日誌收集機制會從 Kubernetes Pod 擷取 STDOUT/STDERR 日誌。DaemonSet 是從容器收集日誌的常見方式。它可讓您獨立於應用程式管理日誌routing/filtering/enrichment。Fluentd DaemonSet 可用來將這些日誌和任何其他應用程式產生的日誌串流到所需的日誌彙總器。

此處說明從 Windows 工作負載到 CloudWatch 的日誌串流詳細資訊 https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/

記錄建議

在 Kubernetes 中操作 Windows 工作負載時，一般記錄最佳實務並無不同。

  • 一律記錄結構化日誌項目 (JSON/SYSLOG)，讓處理日誌項目變得更容易，因為這類結構化格式有許多預先編寫的剖析器。

  • 集中日誌 - 專用日誌容器可用於收集日誌訊息，並將日誌訊息從所有容器轉送至目的地

  • 保持日誌詳細程度，除除除除除偵錯之外。Verbosity 會對記錄基礎設施造成很大壓力，而且在噪音中可能會遺失重大事件。

  • 一律記錄應用程式資訊以及交易/請求 ID 以供追蹤。Kubernetes 物件不會攜帶應用程式名稱，因此例如，偵錯日誌時，Pod 名稱windows-twryrqyw可能沒有任何意義。這有助於使用彙總日誌追蹤和疑難排解應用程式。

    如何產生這些交易/關聯 ID 的方式取決於程式設計建構。但是，非常常見的模式是使用記錄 Aspect/攔截器，它可以使用 MDC （映射診斷內容） 將唯一的交易/關聯 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();
    }
}