本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
日誌
容器化應用程式通常會將應用程式日誌導向 STDOUT。容器執行期會捕捉這些日誌,並對其執行一些操作 - 通常寫入檔案。這些檔案的儲存位置取決於容器執行時間和組態。
與 Windows Pod 的一個基本差異是它們不會產生 STDOUT。您可以執行 LogMonitor
日誌收集機制會從 Kubernetes Pod 擷取 STDOUT/STDERR 日誌。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(); } }