服務在 Kubernetes 上運行時,若沒有完善的監控與日誌系統,一旦出現 記憶體不足、節點負載異常、API 延遲暴增 等問題,就很難快速定位與修復。
這也是為什麼在 DevOps 與 MLOps 的世界裡,Observability(可觀測性) 成為不可或缺的一環。它主要由三大支柱構成:
本篇的目標是建立一套能監控 workload 的 Logging & Monitoring 架構,結合:
| 元件 | 功能 |
|------|------|
| **Prometheus** | 收集與儲存 Metrics |
| **Grafana** | 可視化與告警 |
| **Loki / ELK** | 集中管理與查詢 Log |
| **Alertmanager** | 告警與通知 |
[Kubernetes Nodes]
├── Node Exporter → 系統 Metrics
├── Application Logs → Loki / Fluent Bit
├── Pod Metrics (GPU/CPU) → Prometheus
└── NVIDIA GPU Operator → GPU Metrics
[Prometheus] ←→ [Alertmanager]
[Grafana] ← Prometheus + Loki
推薦使用 kube-prometheus-stack:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitor prometheus-community/kube-prometheus-stack
安裝完成後,會自動部署:
若環境中有 GPU,可搭配 NVIDIA DCGM Exporter:
helm repo add nvidia https://nvidia.github.io/gpu-operator
helm install gpu-operator nvidia/gpu-operator
Prometheus 會自動發現 GPU Metrics,例如:
在 AI 推理服務中,加入自訂延遲監控:
from prometheus_client import start_http_server, Summary
import time, random
# 定義自訂 metrics
INFERENCE_LATENCY = Summary('inference_latency_seconds', 'Model inference latency')
@INFERENCE_LATENCY.time()
def infer():
time.sleep(random.uniform(0.2, 0.8))
if __name__ == '__main__':
start_http_server(8000)
while True:
infer()
部署後,Prometheus 就能自動抓取 /metrics。
| 項目 | ELK Stack (Elasticsearch + Logstash + Kibana) | Loki + Grafana |
|------|-----------------------------------------------|----------------|
| 儲存 | 全文索引,資料量大 | Label 壓縮,輕量化 |
| 搜尋速度 | 高 | 時序最佳化 |
| 成本 | 高 | 低 |
| 安裝複雜度 | 高 | 簡單 |
| 適合場景 | 企業級 Log 分析 | K8s Log 監控與查詢 |
在 Kubernetes 環境中,Loki 通常是更輕量、實用的選擇。
helm repo add grafana https://grafana.github.io/helm-charts
helm install loki-stack grafana/loki-stack
scrape_configs:
- job_name: kubernetes-pods
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app]
target_label: app
Promtail 會將每個 Pod 的 log 傳送至 Loki 儲存,並加上標籤(如 app 名稱、namespace)。
進入 Grafana → Data Source:
可以在 Grafana 建立多層次的儀表板:
系統層級
使用 Grafana Alert 或 Prometheus Alertmanager:
groups:
- name: gpu-alert
rules:
- alert: GPUHighUsage
expr: DCGM_FI_DEV_GPU_UTIL > 90
for: 5m
labels:
severity: warning
annotations:
summary: "GPU 使用率超過 90%"
可設定通知至 Slack、Discord 或 Email。
監控一個部署於 K8s 的 AI 模型服務,包括:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-inference
spec:
replicas: 1
template:
spec:
containers:
- name: ai-model
image: my-ai-inference:latest
ports:
- containerPort: 8000
resources:
limits:
nvidia.com/gpu: 1
env:
- name: PROMETHEUS_PORT
value: "8000"
[AI Inference Pod]
├── /metrics → Prometheus
├── stdout logs → Loki
└── Alerts → Grafana Alertmanager
從 Day 24 的自動伸縮(HPA/VPA)到本篇的 Logging & Monitoring,我們已建立起一個能夠「自我監控、自我調整」的 DevOps 架構。
在下一篇,我們將進一步探討 GPU 資源管理與調度,讓 AI 工作負載的效能最大化、資源利用最優化。
延伸閱讀與進階主題