在前幾天的基礎上，我們已經學會如何部署 Loki 並將應用程式日誌傳送過去。然而，一個完整的可觀測性系統不僅僅是收集日誌，更重要的是如何從中提煉價值、主動發現問題，並有效管理其生命週期。

今天，我們將深入探討 Loki 的三大進階功能，它們是將 Loki 從一個簡單的日誌聚合工具，轉變為企業級日誌管理平台的關鍵：

1. Ruler 告警 (Alerting with Ruler)：學習如何基於 LogQL 查詢建立告警規則，實現對日誌事件的即時監控與主動響應。
2. 儲存策略 (Storage Retention)：探討如何設定日誌的保留期限，以在儲存成本和合規性需求之間找到最佳平衡。
3. 多租戶 (Multi-tenancy)：了解如何在一套 Loki 叢集中為多個團隊或應用程式提供獨立、安全的日誌儲存與查詢環境。

1. Ruler 告警 (Alerting with Ruler)

Loki 的 Ruler 元件讓我們能夠定期執行 LogQL 查詢，並在滿足特定條件時觸發告警，通常會將告警發送到 Alertmanager 進行後續處理 (如分組、靜默、通知)。

運作原理

1. 規則定義：我們在 YAML 檔案中定義一組告警規則。
2. 定期評估：Loki Ruler 會讀取這些規則，並按照指定的時間間隔執行其中的 LogQL 查詢。
3. 觸發告警：如果查詢結果滿足規則中定義的 expr (表達式) 條件，並且持續時間超過 for 的設定，Ruler 就會將該告警標記為 firing 狀態。
4. 發送到 Alertmanager：firing 狀態的告警會被推送到設定好的 Alertmanager URL，由 Alertmanager 負責發送到 Slack、Email、Webhook 等通知渠道。

設定範例

首先，需要在 Loki 的設定檔 (loki-config.yaml) 中啟用 Ruler，並指向 Alertmanager。

# loki-config.yaml

ruler:
  storage:
    type: local
    local:
      # 規則檔案所在的目錄
      directory: /etc/loki/rules
  # 告警規則評估的暫存目錄
  rule_path: /tmp/loki/rules-temp
  # Alertmanager 的地址
  alertmanager_url: http://alertmanager:9093
  enable_api: true
  ring:
    kvstore:
      store: inmemory

接著，我們在 /etc/loki/rules 目錄下建立規則檔案，例如 app-alerts.yaml。

# /etc/loki/rules/app-alerts.yaml

groups:
  - name: api-error-alerts
    rules:
      - alert: HighRateOfHttp500Errors
        # LogQL 查詢：計算過去 5 分鐘內，所有 job 為 "fastapi-app" 且狀態碼為 500 的日誌速率
        expr: |
          sum(rate({job="fastapi-app"} |= "status_code=500" [5m])) by (job) > 0.5
        # 條件必須持續 1 分鐘才會觸發
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "High rate of HTTP 500 errors detected in {{ $labels.job }}."
          description: "The application '{{ $labels.job }}' is experiencing a high rate of server errors (HTTP 500). Please investigate immediately."

透過以上設定，Loki 就能夠主動監控應用程式的錯誤日誌，並在問題發生時第一時間通知我們。

2. 儲存策略 (Storage Retention)

隨著時間推移，日誌量會不斷增長，帶來巨大的儲存成本。Loki 的 Compactor 元件提供了日誌保留 (Retention) 機制，讓我們可以自動刪除過期的日誌。

設定範例

Retention 的設定主要在 loki-config.yaml 的 compactor 和 limits_config 區塊。

# loki-config.yaml

compactor:
  # Compactor 的工作目錄
  working_directory: /tmp/loki/retention
  # 必須設為 true 才能啟用 retention
  retention_enabled: true
  # 刪除請求的儲存方式
  delete_request_store: filesystem

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: filesystem # 或 s3, gcs 等
      schema: v13
      index:
        prefix: index_
        # Retention 機制要求 index.period 必須為 24h
        period: 24h

limits_config:
  # 全域設定：所有日誌保留 30 天 (720 小時)
  retention_period: 720h

  # 也可以針對特定的 stream 設定不同的保留時間
  # retention_stream:
  #   - selector: '{namespace="dev"}'
  #     priority: 1
  #     period: 168h # 開發環境的日誌只保留 7 天
  #   - selector: '{namespace="prod"}'
  #     priority: 1
  #     period: 1440h # 生產環境的日誌保留 60 天

重要提示：

• compactor.retention_enabled 必須為 true。
• schema_config.index.period 必須設定為 24h。
• retention_period 的值必須是 24h 的倍數。

3. 多租戶 (Multi-tenancy)

在大型組織中，多個團隊或應用程式可能共用一套 Loki 系統。為了確保資料的隔離與安全，Loki 提供了多租戶模式。

運作原理

Loki 透過一個 HTTP Header X-Scope-OrgID 來識別不同的租戶。

• 當 auth_enabled: true 時，Loki 會檢查所有傳入的請求 (讀取和寫入)。
• 請求中必須包含 X-Scope-OrgID Header，Loki 會根據這個 ID 將日誌儲存到該租戶專屬的空間。
• 查詢時，Loki 同樣會檢查此 Header，並只返回屬於該租戶的日誌，從而實現資料隔離。

設定範例

1. 啟用 Loki 多租戶模式

   在 loki-config.yaml 中，只需一行設定：

   # loki-config.yaml
   
   auth_enabled: true
   

2. 設定 Promtail (或其他 Agent) 發送 Tenant ID

   在 Promtail 的設定檔中，為 clients 區塊加上 tenant_id。

   # promtail-config.yaml
   
   clients:
     - url: http://loki:3100/loki/api/v1/push
       # 這個值會被作為 X-Scope-OrgID Header 發送
       tenant_id: team-alpha 
   
   scrape_configs:
   # ...
   

3. 在 Grafana 中查詢特定租戶的日誌

   在 Grafana 設定 Loki 資料來源時，可以新增一個自訂的 HTTP Header。

   • Header: X-Scope-OrgID
   • Value: team-alpha

   這樣，所有透過此資料來源發出的查詢，都只會看到 team-alpha 這個租戶的日誌。如果需要查詢不同租戶的資料，可以建立多個對應的 Grafana 資料來源。

總結

今天我們學習了 Loki 的三項核心進階功能。透過 Ruler，我們能建立強大的告警系統；透過 儲存策略，我們能有效控制成本；透過 多租戶，我們能安全地服務多個團隊。掌握這些功能，將使我們的日誌監控平台更加完善、高效與可靠。