My Awesome Project

Appearance

Monitoring — Windows-Specific Metrics & Observability Gaps ​

Vì Sao Quan Trọng ​

Team đã quen với dashboard GKE Observability cho Linux workload thường mặc định assume cùng bộ metrics available cho Windows pod — điều này sai. cAdvisor (nguồn thu thập container metrics chuẩn của Kubernetes) được thiết kế ban đầu xoay quanh cgroups filesystem của Linux; trên Windows, một phần metrics không tồn tại hoặc phải lấy qua nguồn khác. Nếu không biết trước gap này, team sẽ debug "tại sao dashboard trống" thay vì hiểu đây là giới hạn nền tảng cần bổ sung tooling riêng.

cAdvisor Trên Windows: Metrics Nào Có, Metrics Nào Thiếu ​

cAdvisor đọc phần lớn metric Linux trực tiếp từ cgroups filesystem (/sys/fs/cgroup/...) — cơ chế này không tồn tại trên Windows. Trên Windows, cAdvisor phải lấy số liệu qua HCS API (Host Compute System) và Windows Performance Counters, và tập metric thu được hẹp hơn so với Linux:

Metric nhómLinux (cgroups-based)Windows (HCS/Perf Counter-based)
CPU usageĐầy đủ (usage, throttling, per-core)Có, nhưng ít chi tiết throttling hơn
Memory working setĐầy đủ (cache, RSS breakdown)Có working set tổng, ít breakdown chi tiết
Network I/OĐầy đủ per-interfaceHạn chế hơn, qua HNS endpoint counters
Filesystem I/OĐầy đủ per-cgroupRất hạn chế, thường không có breakdown per-container rõ
OOM eventsCó (cgroup OOM killer event)Không có event tương đương rõ ràng — container bị Job Object kill nhưng không luôn có structured event dễ query

Hệ quả thực tế: dashboard "container filesystem usage" hoặc "OOM kill count" quen dùng cho Linux có thể trống hoặc không chính xác khi filter sang node Windows — đừng coi đây là bug của dashboard, đây là giới hạn nguồn dữ liệu.

GKE Cloud Monitoring: Điều Gì Được Thu Thập Tự Động ​

GKE tự động gửi node-level và pod-level metrics cơ bản (CPU, memory, network cơ bản) từ Windows node lên Cloud Monitoring, tương tự Linux — nhưng granularity thấp hơn ở một số dimension, đặc biệt là filesystem và network chi tiết như bảng trên. Với workload cần observability sâu hơn baseline này, cần bổ sung một trong hai hướng:

  1. Windows Performance Counters — hệ thống metric OS-native của Windows, tồn tại từ lâu trước container, cung cấp số liệu chi tiết hơn cAdvisor (ví dụ: .NET CLR Memory, ASP.NET Applications, Process counter category)
  2. windows_exporter — Prometheus exporter community expose Windows Performance Counters ở format Prometheus, chạy như sidecar hoặc DaemonSet trên node
Windows Node
├── Performance Counters (OS-native, luôn có sẵn)
│     ├── \Process(*)\% Processor Time
│     ├── \.NET CLR Memory(*)\# Gen 0 Collections
│     └── \Memory\Available MBytes
│
└── windows_exporter (Prometheus format)
      └── scrape bởi Managed Service for Prometheus (GMP)

Managed Service for Prometheus (GMP) Với windows_exporter ​

GKE Managed Service for Prometheus có thể scrape windows_exporter như bất kỳ Prometheus exporter khác qua PodMonitoring/ClusterPodMonitoring custom resource — không có giới hạn đặc biệt ở phía GMP, nhưng cần lưu ý:

  • windows_exporter cần chạy trên chính Windows node (không thể chạy dạng container Linux đọc metrics từ xa) — deploy dạng DaemonSet với nodeSelector kubernetes.io/os: windows
  • Một số collector của windows_exporter (ví dụ IIS, MSSQL) chỉ có giá trị nếu workload thực sự dùng component đó — nên chỉ enable collector cần thiết để giảm cardinality không cần thiết

.NET-Specific Observability ​

Với workload .NET/.NET Framework, phần lớn signal hữu ích nhất cho debugging performance không nằm ở container/OS layer, mà ở CLR layer:

  • GC metrics (Gen 0/1/2 collection count, pause duration) — quan trọng vì GC pause ảnh hưởng trực tiếp tail latency, và pattern GC trên container (đặc biệt với CPU limit thấp) có thể khác biệt rõ so với chạy trên VM không giới hạn
  • Thread pool starvation — dễ xảy ra hơn trong container có CPU limit thấp; nếu không monitor riêng, biểu hiện chỉ là "latency tăng random" khó trace về root cause
  • ASP.NET Core built-in metrics (Microsoft.AspNetCore.Hosting, request duration histogram) — nên export qua OpenTelemetry .NET hoặc prometheus-net để tích hợp cùng stack Cloud Monitoring/Managed Prometheus, không phụ thuộc hoàn toàn vào infrastructure-level metrics

Node Problem Detector: Hỗ Trợ Giới Hạn ​

node-problem-detector — component phát hiện node-level issue (disk pressure, kernel deadlock, v.v.) trên GKE — có lịch sử support Windows hạn chế hơn so với Linux, vì phần lớn detector rule viết dựa trên việc parse log/kernel message theo format Linux (dmesg, syslog pattern). Khi thiết kế alerting cho Windows node pool, không nên assume coverage tương đương Linux — nên bổ sung custom health check (ví dụ scheduled Job kiểm tra disk free space, event log Windows) nếu cần độ tin cậy phát hiện sự cố tương đương.

Checklist Monitoring Cho Windows Node Pool ​

  1. Xác nhận rõ metric nào có sẵn qua GKE Cloud Monitoring mặc định, đừng assume parity với Linux dashboard
  2. Deploy windows_exporter qua DaemonSet nếu cần observability sâu hơn OS-level (Performance Counters)
  3. Với workload .NET, export GC/thread-pool metrics ở application layer — đây thường là signal quan trọng nhất, không nằm ở infra layer
  4. Không dựa hoàn toàn vào node-problem-detector cho Windows node health — bổ sung custom check nếu cần
  5. Test alerting rule thực tế trên Windows node trước khi tin tưởng coverage — nhiều rule copy từ Linux sẽ silently không trigger vì thiếu metric nguồn

Tham Khảo ​