로그 항목 라우팅

이 문서에서는 Cloud Logging이 Google Cloud에서 수신한 로그 항목을 라우팅하는 방법을 설명합니다. 라우팅 대상에는 여러 가지 유형이 있습니다. 예를 들어 로그 항목을 저장하는 로그 버킷과 같은 대상으로 로그 항목을 라우팅할 수 있습니다. 로그 데이터를 서드 파티 대상으로 내보내려면 로그 항목을 Pub/Sub로 라우팅하면 됩니다. 또한 로그 항목을 여러 대상으로 라우팅할 수 있습니다.

크게 보면 이것은 Cloud Logging이 로그 항목을 라우팅하고 저장하는 방법입니다.

Cloud Logging이 로그 항목을 라우팅하는 방식을 보여주는 그림

로그 라우터 정보

각 Google Cloud 프로젝트, 결제 계정, 폴더, 조직에는 리소스 수준 싱크를 통해 로그 항목의 흐름을 관리하는 로그 라우터가 있습니다. 로그 라우터는 항목의 리소스 계층 구조에 있는 싱크를 통해 로그 항목의 흐름도 관리합니다. 싱크는 로그 항목이 대상으로 라우팅되는 방식을 제어합니다.

로그 라우터는 로그 항목을 임시로 저장합니다. 이 동작으로 인해 로그 항목이 싱크를 통과할 때 일시적인 중단 및 장애가 발생해도 버퍼링 작용을 합니다. 임시 스토리지는 구성 오류로부터 보호되지 않습니다.

로그 라우터의 임시 스토리지는 Logging 버킷에서 제공되는 장기 스토리지와 별개입니다.

타임스탬프가 과거 로그 보관 기간을 초과하거나 향후의 24시간을 초과하는 수신 로그 항목은 삭제됩니다.

로그 싱크 정보

로그 싱크가 로그 항목을 수신하면 로그 항목을 무시할지 라우팅할지 결정합니다. 이 결정은 로그 항목을 로그 싱크의 필터와 비교하여 이루어집니다. 로그 항목이 라우팅되면 로그 싱크가 로그 싱크에 지정된 대상으로 로그 항목을 전송합니다. 대상은 프로젝트, 스토리지 위치 또는 서비스일 수 있습니다.

로그 싱크는 지정된 Google Cloud 리소스( Google Cloud 프로젝트, 결제 계정, 폴더, 조직)에 속합니다. 이러한 리소스에는 여러 로그 싱크도 포함됩니다. 리소스가 로그 항목을 수신하면 해당 리소스의 모든 로그 싱크가 로그 항목을 독립적으로 평가합니다. 따라서 여러 로그 싱크가 동일한 로그 항목을 라우팅할 수 있습니다.

기본적으로 로그 데이터는 데이터가 생성된 프로젝트에 저장됩니다. 하지만 이 구성을 변경해야 하는 몇 가지 이유가 있습니다.

  • 로그 데이터의 스토리지를 중앙화합니다.
  • 로그 데이터를 다른 비즈니스 데이터와 조인합니다.
  • 유용한 방식으로 로그 데이터를 정리하기 위해
  • 로그를 다른 애플리케이션, 다른 저장소, 서드 파티로 스트리밍하기 위해 예를 들어 서드 파티 플랫폼에서 볼 수 있도록 Google Cloud 에서 로그를 내보내려는 경우 로그 항목을 내보내려면 로그 항목을 Pub/Sub로 라우팅하는 로그 싱크를 만드세요.

잘못 구성된 로그 싱크는 로그 항목을 라우팅하지 않습니다. 싱크가 잘못 구성되면 오류 세부정보를 보고하는 로그 항목이 작성됩니다. 또한 리소스의 필수 연락처로 이메일이 전송됩니다. 자세한 내용은 문제 해결: 오류 보기를 참고하세요.

로그 싱크는 로그 항목을 소급해 라우팅할 수 없습니다. 즉, 로그 싱크는 싱크가 생성되기 전에 수신된 로그 항목을 라우팅할 수 없습니다. 마찬가지로 싱크가 잘못 구성된 경우 싱크는 구성 오류가 해결된 후에 도착하는 로그 항목만 라우팅합니다. 하지만 로그 버킷에서 Cloud Storage로 로그 데이터를 소급해 복사할 수는 있습니다. 자세한 내용은 로그 복사를 참고하세요.

조직 및 폴더 지원

조직 또는 폴더의 로그 데이터를 관리하려면 다음 작업을 수행하세요.

  • 조직 또는 폴더와 그 하위 항목의 로그 항목을 싱크에서 지정한 대상으로 라우팅하는 집계 싱크를 만들 수 있습니다. 집계 싱크에는 두 가지 유형이 있습니다.

    • 비가로채기 집계 싱크
    • 집계 싱크 가로채기

    이 두 싱크 유형의 차이점은 리소스 계층 구조의 한 수준에서 싱크를 가로채면 계층 구조에서 더 낮은 리소스의 라우팅에 영향을 줄 수 있다는 점입니다. 차단하지 않는 싱크는 다른 리소스의 라우팅에 영향을 미치지 않습니다. 리소스의 가로채기 싱크가 로그 항목과 일치하면 로그 항목은 하위 리소스의 싱크로 전송되지 않습니다. 단, 로그 항목이 발생한 리소스의 _Required 로그 싱크로는 항상 전송됩니다.

  • 기본 리소스 설정을 구성하여 조직 또는 폴더의 새 리소스에 대해 시스템에서 생성한 _Default 싱크의 구성을 지정할 수 있습니다. 예를 들어 이러한 설정을 사용하여 _Default 싱크를 사용 중지하거나 해당 싱크의 필터를 지정할 수 있습니다.

라우팅 예

이 섹션에서는 프로젝트에서 시작된 로그 항목이 리소스 계층 구조의 싱크를 통해 흐르는 방식을 보여줍니다.

예: 집계된 싱크가 없음

로그 항목의 리소스 계층 구조에 집계된 싱크가 없으면 로그 항목이 로그 항목이 시작된 프로젝트의 로그 싱크로 전송됩니다. 로그 항목이 싱크의 포함 필터와 일치하지만 싱크의 제외 필터와 일치하지 않으면 프로젝트 수준 싱크는 로그 항목을 싱크의 대상으로 라우팅합니다.

예: 비 가로채기 집계 싱크가 있음

로그 항목의 리소스 계층 구조에 비 가로채기 집계 싱크가 있다고 가정합니다. 로그 라우터가 비 가로채기 집계 싱크에 로그 항목을 전송하면 다음이 발생합니다.

  1. 차단되지 않은 집계 싱크는 로그 항목이 포함 필터와 일치하지만 제외 필터와 일치하지 않으면 로그 항목을 싱크의 대상으로 라우팅합니다.

  2. 로그 라우터는 로그 항목이 시작된 프로젝트의 로그 싱크로 로그 항목을 전송합니다.

    로그 항목이 싱크의 포함 필터와 일치하지만 싱크의 제외 필터와 일치하지 않으면 프로젝트 수준 싱크는 로그 항목을 싱크의 대상으로 라우팅합니다.

예: 가로채는 집계 싱크가 있음

로그 항목의 리소스 계층 구조에 가로채기 집계 싱크가 있다고 가정합니다. 로그 라우터가 가로채는 집계된 싱크에 로그 항목을 전송하면 다음 중 하나가 발생합니다.

  • 로그 항목이 포함 필터와 일치하지만 제외 필터와 일치하지 않습니다.

    1. 로그 항목은 인터셉트된 집계 싱크의 대상으로 라우팅됩니다.
    2. 로그 항목은 로그 항목이 시작된 프로젝트의 _Required 싱크로 전송됩니다.
  • 로그 항목이 포함 필터와 일치하지 않거나 하나 이상의 제외 필터와 일치합니다.

    1. 로그 항목은 가로채기 집계 싱크에 의해 라우팅되지 않습니다.
    2. 로그 라우터는 로그 항목이 시작된 프로젝트의 로그 싱크로 로그 항목을 전송합니다.

      로그 항목이 싱크의 포함 필터와 일치하지만 싱크의 제외 필터와 일치하지 않으면 프로젝트 수준 싱크는 로그 항목을 싱크의 대상으로 라우팅합니다.

로그 싱크 필터

각 로그 싱크에는 하나의 포함 필터가 포함되며 여러 개의 제외 필터가 포함될 수 있습니다. 이러한 필터는 로그 싱크가 로그 항목을 싱크의 대상으로 라우팅할지 여부를 결정합니다. 필터를 지정하지 않으면 모든 로그 항목이 싱크의 대상으로 라우팅됩니다.

로그 항목은 다음 규칙에 따라 로그 싱크에 의해 라우팅됩니다.

  • 로그 항목이 포함 필터와 일치하지 않으면 라우팅되지 않습니다. 싱크에서 포함 필터를 지정하지 않으면 모든 로그 항목이 해당 필터와 일치합니다.

  • 로그 항목이 포함 필터 및 하나 이상의 제외 필터와 일치하면 라우팅되지 않습니다.

  • 로그 항목이 포함 필터와 일치하고 제외 필터와 일치하지 않으면 싱크의 목적지로 라우팅됩니다.

로그 싱크의 필터는 로깅 쿼리 언어를 사용하여 지정됩니다.

제외 필터를 사용하여 entries.write API 할당량 또는 entries.write API 호출 수의 소비를 줄일 수는 없습니다. 제외 필터는 로그 항목이 Logging API에 의해 수신된 후에 적용됩니다.

시스템에서 생성된 로그 싱크

각 Google Cloud 프로젝트, 결제 계정, 폴더, 조직마다 Cloud Logging은 _Required라는 이름의 로그 싱크와 _Default라는 이름의 로그 싱크를 만듭니다. 이러한 싱크의 포함 및 제외 필터는 리소스에 도달하는 모든 로그 항목이 이러한 싱크 중 하나에 의해 라우팅되는지 확인합니다. 두 싱크 모두 로그 싱크와 동일한 리소스에 있는 로그 버킷으로 로그 데이터를 라우팅합니다.

이 섹션의 나머지 부분에서는 시스템에서 생성된 로그 싱크의 필터와 대상에 관한 정보를 제공합니다.

_Required 로그 싱크

리소스의 _Required 로그 싱크는 감사 로그의 하위 집합을 리소스의 _Required 로그 버킷으로 라우팅합니다. 이 싱크는 제외 필터를 지정하지 않으며 포함 필터는 다음과 같습니다.

LOG_ID("cloudaudit.googleapis.com/activity") OR
LOG_ID("externalaudit.googleapis.com/activity") OR
LOG_ID("cloudaudit.googleapis.com/system_event") OR
LOG_ID("externalaudit.googleapis.com/system_event") OR
LOG_ID("cloudaudit.googleapis.com/access_transparency") OR
LOG_ID("externalaudit.googleapis.com/access_transparency")

_Required 로그 싱크는 _Required 로그 싱크가 정의된 리소스에서 시작된 로그 항목만 일치시킵니다. 예를 들어 로그 싱크가 프로젝트 A의 활동 로그 항목을 프로젝트 B로 라우팅한다고 가정해 보겠습니다. 로그 항목이 프로젝트 B에서 발생하지 않았으므로 프로젝트 B_Required 로그 싱크는 이 로그 항목을 _Required 로그 버킷으로 라우팅하지 않습니다.

_Required 로그 싱크는 수정하거나 삭제할 수 없습니다.

_Default 로그 싱크

리소스의 _Default 로그 싱크는 _Required 로그 싱크의 필터와 일치하는 로그 항목을 제외한 모든 로그 항목을 리소스의 _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")

_Default 로그 싱크를 수정하고 사용 중지할 수 있습니다. 예를 들어 _Default 로그 싱크를 수정하고 대상을 변경할 수 있습니다. 기존 필터를 수정하고 제외 필터를 추가할 수도 있습니다.

싱크 대상

싱크의 대상은 싱크와 다른 리소스에 있을 수 있습니다. 예를 들어 로그 싱크를 사용하여 한 프로젝트의 로그 항목을 다른 프로젝트에 저장된 로그 버킷으로 라우팅할 수 있습니다.

다음 대상이 지원됩니다.

Google Cloud 프로젝트

대상 프로젝트의 로그 싱크가 로그 항목의 경로를 다시 변경하도록 하려는 경우 또는 차단 집계 싱크를 만든 경우 이 대상을 선택합니다. 싱크 대상인 프로젝트의 로그 싱크는 로그 항목을 프로젝트를 제외한 지원되는 대상으로 다시 라우팅할 수 있습니다.

로그 버킷

Cloud Logging에서 관리하는 리소스에 로그 데이터를 저장하려면 이 대상을 선택하세요. 로그 버킷에 저장된 로그 데이터는 로그 탐색기 및 로그 애널리틱스와 같은 서비스를 사용하여 보고 분석할 수 있습니다.

로그 데이터를 다른 비즈니스 데이터와 조인하려면 로그 버킷에 로그 데이터를 저장하고 연결된 BigQuery 데이터 세트를 만들면 됩니다. 연결된 데이터 세트는 다른 BigQuery 데이터 세트와 마찬가지로 쿼리할 수 있는 읽기 전용 데이터 세트입니다.

BigQuery 데이터 세트
로그 데이터를 다른 비즈니스 데이터와 결합하려는 경우 이 대상을 선택합니다. 지정한 데이터 세트에서 쓰기를 사용 설정해야 합니다. 싱크의 대상을 연결된 BigQuery 데이터 세트로 설정하지 마세요. 연결된 데이터 세트는 읽기 전용입니다.
Cloud Storage 버킷
로그 데이터를 장기 저장하려는 경우 이 대상을 선택합니다. Cloud Storage 버킷은 로그 항목이 시작된 동일한 프로젝트에 있거나 다른 프로젝트에 있을 수 있습니다. 로그 항목은 JSON 파일로 저장됩니다.
Pub/Sub 주제
Google Cloud 에서 로그 데이터를 내보낸 후 Splunk 또는 Datadog와 같은 서드 파티 통합을 사용하려면 이 대상을 선택하세요.
로그 항목은 JSON 형식으로 지정된 후 Pub/Sub 주제로 라우팅됩니다.

목적지 제한사항

이 섹션에서는 목적지별 제한사항을 설명합니다.

  • 로그 항목을 다른 Google Cloud 프로젝트의 로그 버킷으로 라우팅하는 경우 Error Reporting이 이러한 로그 항목을 분석하지 않습니다. 자세한 내용은 Error Reporting 개요를 참고하세요.
  • 로그 항목을 BigQuery 데이터 세트로 라우팅하는 경우 BigQuery 데이터 세트에서 쓰기가 사용 설정되어야 합니다. 읽기 전용인 연결된 데이터 세트로 로그 항목을 라우팅할 수는 없습니다.
  • 로그 데이터를 Cloud Storage 버킷으로 라우팅하는 새 싱크가 로그 항목 라우팅을 시작하는 데 몇 시간이 걸릴 수 있습니다. 이러한 싱크는 매시간 처리됩니다.
  • 로그 싱크의 대상이 Google Cloud 프로젝트인 경우 다음 제한사항이 적용됩니다.

    • 하나의 홉 제한이 있습니다.
    • _Required 로그 싱크의 필터와 일치하는 로그 항목은 대상 프로젝트에서 시작된 경우에만 대상 프로젝트의 _Required 로그 버킷으로 라우팅됩니다.
    • 로그 항목의 리소스 계층 구조에 있는 집계된 싱크만 로그 항목을 처리합니다.

    예를 들어 프로젝트 A의 로그 싱크 대상이 프로젝트 B이라고 가정해 보겠습니다. 그러면 다음이 참입니다.

    • 원홉 제한으로 인해 B 프로젝트의 로그 싱크가 로그 항목을 Google Cloud 프로젝트로 다시 라우팅할 수 없습니다.
    • 프로젝트 B_Required 로그 버킷은 프로젝트 B에서 시작된 로그 항목만 저장합니다. 이 로그 버킷은 프로젝트 A에서 시작된 로그 항목을 비롯하여 다른 리소스에서 시작된 로그 항목을 저장하지 않습니다.
    • 프로젝트 A와 프로젝트 B의 리소스 계층 구조가 다른 경우 프로젝트 A의 로그 싱크가 프로젝트 B로 라우팅하는 로그 항목은 프로젝트 B의 리소스 계층 구조에 있는 집계된 싱크로 전송되지 않습니다.
    • 프로젝트 A과 프로젝트 B의 리소스 계층 구조가 동일한 경우 로그 항목이 해당 계층 구조의 집계된 싱크로 전송됩니다. 로그 항목이 집계된 싱크에 의해 가로채지 않으면 로그 라우터가 로그 항목을 프로젝트 A의 싱크로 전송합니다.

로그 항목 라우팅이 로그 기반 측정항목에 미치는 영향

로그 기반 측정항목은 로그 항목 콘텐츠에서 파생되는 Cloud Monitoring 측정항목입니다. 예를 들어 로그 기반 측정항목을 사용하여 특정 메시지가 포함된 로그 항목의 개수를 세거나 로그 항목에 기록된 지연 시간 정보를 추출할 수 있습니다. Cloud Monitoring 차트에서 로그 기반 측정항목을 표시할 수 있고, 알림 정책은 이러한 측정항목을 모니터링할 수 있습니다.

시스템 정의 로그 기반 측정항목은 프로젝트 수준에서 적용됩니다. 사용자 정의 로그 기반 측정항목은 프로젝트 수준 또는 로그 버킷 수준에 적용될 수 있습니다. 버킷 범위 로그 기반 측정항목은 집계 싱크를 사용하여 로그 항목을 로그 버킷으로 라우팅할 때와 한 프로젝트에서 다른 프로젝트의 로그 버킷으로 로그 항목을 라우팅할 때 유용합니다.

시스템 정의 로그 기반 측정항목
다음 조건이 모두 충족되면 로그 라우터에서 로그 항목을 집계합니다.
  • 로그 항목은 로그 기반 측정항목이 정의된 프로젝트의 로그 싱크를 통과합니다.
  • 로그 항목이 로그 버킷에 저장됩니다. 로그 버킷은 모든 프로젝트에 있을 수 있습니다.

    예를 들어 프로젝트 A에 대상이 프로젝트 B인 로그 싱크가 있다고 가정해 보겠습니다. 또한 프로젝트 B의 로그 싱크가 로그 항목을 로그 버킷으로 라우팅한다고 가정합니다. 이 시나리오에서는 프로젝트 A에서 프로젝트 B로 라우팅된 로그 항목이 프로젝트 A의 시스템 정의 로그 기반 측정항목에 반영됩니다. 이러한 로그 항목은 프로젝트 B의 시스템 정의 로그 기반 측정항목에도 반영됩니다.

사용자 정의 로그 기반 측정항목
다음 조건이 모두 충족되면 로그 라우터에서 로그 항목을 집계합니다.
  • 로그 기반 측정항목이 정의된 프로젝트에서 결제가 사용 설정되어 있습니다.
  • 버킷 범위 측정항목의 경우 로그 항목은 로그 기반 측정항목이 정의된 로그 버킷에 저장됩니다.
  • 프로젝트 범위 측정항목의 경우 로그 항목은 로그 기반 측정항목이 정의된 프로젝트의 로그 싱크를 통과합니다.

자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

권장사항

데이터 거버넌스 또는 일반적인 사용 사례를 위한 라우팅 사용에 대한 권장사항은 다음 문서를 참고하세요.

예: 로그 스토리지 중앙 집중화

이 섹션에서는 중앙 집중식 스토리지를 구성하는 방법을 간략하게 설명합니다. 중앙 집중식 스토리지는 로그 데이터를 쿼리할 수 있는 단일 위치를 제공하므로 동향을 검색하거나 문제를 조사할 때 쿼리를 간소화할 수 있습니다. 보안 관점에서 하나의 스토리지 위치가 있으므로 보안 분석가의 작업을 간소화할 수 있습니다.

로그 스토리지를 중앙 집중화하는 경우 로그 데이터를 저장하는 프로젝트에 유치권을 설정할지 고려하세요. 선취권은 실수로 프로젝트가 삭제되는 것을 방지할 수 있습니다. 자세한 내용은 선취권으로 프로젝트 보호를 참고하세요.

폴더의 프로젝트에 대한 로그 저장소 중앙화

폴더를 관리하고 로그 항목의 스토리지를 중앙화한다고 가정해 보겠습니다. 이 사용 사례의 경우 다음을 수행할 수 있습니다.

  1. 폴더에서 CentralStorage이라는 프로젝트를 만듭니다.
  2. 폴더의 가로채기 집계 싱크를 만들고 모든 로그 항목을 라우팅하도록 구성합니다. 싱크의 대상을 CentralStorage 프로젝트로 설정합니다.

폴더 또는 하위 리소스 중 하나에서 시작된 로그 항목이 도착하면 해당 로그 항목은 사용자가 만든 인터셉트 집계 싱크로 전송됩니다. 이 싱크는 로그 항목을 CentralStorage 프로젝트로 라우팅합니다. 이 프로젝트의 로그 싱크는 로그 항목을 처리합니다.

  • _Default 로그 싱크는 싱크의 필터와 일치하는 모든 로그 항목을 _Default 로그 버킷으로 라우팅합니다. 이 로그 버킷은 중앙 집중식 스토리지 위치입니다.

  • _Required 로그 싱크는 싱크의 필터와 일치하고 CentralStorage 프로젝트에서 시작된 로그 항목을 _Required 로그 버킷으로 라우팅합니다. 이 로그 버킷은 중앙 집중식 스토리지 위치가 아닙니다. 하지만 모든 로그 데이터를 중앙에 저장할 수 있습니다. 예를 보려면 중앙 위치에 감사 로그 저장을 참고하세요.

집계된 싱크 처리가 완료되면 로그 항목이 로그 항목이 발생한 리소스의 _Required 로그 싱크로 전송됩니다. 로그 항목이 _Required 로그 싱크의 필터와 일치하면 로그 항목이 리소스의 _Required 로그 버킷으로 라우팅됩니다. 따라서 폴더의 각 Google Cloud 프로젝트는 _Required 로그 버킷에 로그 항목을 저장합니다.

일련의 프로젝트의 로그 저장소 중앙화

조직이나 폴더가 없는 경우 단일 위치에 로그 항목을 저장할 수도 있습니다. 예를 들어 다음과 같은 작업을 할 수 있습니다.

  1. CentralStorage라는 프로젝트를 만듭니다.
  2. CentralStorage를 제외한 각 프로젝트에 대해 _Default 로그 싱크를 수정하고 대상을 CentralStorage라는 프로젝트로 설정합니다.

이전 예시에서는 해당 프로젝트의 _Default 로그 버킷 대신 _Default 로그 싱크의 대상을 프로젝트로 설정하는 이유가 궁금할 수 있습니다. 주된 이유는 단순성과 일관성입니다. 로그 항목을 프로젝트로 라우팅하면 대상 프로젝트의 로그 싱크가 저장되는 로그 항목과 저장 위치를 제어합니다. 즉, 필터와 대상 기능을 중앙 집중화합니다. 저장되는 로그 항목 또는 저장 위치를 변경하려면 한 프로젝트의 로그 싱크만 수정하면 됩니다.

감사 로그의 로그 스토리지 중앙화

_Required 로그 싱크와 일치하는 로그 항목을 중앙에 저장할 수 있습니다. 이러한 로그 항목을 중앙에 저장하려면 다음 중 하나를 수행합니다.

  • _Required 로그 싱크와 일치하는 로그 항목을 중앙 집중식 로그 버킷으로 라우팅하는 로그 싱크를 만듭니다.

  • 이전 두 예와 같이 로그 싱크를 구성한 다음 _Required 로그 싱크와 일치하는 로그 항목을 로그 버킷으로 라우팅하는 대상 프로젝트에 로그 싱크를 추가합니다. _Default 로그 싱크에서 필터를 수정할 수도 있습니다.

이러한 전략을 구현하기 전에 가격 책정 가이드라인을 검토하세요.

가격 책정

Cloud Logging 가격 책정에 대한 자세한 내용은 Google Cloud Observability 가격 책정을 참조하세요.

다음 단계

Cloud Logging 데이터를 라우팅하고 저장하는 방법은 다음 문서를 참조하세요.