OpenShift Logging 完整指南：日誌收集、分析與監控

系統出問題的時候，日誌是你最好的朋友。但在 Kubernetes 環境，Pod 隨時可能被刪除重建，日誌也跟著消失。

OpenShift Logging 解決這個問題，把所有日誌集中收集、儲存、查詢。不管 Pod 跑到哪、活多久，日誌都不會丟。

本文將完整介紹 OpenShift Logging 的架構與設定，幫助你建立可靠的日誌管理系統。如果你對 OpenShift 還不熟悉，建議先閱讀 OpenShift 完整指南。

---

OpenShift Logging 簡介

日誌的重要性

在容器環境中，日誌是：

• 問題排查的第一手資料：應用錯誤、效能問題
• 安全稽核的關鍵：誰做了什麼、何時做的
• 合規要求：許多法規要求保留日誌
• 業務分析來源：用戶行為、使用模式

沒有日誌系統，就像開車沒有儀表板。

架構總覽

OpenShift Logging 由三大部分組成：

┌─────────────────────────────────────────────────────┐
│                    日誌來源                          │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐             │
│  │ 應用程式 │  │ 基礎設施 │  │ 稽核日誌 │             │
│  │  日誌   │  │  日誌   │  │         │             │
│  └────┬────┘  └────┬────┘  └────┬────┘             │
├───────┼────────────┼────────────┼───────────────────┤
│       └────────────┼────────────┘                   │
│                    ▼                                │
│              ┌─────────┐                           │
│              │ Vector  │  ← 日誌收集器              │
│              └────┬────┘                           │
│                   ▼                                │
│              ┌─────────┐                           │
│              │  Loki   │  ← 日誌儲存                │
│              └────┬────┘                           │
│                   ▼                                │
│              ┌─────────┐                           │
│              │ Console │  ← 日誌查詢                │
│              └─────────┘                           │
└─────────────────────────────────────────────────────┘

5.x vs 6.x 差異

OpenShift Logging 在 6.x 版本有重大架構變更：

面向	5.x	6.x
日誌收集器	Fluentd	Vector
日誌儲存	Elasticsearch	LokiStack（推薦）
設定方式	ClusterLogging CR	ClusterLogForwarder 為主
架構複雜度	較複雜	簡化
效能	一般	提升

6.x 是目前推薦的版本，本文以 6.x 為主。

---

Logging 6.x 新功能

Vector 日誌收集器

Vector 取代 Fluentd 成為預設收集器。

Vector 的優勢：

• 效能更好：用 Rust 寫的，記憶體和 CPU 效率更高
• 設定更簡單：語法更直覺
• 功能更完整：內建轉換、路由、過濾

Vector 以 DaemonSet 部署，每個節點一個：

oc get pods -n openshift-logging -l app.kubernetes.io/component=collector

LokiStack

LokiStack 是推薦的日誌儲存方案，取代 Elasticsearch。

Loki 的設計理念與 Elasticsearch 不同：

• 只索引元資料（時間戳、標籤），不索引日誌內容
• 儲存成本更低
• 查詢速度快（已知標籤時）
• 水平擴展更容易

LokiStack 架構：

┌─────────────────────────────────────┐
│           LokiStack                  │
│  ┌─────────┐ ┌─────────┐            │
│  │Ingester │ │ Querier │            │
│  └────┬────┘ └────┬────┘            │
│       │           │                  │
│  ┌────▼───────────▼────┐            │
│  │   Object Storage    │            │
│  │   (S3 / ODF)        │            │
│  └─────────────────────┘            │
└─────────────────────────────────────┘

簡化架構

6.x 的架構更簡潔：

舊架構（5.x）： Fluentd → Kafka（可選）→ Elasticsearch → Kibana

新架構（6.x）： Vector → LokiStack → OpenShift Console

不需要額外的 Kibana，直接用 OpenShift Console 查詢。

插圖：左右對照展示 5.x 和 6.x 的架構差異。左邊 5.x ...

場景描述： 左右對照展示 5.x 和 6.x 的架構差異。左邊 5.x 架構（Fluentd → Elasticsearch → Kibana，較多組件），右邊 6.x 架構（Vector → LokiStack → Console，較精簡）。用箭頭表示從舊到新的演進，標註「簡化」。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪

Slug: openshift-logging-5x-vs-6x-architecture

---

安裝與設定

安裝 Operator

Step 1：安裝 Loki Operator

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: stable-6.0
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

Step 2：安裝 Cluster Logging Operator

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: stable-6.0
  name: cluster-logging
  source: redhat-operators
  sourceNamespace: openshift-marketplace

設定 LokiStack

LokiStack 需要物件儲存。以 AWS S3 為例：

Step 1：建立 Secret（S3 憑證）

apiVersion: v1
kind: Secret
metadata:
  name: logging-loki-s3
  namespace: openshift-logging
stringData:
  access_key_id: "<AWS_ACCESS_KEY>"
  access_key_secret: "<AWS_SECRET_KEY>"
  bucketnames: "openshift-logging-loki"
  endpoint: "https://s3.ap-northeast-1.amazonaws.com"
  region: "ap-northeast-1"

Step 2：建立 LokiStack

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  size: 1x.small
  storage:
    schemas:
    - version: v13
      effectiveDate: "2024-10-01"
    secret:
      name: logging-loki-s3
      type: s3
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

設定 ClusterLogForwarder

ClusterLogForwarder 定義日誌如何收集和轉發：

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  serviceAccount:
    name: cluster-logging-operator
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      target:
        name: logging-loki
        namespace: openshift-logging
      authentication:
        token:
          from: serviceAccount
  pipelines:
  - name: default-logstore
    inputRefs:
    - application
    - infrastructure
    outputRefs:
    - default-lokistack

儲存配置建議

叢集規模	LokiStack Size	儲存需求/天	建議保留期
小（<50 Pod）	1x.extra-small	~10 GB	7 天
中（50-200 Pod）	1x.small	~50 GB	14 天
大（200+ Pod）	1x.medium	~200 GB	30 天

---

Loki 整合

LokiStack 架構詳解

LokiStack 包含多個組件：

組件	功能
Distributor	接收日誌，分發給 Ingester
Ingester	暫存日誌，寫入儲存
Querier	處理查詢請求
Query Frontend	查詢快取、分割
Compactor	壓縮舊資料

LogQL 查詢語法

Loki 使用 LogQL 查詢語言，類似 PromQL：

基本查詢：

# 查詢特定 namespace 的日誌
{kubernetes_namespace_name="my-app"}

# 查詢特定 Pod
{kubernetes_pod_name="my-pod-abc123"}

# 多條件組合
{kubernetes_namespace_name="my-app", kubernetes_container_name="web"}

過濾日誌內容：

# 包含 "error" 的日誌
{kubernetes_namespace_name="my-app"} |= "error"

# 不包含 "debug" 的日誌
{kubernetes_namespace_name="my-app"} != "debug"

# 正則表達式
{kubernetes_namespace_name="my-app"} |~ "error|exception"

JSON 解析：

# 解析 JSON 日誌，過濾 level=error
{kubernetes_namespace_name="my-app"} | json | level="error"

# 提取特定欄位
{kubernetes_namespace_name="my-app"} | json | line_format "{{.message}}"

統計查詢：

# 過去 5 分鐘的錯誤數量
count_over_time({kubernetes_namespace_name="my-app"} |= "error" [5m])

# 每分鐘的日誌量
rate({kubernetes_namespace_name="my-app"} [1m])

在 Console 查詢

OpenShift Console 內建日誌查詢介面：

1. 進入 Observe → Logs
2. 選擇日誌類型（Application / Infrastructure / Audit）
3. 輸入 LogQL 查詢
4. 查看結果

也可以用 CLI：

# 安裝 logcli
# 查詢日誌
logcli query '{kubernetes_namespace_name="my-app"}' --limit=100

---

日誌類型

OpenShift 將日誌分為三大類：

應用程式日誌（Application）

來自使用者部署的應用程式（非 openshift-* namespace）：

• 容器 stdout/stderr
• 應用程式寫入的日誌檔案

標籤範例：

{
  log_type: "application",
  kubernetes_namespace_name: "my-app",
  kubernetes_pod_name: "web-abc123",
  kubernetes_container_name: "web"
}

基礎設施日誌（Infrastructure）

來自 OpenShift 系統組件：

• openshift-* namespace 的 Pod
• kube-* namespace 的 Pod
• 節點系統日誌（journald）

標籤範例：

{
  log_type: "infrastructure",
  kubernetes_namespace_name: "openshift-apiserver"
}

稽核日誌（Audit）

系統操作的稽核紀錄：

• Kubernetes API 稽核：誰對 API 做了什麼操作
• OpenShift API 稽核：OAuth、Route 等操作
• OVN 稽核：網路操作
• 節點稽核：Linux auditd 日誌

稽核日誌對合規非常重要。

---

日誌轉發

除了存到 LokiStack，日誌也可以轉發到外部系統。

轉發到 Kafka

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: kafka-receiver
    type: kafka
    kafka:
      brokers:
      - kafka.example.com:9092
      topic: openshift-logs
  pipelines:
  - name: to-kafka
    inputRefs:
    - application
    outputRefs:
    - kafka-receiver

轉發到 Splunk

outputs:
- name: splunk-receiver
  type: splunk
  splunk:
    url: https://splunk.example.com:8088
    token:
      secretName: splunk-token
      key: token

轉發到雲端服務

AWS CloudWatch：

outputs:
- name: cloudwatch
  type: cloudwatch
  cloudwatch:
    region: ap-northeast-1
    groupBy: namespaceName
    secret:
      name: cloudwatch-credentials

Azure Monitor：

outputs:
- name: azure-monitor
  type: azureMonitor
  azureMonitor:
    customerId: "<workspace-id>"
    logType: openshift
    secret:
      name: azure-monitor-secret

日誌轉發架構需要考量延遲、可靠性和成本。預約架構諮詢，讓我們幫你設計最佳方案。

插圖：展示日誌轉發的多目的地架構。中央是 Vector 收集器，向...

場景描述： 展示日誌轉發的多目的地架構。中央是 Vector 收集器，向外輻射到多個目的地：LokiStack（本地儲存）、Kafka（串流處理）、Splunk（企業 SIEM）、CloudWatch（AWS 雲端）。每個目的地用不同顏色的方框表示。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪

Slug: openshift-logging-multi-destination

---

稽核日誌管理

Kubernetes API 稽核

記錄所有對 Kubernetes API 的操作：

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/default/pods",
  "verb": "create",
  "user": {
    "username": "admin",
    "groups": ["system:authenticated"]
  },
  "responseStatus": {
    "code": 201
  }
}

稽核策略

OpenShift 預設的稽核策略已經平衡了完整性和儲存量。如需調整：

apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  audit:
    profile: Default  # 或 WriteRequestBodies, AllRequestBodies

Profile	說明	日誌量
Default	記錄元資料	中
WriteRequestBodies	記錄寫入操作的 body	大
AllRequestBodies	記錄所有操作的 body	非常大

合規需求

常見合規標準對日誌的要求：

標準	要求
PCI DSS	保留至少 1 年，可取用 3 個月
SOC 2	系統存取日誌、變更日誌
HIPAA	存取稽核、完整性保護
ISO 27001	日誌保護、定期審查

設定日誌保留策略：

apiVersion: loki.grafana.com/v1
kind: LokiStack
spec:
  limits:
    global:
      retention:
        days: 30
        streams:
        - selector: '{log_type="audit"}'
          priority: 1
          period: 365d  # 稽核日誌保留 1 年

---

最佳實踐

日誌保留策略

分層保留：

日誌類型	建議保留期	說明
應用程式日誌	7-30 天	依問題排查需求
基礎設施日誌	14-30 天	系統問題排查
稽核日誌	90-365 天	合規需求

資源規劃

Vector（收集器）：

• 每節點約 200-500 MB RAM
• CPU 依日誌量而定

LokiStack：

• Ingester 需要較多記憶體
• 選擇適當的 size

# 生產環境建議
spec:
  size: 1x.medium  # 或更大
  replication:
    factor: 3  # 副本數

效能調優

1. 使用標籤過濾

# 好：先用標籤過濾，減少掃描量
{kubernetes_namespace_name="my-app"} |= "error"

# 不好：沒有標籤，全部掃描
{} |= "error"

2. 限制時間範圍

# 好：明確時間範圍
{kubernetes_namespace_name="my-app"} |= "error"
# 查詢時選擇「過去 1 小時」

# 不好：查詢「過去 30 天」的大量資料

3. 適當的日誌級別

應用程式應該：

• 生產環境用 INFO 或 WARN 級別
• 避免過多 DEBUG 日誌
• 結構化日誌（JSON）更容易查詢

安全考量

1. 存取控制

限制誰能看到哪些日誌：

# RBAC：只允許看自己 namespace 的日誌
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: log-viewer
  namespace: my-app
subjects:
- kind: User
  name: developer
roleRef:
  kind: ClusterRole
  name: cluster-logging-application-view

2. 敏感資料

避免在日誌中記錄敏感資訊：

• 密碼、API Key
• 個人識別資訊（PII）
• 信用卡號

可以用 Vector 的轉換功能遮蔽：

spec:
  filters:
  - name: mask-sensitive
    type: prune
    prune:
      in:
      - .message
      notIn:
      - password
      - secret

---

常見問題排除

日誌遺失

症狀：某些 Pod 的日誌沒有出現

排查：

# 檢查 Vector Pod 狀態
oc get pods -n openshift-logging -l app.kubernetes.io/component=collector

# 檢查 Vector 日誌
oc logs -n openshift-logging -l app.kubernetes.io/component=collector

# 檢查 ClusterLogForwarder 狀態
oc get clusterlogforwarder -n openshift-logging -o yaml

常見原因：

• Pod 的日誌路徑不是標準位置
• Vector 資源不足
• 目標儲存有問題

效能問題

症狀：查詢很慢或 timeout

解決：

1. 縮小查詢範圍（時間、namespace）
2. 增加 LokiStack 資源
3. 檢查物件儲存延遲

儲存空間不足

症狀：日誌停止寫入

解決：

1. 檢查儲存使用量
2. 調整保留策略
3. 擴充儲存

# 檢查 PVC 使用量
oc get pvc -n openshift-logging

---

常見問題 FAQ

Q1：為什麼 6.x 改用 Loki 而不是 Elasticsearch？

Loki 的設計更適合日誌場景：（1）只索引標籤不索引內容，儲存成本低很多；（2）架構更簡單，運維負擔小；（3）與 Prometheus 生態整合好。Elasticsearch 功能強大但對日誌來說有點過度設計，而且資源消耗大。

Q2：舊的 Elasticsearch 日誌可以遷移到 Loki 嗎？

技術上可以，但通常不建議。比較務實的做法是：（1）保留舊的 Elasticsearch 讀取舊日誌；（2）新日誌寫到 LokiStack；（3）舊日誌過保留期後自然淘汰。

Q3：日誌量很大，成本怎麼控制？

幾個方向：（1）只收集需要的日誌，用 ClusterLogForwarder 過濾；（2）縮短保留期；（3）用便宜的物件儲存（S3 Standard-IA）；（4）壓縮比調高；（5）避免記錄 DEBUG 級別日誌到生產環境。

Q4：可以同時送到 Loki 和 Splunk 嗎？

可以。ClusterLogForwarder 支援多個 output，同一份日誌可以送到多個目的地。但要注意網路頻寬和 Splunk 的授權成本。

Q5：怎麼知道日誌有沒有漏？

幾個檢查點：（1）比對 Pod 數量和有日誌的 Pod 數量；（2）監控 Vector 的 drop 指標；（3）抽查特定 Pod 的日誌是否完整；（4）設定告警，當日誌量突然下降時通知。

---

日誌系統是運維的眼睛

設計不好會讓你看不清問題。從日誌架構到保留策略，每個決定都影響後續的問題排查效率。

預約架構諮詢，讓我們幫你優化日誌架構。

---

參考資源

• OpenShift 完整指南
• OpenShift 架構詳解
• OpenShift 進階功能設定
• OpenShift 安裝教學
• OpenShift 價格與授權分析
• OpenShift 版本生命週期
• Red Hat OpenShift Logging Documentation