이 문서에서는 Cloud Logging이 로그 항목을 처리하는 방법을 알아보고, Logging 라우팅 및 스토리지의 핵심 구성요소에 대해 설명합니다. 라우팅은 Cloud Logging이 새로 도착한 로그 항목으로 수행할 작업을 결정하는 데 사용하는 프로세스를 의미합니다. 로그 항목을 저장하는 Logging 버킷과 같은 목적지나 Pub/Sub로 로그 항목을 라우팅할 수 있습니다. 로그를 서드 파티 목적지로 내보내려면 Pub/Sub 주제로 로그를 라우팅한 후 서드 파티 목적지가 Pub/Sub 주제를 구독하도록 승인합니다.
로그 라우터로 로그 라우팅
다음 섹션에서는 Logging이 싱크를 사용하여 로그 라우터로 로그를 라우팅하는 방법을 설명합니다.
로그 라우터
로그 항목은 entries.write 호출 도중 logName 필드에 지정된 Trusted Cloud 리소스로 전송됩니다.
Cloud Logging은 로그 라우터를 통해 전달하는 Cloud Logging API를 사용하여 로그 항목을 수신합니다. 로그 라우터의 싱크는 Cloud Logging 버킷을 포함하여 로그 항목이 전송되어야 할 목적지를 확인하는 포함 필터 및 제외 필터에 대해 각 로그 항목을 확인합니다. 싱크 조합을 사용하면 로그 항목을 여러 목적지로 라우팅할 수 있습니다.
로그 라우터는 로그 항목을 임시로 저장합니다. 이 동작으로 인해 싱크가 로그 항목을 목적지로 라우팅할 때 일시적인 중단 및 장애가 발생해도 버퍼링 작용을 합니다. 이러한 버퍼링도 싱크 구성 오류로 인한 문제는 막을 수 없습니다. 싱크가 잘못 구성된 경우 로그 항목이 라우팅되지 않고 오류 로그가 생성되며 싱크 구성 오류를 알리는 이메일이 전송됩니다. 로그 항목을 라우팅할 수 없는 경우 삭제됩니다.
로그 라우터의 임시 스토리지는 Logging 버킷에서 제공되는 장기 스토리지와 별개입니다.
타임스탬프가 과거 로그 보관 기간을 초과하거나 향후의 24시간을 초과하는 수신 로그 항목은 삭제됩니다.
싱크
싱크는 Cloud Logging의 로그 라우팅 방법을 제어합니다. 싱크를 사용하면 로그의 일부 또는 전부를 지원되는 목적지로 라우팅할 수 있습니다. 로그 라우팅 방법을 제어해야 하는 몇 가지 이유는 다음과 같습니다.
- 읽을 가능성이 없지만 규정 준수를 위해 유지해야 하는 로그를 저장하기 위해
- 버킷에 유용한 형식으로 로그를 정리하기 위해
- 로그에 빅데이터 분석 도구를 사용하기 위해
- 로그를 다른 애플리케이션, 다른 저장소, 서드 파티로 스트리밍하기 위해 예를 들어 서드 파티 플랫폼에서 볼 수 있도록 Trusted Cloud by S3NS 에서 로그를 내보내려는 경우 싱크를 구성하여 Pub/Sub로 로그 항목을 라우팅합니다.
싱크는 Google Cloud 프로젝트, 결제 계정, 폴더, 조직 등 지정된 Trusted Cloud 리소스에 속합니다. 리소스가 로그 항목을 수신하면 해당 리소스에 포함된 싱크에 따라 로그 항목을 라우팅하며, 사용 설정된 경우 리소스 계층 구조에 속하는 모든 상위 싱크에 따라 로그 항목을 라우팅합니다. 로그 항목은 일치하는 각 싱크와 연결된 목적지로 전송됩니다.
Cloud Logging은 각 Google Cloud 프로젝트, 결제 계정, 폴더, 조직에 두 개의 사전 정의된 싱크인 _Required 및 _Default를 제공합니다. 리소스에서 생성된 모든 로그는 이 두 싱크를 통해 자동으로 처리된 후 _Required 또는 _Default라는 버킷에 저장됩니다.
싱크는 서로 독립적으로 작동합니다. 사전 정의된 싱크가 로그 항목을 처리하는 방식에 관계없이 고유한 싱크를 만들어 일부 또는 전체 로그를 여러 지원되는 목적지로 라우팅하거나 Cloud Logging에서 저장되지 않도록 제외할 수 있습니다.
싱크에서 라우팅하는 로그 항목은 싱크의 포함 필터 및 제외 필터를 구성하여 제어합니다. 싱크의 구성에 따라 Cloud Logging에서 수신되는 모든 로그 항목은 다음 카테고리 중 하나 이상에 포함됩니다.
Cloud Logging에 저장되고 다른 곳으로 라우팅되지 않음
Cloud Logging에 저장되고 지원되는 목적지로 라우팅됨
Cloud Logging에 저장되지 않지만 지원되는 목적지로 라우팅됨
Cloud Logging에 저장되지 않고 다른 곳으로 라우팅되지 않음
일반적으로 Google Cloud 프로젝트 수준에서 싱크를 만들지만 Trusted Cloud 조직 또는 폴더에 포함된 리소스의 로그를 결합하고 라우팅하려면 집계 싱크를 만들 수 있습니다.
로그가 Logging API를 통과하면서 라우팅이 발생하므로 싱크는 싱크가 생성된 후에 도착하는 로그 항목만 라우팅합니다.포함 필터
싱크에서 필터를 지정하지 않으면 모든 로그 항목이 일치하여 싱크의 목적지로 라우팅됩니다. 포함 필터를 설정하여 특정 로그 항목을 선택하도록 싱크를 구성할 수 있습니다. 하나 이상의 제외 필터를 설정하여 로그 항목이 라우팅되지 않도록 제외할 수도 있습니다.
싱크를 구성할 때 Logging 쿼리 언어를 사용하여 필터를 지정합니다.
로그 항목은 다음 규칙에 따라 싱크에서 라우팅됩니다.
로그 항목이 포함 필터와 일치하지 않으면 라우팅되지 않습니다. 싱크가 포함 필터를 지정하지 않으면 모든 로그 항목이 해당 필터와 일치합니다.
로그 항목이 포함 필터와 하나 이상의 제외 필터와 일치하면 라우팅되지 않습니다.
로그 항목이 포함 필터와 일치하고 제외 필터와 일치하지 않으면 싱크의 목적지로 라우팅됩니다.
제외 필터
싱크를 만들 때 제외 필터를 여러 개 설정할 수 있습니다. 제외 필터를 사용하면 포함 필터와 일치하는 로그 항목이 싱크 목적지로 라우팅되거나 로그 버킷에 저장되지 않도록 제외할 수 있습니다. 제외 필터는 Logging 쿼리 언어를 사용하여 정의합니다.
제외된 로그 항목은 entries.write API 할당량을 사용합니다. 이들 항목은 Logging API에서 수신된 후 제외되기 때문입니다.
로그 항목을 제외하여 entries.write API 호출 수를 줄일 수 없습니다.
제외된 로그 항목은 로그 탐색기에서 사용할 수 없습니다.
지원되는 목적지
로그 라우터를 사용하여 특정 로그 항목을 Google Cloud 프로젝트의 지원되는 목적지로 라우팅할 수 있습니다. 로그 싱크의 목적지가 프로젝트인 경우 해당 프로젝트의 로그 싱크가 로그 항목의 경로를 다시 변경합니다. 로그 항목은 다른 목적지로 다시 라우팅되지 않습니다. 예를 들어 한 프로젝트의 로그 항목을 다른 프로젝트의 로그 버킷으로 라우팅하는 경우 로그 버킷을 저장하는 프로젝트의 로그 싱크에서 이러한 로그 항목을 다시 라우팅하지 않습니다.
Logging은 다음 싱크 목적지를 지원합니다.
Cloud Logging 버킷: Cloud Logging에서 스토리지를 제공합니다. 로그 버킷은 여러 Google Cloud 프로젝트에서 수신한 로그 항목을 저장할 수 있습니다. 로그 버킷은 로그 항목이 시작된 동일한 프로젝트에 있거나 다른 프로젝트에 있을 수 있습니다. 로그 버킷에 저장된 로그 항목을 보는 방법에 대한 자세한 내용은 로그 쿼리 및 보기 개요 및 Cloud Logging 버킷으로 라우팅된 로그 보기를 참조하세요.
- Pub/Sub 주제: 서드 파티 통합을 지원합니다. 로그 항목은 JSON 형식으로 지정된 후 Pub/Sub 주제로 라우팅됩니다. 주제는 로그 항목이 시작된 동일한 프로젝트에 있거나 다른 프로젝트에 있을 수 있습니다. Pub/Sub로 라우팅된 로그 항목을 보는 방법을 자세히 알아보려면 Pub/Sub로 라우팅된 로그 보기를 참조하세요.
- Google Cloud 프로젝트: 로그 항목을 다른 Google Cloud 프로젝트로 라우팅합니다. 이 구성에서는 목적지 프로젝트의 싱크가 로그 항목을 처리합니다.
싱크를 만드는 방법과 Google Cloud 콘솔 또는 API를 사용할 때 표시될 수 있는 옵션을 구성하는 방법에 관한 자세한 내용은 지원되는 목적지에 로그 라우팅을 참고하세요.
로그 저장, 보기, 관리
다음 섹션에서는 Cloud Logging에 로그가 저장되는 방식과 로그를 보고 관리하는 방법을 자세히 설명합니다.
로그 버킷
Cloud Logging은 로그 버킷을 Google Cloud 프로젝트, 결제 계정, 폴더, 조직의 컨테이너로 사용하여 로그 데이터를 저장하고 정리합니다. Cloud Logging에 저장하는 로그 항목은 로그를 실시간으로 분석할 수 있도록 색인을 생성하고 최적화하여 전달됩니다.
각 Google Cloud 프로젝트, 결제 계정, 폴더, 조직에 대해 Logging은 자동으로 두 개의 _Required 및 _Default 로그 버킷을 만듭니다. Logging은 _Required 및 _Default라는 싱크를 자동으로 만듭니다. 이러한 싱크는 기본 구성에서 해당 이름의 버킷으로 로그 항목을 라우팅합니다.
로그 항목을 _Default 로그 버킷으로 라우팅하는 _Default 싱크를 중지할 수 있습니다. 또한, 새 Google Cloud 프로젝트나 폴더에 대해 생성된 _Default 싱크의 동작을 원하는 대로 변경할 수 있습니다. 자세한 내용은 조직 및 폴더의 기본 설정 구성을 참조하세요.
_Required 버킷의 라우팅 규칙을 변경할 수 없습니다.
또한 모든 Google Cloud 프로젝트에 대해 사용자 정의 버킷을 만들 수 있습니다.
싱크를 만들어 로그 항목 전체 또는 하위 집합을 로그 버킷으로 라우팅합니다. 이를 통해 로그 항목이 저장되는 Google Cloud 프로젝트를 선택하고 여러 리소스의 로그 항목을 한 위치에 저장할 수 있습니다.
자세한 내용은 로그 버킷 구성을 참조하세요.
_Required 로그 버킷
Cloud Logging은 다음 유형의 로그 항목을 _Required 버킷으로 자동 라우팅합니다.
- 관리 활동 감사 로그
- 시스템 이벤트 감사 로그
- Google Workspace 관리자 감사 로그
- Enterprise 그룹스 감사 로그
- 로그인 감사 로그
Cloud Logging은 _Required 버킷의 로그 항목을 400일 동안 보관합니다. 이 보관 기간은 변경할 수 없습니다.
_Required 버킷은 수정하거나 삭제할 수 없습니다. 로그 항목을 _Required 버킷으로 라우팅하는 _Required 싱크는 사용 중지할 수 없습니다.
_Default 로그 버킷
_Required 버킷에 저장되지 않은 로그 항목은 _Default 싱크를 중지하거나 수정하지 않는 한 _Default 싱크에서 _Default 버킷으로 라우팅됩니다. 싱크 수정에 대한 상세 설명은 싱크 관리를 참조하세요.
예를 들어 Cloud Logging은 다음 유형의 로그 항목을 _Default 버킷으로 자동 라우팅합니다.
_Default 버킷의 로그 항목을 30일 동안 보관합니다.
_Default 버킷은 삭제할 수 없습니다.
사용자 정의 로그 버킷
모든 Google Cloud 프로젝트에서 사용자 정의 로그 버킷을 만들 수도 있습니다. 사용자 정의 로그 버킷에 싱크를 적용하면 로그 항목의 하위 집합을 모든 로그 버킷으로 라우팅하여 로그 항목이 저장될 Google Cloud 프로젝트를 선택하고 여러 리소스의 로그 항목을 한 위치에 저장할 수 있습니다.
예를 들어 프로젝트 A에서 생성된 로그의 경우 프로젝트 A의 사용자 정의 버킷 또는 프로젝트 B의 로그 버킷으로 로그 항목을 라우팅하도록 싱크를 구성할 수 있습니다.
삭제 또는 업데이트를 포함하여 사용자 정의된 로그 버킷 관리에 대한 자세한 내용은 로그 버킷 구성 및 관리를 참조하세요.
리전화
로그 버킷은 리전별 리소스입니다. 로그 항목을 저장하고, 색인을 생성하고, 검색하는 인프라는 특정 지리적 위치에 있습니다. Trusted Cloud by S3NS는 해당 리전 내의 영역에서 애플리케이션을 중복으로 사용할 수 있도록 해당 인프라를 관리합니다.
로그 버킷을 생성하거나 조직 수준 리전 정책을 설정할 때 로그를 저장할 위치를 선택할 수 있습니다.
Cloud Logging에서 지원하는 리전은 다음과 같습니다.
| 리전 이름 | 리전 설명 |
|---|---|
u-france-east1 |
프랑스 |
global |
지원되는 리전에 있는 데이터 센터에 저장된 로그 로그가 다른 데이터 센터로 이동할 수 있습니다. 추가 중복 보장은 없습니다. 로그 데이터의 저장소 위치를 선택하려면 지역 로그 버킷을 사용하세요. |
위치를 global로 설정하면 로그 항목이 실제로 저장되는 위치를 지정할 필요가 없습니다.
특정 스토리지 리전을 조직 또는 폴더에 생성된 _Default 및 _Required 버킷에 자동으로 적용할 수 있습니다.
자세한 내용은 조직 및 폴더의 기본 설정 구성을 참조하세요.
조직 정책
조직 정책을 만들어서 해당 조직이 규정 준수 및 규제 요구 사항을 충족하는지 확인할 수 있습니다. 조직 정책을 사용하여 해당 조직에서 새 로그 버킷을 만들 수 있는 리전을 지정할 수 있습니다. 또한 지정된 리전에서는 조직이 새 로그 버킷을 만들지 못하도록 제한할 수 있습니다.
Cloud Logging은 기존 로그 버킷에 새로 생성된 조직 정책을 강제 적용하지 않으며, 새 로그 버킷에만 정책을 적용합니다.
위치 기반 조직 정책 만들기에 대한 자세한 내용은 리소스 위치 제한을 참조하세요.
또한 조직 또는 폴더에서 _Default 및 _Required 버킷의 기본 스토리지 위치를 구성할 수 있습니다.
데이터를 저장할 수 있는 위치를 제한하는 조직 정책을 구성하는 경우 지정하는 기본 스토리지 위치가 해당 제약조건과 일치하는지 확인해야 합니다. 자세한 내용은 조직 및 폴더의 기본 설정 구성을 참조하세요.
보관
Cloud Logging은 로그가 보관되는 로그 버킷 유형에 적용되는 보관 규칙에 따라 로그를 보관합니다. 다양한 로그 유형의 보관 기간에 대한 자세한 내용은 할당량 및 한도를 참조하세요.
로그 뷰
로그 뷰를 사용하면 로그 버킷에 저장된 로그 항목의 하위 집합에 대해서만 사용자에게 액세스 권한을 부여할 수 있습니다. 로그 뷰를 구성하는 방법과 특정 로그 뷰에 대한 액세스 권한을 부여하는 방법에 대한 자세한 내용은 로그 버킷에서 로그 뷰 구성을 참조하세요.
모든 로그 버킷에 대해 Cloud Logging은 해당 버킷에 저장된 모든 로그를 표시하는 _AllLogs 뷰를 자동으로 만듭니다. 또한 Cloud Logging은 _Default라는 _Default 버킷의 뷰도 만듭니다. _Default 버킷의 _Default 뷰에는 데이터 액세스 감사 로그를 제외한 모든 로그가 표시됩니다. _AllLogs 및 _Default 뷰는 수정 불가능하고 _Default 로그 뷰를 삭제할 수 없습니다.
커스텀 로그 뷰는 로그 데이터에 대한 액세스를 세부적으로 제어할 수 있는 고급 방법을 제공합니다. 예를 들어 중앙 Google Cloud 프로젝트의 모든 조직 로그를 저장하는 시나리오를 가정해 보겠습니다. 로그 버킷에는 여러 Google Cloud 프로젝트의 로그가 포함될 수 있으므로 다른 사용자가 로그를 볼 수 있는 Google Cloud 프로젝트를 제어하려 할 수 있습니다. 커스텀 로그 뷰를 사용하면 사용자 한 명에게 단일 Google Cloud 프로젝트의 로그에 대한 액세스 권한을 부여하면서 동시에 다른 사용자에게 모든 Google Cloud 프로젝트의 로그에 대한 액세스 권한을 부여할 수 있습니다.
Trusted Cloud by S3NS 생태계에서 로그 사용
다음 섹션에서는 광범위한Trusted Cloud에서 로그를 사용하는 방법을 설명합니다.
지원되는 목적지에서 로그 찾기
라우팅된 로그 항목의 형식에 관해 알아보고 로그가 목적지에서 어떻게 구성되는지 알아보려면 싱크 목적지의 로그 보기를 참조하세요.
일반 사용 사례
로그 라우팅 및 저장의 일반적인 사용 사례를 다루려면 다음 문서 및 튜토리얼을 참조하세요.
규정 준수 필요
데이터 거버넌스의 라우팅 사용에 대한 권장사항은 다음 문서를 참조하세요.
IAM으로 액세스 제어
Cloud Logging 데이터에 대한 액세스를 제어하기 위해 Identity and Access Management(IAM) 역할과 권한을 사용하는 방법은 IAM으로 액세스 제어를 참조하세요.
다음 단계
Cloud Logging 데이터를 라우팅하고 저장하는 방법은 다음 문서를 참조하세요.
지원되는 목적지에 로그 항목을 라우팅하기 위해 싱크를 만들려면 지원되는 목적지로 로그 라우팅을 참고하세요.
폴더 또는 조직의 리소스에서 로그 항목을 라우팅할 수 있는 집계 싱크를 만드는 방법을 알아보려면 조직 및 폴더 수준 로그를 수집하여 지원되는 목적지로 라우팅을 참고하세요.
로그 버킷에 저장된 로그 항목의 하위 집합에 대한 액세스 권한을 부여하는 방법을 알아보려면 로그 버킷에서 로그 뷰 구성을 참고하세요.