조직 및 폴더 수준 로그를 취합하여 지원되는 목적지로 라우팅

이 문서에서는 집계 싱크를 만드는 방법을 설명합니다. 집계 싱크를 사용하면 조직 또는 폴더의 Google Cloud 리소스에서 생성된 로그를 결합하여 중앙 위치로 라우팅할 수 있습니다.

개요

집계 싱크는 조직 또는 폴더에 포함된 리소스의 로그 항목을 결합하고 목적지로 라우팅합니다.

이러한 리소스에서 쿼리하거나 이러한 리소스의 싱크를 통해 라우팅할 수 있는 로그를 제어하려면 집계 싱크를 비 가로채기 또는 가로채기로 구성할 수 있습니다.

  • 비 가로채기 집계 싱크는 하위 리소스의 싱크를 통해 로그를 라우팅합니다. 이 싱크를 사용하면 로그가 생성된 리소스의 로그 가시성을 유지할 수 있습니다. 비 가로채기 싱크는 하위 리소스에 표시되지 않습니다.

    예를 들어 조직에 포함된 폴더에서 생성된 모든 로그 항목을 중앙 Cloud Storage 버킷으로 라우팅하는 가로채기 집계 싱크를 만들 수 없습니다. 로그는 중앙 Cloud Storage 버킷과 로그가 생성된 리소스에 저장됩니다.

  • 가로채기 집계 싱크는 _Required 싱크를 제외하면 하위 리소스의 싱크를 통해 로그가 라우팅되지 않습니다. 이 싱크는 로그의 중복 사본이 여러 위치에 저장되지 않도록 방지하는 데 유용할 수 있습니다.

    예를 들어 데이터 액세스 감사 로그는 볼륨이 크고 여러 복사본을 저장하는 데 비용이 많이 들 수 있습니다. 데이터 액세스 감사 로그를 사용 설정한 경우 분석을 위해 모든 데이터 액세스 감사 로그를 중앙 프로젝트로 라우팅하는 폴더 수준의 가로채기 싱크를 만들 수 있습니다. 또한 이 가로채기 싱크는 하위 리소스의 싱크가 다른 곳으로 로그 사본을 라우팅하는 것을 방지합니다.

    가로채기 싱크는 로그가 _Required 싱크와도 일치하지 않는 한 하위 리소스의 로그 라우터를 통해 로그가 전달되지 않습니다. 로그를 가로채기 때문에 로그는 하위 리소스의 로그 기반 측정항목 또는 로그 기반 알림에 포함되지 않습니다. 하위 리소스의 로그 라우터 페이지에서 가로채기 싱크를 볼 수 있습니다.

싱크 관리에 대한 자세한 내용은 지원되는 목적지로 로그 라우팅: 싱크 관리를 참조하세요.

폴더 또는 조직당 싱크를 최대 200개까지 만들 수 있습니다.

지원되는 목적지

비 가로채기 집계 싱크를 사용하여 동일한 조직 및 폴더 내 또는 사이에서의 로그를 라우팅할 수 있습니다.

  • Cloud Logging 버킷: Cloud Logging에서 스토리지를 제공합니다. 로그 버킷은 여러 Google Cloud 프로젝트에서 수신한 로그 항목을 저장할 수 있습니다. Cloud Logging 데이터를 다른 데이트와 결합하려면, 로그 애널리틱스를 사용하도록 로그 버킷을 업그레이드한 후 연결된 BigQuery 데이터 세트를 만들면 됩니다. 로그 버킷에 저장된 로그 항목을 보는 방법을 자세히 알아보려면 쿼리 및 로그 보기 개요와 Cloud Logging 버킷으로 라우팅된 로그 보기를 참조하세요.
  • BigQuery 데이터 세트: BigQuery 데이터 세트에서 로그 항목의 스토리지를 제공합니다. 저장된 로그 항목에서 빅데이터 분석 기능을 사용할 수 있습니다. Cloud Logging 데이터를 다른 데이터 소스와 결합하려면, 로그 애널리틱스를 사용하도록 로그 버킷을 업그레이드한 후 연결된 BigQuery 데이터 세트를 만드는 것이 좋습니다. BigQuery로 라우팅된 로그 항목을 보는 방법을 자세히 알아보려면 BigQuery로 라우팅된 로그 보기를 참조하세요.
  • Cloud Storage 버킷: Cloud Storage에서 로그 항목의 스토리지를 제공합니다. 로그 항목은 JSON 파일로 저장됩니다. Cloud Storage로 라우팅된 로그 항목을 보는 방법을 자세히 알아보려면 Cloud Storage로 라우팅된 로그 보기를 참조하세요.
  • Pub/Sub 주제: 서드 파티 통합을 지원합니다. 로그 항목은 JSON 형식으로 지정된 후 Pub/Sub 주제로 라우팅됩니다. Pub/Sub로 라우팅된 로그 항목을 보는 방법을 자세히 알아보려면 Pub/Sub로 라우팅된 로그 보기를 참조하세요.
  • Splunk: Splunk를 지원합니다. Pub/Sub 주제로 로그 항목을 라우팅한 후 Splunk를 사용하여 해당 주제를 구독해야 합니다.
  • Google Cloud 프로젝트: 로그 항목을 다른 Google Cloud 프로젝트로 라우팅합니다. 다른 Google Cloud 프로젝트로 로그 항목을 라우팅하면 대상 프로젝트의 로그 라우터가 로그 항목을 수신하고 처리합니다. 수신된 로그 항목의 라우팅 방법은 대상 프로젝트의 싱크에 따라 결정됩니다. 대상 프로젝트가 로그 항목을 대상 프로젝트 소유의 로그 버킷으로 라우팅할 때, Error Reporting을 이용해 해당 로그 항목을 분석할 수 있습니다.
  • 기타 리소스: 로그 항목을 다른 프로젝트에 있는 지원 가능한 대상으로 라우팅합니다. 사용할 경로에 대해 자세히 알아보려면 대상 경로 형식을 참조하세요.

가로채기 싱크 권장 사항

가로채기 싱크를 만들 때 다음을 수행하는 것이 좋습니다.

  • 하위 리소스에 로그 라우팅을 독립적으로 제어해야 하는지 여부를 고려합니다. 하위 리소스가 특정 로그를 독립적으로 제어해야 하는 경우 가로채기 싱크가 이러한 로그를 라우팅하지 않는지 확인합니다.

  • 가로채기 싱크의 설명에 연락처 정보를 추가합니다. 이는 가로채기 싱크를 관리하는 사람이 로그를 가로채는 프로젝트를 관리하는 사용자와 다르면 유용할 수 있습니다.

  • 먼저 비 가로채기 집계 싱크를 만들어 싱크 구성을 테스트하여 올바른 로그가 라우팅되는지 확인합니다.

집계 싱크 및 VPC 서비스 제어

집계 싱크와 VPC 서비스 제어를 사용할 때는 다음 제한사항이 적용됩니다.

  • 집계 싱크는 서비스 경계 내 프로젝트의 데이터에 액세스할 수 있습니다. 집계 싱크가 경계 내 데이터에 액세스하는 것을 제한하려면 IAM을 사용하여 Logging 권한을 관리하는 것이 좋습니다.

  • VPC 서비스 제어에서는 폴더나 조직 리소스를 서비스 경계에 추가할 수 없습니다. 따라서 VPC 서비스 제어를 사용하여 집계 로그를 포함한 폴더 및 조직 수준의 로그를 보호할 수 없습니다. 폴더 또는 조직 수준에서 Logging 권한을 관리하려면 IAM을 사용하는 것이 좋습니다.

  • 폴더 또는 조직 수준 싱크를 사용하여 로그를 서비스 경계가 보호하는 리소스에 라우팅하는 경우 인그레스 규칙을 서비스 경계에 추가해야 합니다. 인그레스 규칙은 집계 싱크에서 사용하는 서비스 계정의 리소스에 대한 액세스를 허용해야 합니다. 자세한 내용은 다음 페이지를 참조하세요.

  • 서비스 경계에 대한 인그레스 또는 이그레스 정책을 지정하면 로그 싱크를 사용하여 로그를 Cloud Storage 리소스로 라우팅할 때 ANY_SERVICE_ACCOUNT 및 ANY_USER_ACCOUNT를 ID 유형으로 사용할 수 없습니다. 하지만 ANY_IDENTITY를 ID 유형으로 사용할 수 있습니다.

시작하기 전에

싱크를 만들기 전에 먼저 다음을 확인합니다.

  • 로그 탐색기에서 볼 수 있는 로그가 포함된 Google Cloud 폴더 또는 조직이 있습니다.

  • 로그를 라우팅할 Google Cloud 조직 또는 폴더에 다음 IAM 역할 중 하나가 있습니다.

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

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

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

    라우팅 목적지는 Google Cloud CLI, Google Cloud 콘솔, Google Cloud API를 통해 싱크 전에 생성해야 합니다. 모든 조직의 모든 Google Cloud 프로젝트에서 목적지을 만들 수 있지만 싱크의 서비스 계정에 목적지에 쓰기 권한이 있는지 확인해야 합니다.

집계 싱크 만들기

비 가로채기 집계 싱크를 만들려면 Google Cloud 조직 또는 폴더에서 싱크를 만들고 싱크의 includeChildren 매개변수를 True로 설정합니다. includeChildren 매개변수를 설정하면 싱크가 조직 또는 폴더에서 로그 항목을 라우팅하고, 포함된 폴더, 결제 계정 또는 Google Cloud 프로젝트에서도 (재귀적으로) 로그 항목을 라우팅할 수 있습니다. 가로채기 싱크를 만들려면 includeChildren 및 interceptChildren 매개변수를 모두 True로 설정합니다.

목적지로 라우팅할 로그 항목을 지정하려면 싱크의 포함 및 제외 필터를 설정합니다.

폴더 또는 조직의 집계 싱크를 만들려면 다음을 수행하세요.

콘솔

  1. Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 라우터를 선택합니다.

    로그 라우터로 이동

  2. 기존 폴더 또는 조직을 선택합니다.

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

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

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

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

  5. 싱크 목적지 패널에서 싱크 서비스 및 목적지을 선택합니다.

    • 싱크 서비스 선택: 로그를 라우팅할 서비스를 선택합니다. 가로채기 싱크를 만드는 경우 Google Cloud 프로젝트만 목적지로 선택할 수 있습니다.

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

    • Cloud Logging 버킷: Logging 버킷을 선택하거나 만듭니다. 로그 버킷을 만드는 경우 프로젝트 수준에서 만들어야 합니다. 폴더 또는 조직 수준에서는 로그 버킷을 만들 수 없습니다.
    • BigQuery 테이블: 라우팅된 로그를 수신할 특정 데이터 세트를 선택하거나 만듭니다. 파티션을 나눈 테이블도 사용할 수 있습니다.
    • Cloud Storage 버킷: 라우팅된 로그를 수신할 특정 Cloud Storage 버킷을 선택하거나 만듭니다.
    • Pub/Sub 주제: 라우팅된 로그를 수신할 특정 주제를 선택하거나 만듭니다.
    • Splunk: Splunk 서비스에 대한 Pub/Sub 주제를 선택합니다.

    • Google Cloud 프로젝트: 경로 로그를 수신할 Google Cloud 프로젝트를 선택합니다.

      예를 들어 싱크 목적지가 BigQuery 데이터 세트이면 싱크 목적지은 다음과 같습니다.

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

  6. 싱크에 포함할 로그 선택 패널에서 다음 중 하나를 수행합니다.

    • 비 가로채기 집계 싱크를 만들려면 이 리소스와 모든 하위 리소스에서 수집한 로그 포함을 선택합니다.

    • 가로채기 싱크를 만들려면 이 조직과 모든 하위 리소스에서 수집한 로그 가로채기를 선택합니다.

  7. 포함 필터 빌드 필드에 포함하려는 로그 항목과 일치하는 필터 표현식을 입력하여 대화상자를 완성합니다. 필터를 설정하지 않으면 선택한 리소스의 모든 로그가 목적지로 라우팅됩니다.

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

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

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

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

  9. (선택사항) 싱크에서 제외할 로그 선택 패널에서 다음을 수행합니다.

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

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

      예를 들어 특정 프로젝트의 로그가 목적지로 라우팅되지 않도록 제외하려면 다음 제외 필터를 추가합니다.

      logName:projects/PROJECT_ID

      여러 프로젝트에서 로그를 제외하려면 논리 연산자 OR을 사용하여 logName 절을 조인합니다.

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

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

API

싱크를 만들려면 Logging API에서 organizations.sinks.create 또는 folders.sinks.create를 사용합니다. 메서드의 인수를 다음과 같이 준비하세요.

  1. parent 매개변수는 싱크를 만들 Google Cloud 조직 또는 폴더로 설정합니다. 이 상위 요소는 다음 중 하나가 되어야 합니다.

    • organizations/ORGANIZATION_ID
    • folders/FOLDER_ID

  2. 메서드 요청 본문의 LogSink 객체에서 다음 중 하나를 수행합니다.

    • 비 가로채기 집계 싱크를 만들려면 includeChildren을 True로 설정합니다.

    • 가로채기 싱크를 만들려면 includeChildren 및 interceptChildren 매개변수를 True로 설정합니다.

  3. 포함하려는 로그 항목과 일치하도록 filter 속성을 설정합니다. 필터의 길이는 20,000자를 초과할 수 없습니다.

    유용한 필터의 예시는 집계 싱크의 필터 만들기를 참조하세요.

  4. 나머지 LogSink 필드는 일반 싱크와 동일하게 설정합니다. 자세한 내용은 지원되는 목적지로 로그 라우팅을 참조하세요.

  5. organizations.sinks.create 또는 folders.sinks.create를 호출하여 싱크를 만듭니다.

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

  7. 서비스 계정에 싱크 목적지에 대한 쓰기 권한을 부여합니다.

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

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

gcloud

집계 싱크를 만들려면 logging sinks create 명령어를 사용합니다. 비 가로채기 집계 싱크를 만들려면 --include-children 플래그를 지정합니다. 가로채기 싱크를 만들려면 --include-children 플래그와 --intercept-children 플래그를 모두 지정합니다.

  1. 싱크 이름, 싱크 목적지, 필터, 로그를 라우팅하는 폴더나 조직의 ID를 입력합니다. 다음 예시에서는 비 가로채기 집계 싱크를 만듭니다.

    gcloud logging sinks create SINK_NAME \
  SINK_DESTINATION  --include-children \
  --folder=FOLDER_ID --log-filter="LOG_FILTER"

    예를 들어 폴더 수준에서 집계 싱크를 만들고 목적지가 BigQuery 데이터 세트인 경우 명령어는 다음과 같을 수 있습니다.

    gcloud logging sinks create SINK_NAME \
  bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID --include-children \
  --folder=FOLDER_ID --log-filter="logName:activity"

    참고:

    • 조직 수준에서 싱크를 만들려면 --folder=FOLDER_ID를 --organization=ORGANIZATION_ID로 바꿉니다.

    • 싱크에 조직 내 모든 리소스를 포함하려면 --include-children 플래그를 설정해야 합니다. 이는 create에 --organization 플래그를 전달하는 경우에도 해당됩니다. false(기본값)로 설정하면 싱크가 호스트 리소스의 로그만 라우팅합니다.

    • 유용한 필터의 예시는 집계 싱크의 필터 만들기를 참조하세요.

  2. 명령어 결과에서 싱크를 만드는 데 사용된 서비스 계정 이름을 검색합니다.

  3. 서비스 계정에 싱크 목적지에 대한 쓰기 권한을 부여합니다.

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

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

싱크에서 변경사항을 적용하는 데 몇 분 정도 걸릴 수 있습니다.

집계 싱크를 위한 필터 만들기

여타 싱크와 마찬가지로 집계 싱크에도 개별 로그 항목을 선택하는 필터가 포함됩니다. 집계 싱크를 만드는 데 사용할 수 있는 필터의 예시는 로그 탐색기를 사용하는 샘플 쿼리를 참조하세요.

다음은 집계 싱크 기능을 사용할 때 유용한 필터 비교의 예시입니다. 일부 예에서는 다음과 같은 표기법을 사용합니다.

  • :은 하위 문자열 연산자입니다. = 연산자를 대체하지 마세요.
  • ...은 추가 필터 비교를 나타냅니다.
  • 변수는 색상별 텍스트로 표시됩니다. 변수 값을 유효한 값으로 바꿉니다.

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

필터링 문법에 대한 자세한 내용은 Logging 쿼리 언어를 참조하세요.

로그 소스 선택

집계 싱크의 경우 조직 또는 폴더의 각 하위 리소스에 대해 하위 리소스로 전송되는 각 로그 항목에 싱크의 포함 및 제외 필터가 적용됩니다. 포함 필터와 일치하고 제외되지 않은 로그 항목은 라우팅됩니다.

싱크에서 모든 하위 리소스의 로그를 라우팅하도록 하려면 싱크의 포함 및 제외 필터에 프로젝트, 폴더, 조직을 지정하지 마세요. 예를 들어 다음 필터를 사용하여 조직에 대해 집계 싱크를 구성한다고 가정합니다.

resource.type="gce_instance"

이전 필터를 사용하면 해당 조직의 모든 하위 요소에 작성된 Compute Engine 인스턴스의 리소스 유형이 있는 로그가 집계 싱크에 의해 목적지로 라우팅됩니다.

그러나 집계 싱크를 사용하여 특정 하위 리소스에서만 로그를 라우팅하려는 상황이 발생할 수 있습니다. 예를 들어 규정 준수를 위해 특정 폴더 또는 프로젝트의 감사 로그를 자체 Cloud Storage 버킷에 저장해야 할 수 있습니다. 이 경우 포함 필터를 구성하여 라우팅할 로그가 있는 각 하위 리소스를 지정합니다. 폴더와 해당 폴더 내의 모든 프로젝트에서 로그를 라우팅하려면 필터에서 폴더와 해당 폴더에 포함된 각 프로젝트를 나열하고 OR 절과 함께 문을 조인해야 합니다.

다음 필터는 로그를 특정 Google Cloud 프로젝트, 폴더 또는 조직으로 제한합니다.

logName:"projects/PROJECT_ID/logs/" AND ... 
logName:("projects/PROJECT_A_ID/logs/" OR "projects/PROJECT_B_ID/logs/") AND ... 
logName:"folders/FOLDER_ID/logs/" AND ... 
logName:"organizations/ORGANIZATION_ID/logs/" AND ...

예를 들어 my-folder 폴더에 기록된 Compute Engine 인스턴스에 기록된 로그만 라우팅하려면 다음 필터를 사용합니다.

logName:"folders/my-folder/logs/" AND resource.type="gce_instance"

이전 필터를 사용하면 my-folder의 하위 요소인 Google Cloud 프로젝트에 기록된 로그를 포함하여 my-folder 이외의 리소스에 작성된 로그는 목적지로 라우팅되지 않습니다.

모니터링 리소스 선택

Google Cloud 프로젝트 내의 특정 모니터링 리소스에서만 로그를 라우팅하려면 여러 가지 비교를 사용하여 리소스를 정확하게 지정합니다.

logName:"projects/PROJECT_ID/logs" AND
resource.type=RESOURCE_TYPE AND
resource.labels.instance_id=INSTANCE_ID

리소스 유형 목록은 모니터링 리소스 유형을 참조하세요.

로그 항목 샘플 선택

로그 항목 중 임의의 샘플을 라우팅하려면 기본 제공 함수 sample을 추가합니다. 예를 들어 현재 필터와 일치하는 로그 항목의 10%만 라우팅하려면 다음과 같이 추가합니다.

sample(insertId, 0.10) AND ...

자세한 내용은 sample 함수를 참조하세요.

Cloud Logging 필터에 대한 자세한 내용은 Logging 쿼리 언어를 참조하세요.

목적지 권한 설정

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

현재 프로젝트에서 로그 버킷이 아닌 다른 목적지로 로그를 라우팅하는 싱크를 만들거나 업데이트할 때 해당 싱크의 서비스 계정이 필요합니다. Logging은 서비스 계정을 자동으로 만들고 관리합니다.

  • 2023년 5월 22일자로 싱크를 만들고 기본 리소스에 대한 서비스 계정이 없으면 Logging에서 서비스 계정을 만듭니다. Logging은 기본 리소스의 모든 싱크에 대해 동일한 서비스 계정을 사용합니다. 리소스는 Google Cloud 프로젝트, 조직, 폴더, 결제 계정일 수 있습니다.
  • 2023년 5월 22일 이전에 Logging은 각 싱크에 대한 서비스 계정을 만들었습니다. 2023년 5월 22일부터 Logging은 기본 리소스의 모든 싱크에 공유 서비스 계정을 사용합니다.

싱크의 작성자 ID는 해당 싱크와 연결된 서비스 계정의 식별자입니다. 현재 Google Cloud 프로젝트의 로그 버킷에 쓰지 않는 한 모든 싱크는 작성자 ID를 가집니다.

서비스 경계로 보호되는 리소스로 로그를 라우팅하려면 해당 싱크의 서비스 계정을 액세스 수준에 추가한 후 목적지 서비스 경계에 할당해야 합니다. 비집계 싱크에는 이 작업이 필요하지 않습니다. 자세한 내용은 VPC 서비스 제어: Cloud Logging을 참조하세요.

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

콘솔

  1. 싱크의 서비스 계정에 대한 정보를 가져오려면 다음을 수행합니다.

    1. Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 라우터를 선택합니다.

      로그 라우터로 이동

    2. 메뉴를 선택한 다음 싱크 세부정보 보기를 선택합니다.

      싱크 세부정보 패널에서 writerIdentity 필드에는 서비스 계정의 ID가 포함됩니다. serviceAccount: 문자열은 서비스 계정 ID의 일부입니다. 예를 들면 다음과 같습니다.

      serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com

  2. 목적지 프로젝트에서 작성자 ID에 서비스 계정이 목적지에 쓰는 데 필요한 역할을 부여합니다. 주 구성원에게 역할을 부여하려면 소유자 역할(roles/owner)이 있어야 합니다.

    • 목적지 위치가 Cloud Storage이면 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 스토리지 객체 생성자 역할(roles/storage.objectCreator)을 부여합니다.
    • 목적지 위치가 BigQuery이면 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 BigQuery 데이터 편집자 역할(roles/bigquery.dataEditor)을 부여합니다.
    • Splunk를 포함한 Pub/Sub 목적지의 경우, IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후Pub/Sub 게시자 역할(roles/pubsub.publisher)을 부여합니다.
    • 다른 Google Cloud 프로젝트에 있는 Logging 버킷 목적지의 경우 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 로그 버킷 작성자 역할(roles/logging.bucketWriter)을 부여합니다.
    • Google Cloud 프로젝트 목적지의 경우 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 로그 작성자 역할(roles/logging.logWriter)을 부여합니다. 특히 주 구성원에게는 logging.logEntries.route 권한이 필요합니다.
    싱크의 목적지에 소유자 액세스 권한이 없으면 프로젝트 소유자에게 작성자 ID를 주 구성원으로 추가하도록 요청하세요.

API

  1. 싱크의 서비스 계정에 대한 정보를 가져오려면 API 메서드 organizations.sinks.get 또는 folders.sinks.get을 호출합니다.

    writerIdentity 필드에는 서비스 계정의 ID가 포함됩니다. serviceAccount: 문자열은 서비스 계정 ID의 일부입니다. 예를 들면 다음과 같습니다.

    serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com

  2. 목적지 프로젝트에서 작성자 ID에 서비스 계정이 목적지에 쓰는 데 필요한 역할을 부여합니다. 주 구성원에게 역할을 부여하려면 소유자 역할(roles/owner)이 있어야 합니다.

    • 목적지 위치가 Cloud Storage이면 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 스토리지 객체 생성자 역할(roles/storage.objectCreator)을 부여합니다.
    • 목적지 위치가 BigQuery이면 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 BigQuery 데이터 편집자 역할(roles/bigquery.dataEditor)을 부여합니다.
    • Splunk를 포함한 Pub/Sub 목적지의 경우, IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후Pub/Sub 게시자 역할(roles/pubsub.publisher)을 부여합니다.
    • 다른 Google Cloud 프로젝트에 있는 Logging 버킷 목적지의 경우 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 로그 버킷 작성자 역할(roles/logging.bucketWriter)을 부여합니다.
    • Google Cloud 프로젝트 목적지의 경우 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 로그 작성자 역할(roles/logging.logWriter)을 부여합니다. 특히 주 구성원에게는 logging.logEntries.route 권한이 필요합니다.
    싱크의 목적지에 소유자 액세스 권한이 없으면 프로젝트 소유자에게 작성자 ID를 주 구성원으로 추가하도록 요청하세요.

gcloud

  1. 싱크의 서비스 계정에 대한 정보를 가져오려면 다음 명령어를 실행합니다.

    gcloud logging sinks describe SINK_NAME

    writerIdentity 필드에는 서비스 계정의 ID가 포함됩니다. serviceAccount: 문자열은 서비스 계정 ID의 일부입니다. 예를 들면 다음과 같습니다.

    serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com

  2. 목적지 프로젝트에서 작성자 ID에 서비스 계정이 목적지에 쓰는 데 필요한 역할을 부여합니다. 주 구성원에게 역할을 부여하려면 소유자 역할(roles/owner)이 있어야 합니다.

    • 목적지 위치가 Cloud Storage이면 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 스토리지 객체 생성자 역할(roles/storage.objectCreator)을 부여합니다.
    • 목적지 위치가 BigQuery이면 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 BigQuery 데이터 편집자 역할(roles/bigquery.dataEditor)을 부여합니다.
    • Splunk를 포함한 Pub/Sub 목적지의 경우, IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후Pub/Sub 게시자 역할(roles/pubsub.publisher)을 부여합니다.
    • 다른 Google Cloud 프로젝트에 있는 Logging 버킷 목적지의 경우 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 로그 버킷 작성자 역할(roles/logging.bucketWriter)을 부여합니다.
    • Google Cloud 프로젝트 목적지의 경우 IAM을 사용하여 싱크의 작성자 ID를 주 구성원으로 추가한 후 로그 작성자 역할(roles/logging.logWriter)을 부여합니다. 특히 주 구성원에게는 logging.logEntries.route 권한이 필요합니다.
    싱크의 목적지에 소유자 액세스 권한이 없으면 프로젝트 소유자에게 작성자 ID를 주 구성원으로 추가하도록 요청하세요.

다음 단계