이 페이지는 Cloud Translation API를 통해 번역되었습니다.

워크플로에서 로그 수집

이 페이지에서는 로깅 및 데이터 관측 가능성을 지원하기 위해 Google Distributed Cloud (GDC) 에어 갭 어플라이언스 환경에서 워크플로의 로그를 수집하는 프로세스를 설명합니다.

로그는 GDC에서 서비스의 작업을 관리할 때 조건과 작업을 기록합니다. 구성요소에서 생성하는 로그를 스크랩하여 이벤트와 활동을 기록할 수 있습니다. 로깅 플랫폼은 로깅 타겟을 통해 워크플로에서 생성된 프로젝트 수준 로그를 수집하는 맞춤 API를 제공합니다.

로그 데이터 수집을 시작하려면 관리 API 서버의 프로젝트 네임스페이스에 LoggingTarget 커스텀 리소스를 배포합니다. 로그 수집기가 워크플로에서 데이터를 가져오면 로깅 플랫폼은 모든 로그 소스의 로그를 집계하고, 색인을 추가하고, 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 뷰어: LoggingTarget 커스텀 리소스를 봅니다. LoggingTarget 뷰어 (loggingtarget-viewer) 역할을 요청합니다.
플랫폼 관리자: 관리 API 서버의 platform-obs 네임스페이스에서 LoggingTarget 커스텀 리소스를 관리하는 데 필요한 권한을 얻으려면 조직 IAM 관리자에게 platform-obs 네임스페이스에서 다음 클러스터 역할 중 하나를 부여해 달라고 요청하세요.
- LoggingTarget PA Creator: LoggingTarget 커스텀 리소스를 만듭니다. LoggingTarget PA Creator (loggingtarget-pa-creator) 클러스터 역할을 요청합니다.
- LoggingTarget PA 편집자: LoggingTarget 커스텀 리소스를 수정합니다. LoggingTarget PA 편집자 (loggingtarget-pa-editor) 클러스터 역할을 요청합니다.
- LoggingTarget PA 뷰어: LoggingTarget 맞춤 리소스를 봅니다. LoggingTarget PA Viewer (loggingtarget-pa-viewer) 클러스터 역할을 요청합니다.

작업 로그 수집

운영 로그는 GDC의 애플리케이션 및 서비스에서 진행 중인 작업을 관리할 때 조건, 변경사항, 작업을 기록합니다. LoggingTarget 커스텀 리소스를 관리 API 서버에 배포하여 프로젝트 수준에서 특정 서비스의 운영 로그를 수집하는 시스템 로깅 파이프라인을 구성합니다.

서비스에서 운영 로그를 수집하려면 다음 단계를 완료하세요.

관리 API 서버에서 LoggingTarget 커스텀 리소스를 구성하여 운영 로그를 수집할 선택한 포드, 프로젝트 네임스페이스, 추가 설정을 지정합니다. LoggingTarget의 모양을 알아보려면 LoggingTarget 커스텀 리소스 구성을 참고하세요.
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).
파이프라인이 프로젝트의 추가 구성요소에서 로그를 수집하기 시작합니다.
프로젝트의 Grafana 인스턴스에서 로그를 쿼리합니다. 자세한 내용은 로그 쿼리 및 보기를 참고하세요.

서비스의 다양한 로그 수준에 Grafana의 기본 제공 색상 코딩 기능을 사용합니다. 로그 수준 값 설정에 관한 자세한 내용은 https://grafana.com/docs/grafana/latest/explore/logs-integration/을 참고하세요.

`LoggingTarget` 커스텀 리소스 구성

LoggingTarget 커스텀 리소스는 로깅 파이프라인에 GDC 프로젝트 내의 특정 서비스에서 로그를 수집하도록 지시합니다. 로그를 수집하는 타겟, 로그 파서, 액세스 수준, 추가 설정을 지정할 수 있습니다.

이 리소스는 다음 구성을 정의합니다.

타겟: 로그를 수집할 포드와 컨테이너를 선택하는 기준입니다. 클러스터 이름, 포드 이름 접두사, 컨테이너 이름 접두사를 지정할 수 있습니다.
로그 분석기: 로그 항목을 해석하고, 로그 출력을 라벨에 매핑하고, 관련 필드를 추출하는 사전 정의된 파서입니다.
서비스 식별: 더 쉽게 식별하고 필터링할 수 있도록 로그 항목에 라벨로 적용된 서비스 이름입니다.
승인: 수집된 로그를 볼 수 있는 사용자를 제어하는 로그 항목의 액세스 수준입니다.

참고: 기본적으로 모든 운영 로그 항목은 프로젝트 네임스페이스의 테넌트 ID에 저장됩니다. 이 동작을 덮어쓰려면 LoggingTarget 커스텀 리소스에 logAccessLevel 값을 제공하세요.

LoggingTarget 커스텀 리소스 내에서 이러한 매개변수를 구성하면 서비스의 로그 수집 및 구성을 정확하게 제어할 수 있습니다.

다음 단계에 따라 서비스에서 운영 로그를 수집하세요.

로그를 수집할 GDC 프로젝트를 확인합니다.
LoggingTarget 구성에서 운영 로그를 수집할 포드, 프로젝트 네임스페이스, 추가 설정을 지정합니다.

다음 YAML 파일은 my-project-namespace의 LoggingTarget 구성의 예를 보여줍니다. 여기서 로그를 수집할 포드 이름 접두사는 my-pod-prefix이고, 로그 항목의 액세스 수준은 애플리케이션 운영자 (ao)에게 부여되며, 서비스 이름은 my-service-name이고, 로그 형식은 JSON입니다.
```
# 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 참조 문서를 참고하세요.
타겟 포드와 동일한 네임스페이스 내의 관리 API 서버에 LoggingTarget 구성을 적용합니다.
```
kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml
```
다음을 바꿉니다.
- KUBECONFIG_PATH: 관리 API 서버의 kubeconfig 파일 경로입니다.
- LOGGING_TARGET_NAME: LoggingTarget 정의 파일의 이름(예: my-service-logging-target)
로깅 파이프라인이 프로젝트의 추가 구성요소에서 로그를 수집하기 시작합니다.

Grafana 사용자 인터페이스 또는 로그 쿼리 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 정의 파일의 이름입니다.