收集工作流程的記錄

本頁說明如何從 Google Distributed Cloud (GDC) 實體隔離裝置環境中的工作流程收集記錄，以利記錄和資料可觀測性。

當您在 GDC 中管理服務的操作時，記錄會記錄條件和動作。您可以擷取元件產生的記錄，以記錄事件和活動。記錄平台提供自訂 API，可透過記錄目標收集工作流程產生的專案層級記錄。

如要開始收集記錄資料，請將LoggingTarget自訂資源部署至 Management API 伺服器中的專案命名空間。記錄收集器從工作流程提取資料後，記錄平台會匯總所有記錄來源的記錄、新增索引，並根據 LoggingTarget 自訂資源的設定，將記錄與標籤建立關聯。

如要透過 Grafana 使用者介面存取收集的記錄，請參閱「查詢和查看記錄」一文。

如要瞭解如何導入記錄功能以觀察資料，請參閱 Kubernetes 社群指南：

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

事前準備

如要取得管理 LoggingTarget 自訂資源所需的權限，請要求機構 IAM 管理員或專案 IAM 管理員授予您相關的 LoggingTarget 角色。

視存取層級和所需權限而定，您可能會在機構或專案中取得這項資源的建立者、編輯者或檢視者角色。詳情請參閱「準備 IAM 權限」。

  • 應用程式運算子：如要取得管理 API 伺服器中專案的 LoggingTarget 自訂資源所需權限，請專案 IAM 管理員在專案命名空間中授予您下列其中一個角色：

    • LoggingTarget Creator：建立 LoggingTarget 自訂資源。要求 LoggingTarget 建立者 (loggingtarget-creator) 角色。
    • LoggingTarget Editor：編輯或修改 LoggingTarget 自訂資源。要求 LoggingTarget 編輯者 (loggingtarget-editor) 角色。
    • LoggingTarget Viewer：檢視 LoggingTarget 自訂資源。要求 LoggingTarget 檢視者 (loggingtarget-viewer) 角色。

  • 平台管理員：如要取得管理 API 伺服器中 platform-obs 命名空間內 LoggingTarget 自訂資源所需的權限，請機構 IAM 管理員在 platform-obs 命名空間中授予您下列其中一個叢集角色：

    • LoggingTarget PA Creator：建立 LoggingTarget 自訂資源。要求 LoggingTarget PA 建立者 (loggingtarget-pa-creator) 叢集角色。
    • LoggingTarget PA Editor：編輯或修改LoggingTarget自訂資源。要求 LoggingTarget PA 編輯者 (loggingtarget-pa-editor) 叢集角色。
    • LoggingTarget PA Viewer：檢視 LoggingTarget 自訂資源。要求 LoggingTarget PA 檢視者 (loggingtarget-pa-viewer) 叢集角色。

收集作業記錄檔

當您在 GDC 上管理應用程式和服務的持續作業時，作業記錄會記錄條件、變更和動作。將 LoggingTarget 自訂資源部署至 Management API 伺服器，即可設定系統記錄管道，從專案層級的特定服務收集作業記錄。

如要從服務收集作業記錄，請完成下列步驟：

  1. 在 Management API 伺服器中設定 LoggingTarget 自訂資源，指定要收集作業記錄的所選 Pod、專案命名空間和任何其他設定。如要瞭解 LoggingTarget 的外觀，請參閱「設定 LoggingTarget 自訂資源」。

  2. 將 LoggingTarget 自訂資源部署至 Management API 伺服器中的專案命名空間：

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAME

    更改下列內容：

    • MANAGEMENT_API_SERVER：區域管理 API 伺服器的 kubeconfig 路徑。
    • LOGGING_TARGET_NAME：LoggingTarget 自訂資源的名稱，例如 my-service-logging-target.yaml。

    管道會開始從專案的其他元件收集記錄。

  3. 從專案的 Grafana 執行個體查詢記錄。詳情請參閱「查詢及查看記錄」。

使用 Grafana 的內建顏色編碼功能，為服務的不同記錄檔層級設定顏色。如要進一步瞭解如何設定記錄層級值，請參閱 https://grafana.com/docs/grafana/latest/explore/logs-integration/。

設定 LoggingTarget 自訂資源

LoggingTarget 自訂資源會指示記錄管道從 GDC 專案中的特定服務收集記錄。您可以指定要收集記錄的目標、記錄剖析器、存取層級，以及任何其他設定。

這項資源定義下列設定：

  • 目標：選取要收集記錄的 Pod 和容器所用的條件。您可以指定叢集名稱、Pod 名稱前置字元和容器名稱前置字元。
  • 記錄分析工具：預先定義的剖析器，可解讀記錄項目、將記錄輸出內容對應至標籤，以及擷取相關欄位。
  • 服務識別：套用至記錄項目的服務名稱，方便識別及篩選。

  • 授權：記錄項目的存取層級，可控管誰能查看收集的記錄。

在 LoggingTarget 自訂資源中設定這些參數，即可精確控制服務記錄的收集和整理方式。

如要從服務收集作業記錄，請按照下列步驟操作：

  1. 決定要從哪個 GDC 專案收集記錄。

  2. 在 LoggingTarget 設定中，指定要收集作業記錄的 Pod、專案命名空間，以及任何其他設定。

    下列 YAML 檔案顯示 LoggingTarget 中的 LoggingTarget 設定範例，其中要收集記錄的 Pod 名稱前置字元為 my-pod-prefix，記錄項目的存取層級授予應用程式運算子 (ao)，服務名稱為 my-service-name，記錄格式為 JSON：my-project-namespace

    # Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
  # Choose a namespace that matches the namespace of the workload pods.
  namespace: my-project-namespace
  name: my-service-logging-target
spec:
  selector:
    matchPodNames:
      - my-pod-prefix
  parser: json
  logAccessLevel: ao
  serviceName: my-service-name

    如需其他欄位和選項，請參閱完整LoggingTarget規格和 API 參考說明文件。

  3. 在與目標 Pod 相同的命名空間中，將 LoggingTarget 設定套用至 Management API 伺服器：

    kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml

    更改下列內容：

    • KUBECONFIG_PATH：管理 API 伺服器的 kubeconfig 檔案路徑。
    • LOGGING_TARGET_NAME：定義檔案的名稱，例如 my-service-logging-target。LoggingTarget

    記錄管道會開始從專案的其他元件收集記錄。

您可以使用 Grafana 使用者介面或 Log Query API，查詢收集到的記錄。詳情請參閱「查詢及查看記錄」。

如果您使用 Grafana 查詢記錄，可以運用內建的顏色編碼功能，為服務的不同記錄層級設定顏色。如要進一步瞭解如何設定記錄層級值，請參閱 https://grafana.com/docs/grafana/latest/explore/logs-integration/。

完成LoggingTarget規格

下列 YAML 檔案範例顯示 LoggingTarget 自訂資源的完整規格。如需欄位的完整說明，請參閱 API 參考說明文件。

# Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
  # Choose a namespace that matches the namespace of the workload pods.
  namespace: PROJECT_NAMESPACE
  name: LOGGING_TARGET_NAME
spec:
  # Choose a matching pattern that identifies the pods for this job.
  # Optional.
  # Relationship between different selectors: 'AND'
  selector:
    # The clusters to collect logs from.
    # The default configuration is to collect logs from all clusters.
    # The relationship between different clusters is an 'OR' relationship.
    # Optional
    matchClusters:
    - my-cluster
    - another-cluster

    # The pod name prefixes to collect logs from.
    # The logging platform scrapes all pods with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional.
    matchPodNames:
      - my-pod-prefix
      - another-pod-prefix

    # The container name prefixes to collect logs from.
    # The logging platform scrapes all containers with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional.
    matchContainerNames:
      - my-container-prefix
      - another-container-prefix

  # Choose the predefined parser for log entries.
  # Use parsers to map the log output to labels and extract fields.
  # Specify the log format.
  # Optional.
  # Options: klog_text, klog_json, klogr, gdch_json, json
  parser: klog_text

  # Specify an access level for log entries.
  # The default value is 'ao'.
  # Optional.
  # Options: ao, pa, io
  logAccessLevel: ao

  # Specify a service name to be applied as a label.
  # For user workloads consider this field as a workload name.
  # Required.
  serviceName: my-service-name

  # The additional static fields to apply to log entries.
  # The field is a key-value pair, where the field name is the key and
  # the field value is the value.
  # Optional.
  additionalFields:
    app: workload2
    key: value

更改下列內容：

  • PROJECT_NAMESPACE：您的專案命名空間。
  • LOGGING_TARGET_NAME：LoggingTarget 定義檔案的名稱。