AWS帳號充值辦理 雲原生系統可觀測性實踐：日誌、指標與追蹤分析
# 雲原生系統可觀測性實踐：日誌、指標與追蹤分析
在雲原生系統中，真正讓運維與研發頭疼的，往往不是服務能不能啟動，而是**服務出了問題之後，能不能快速定位**。當應用拆分為多個微服務、運行在 Kubernetes 集群、依賴資料庫、快取、消息隊列和外部 API 時，單靠登入 Pod 看日誌，通常已經無法支撐故障排查。
這篇文章不講概念鋪墊，直接從實際操作出發，帶你建立一套可落地的雲原生可觀測性方案，核心覆蓋三部分：
- 日誌收集與查詢
- 指標採集與告警
- 分散式追蹤分析
同時會重點回答幾個實際場景中最常見的問題：
- Kubernetes 中容器日誌怎麼集中收集？
- Prometheus 抓不到指標時該從哪裡排查？
- 介面變慢時，怎麼從鏈路追蹤裡找到具體瓶頸？
- 日誌、指標、追蹤三者怎麼串起來提高排障效率？
---
## 一、用戶搜尋這個主題時，真正想解決什麼問題？
如果用戶搜尋「雲原生系統可觀測性實踐：日誌、指標與追蹤分析」，通常不是為了了解理論，而是在以下幾種場景中遇到了具體問題：
1. **Kubernetes 集群已經上線，但出故障時找不到根因**
2. **服務調用鏈很長，介面超時卻不知道卡在哪一跳**
3. **日誌分散在不同 Pod，排查時效率非常低**
4. **Prometheus 已部署，但沒有關鍵業務指標與有效告警**
5. **可觀測工具裝了很多，卻沒有形成統一的排障流程**
所以這篇文章的核心不是介紹工具，而是告訴你：
**如何在雲原生環境中完成部署、配置、驗證與排障。**
---
## 二、實踐環境與工具選型
下面使用一套常見且容易落地的組合來演示：
AWS帳號充值辦理 - Kubernetes：1.24+
- 日誌：EFK 或 Loki + Promtail
- 指標：Prometheus + Grafana
- 追蹤：OpenTelemetry + Jaeger / Tempo
- 告警：Alertmanager
如果你已經在公有雲 Kubernetes 服務中運行，也可以直接套用，思路是一樣的。
建議最小部署順序：
1. 先上指標
2. 再補日誌
3. 最後接入追蹤
4. 再做三者關聯
這樣做的原因很簡單：
- 指標最適合先做存活監控與資源觀察
- 日誌最適合處理具體錯誤信息
- 追蹤最適合定位慢查詢、跨服務延遲與依賴瓶頸
---
## 三、日誌實踐：Kubernetes 容器日誌集中收集
### 1. 日誌方案選擇建議
在雲原生場景中，最常見的日誌收集方式有兩種：
#### 方案 A：EFK
- Elasticsearch：存儲與檢索
- Fluent Bit / Fluentd：採集與轉發
- Kibana：查詢分析
適合場景：
- 需要較強的全文檢索
- 需要複雜查詢與可視化
- 日誌量較大且有專門運維能力
#### 方案 B：Loki + Promtail
- Loki：存儲日誌索引
- Promtail：採集容器日誌
- Grafana：統一查看日誌與指標
適合場景：
- 希望部署簡單
- 資源成本更可控
- 想在 Grafana 裡統一看圖表和日誌
AWS帳號充值辦理 如果你的目標是快速落地，建議優先考慮 **Loki + Promtail**。
---
AWS帳號充值辦理 ### 2. Kubernetes 中部署 Promtail 收集容器日誌
Promtail 一般以 DaemonSet 方式部署，保證每個節點都能讀取本地容器日誌。
操作思路如下：
1. 為 Promtail 建立命名空間
2. 配置 RBAC 權限
3. 掛載宿主機 `/var/log`、`/var/lib/docker/containers` 或 containerd 日誌目錄
4. 配置抓取規則與標籤
5. 將日誌發送到 Loki
示例配置片段：
```yaml
scrape_configs:
- job_name: kubernetes-pods
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
target_label: namespace
- source_labels: [__meta_kubernetes_pod_name]
target_label: pod
- source_labels: [__meta_kubernetes_pod_container_name]
target_label: container
```
這一步最容易出現的問題有三個：
#### 問題 1：日誌沒有被採集到
排查順序：
1. 確認 Promtail Pod 是否在所有節點正常運行
2. 檢查宿主機日誌目錄是否正確掛載
3. 確認容器運行時是 Docker 還是 containerd
4. 查看 Promtail 啟動日誌是否有權限錯誤
5. 驗證 relabel 規則是否把目標過濾掉了
常見命令：
```bash
kubectl get pods -n logging -o wide
kubectl logs -n logging promtail-xxxxx
kubectl describe pod promtail-xxxxx -n logging
```
#### 問題 2：查得到日誌，但沒有 namespace、pod 等標籤
這通常是 `relabel_configs` 配置不完整，或者 Kubernetes 服務發現沒有生效。檢查點：
- Promtail 是否啟用了 `kubernetes_sd_configs`
- RBAC 是否允許讀取 Pod metadata
- 目標標籤名稱是否寫錯
#### 問題 3：日誌量太大，查詢很慢
建議做三個優化：
1. 避免把整段 JSON 當成高基數標籤
2. 只保留必要標籤，如 `namespace`、`pod`、`container`、`app`
3. 在應用層規範日誌格式，減少無意義重複輸出
---
### 3. 應用日誌格式建議
不要直接輸出隨意拼接的文本，建議統一 JSON 格式，至少包含以下字段：
```json
{
"time": "2026-10-21T10:00:00Z",
"level": "ERROR",
"service": "order-service",
"trace_id": "abc123",
"span_id": "def456",
"message": "db query timeout",
"path": "/api/order/create"
}
```
這樣做的直接收益是：
- 可以按 `trace_id` 回溯完整請求
- 可以按 `service` 快速定位哪個服務報錯
- 可以在 Grafana / Kibana 中直接做字段過濾
AWS帳號充值辦理 如果你後續要把日誌和追蹤串起來，`trace_id` 必須保留。
---
AWS帳號充值辦理 ## 四、指標實踐：Prometheus 採集、告警與排障
### 1. 部署 Prometheus 的基本思路
在 Kubernetes 環境中，最常見做法是使用 Helm 安裝 `kube-prometheus-stack`，它通常會包含：
- Prometheus
- Alertmanager
- Grafana
- node-exporter
- kube-state-metrics
安裝前要先想清楚三個配置問題：
1. **存儲保留多久**：7 天、15 天還是 30 天？
2. **磁碟容量是否足夠**：Prometheus 本地 TSDB 對磁碟較敏感
3. **是否需要高可用**：單實例還是雙副本
如果只是內部業務監控，初期可以先做：
- 保留 7~15 天資料
- 採樣間隔 15s 或 30s
- 優先監控節點、Pod、Ingress、核心應用
---
AWS帳號充值辦理 ### 2. 抓取應用指標的標準步驟
很多人部署了 Prometheus，卻只看到節點資源指標，看不到自己的業務指標。標準排查流程如下。
#### 第一步：確認應用是否暴露 metrics 端點
例如 Java、Go、Python 應用通常會暴露：
```bash
curl http://app-service:8080/metrics
```
如果這一步拿不到資料，先不要去看 Prometheus，先解決應用暴露問題。
#### 第二步：確認 Service 是否正確指向 Pod
```bash
kubectl get svc -n prod
kubectl describe svc app-service -n prod
kubectl get endpoints -n prod app-service
```
常見問題：
- selector 標籤不匹配
- metrics 端口沒有暴露
- targetPort 設錯
#### 第三步：確認 ServiceMonitor / PodMonitor 配置
如果你使用 `kube-prometheus-stack`，通常透過 `ServiceMonitor` 收集。
示例：
```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: order-service-monitor
namespace: monitoring
spec:
selector:
matchLabels:
app: order-service
namespaceSelector:
matchNames:
- prod
endpoints:
- port: metrics
path: /metrics
interval: 15s
```
最常見錯誤：
1. `port` 名稱和 Service 裡定義的不一致
2. `namespaceSelector` 沒有覆蓋應用所在 namespace
3. Prometheus 沒有選中這個 ServiceMonitor
4. metrics path 不正確
#### 第四步：到 Prometheus Targets 頁面檢查狀態
如果 target 顯示 `DOWN`，重點看錯誤信息：
- connection refused：應用端口沒開或 Service 配置錯
- context deadline exceeded：網絡不通或響應太慢
- 403 / 401：被認證攔截
- no route to host：網絡策略或 CNI 問題
---
### 3. 需要優先建立的核心監控指標
在雲原生環境中，不要一開始就做大量指標，先抓關鍵面。
#### 基礎資源層
- 節點 CPU 使用率
- 節點記憶體使用率
- 磁碟使用率
- 網絡丟包與重傳
- Pod 重啟次數
- 容器 OOMKilled 次數
AWS帳號充值辦理 #### Kubernetes 控制層
- Pod Pending 數量
- Deployment 不可用副本數
- API Server 延遲
- etcd 延遲
- CoreDNS 錯誤率
#### 應用層
- QPS / RPS
- P95 / P99 響應時間
- 錯誤率
- 活躍連接數
- 資料庫查詢耗時
- 快取命中率
#### 業務層
- 訂單成功率
- 支付回調成功率
- 登入失敗率
- 消息消費堆積量
重點不是指標多，而是**能直接對應故障現象**。
---
### 4. 告警規則配置建議
告警不要只盯 CPU、記憶體，更要盯業務可用性。下面是一個思路：
#### 資源類告警
- CPU 持續高於 85% 超過 10 分鐘
- 記憶體使用率高於 90%
- 磁碟剩餘空間低於 15%
#### 可用性告警
- Pod 重啟次數異常增加
- Deployment 可用副本數少於期望值
- 5xx 錯誤率超過閾值
- API P95 響應時間突增
#### 業務告警
- 訂單建立成功率低於 95%
- 消費延遲超過 5 分鐘
- Redis 連接數打滿
- MySQL 慢查詢明顯增加
配置原則：
1. 告警一定要可行動
2. 同一問題不要重複轟炸
3. 先有 S1、S2 分級，再談通知方式
4. 每條告警都要有對應處理手冊
---
## 五、追蹤實踐：OpenTelemetry 接入與慢請求分析
### 1. 為什麼很多團隊裝了追蹤卻用不起來？
根本原因通常不是工具問題，而是下面幾點沒處理好：
1. 沒有把核心服務都接入
2. trace 上下文沒有在服務間正確傳遞
3. 採樣率設置不合理
4. trace 裡沒有關鍵業務標籤
5. 日誌與 trace_id 沒打通
所以追蹤系統部署只是第一步，更關鍵的是接入方式。
---
### 2. OpenTelemetry 接入的操作路徑
建議優先使用 OpenTelemetry，因為它更適合作為統一標準。
落地步驟：
1. 部署 OpenTelemetry Collector
2. 在應用中引入對應語言 SDK
3. 配置 exporter，把 trace 發送到 Jaeger 或 Tempo
4. 確認 HTTP / gRPC 調用傳遞 trace context
5. 在日誌中寫入 trace_id
典型架構如下：
- 應用程式 → OTel SDK → OTel Collector → Jaeger / Tempo
Collector 的好處是：
- 統一接收多語言資料
- 可做採樣、過濾、轉發
- 後續調整後端不需要每個服務改配置
---
### 3. 介面慢時的標準分析流程
假設現在有一個下單介面變慢，排查順序建議如下：
#### 第一步：先看指標
在 Grafana 查看：
- 該 API 的 P95 / P99 是否升高
- 錯誤率是否同步升高
- 是否只有單一地域、單一節點異常
如果指標已經明確顯示是局部異常，就不要直接全局查日誌。
#### 第二步：在追蹤系統中定位慢 Trace
在 Jaeger / Tempo 查詢：
- service = order-service
- operation = POST /api/order/create
- duration > 2s
打開慢 Trace 後，重點看：
- 哪個 span 最長
- 外部依賴是否超時
- 是否出現重試
- 是否卡在資料庫查詢
- 是否有序列化 / 反序列化耗時
#### 第三步：按 trace_id 回查日誌
當你在追蹤裡拿到 trace_id 之後，到日誌系統中過濾：
```text
trace_id="abc123"
```
此時通常能看到：
- SQL 超時
- 下游接口返回 500
- 某次重試失敗
- Redis 連接池耗盡
這就是日誌、指標、追蹤聯動的核心價值。
---
## 六、三者如何打通：建立可操作的排障鏈路
很多團隊最大的問題不是缺工具，而是缺少統一排障入口。建議用下面這條鏈路：
### 場景一：使用者反映介面慢
AWS帳號充值辦理 排查順序：
1. 看 Grafana 指標面板，確認慢的是哪個 API、哪個時間段
2. 跳轉到 Trace，找 duration 最長的請求
3. 拿 trace_id 去 Loki / EFK 查日誌
4. 定位是應用、資料庫、快取還是網絡問題
### 場景二：Pod 頻繁重啟
排查順序：
1. 看 Pod 重啟告警
2. 用 `kubectl describe pod` 看事件
3. 到日誌系統查崩潰前最後幾十行日誌
4. 看是否 OOM、探針失敗、配置錯誤
5. 對照節點資源指標判斷是否節點擁塞
### 場景三：資料庫連接失敗
排查順序：
1. 看應用錯誤率是否升高
2. 看 trace 是否大量停留在 DB span
3. 查應用日誌中的連接錯誤類型
4. 檢查資料庫白名單、私網、端口、安全組
5. 看資料庫實例連接數與 CPU 是否打滿
這裡可以看到，可觀測性不只是可視化，而是**形成固定的排障流程**。
---
## 七、Kubernetes 中常見可觀測性故障排查
### 1. Prometheus 抓不到 Pod 指標
按下面順序查：
1. Pod 是否正常運行
2. 應用 `/metrics` 是否可訪問
3. Service selector 是否命中 Pod
4. ServiceMonitor 標籤是否匹配
5. Prometheus 是否選中了 ServiceMonitor
6. NetworkPolicy 是否阻止訪問
---
### 2. Grafana 有面板但沒有數據
排查點：
AWS帳號充值辦理 1. Data Source 是否連通
2. 查詢語句中的 label 是否拼錯
3. 時間範圍是否過窄
4. Prometheus 裡是否真的有這個 metric
5. 儀表板變量是否選錯 namespace 或 cluster
可直接在 Prometheus 中先跑原始 PromQL 驗證。
---
### 3. Jaeger 裡 trace 很少或查不到
常見原因：
1. 採樣率太低
2. SDK 沒有正確初始化
3. Collector 地址配置錯誤
4. 服務間上下文沒有透傳
5. 入口層如 Nginx / Gateway 沒有保留追蹤 header
如果是跨語言服務鏈路，一定要統一傳遞規範，優先使用 W3C Trace Context。
---
### 4. 日誌收集正常，但查詢不到最新日誌
AWS帳號充值辦理 檢查：
1. 採集端是否有發送延遲
2. Loki / Elasticsearch 是否有寫入壓力
3. 節點時間是否同步
4. 查詢時間範圍是否包含當前時區
5. 是否被 pipeline 過濾掉
時間不同步是非常常見但容易忽略的問題，務必保證節點 NTP 正常。
---
## 八、性能與成本控制：不要把可觀測性系統做成新瓶頸
可觀測性本身也會消耗資源，尤其在日誌量大、trace 採樣高的情況下，控制不好反而會增加成本與管理難度。
### 1. 日誌控制建議
- INFO 不要打印大量重複請求內容
- DEBUG 只在短期排查時開啟
- 大字段如完整請求體、完整響應體不要默認全量記錄
- 敏感資料要脫敏
- 設置保留週期，避免無限制堆積
### 2. 指標控制建議
- 避免高基數 label，例如 user_id、order_id
- 同一業務不要重複上報多套近似指標
- 保留能支撐告警與排障的核心 metric 即可
### 3. 追蹤控制建議
- 不要對所有流量 100% 採樣
- 核心接口可以提高採樣率
- 異常請求、慢請求可做優先保留
- 用 Collector 做尾部採樣比應用內硬編碼更靈活
AWS帳號充值辦理 ---
## 九、實戰配置建議：從 0 到可用的落地順序
如果你現在要在一套新的雲原生環境中落地可觀測性，建議按下面步驟做。
### 第一階段：先把基礎監控跑起來
1. 部署 Prometheus + Grafana
2. 接入 node-exporter、kube-state-metrics
3. 建立節點、Pod、Deployment 面板
4. 配置 CPU、記憶體、磁碟、Pod 重啟告警
### 第二階段：補齊應用指標
1. 業務服務暴露 `/metrics`
2. 建立 ServiceMonitor
3. 製作 API 延遲、錯誤率、QPS 面板
4. 對關鍵接口設告警
### 第三階段：接入日誌平台
1. 部署 Promtail / Fluent Bit
2. 統一採集容器標準輸出
3. 約定 JSON 日誌格式
4. 增加 trace_id、service、env 等字段
### 第四階段：接入分散式追蹤
1. 部署 OTel Collector
2. 關鍵服務接入 OTel SDK
3. 驗證 trace context 透傳
4. 打通日誌中的 trace_id
### 第五階段：建立標準化排障手冊
針對以下問題各寫一份 Runbook：
- API 變慢怎麼查
- Pod 重啟怎麼查
- 5xx 升高怎麼查
- 資料庫連接失敗怎麼查
- 消息堆積怎麼查
這一步比加更多圖表更重要。
---
## 十、最佳實踐總結
最後總結幾條在實際專案中最有用的經驗：
1. **先建排障流程，再堆工具**
2. **日誌必須帶 trace_id**
3. **指標優先覆蓋延遲、錯誤率、流量、飽和度**
4. **避免高基數 label，否則 Prometheus 會很痛苦**
5. **追蹤不要全量採樣，要有策略**
6. **告警要能行動，不要只會通知**
7. **Kubernetes 中先查 Service、Endpoints、NetworkPolicy，再懷疑應用**
8. **可觀測性平台本身也要監控**
AWS帳號充值辦理 可觀測性做得好，最直接的結果不是面板變多，而是：
- 故障能更快定位
- 慢請求能更快拆解
- 跨服務問題不再只能靠猜
- 運維與研發之間能共享同一套排障依據
AWS帳號充值辦理 如果你的系統目前還停留在「登入 Pod 看日誌」階段，那麼最值得優先落地的不是全部重建，而是先完成這三件事：
1. Prometheus 把核心應用指標抓起來
2. 日誌統一收集並寫入 trace_id
3. 核心服務接入 OpenTelemetry
先把這三步做好，可觀測性體系就已經具備了實際排障能力。
