프로젝트의 싱크 구성

이 문서에서는 Cloud Console, Cloud Logging API, gcloud 명령줄 도구를 사용하여 로그 항목을 라우팅하도록 싱크를 만들고 관리하는 방법을 설명합니다.

요약하자면 필터 표현식 및 대상이 포함된 하나 이상의 싱크를 만들어 로그를 라우팅합니다. Logging에서 새로운 로그 항목을 수신하면 로그 항목이 각 싱크와 비교됩니다. 로그 항목이 싱크의 필터와 일치하면 로그 항목의 복사본이 싱크 대상에 기록됩니다. 싱크에 대한 더 포괄적인 개념 개요는 라우팅 및 스토리지 개요: 싱크를 참조하세요.

Cloud Console을 사용하여 다음을 수행할 수 있습니다.

  • 한 곳에서 모든 싱크를 보고 관리합니다.
  • 싱크를 만들기 전에 싱크의 필터와 일치하는 로그 항목을 미리 확인하세요.
  • 싱크의 대상 위치를 만들고 승인합니다.

하지만 Cloud Console에서는 Cloud 프로젝트에 싱크만 만들거나 볼 수 있습니다. gcloud 명령줄 도구 또는 Cloud Logging API를 사용하여 조직, 폴더, 또는 결제 계정에 싱크를 만들려면 집계 싱크를 참조하세요.

지원되는 대상

동일한 클라우드 프로젝트 내에서 또는 클라우드 프로젝트 간에 로그를 다음 대상으로 라우팅할 수 있습니다.

  • Cloud Storage: Cloud Storage 버킷에 저장된 JSON 파일입니다.
  • Pub/Sub: Pub/Sub 주제로 제공된 JSON 메시지 Logging과 함께 Splunk와 같은 타사 통합을 지원합니다.
  • BigQuery: BigQuery 데이터 세트에 생성된 테이블입니다.
  • 다른 Cloud Logging 버킷: Cloud Logging 로그 버킷에 있는 로그 항목입니다.

조직, 폴더 또는 결제 계정에서 싱크를 만들려면 집계 싱크를 참조하세요.

시작하기 전에

싱크를 만들려면 먼저 다음을 확인해야 합니다.

  • 로그 탐색기에서 볼 수 있는 로그가 포함된 Google Cloud 프로젝트가 있어야 합니다.

  • 로그를 전송할 소스 클라우드 프로젝트에 대해 다음 IAM 역할 중 하나가 있어야 합니다.

    • 소유자(roles/owner)
    • Logging 관리자(roles/logging.admin)
    • 로그 구성 작성자(roles/logging.configWriter)

    이러한 역할에 포함된 권한은 싱크를 생성, 삭제 또는 수정할 수 있게 해줍니다. IAM 역할 설정에 대한 자세한 내용은 Logging 액세스 제어 가이드를 참조하세요.

  • 지원되는 대상에 리소스가 있거나 이를 만들 수 있어야 합니다.

    gcloud 명령줄 도구, Cloud Console 또는 Google Cloud API를 사용하여 싱크 전에 로그 싱크 대상을 만들어야 합니다. 모든 조직의 모든 Cloud 프로젝트에서 대상을 만들 수 있지만 싱크의 서비스 계정에 대상에 쓰기 권한이 있는지 확인해야 합니다.

싱크 만들기

다음은 Cloud Console 또는 gcloud 명령줄 도구를 사용하여 클라우드 프로젝트에서 싱크 만들기에 대한 안내입니다.

Cloud 프로젝트당 최대 200개의 싱크를 만들 수 있습니다.

싱크를 만들려면 다음을 수행합니다.

Console

  1. Cloud Console에서 Logging > 로그 라우터 페이지로 이동합니다.

    로그 라우터로 이동

  2. 기존 Cloud 프로젝트를 선택합니다.

  3. 싱크 만들기를 선택합니다.

  4. 싱크 세부정보 패널에서 다음 세부정보를 입력합니다.

    • 싱크 이름: 싱크의 식별자를 제공합니다. 싱크를 만든 후에는 싱크 이름을 바꿀 수 없지만 이를 삭제하고 새 싱크를 만들 수 있습니다.

    • 싱크 설명(선택사항): 싱크의 목적 또는 사용 사례를 설명합니다.

  5. 싱크 대상 패널에서 싱크 서비스 및 대상을 선택합니다.

    • 싱크 서비스 선택: 로그를 라우팅할 서비스를 선택합니다.

    선택한 서비스를 기준으로 다음 대상 중에서 선택할 수 있습니다.

    • Cloud Logging 버킷: Logging 버킷을 선택하거나 만듭니다.
    • BigQuery 테이블: 라우팅된 로그를 수신할 특정 데이터 세트를 선택하거나 만듭니다. 파티션을 나눈 테이블도 사용할 수 있습니다.
    • Cloud Storage 버킷: 라우팅된 로그를 수신할 특정 Cloud Storage 버킷을 선택하거나 만듭니다.
    • Pub/Sub 주제: 라우팅된 로그를 수신할 특정 주제를 선택하거나 만듭니다.
    • Splunk: Splunk 서비스에 대한 Pub/Sub 주제를 선택합니다.
    • 기타 클라우드 프로젝트: Logging, BigQuery, Cloud Storage, Pub/Sub 서비스 및 대상 정보를 다음 형식으로 수동으로 추가합니다.

      SERVICE.googleapis.com/projects/PROJECT_ID/SINK_DESTINATION/DESTINATION_ID
      

      예를 들어 싱크 대상이 BigQuery 데이터 세트이면 싱크 대상은 다음과 같습니다.

      bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID
      

      클라우드 프로젝트 간에 로그를 라우팅할 때에도 적절한 대상 권한이 필요합니다.

  6. 포함 필터 빌드 패널에서 싱크에 포함할 로그를 선택합니다.

    1. 포함하려는 로그 항목과 일치하는 필터 표현식을 입력합니다. 필터를 설정하지 않으면 클라우드 프로젝트의 모든 로그가 대상으로 라우팅됩니다.

      예를 들어 데이터 액세스 로그를 단일 Logging 버킷으로 라우팅하도록 필터를 빌드해야 할 수 있습니다. 이 필터는 다음과 같습니다.

      LOG_ID("cloudaudit.googleapis.com/data_access") OR LOG_ID("externalaudit.googleapis.com/data_access")
      

      필터의 길이는 20,000자를 초과할 수 없습니다.

    2. 올바른 필터를 입력했는지 확인하려면 미리보기 로그를 선택합니다. 그러면 필터가 미리 채워진 새 탭에서 로그 탐색기가 열립니다.

  7. (선택사항) 제외 필터 빌드 패널에서 싱크에서 제외할 로그를 선택합니다.

    1. 제외 필터 이름 필드에 이름을 입력합니다.

    2. 제외 필터 빌드 섹션에서 제외할 로그 항목과 일치하는 필터 표현식을 입력합니다. 또한 sample 함수를 사용하여 제외할 로그 항목 부분을 선택할 수 있습니다.

    싱크당 최대 50개의 제외 필터를 만들 수 있습니다. 필터의 길이는 20,000자를 초과할 수 없습니다.

  8. 싱크 만들기를 선택합니다.

API

  1. 클라우드 프로젝트에서 로깅 싱크를 만들려면 Logging API에서 projects.sinks.create를 사용합니다. LogSink 객체에서 메서드 요청 본문에 적절한 필수 값을 제공합니다.

    • name: 싱크의 식별자입니다. 싱크를 만든 후에는 싱크 이름을 바꿀 수 없지만 이를 삭제하고 새 싱크를 만들 수 있습니다.
    • destination: 로그를 라우팅하려는 서비스 및 대상입니다. 예를 들어 싱크 대상이 BigQuery 데이터 세트이면 destination이 다음과 같습니다.

      bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID
      
  2. LogSink 객체에서 적절한 선택적 정보를 제공합니다.

    • filter: 싱크에 포함할 로그 항목과 일치하도록 filter 속성을 설정합니다. 필터를 설정하지 않으면 클라우드 프로젝트의 모든 로그가 대상으로 라우팅됩니다. 필터의 길이는 20,000자를 초과할 수 없습니다.
    • exclusions: 싱크에서 제외하려는 로그 항목과 일치하도록 이 속성을 설정합니다. 또한 sample 함수를 사용하여 제외할 로그 항목 부분을 선택할 수 있습니다. 싱크당 최대 50개의 제외 필터를 만들 수 있습니다.
    • description: 이 속성을 설정하여 싱크의 목적 또는 사용 사례를 기술합니다.
  3. projects.sinks.create를 호출하여 싱크를 만듭니다.

  4. API 응답으로 반환된 writer_identity 필드에서 서비스 계정 이름을 검색합니다.

  5. 서비스 계정에 싱크 대상에 대한 쓰기 권한을 부여합니다.

    싱크 대상에 이러한 변경을 적용할 권한이 없으면 이러한 변경을 할 수 있는 사람에게 서비스 계정 이름을 전송합니다.

    서비스 계정에 리소스 권한을 부여하는 방법에 대한 자세한 내용은 대상 권한 설정 섹션을 참조하세요.

Logging API를 사용하여 싱크 만들기에 대한 자세한 내용은 LogSink 참조를 확인하세요.

gcloud

싱크를 만들려면 다음 gcloud logging sinks create명령어를 실행합니다.

다음과 같이 명령어에서 변수에 대해 적절한 값을 제공합니다.

  • SINK_NAME: 싱크의 식별자입니다. 싱크를 만든 후에는 싱크 이름을 바꿀 수 없지만 이를 삭제하고 새 싱크를 만들 수 있습니다.
  • SINK_DESTINATION: 로그를 라우팅하려는 서비스 및 대상입니다. 예를 들어 싱크 대상이 BigQuery 데이터 세트이면 SINK_DESTINATION이 다음과 같습니다.

    bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID
    
  • OPTIONAL_FLAGS에는 다음 플래그가 포함됩니다.

    • --log-filter: 이 플래그를 사용하여 싱크에 포함하려는 로그 항목과 일치하는 필터를 설정합니다. 필터를 설정하지 않으면 클라우드 프로젝트의 모든 로그가 대상으로 라우팅됩니다.
    • --exclusion: 이 플래그를 사용하여 싱크에서 제외하려는 로그 항목에 대해 제외 필터를 설정합니다. 또한 sample 함수를 사용하여 제외할 로그 항목 부분을 선택할 수 있습니다. 이 플래그는 반복 가능합니다. 싱크당 최대 50개까지 제외 필터를 만들 수 있습니다.
    • --description: 이 플래그를 사용하여 싱크의 목적 또는 사용 사례를 기술할 수 있습니다.
gcloud logging sinks create SINK_NAME
SINK_DESTINATION OPTIONAL_FLAGS

예를 들어 Logging 버킷에 대해 싱크를 만들려는 경우 명령어가 다음과 같습니다.

gcloud logging sinks create my-sink logging.googleapis.com/projects/myproject123/locations/global/buckets/my-bucket \
  --log-filter='logName="projects/myproject123/logs/matched"' --description="My first sink"

추가 플래그 및 예시를 포함하여 gcloud 명령줄 도구를 사용하여 싱크를 만드는 방법에 대한 자세한 내용은 gcloud logging sinks 참조를 확인하세요.

싱크 대상에서 로그를 확인하는 방법에 대한 자세한 내용은 라우팅된 로그 찾기를 참조하세요.

싱크를 만든 후 logging.googleapis.com/exports/ 측정항목을 사용하여 수신된 로그 항목의 수와 볼륨을 볼 수 있습니다.

오류 알림을 받으면 라우팅 및 싱크 문제 해결을 참조하세요.

다른 클라우드 프로젝트에서 로그 버킷 간 로그 라우팅

싱크가 생성된 Cloud 프로젝트가 아닌 다른 Cloud 프로젝트의 대상으로 로그를 라우팅할 수 있습니다.

이렇게 하려면 다음 중 하나를 수행해야 합니다.

  • 싱크의 서비스 계정에 대상에 쓰기를 위한 roles/logging.bucketWriter 역할을 부여합니다. 자세한 내용은 대상 권한을 참조하세요.

  • 로그를 전송할 소스 클라우드 프로젝트에 대해 다음 IAM 권한 중 하나를 지정합니다.

    • 소유자(roles/owner)
    • Logging 관리자(roles/logging.admin)
    • 로그 구성 작성자(roles/logging.configWriter)

    대상 클라우드 프로젝트에서 새 Logging 버킷을 만드는 경우 다음 권한 중 하나를 포함해야 합니다.

싱크 관리

싱크가 생성된 후 여기에서 다음 작업을 수행할 수 있습니다.

  • 싱크 세부정보 보기
  • 싱크 업데이트
  • 싱크 사용 중지
  • 싱크 삭제

싱크를 보고 관리하려면 다음을 수행합니다.

Console

로그 라우터 페이지에서 싱크를 보고 관리할 수 있습니다.

로그 라우터로 이동

Cloud Console의 모든 위치에서 리소스 선택기를 사용하여 싱크가 포함된 Cloud 프로젝트를 선택했는지 확인합니다.

드롭다운 메뉴에서 프로젝트 선택

집계 싱크를 보려면 싱크가 포함된 조직, 폴더 또는 결제 계정을 선택하세요.

로그 라우터 인터페이스에는 싱크가 요약된 테이블이 있습니다. 각 테이블 행에는 싱크의 속성에 대한 정보가 포함됩니다.

  • 사용 설정: 싱크 상태가 사용 설정 또는 사용 중지되었는지를 나타냅니다.
  • 유형: 싱크의 대상 서비스입니다. 예를 들면 Cloud Logging bucket입니다.
  • 이름: 싱크가 생성될 때 제공된 대로의 싱크 식별자입니다. 예를 들면 _Default입니다.
  • 설명: 싱크가 생성될 때 제공된 대로의 싱크 설명입니다.
  • 대상: 라우팅된 로그 항목이 전송되는 대상의 전체 이름입니다.
  • 생성됨: 싱크가 생성된 날짜 및 시간입니다.
  • 업데이트됨: 싱크가 마지막으로 수정된 날짜 및 시간입니다.

각 테이블 행에는 메뉴 가 있으며 다음과 같은 옵션이 있습니다.

  • 싱크 세부정보 보기: 싱크의 이름, 설명, 대상 서비스, 대상, 포함 필터, 제외 필터를 표시합니다. 수정을 선택하면 싱크 수정 패널이 열립니다.
  • 싱크 수정: 싱크 매개변수를 업데이트할 수 있는 싱크 수정 패널이 열립니다.
  • 싱크 사용 중지: 싱크를 사용 중지하고 싱크의 대상 위치로 로그 라우팅을 중지합니다. 싱크 사용 중지에 대한 자세한 내용은 로그 수집 중지를 참조하세요.
  • 싱크 사용 설정: 사용 중지된 싱크를 사용 설정하고 싱크의 대상 위치로 로그 라우팅을 다시 시작합니다.
  • 싱크 삭제: 싱크를 삭제하고 싱크 대상으로 로그 라우팅을 중지할 수 있습니다. _Default_Required 싱크는 삭제할 수 없지만 _Default 싱크를 사용 중지하여 _Default Logging 버킷으로의 로그 라우팅을 중지할 수 있습니다.

열 이름을 클릭하여 데이터를 오름차순 또는 내림차순으로 정렬할 수 있습니다.

API

  • 클라우드 프로젝트의 싱크를 보려면 projects.sinks.list를 호출합니다.

  • 싱크의 세부정보를 보려면 projects.sinks.get을 호출합니다.

  • 싱크를 업데이트하려면 projects.sink.update를 호출합니다.

    싱크의 대상, 필터, 설명을 업데이트할 수 있습니다. 싱크를 사용 중지하거나 다시 사용 설정할 수도 있습니다.

  • 싱크를 사용 중지하려면 projects.sink.update를 호출하고 disabled 속성을 true로 설정합니다.

    싱크를 다시 사용 설정하려면 projects.sink.update를 호출하고 disabled 속성을 false로 설정합니다.

  • 싱크를 삭제하려면 projects.sinks.delete를 호출합니다.

    싱크를 삭제할 경우 로그 항목이 더 이상 라우팅되지 않습니다.

    Logging API를 사용하여 싱크를 관리하기 위한 이러한 메서드에 대한 자세한 내용은 LogSink 참조를 확인하세요.

gcloud

  • Cloud 프로젝트의 싱크 목록을 보려면 Logging API 메서드 projects.sinks.list에 해당하는 gcloud logging sinks list 명령어를 사용하세요.

    gcloud logging sinks list
    

    집계 싱크 목록을 보려면 적절한 플래그를 사용하여 싱크가 포함된 리소스를 지정합니다. 예를 들어 조직 수준에서 싱크를 만든 경우 --organization=ORGANIZATION_ID 플래그를 사용하여 조직의 싱크를 나열합니다.

  • 싱크를 설명하려면 gcloud logging sinks describe 명령어를 사용합니다. 이 명령어는 Logging API 메서드 projects.sinks.get에 해당합니다.

    gcloud logging sinks describe SINK_NAME
    
  • 싱크를 업데이트하려면 gcloud logging sinks update 명령어를 사용합니다. 이 명령어는 API 메서드 projects.sink.update에 해당합니다.

    대상, 필터, 설명을 변경하기 위해 또는 싱크를 사용 중지하거나 다시 사용 설정하기 위해 싱크를 업데이트할 수 있습니다.

    gcloud logging sinks update SINK_NAME  NEW_DESTINATION  --log-filter=NEW_FILTER

    해당 파트가 변경되지 않으면 NEW_DESTINATION 또는 --log-filter를 생략합니다.

    예를 들어 my-project-sink라는 싱크 대상을 my-second-gcs-bucket이라는 새로운 Cloud Storage 버킷 대상으로 업데이트할 때 명령어는 다음과 같습니다.

    gcloud logging sinks update  my-project-sink  storage.googleapis.com/my-second-gcs-bucket
    
  • 싱크를 사용 중지하려면 gcloud logging sinks update 명령어를 사용합니다. 이 명령어는 API 메서드 projects.sink.update에 해당하며 --disabled 플래그를 포함합니다.

    gcloud logging sinks update _Default  --disabled
    

    싱크를 다시 설정하려면 gcloud logging sinks update 명령어를 사용하고, --disabled 플래그를 삭제하고, --no-disabled 플래그를 포함합니다.

    gcloud logging sinks update _Default  --no-disabled
    
  • 싱크를 삭제하려면 gcloud logging sinks delete 명령어를 사용합니다. 이 명령어는 API 메서드 projects.sinks.delete에 해당합니다.

    gcloud logging sinks delete SINK_NAME
    

    싱크를 삭제할 경우 로그 항목이 더 이상 라우팅되지 않습니다.

    gcloud 명령줄 도구를 사용한 싱크 관리에 대한 자세한 내용은 gcloud logging sinks 참조를 확인하세요.

로그 수집 중지

Cloud 프로젝트마다 Logging은 _Required_Default라는 두 개의 로그 버킷을 자동으로 만듭니다. Logging은 해당 이름으로 지정된 버킷으로 로그를 라우팅하는 _Required_Default라는 로그 싱크 2개를 자동으로 만듭니다.

_Required 싱크를 사용 중지할 수 없습니다. 수집 가격 책정 또는 스토리지 가격 책정 모두 _Required 로그 버킷에 저장된 로그 데이터에 적용되지 않습니다. _Default 싱크를 사용 중지하여 로그가 _Default 버킷에 수집되지 않도록 할 수 있습니다. 또한 모든 사용자 정의 싱크를 사용 중지할 수 있습니다.

클라우드 프로젝트에서 _Default 버킷으로 로그를 전송하는 모든 싱크를 사용 중지하여 _Default 버킷에 대해 로그 수집을 중지하면 클라우드 프로젝트에서 _Default 버킷에 대해 새로운 Cloud Logging 수집 청구가 발생합니다. _Default 버킷에서 이전에 수집된 모든 로그가 버킷의 보관 기간을 완료했으면 _Default 버킷이 비어 있습니다.

로그를 _Default 버킷에 라우팅하는 클라우드 프로젝트를 사용 중지하려면 다음 단계를 수행합니다.

Console

  1. 로그 라우터로 이동합니다.

    로그 라우터로 이동

  2. 로그를 _Default 버킷으로 라우팅하는 모든 싱크를 찾으려면 싱크를 대상별로 필터링한 후 _Default를 입력합니다.

    로그를 기본 버킷으로 라우팅하는 모든 싱크 찾기

  3. 싱크마다 메뉴 를 선택한 후 싱크 사용 중지를 선택합니다.

이제 싱크가 사용 중지되고 Cloud 프로젝트가 더 이상 로그를 _Default 버킷으로 라우팅하지 않습니다.

사용 중지된 싱크를 다시 사용 설정하고 싱크 대상으로 로그 라우팅을 다시 시작하려면 다음을 수행합니다.

  1. 로그 라우터 페이지로 이동합니다.

    로그 라우터로 이동

  2. 이전에 로그를 _Default 버킷으로 라우팅하도록 구성된 모든 사용 중지된 싱크를 찾으려면 대상으로 싱크를 필터링한 후 _Default를 입력합니다.

  3. 싱크마다 메뉴 를 선택한 후 싱크 사용 설정을 선택합니다.

API

  1. 클라우드 프로젝트의 싱크를 보려면 Logging API 메서드 projects.sinks.list를 호출합니다.

    _Default 버킷으로 라우팅하는 싱크를 식별합니다.

  2. 예를 들어 _Default 싱크를 사용 중지하려면 projects.sink.update를 호출하고 disabled 속성을 true로 설정합니다.

이제 _Default 싱크가 사용 중지되고, 더 이상 로그를 _Default 버킷으로 라우팅하지 않습니다.

클라우드 프로젝트에서 _Default 버킷으로 라우팅하는 다른 싱크를 사용 중지하려면 위 단계를 반복합니다.

싱크를 다시 사용 설정하려면 projects.sink.update를 호출하고 disabled 속성을 false로 설정합니다.

gcloud

  1. Cloud 프로젝트의 싱크 목록을 보려면 Logging API 메서드 projects.sinks.list에 해당하는 gcloud logging sinks list 명령어를 사용하세요.

    gcloud logging sinks list
    
  2. _Default 버킷으로 라우팅하는 싱크를 식별합니다. 대상 이름 보기를 포함하여 싱크를 설명하려면 gcloud logging sinks describe 명령어를 사용합니다. 이 명령어는 Logging API 메서드 projects.sinks.get에 해당합니다.

    gcloud logging sinks describe SINK_NAME
    
  3. 예를 들어 _Default 싱크를 사용 중지하려면 gcloud logging sinks update 명령어를 사용하고 --disabled 플래그를 포함합니다.

    gcloud logging sinks update _Default  --disabled
    

이제 _Default 싱크가 사용 중지되고, 더 이상 로그를 _Default 버킷으로 라우팅하지 않습니다.

클라우드 프로젝트에서 _Default 버킷으로 라우팅하는 다른 싱크를 사용 중지하려면 위 단계를 반복합니다.

싱크를 다시 설정하려면 gcloud logging sinks update 명령어를 사용하고, --disabled 플래그를 삭제하고, --no-disabled 플래그를 포함합니다.

gcloud logging sinks update _Default  --no-disabled

대상 권한 설정

이 섹션에서는 Logging에 Identity and Access Management 권한을 부여하여 싱크의 대상에 로그를 작성할 수 있는 방법을 설명합니다. Logging 역할과 권한 전체 목록은 액세스 제어를 참조하세요.

싱크를 만들면 Logging에서 고유한 작성자 ID라는 싱크의 새로운 서비스 계정을 만듭니다. 싱크 대상은 이 서비스 계정이 로그 항목을 작성하도록 허용해야 합니다. 이 서비스 계정은 Cloud Logging에서 소유 및 관리하는 계정으로, 직접 관리할 수 없습니다. 싱크가 삭제되면 서비스 계정이 삭제됩니다.

동일한 클라우드 프로젝트에서 Logging 버킷 간에 로그를 라우팅하도록 싱크를 사용하는 경우 새 서비스 계정이 생성되지 않습니다. 고유한 작업자 ID 없이 싱크가 작동합니다. 다른 클라우드 프로젝트에서 Logging 버킷 간에 로그를 라우팅하도록 싱크를 사용하는 경우 새 서비스 계정이 생성됩니다.

싱크가 대상으로 라우팅하도록 권한을 설정하려면 다음을 수행합니다.

Console

  1. 새로운 싱크에서 싱크의 작성자 ID(이메일 주소)를 가져옵니다. 로그 라우터 페이지로 이동하여 메뉴 > 싱크 세부정보 보기를 선택합니다. 작성자 ID가 싱크 세부정보 패널에 표시됩니다.

  2. 대상에 대한 소유자 액세스 권한이 있으면 다음 방식으로 대상에 서비스 계정을 추가하세요.

    • 대상 위치가 Cloud Storage이면 Cloud Storage 버킷에 싱크의 작성자 ID를 추가하고 Storage 객체 생성자 역할을 부여합니다.
    • 대상 위치가 BigQuery이면 데이터 세트에 싱크의 작성자 ID를 추가하고 BigQuery 데이터 편집자 역할을 부여합니다.
    • 대상 위치가 Splunk를 포함하여 Pub/Sub이면 주제에 싱크의 작성자 ID를 추가하고 Pub/Sub 게시자 역할을 부여합니다.
    • 다른 클라우드 프로젝트에 있는 Logging 버킷 대상의 경우 싱크의 작성자 ID를 대상 로그 버킷에 추가하고 여기에 roles/logging.bucketWriter 권한을 부여합니다.

    싱크 대상에 대한 소유자 액세스 권한이 없으면 해당 권한이 있는 사용자에게 작성자 ID 서비스 계정 이름을 보냅니다. 그러면 해당 사용자는 이전 단계의 지침에 따라 작성자 ID를 싱크 대상에 추가해야 합니다.

API

  1. 싱크를 만들거나 수정하려면 API 메서드 projects.sinks.create 또는 projects.sinks.update를 호출합니다.

    uniqueWriterIdentitytrue로 설정합니다. 싱크를 업데이트할 때 공유 작성자를 사용하는 대신 고유 작성자를 사용하도록 변경할 수 있습니다. 기존 싱크가 이미 고유 작성자를 사용하는 경우 업데이트된 싱크가 동일한 작성자를 사용합니다.

    이 메서드는 새로운 작성자 ID가 포함된 새 싱크를 반환합니다.

  2. 대상에 대해 IAM 소유자 액세스 권한이 있으면 다음 방식으로 대상에 서비스 계정을 추가하세요.

    • 대상 위치가 Cloud Storage이면 Cloud Storage 버킷에 싱크의 작성자 ID를 추가하고 Storage 객체 생성자 역할을 부여합니다.
    • 대상 위치가 BigQuery이면 데이터 세트에 싱크의 작성자 ID를 추가하고 BigQuery 데이터 편집자 역할을 부여합니다.
    • 대상 위치가 Splunk를 포함하여 Pub/Sub이면 주제에 싱크의 작성자 ID를 추가하고 Pub/Sub 게시자 역할을 부여합니다.
    • 다른 클라우드 프로젝트에 있는 Logging 버킷 대상의 경우 싱크의 작성자 ID를 대상 로그 버킷에 추가하고 여기에 roles/logging.bucketWriter 권한을 부여합니다.

    싱크 대상에 대한 소유자 액세스 권한이 없으면 해당 권한이 있는 사용자에게 작성자 ID 서비스 계정 이름을 보냅니다. 그러면 해당 사용자는 이전 단계의 지침에 따라 작성자 ID를 싱크 대상에 추가해야 합니다.

gcloud

  1. 싱크 writerIdentity 필드에서 서비스 계정을 가져옵니다.

    gcloud logging sinks describe SINK_NAME
    

    서비스 계정은 다음과 유사합니다.

    serviceAccount:p123456789012-12345@gcp-sa-logging.iam.gserviceaccount.com
    
  2. 대상에 대해 IAM 소유자 액세스 권한이 있으면 다음 방식으로 대상에 서비스 계정을 추가하세요.

    • 대상 위치가 Cloud Storage이면 Cloud Storage 버킷에 싱크의 작성자 ID를 추가하고 Storage 객체 생성자 역할을 부여합니다.
    • 대상 위치가 BigQuery이면 데이터 세트에 싱크의 작성자 ID를 추가하고 BigQuery 데이터 편집자 역할을 부여합니다.
    • 대상 위치가 Splunk를 포함하여 Pub/Sub이면 주제에 싱크의 작성자 ID를 추가하고 Pub/Sub 게시자 역할을 부여합니다.
    • 다른 클라우드 프로젝트에 있는 Logging 버킷 대상의 경우 싱크의 작성자 ID를 대상 로그 버킷에 추가하고 여기에 roles/logging.bucketWriter 권한을 부여합니다.

    싱크 대상에 대한 소유자 액세스 권한이 없으면 해당 권한이 있는 사용자에게 작성자 ID 서비스 계정 이름을 보냅니다. 그러면 해당 사용자는 이전 단계의 지침에 따라 작성자 ID를 싱크 대상에 추가해야 합니다.

    예를 들어 다른 클라우드 프로젝트에서 Logging 버킷 간에 로그를 라우팅하는 경우 다음과 같이 서비스 계정에 roles/logging.bucketWriter를 추가합니다.

    1. 대상 Cloud 프로젝트에 대한 Cloud Identity and Access Management 정책을 가져와서 JSON 형식으로 로컬 파일에 작성합니다.

      gcloud projects get-iam-policy DESTINATION_PROJECT_ID --format json > output.json
      
    2. 서비스 계정이 만들어진 Cloud Logging 버킷에만 쓰기를 수행할 수 있는 IAM 조건을 추가합니다. 예를 들면 다음과 같습니다.

      {
      "bindings": [
       {
         "members": [
           "user:username@gmail.com"
         ],
         "role": "roles/owner"
       },
       {
         "members": [
           "[SERVICE_ACCOUNT]"
         ],
         "role": "roles/logging.bucketWriter",
         "condition": {
             "title": "Bucket writer condition example",
             "description": "Grants logging.bucketWriter role to service account [SERVICE_ACCOUNT] used by log sink [SINK_NAME]",
             "expression":
               "resource.name.endsWith(\'locations/global/buckets/BUCKET_ID\')"
         }
       }
      ],
      "etag": "BwWd_6eERR4=",
      "version": 3
      }
    3. IAM 정책을 업데이트합니다.

      gcloud projects set-iam-policy DESTINATION_PROJECT_ID output.json
      

코드 샘플

클라이언트 라이브러리 코드를 사용하여 선택한 언어로 싱크를 구성하려면 Logging 클라이언트 라이브러리: 로그 싱크를 참조하세요.

필터 예시

다음은 싱크를 만들 때 특히 유용한 몇 가지 필터 예시입니다.

포함 필터 및 제외 필터를 만들 때 유용할 수 있는 추가 예시는 샘플 쿼리를 참조하세요.

_Default 싱크 필터 복원

_Default 싱크의 필터를 수정한 경우 기본 필터를 복원해야 할 수 있습니다. 이렇게 하려면 다음 포함 필터를 입력합니다.

  NOT LOG_ID("cloudaudit.googleapis.com/activity") AND NOT \
  LOG_ID("externalaudit.googleapis.com/activity") AND NOT \
  LOG_ID("cloudaudit.googleapis.com/system_event") AND NOT \
  LOG_ID("externalaudit.googleapis.com/system_event") AND NOT \
  LOG_ID("cloudaudit.googleapis.com/access_transparency") AND NOT \
  LOG_ID("externalaudit.googleapis.com/access_transparency")

Google Kubernetes Engine 컨테이너 및 포드 로그 제외

GKE 시스템 namespaces에 대해 Google Kubernetes Engine 컨테이너 및 포드 로그를 제외하려면 다음 필터를 사용합니다.

resource.type = ("k8s_container" OR "k8s_pod")
resource.labels.namespace_name = (
"cnrm-system" OR
"config-management-system" OR
"gatekeeper-system" OR
"gke-connect" OR
"gke-system" OR
"istio-system" OR
"knative-serving" OR
"monitoring-system" OR
"kube-system")

GKE 시스템 logNames에 대해 Google Kubernetes Engine 노드 로그를 제외하려면 다음 필터를 사용합니다.

resource.type = "k8s_node"
logName:( "logs/container-runtime" OR
"logs/docker" OR
"logs/kube-container-runtime-monitor" OR
"logs/kube-logrotate" OR
"logs/kube-node-configuration" OR
"logs/kube-node-installation" OR
"logs/kubelet" OR
"logs/kubelet-monitor" OR
"logs/node-journal" OR
"logs/node-problem-detector")

Google Kubernetes Engine 노드, 포드, Cloud Logging에 수집된 컨테이너 로그 데이터의 볼륨을 보려면 Cloud Monitoring의 측정항목 탐색기를 사용합니다.

지원 용이성에 필요하지 않은 Dataflow 로그 제외

지원 용이성에 필요하지 않은 Dataflow 로그를 제외하려면 다음 필터를 사용합니다.

resource.type="dataflow_step"
labels."dataflow.googleapis.com/log_type"!="system" AND labels."dataflow.googleapis.com/log_type"!="supportability"

Cloud Logging에 수집된 Dataflow 로그 데이터의 볼륨을 보려면 Cloud Monitoring의 측정항목 탐색기를 사용합니다.

지원 용이성

Cloud Logging에서 로그가 수집되지 않도록 제외할 수 있는 기능을 제공하지만 지원 용이성에 도움이 되는 로그를 유지하는 것이 좋습니다. 이러한 로그를 사용하면 애플리케이션의 문제를 신속하게 해결하고 식별할 수 있습니다.

예를 들어 클러스터에서 발생하는 이벤트에 대해 생성되기 때문에 GKE 애플리케이션 및 클러스터를 문제 해결하는 데 유용합니다. 이러한 로그는 애플리케이션 코드 또는 기본 GKE 클러스터가 애플리케이션 오류를 일으키는지 확인하는 데 도움이 될 수 있습니다. GKE 시스템 로그에는 또한 Kubernetes API 서버 구성요소에서 생성되는 Kubernetes Audit Logging이 포함됩니다. 여기에는 kubectl 명령어 및 Kubernetes 이벤트를 사용하여 수행된 변경사항이 포함됩니다.

Dataflow의 경우 최소한 시스템 로그(labels."dataflow.googleapis.com/log_type"="system") 및 지원 로그(labels."dataflow.googleapis.com/log_type"="supportability")를 수집하는 것이 좋습니다. 이러한 로그는 개발자가 Dataflow 파이프라인을 관찰하고 문제를 해결하는 데 필수적이며, 사용자는 Dataflow 작업 세부정보 페이지를 사용하여 작업 로그를 보지 못할 수 있습니다.

다음 단계