이 문서에서는 Cloud Logging이 로그 항목을 처리하는 방법을 설명하고 Logging 라우팅 및 스토리지의 핵심 구성요소에 대해 설명합니다. 라우팅은 Cloud Logging이 새로 도착한 로그 항목으로 수행할 작업을 결정하는 데 사용하는 프로세스를 의미합니다. 로그 항목을 저장하는 Logging 버킷과 같은 대상이나 Pub/Sub로 로그 항목을 라우팅할 수 있습니다. 로그를 서드 파티 대상으로 내보내려면 Pub/Sub 주제로 로그를 라우팅한 후 서드 파티 대상이 Pub/Sub 주제를 구독하도록 승인합니다.
크게 보면 이것은 Cloud Logging이 로그 항목을 라우팅하고 저장하는 방법입니다.
로그 라우터로 로그 라우팅
다음 섹션에서는 Logging이 싱크를 사용하여 로그 라우터로 로그를 라우팅하는 방법을 설명합니다.
로그 라우터
로그 항목은 entries.write 호출 도중 logName 필드에 지정된 Google Cloud 리소스로 전송됩니다.
Cloud Logging은 로그 라우터를 통해 전달하는 Cloud Logging API를 사용하여 로그 항목을 수신합니다. 로그 라우터의 싱크는 Cloud Logging 버킷을 포함하여 로그 항목이 전송되어야 할 대상을 확인하는 포함 필터 및 제외 필터에 대해 각 로그 항목을 확인합니다. 싱크 조합을 사용하면 로그 항목을 여러 대상으로 라우팅할 수 있습니다.
로그 라우터는 로그 항목을 임시로 저장합니다. 이 동작으로 인해 싱크가 로그 항목을 대상으로 라우팅할 때 일시적인 중단 및 장애가 발생해도 버퍼링 작용을 합니다. 이러한 버퍼링도 싱크 구성 오류로 인한 문제는 막을 수 없습니다. 싱크가 잘못 구성된 경우 로그 항목이 라우팅되지 않고 오류 로그가 생성되며 싱크 구성 오류를 알리는 이메일이 전송됩니다. 로그 항목을 라우팅할 수 없는 경우 삭제됩니다.
로그 라우터의 임시 스토리지는 Logging 버킷에서 제공되는 장기 스토리지와 별개입니다.
타임스탬프가 과거 로그 보관 기간을 초과하거나 향후의 24시간을 초과하는 수신 로그 항목은 삭제됩니다.
싱크
싱크는 Cloud Logging의 로그 라우팅 방법을 제어합니다. 싱크를 사용하면 로그의 일부 또는 전부를 지원되는 대상으로 라우팅할 수 있습니다. 로그 라우팅 방법을 제어해야 하는 몇 가지 이유는 다음과 같습니다.
- 읽을 가능성이 없지만 규정 준수를 위해 유지해야 하는 로그를 저장하기 위해
- 버킷에 유용한 형식으로 로그를 정리하기 위해
- 로그에 빅데이터 분석 도구를 사용하기 위해
- 로그를 다른 애플리케이션, 다른 저장소, 서드 파티로 스트리밍하기 위해 예를 들어 서드 파티 플랫폼에서 볼 수 있도록 Google Cloud에서 로그를 내보내려는 경우 싱크를 구성하여 Pub/Sub로 로그 항목을 라우팅합니다.
싱크는 Google Cloud 프로젝트, 결제 계정, 폴더, 조직 등 지정된 Google Cloud 리소스에 속합니다. 리소스가 로그 항목을 수신하면 해당 리소스에 포함된 싱크에 따라 로그 항목을 라우팅하며, 사용 설정된 경우 리소스 계층 구조에 속하는 모든 상위 싱크에 따라 로그 항목을 라우팅합니다. 로그 항목은 일치하는 각 싱크와 연결된 대상으로 전송됩니다.
Cloud Logging은 각 Google Cloud 프로젝트, 결제 계정, 폴더, 조직에 두 개의 사전 정의된 싱크인 _Required 및 _Default를 제공합니다. 리소스에서 생성된 모든 로그는 이 두 싱크를 통해 자동으로 처리된 후 _Required 또는 _Default라는 버킷에 저장됩니다.
싱크는 서로 독립적으로 작동합니다. 사전 정의된 싱크가 로그 항목을 처리하는 방식에 관계없이 고유한 싱크를 만들어 일부 또는 전체 로그를 여러 지원되는 대상으로 라우팅하거나 Cloud Logging에서 저장되지 않도록 제외할 수 있습니다.
싱크에서 라우팅하는 로그 항목은 싱크의 포함 필터 및 제외 필터를 구성하여 제어합니다. 싱크의 구성에 따라 Cloud Logging에서 수신되는 모든 로그 항목은 다음 카테고리 중 하나 이상에 포함됩니다.
Cloud Logging에 저장되고 다른 곳으로 라우팅되지 않습니다.
Cloud Logging에 저장되고 지원되는 대상으로 라우팅됩니다.
Cloud Logging에 저장되지 않지만 지원되는 대상으로 라우팅됩니다.
Cloud Logging에 저장되지 않고 다른 곳으로 라우팅되지 않습니다.
일반적으로 Google Cloud 프로젝트 수준에서 싱크를 만들지만 Google Cloud 조직 또는 폴더에 포함된 리소스의 로그를 결합하고 라우팅하려면 집계 싱크를 만들 수 있습니다.
로그가 Logging API를 통과하면서 라우팅이 발생하므로 싱크는 싱크가 생성된 후에 도착하는 로그 항목만 라우팅합니다. 로그 항목을 소급해서 라우팅해야 하는 경우에는 로그 복사를 참조하세요.
포함 필터
싱크에서 필터를 지정하지 않으면 모든 로그 항목이 일치하여 싱크의 대상으로 라우팅됩니다. 포함 필터를 설정하여 특정 로그 항목을 선택하도록 싱크를 구성할 수 있습니다. 하나 이상의 제외 필터를 설정하여 로그 항목이 라우팅되지 않도록 할 수도 있습니다.
싱크를 구성할 때 Logging 쿼리 언어를 사용하여 필터를 지정합니다.
로그 항목은 다음 규칙에 따라 싱크에서 라우팅됩니다.
로그 항목이 포함 필터와 일치하지 않으면 라우팅되지 않습니다. 싱크가 포함 필터를 지정하지 않으면 모든 로그 항목이 해당 필터와 일치합니다.
로그 항목이 포함 필터와 하나 이상의 제외 필터와 일치하면 라우팅되지 않습니다.
로그 항목이 포함 필터와 일치하고 제외 필터와 일치하지 않으면 싱크의 대상으로 라우팅됩니다.
제외 필터
싱크를 만들 때 제외 필터를 여러 개 설정할 수 있습니다. 제외 필터를 사용하면 포함 필터와 일치하는 로그 항목이 싱크 대상으로 라우팅되거나 로그 버킷에 저장되지 않도록 제외할 수 있습니다. 제외 필터는 Logging 쿼리 언어를 사용하여 정의합니다.
제외된 로그 항목은 entries.write API 할당량을 사용합니다. 이들 항목은 Logging API에서 수신된 후 제외되기 때문입니다.
로그 항목을 제외하여 entries.write API 호출 수를 줄일 수 없습니다.
제외된 로그 항목은 로그 탐색기에서 사용할 수 없습니다.
명시적인 제외 필터를 통해서, 또는 Logging 스토리지 대상이 있는 싱크와 일치하지 않기 때문에 하나 이상의 로그 버킷으로 라우팅되지 않은 로그 항목도 Error Reporting에서 제외됩니다. 따라서 이러한 로그 항목은 실패 문제를 해결하는 데 사용할 수 없습니다. 사용자 정의 로그 기반 측정항목은 포함된 로그 항목과 제외된 로그 항목의 로그 항목에서 계산됩니다. 자세한 내용은 로그 모니터링을 참조하세요.지원되는 대상
로그 라우터를 사용하여 특정 로그 항목을 Google Cloud 프로젝트의 지원되는 대상으로 라우팅할 수 있습니다. Logging은 다음 싱크 대상을 지원합니다.
Cloud Logging 버킷: Cloud Logging에 스토리지를 제공합니다. 로그 버킷은 여러 Google Cloud 프로젝트에서 수신한 로그 항목을 저장할 수 있습니다. 로그 버킷은 로그 항목이 시작된 동일한 프로젝트에 있거나 다른 프로젝트에 있을 수 있습니다. 로그 버킷에 저장된 로그 항목을 보는 방법에 대한 자세한 내용은 로그 쿼리 및 보기 개요 및 Cloud Logging 버킷으로 라우팅된 로그 보기를 참조하세요.
로그 애널리틱스를 사용하도록 로그 버킷을 업그레이드한 후 연결된 데이터 세트를 만들어 Cloud Logging 데이터를 다른 데이터와 결합할 수 있습니다. 연결된 데이터 세트는 BigQuery Studio 및 Looker Studio 페이지에서 쿼리할 수 있는 읽기 전용 데이터 세트입니다.
BigQuery 데이터 세트: 쓰기 가능한 BigQuery 데이터 세트에서 로그 항목의 스토리지를 제공합니다. BigQuery 데이터 세트는 로그 항목이 시작하는 같은 프로젝트에 있거나 다른 프로젝트에 있을 수 있습니다. 저장된 로그 항목에서 빅데이터 분석 기능을 사용할 수 있습니다. BigQuery로 라우팅된 로그 항목을 보는 방법을 자세히 알아보려면 BigQuery로 라우팅된 로그 보기를 참조하세요.
- Cloud Storage 버킷: Cloud Storage에서 로그 항목의 스토리지를 제공합니다. Cloud Storage 버킷은 로그 항목이 시작된 동일한 프로젝트에 있거나 다른 프로젝트에 있을 수 있습니다. 로그 항목은 JSON 파일로 저장됩니다. Cloud Storage로 라우팅된 로그 항목을 보는 방법을 자세한 내용은 Cloud Storage로 라우팅된 로그 보기를 참조하세요.
Pub/Sub 주제: 서드 파티 통합을 지원합니다. 로그 항목은 JSON 형식으로 지정된 후 Pub/Sub 주제로 라우팅됩니다. 주제는 로그 항목이 시작된 동일한 프로젝트에 있거나 다른 프로젝트에 있을 수 있습니다. Pub/Sub로 라우팅된 로그 항목을 보는 방법을 자세한 내용은 Pub/Sub로 라우팅된 로그 보기를 참조하세요.
Google Cloud 프로젝트: 로그 항목을 다른 Google Cloud 프로젝트로 라우팅합니다. 이 구성에서는 대상 프로젝트의 싱크가 로그 항목을 처리합니다.
자세한 내용은 지원되는 대상으로 로그 라우팅을 참조하세요.
로그 저장, 보기, 관리
다음 섹션에서는 Cloud Logging에 로그가 저장되는 방식과 로그를 보고 관리하는 방법을 자세히 설명합니다.
로그 버킷
Cloud Logging은 로그 버킷을 Google Cloud 프로젝트, 결제 계정, 폴더, 조직의 컨테이너로 사용하여 로그 데이터를 저장하고 정리합니다. Cloud Logging에 저장하는 로그 항목은 로그를 실시간으로 분석할 수 있도록 색인을 생성하고 최적화하여 전달됩니다. Cloud Logging 버킷은 비슷한 이름의 Cloud Storage 버킷과 다른 스토리지 항목입니다.
각 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 버킷으로 자동 라우팅합니다.
Cloud Logging은 버킷에 대한 커스텀 보관 기간을 구성하지 않는 한 _Default 버킷의 로그 항목을 30일 동안 보관합니다.
_Default 버킷은 삭제할 수 없습니다.
사용자 정의 로그 버킷
모든 Google Cloud 프로젝트에서 사용자 정의 로그 버킷을 만들 수도 있습니다. 사용자 정의 로그 버킷에 싱크를 적용하면 로그 항목의 하위 집합을 모든 로그 버킷으로 라우팅하여 로그 항목이 저장될 Google Cloud 프로젝트를 선택하고 여러 리소스의 로그 항목을 한 위치에 저장할 수 있습니다.
예를 들어 프로젝트 A에서 생성된 로그의 경우 프로젝트 A의 사용자 정의 버킷 또는 프로젝트 B의 로그 버킷으로 로그 항목을 라우팅하도록 싱크를 구성할 수 있습니다.
삭제 또는 업데이트를 포함하여 사용자 정의된 로그 버킷 관리에 대한 자세한 내용은 로그 버킷 구성 및 관리를 참조하세요.
리전화
로그 버킷은 리전별 리소스입니다. 로그 항목을 저장하고, 색인을 생성하고, 검색하는 인프라는 특정 지리적 위치에 있습니다. Google Cloud는 해당 리전 내의 영역에서 애플리케이션을 중복으로 사용할 수 있도록 해당 인프라를 관리합니다.
로그 버킷을 생성하거나 조직 수준 리전 정책을 설정할 때 다음 리전 중 하나에 로그 항목을 저장할 수 있습니다.
아프리카
| 리전 이름 | 리전 설명 |
|---|---|
africa-south1 |
요하네스버그 |
미주
| 리전 이름 | 리전 설명 |
|---|---|
northamerica-northeast1 |
몬트리올 |
northamerica-northeast2 |
토론토 |
southamerica-east1 |
상파울루 |
southamerica-west1 |
산티아고 |
us-central1 |
아이오와 |
us-east1 |
사우스캐롤라이나 |
us-east4 |
북 버지니아 |
us-east5 |
콜럼버스 |
us-south1 |
댈러스 |
us-west1 |
오리건 |
us-west2 |
로스앤젤레스 |
us-west3 |
솔트레이크시티 |
us-west4 |
라스베이거스 |
아시아 태평양
| 리전 이름 | 리전 설명 |
|---|---|
asia-east1 |
타이완 |
asia-east2 |
홍콩 |
asia-northeast1 |
도쿄 |
asia-northeast2 |
오사카 |
asia-northeast3 |
서울 |
asia-south1 |
뭄바이 |
asia-south2 |
델리 |
asia-southeast1 |
싱가포르 |
asia-southeast2 |
자카르타 |
australia-southeast1 |
시드니 |
australia-southeast2 |
멜버른 |
유럽
| 리전 이름 | 리전 설명 |
|---|---|
europe-central2 |
바르샤바 |
europe-north1 |
핀란드 |
europe-southwest1 |
마드리드 |
europe-west1 |
벨기에 |
europe-west2 |
런던 |
europe-west3 |
프랑크푸르트 |
europe-west4 |
네덜란드 |
europe-west6 |
취리히 |
europe-west8 |
밀라노 |
europe-west9 |
파리 |
europe-west10 |
베를린 |
europe-west12 |
토리노 |
중동
| 리전 이름 | 리전 설명 |
|---|---|
me-central1 |
도하 |
me-central2 |
Dammam |
me-west1 |
텔아비브 |
기타
| 리전 이름 | 리전 설명 |
|---|---|
eu |
유럽 연합 내 데이터 센터에 저장된 로그. 추가 중복성이 보장되지 않음 |
us |
미국 내 데이터 센터에 저장된 로그. 추가 중복성이 보장되지 않음 |
global |
전 세계 모든 데이터 센터에 저장된 로그. 추가 중복성이 보장되지 않음 |
위치를 global로 설정하면 로그 항목이 실제로 저장되는 위치를 지정할 필요가 없습니다.
특정 스토리지 리전을 조직 또는 폴더에 생성된 _Default 및 _Required 버킷에 자동으로 적용할 수 있습니다.
자세한 내용은 조직 및 폴더의 기본 설정 구성을 참조하세요.
데이터 리전성과 로그 데이터 저장 위치에 대한 자세한 내용은 데이터 리전 이해를 참조하세요.
조직 정책
조직 정책을 만들어서 해당 조직이 규정 준수 및 규제 요구 사항을 충족하는지 확인할 수 있습니다. 조직 정책을 사용하여 해당 조직에서 새 로그 버킷을 만들 수 있는 리전을 지정할 수 있습니다. 또한 지정된 리전에서는 조직이 새 로그 버킷을 만들지 못하도록 제한할 수 있습니다.
Cloud Logging은 기존 로그 버킷에 새로 생성된 조직 정책을 강제 적용하지 않으며, 새 로그 버킷에만 정책을 적용합니다.
위치 기반 조직 정책 만들기에 대한 자세한 내용은 리소스 위치 제한을 참조하세요.
또한 조직 또는 폴더에서 _Default 및 _Required 버킷의 기본 스토리지 위치를 구성할 수 있습니다.
데이터 저장 위치를 제한하는 조직 정책을 구성하는 경우 지정한 기본 스토리지 위치가 해당 제약조건과 일치하는지 확인해야 합니다. 자세한 내용은 조직 및 폴더의 기본 설정 구성을 참조하세요.
보관
Cloud Logging은 로그가 보관되는 로그 버킷 유형에 적용되는 보관 규칙에 따라 로그를 보관합니다. 다양한 로그 유형의 보관 기간에 대한 자세한 내용은 할당량 및 한도를 참조하세요.
로그를 1~3,650일 동안 보관하도록 Cloud Logging을 구성할 수 있습니다. 커스텀 보관 규칙은 로그 유형 또는 로그가 다른 위치에서 복사되었는지 여부와 관계없이 버킷의 모든 로그에 적용됩니다.
로그 버킷의 보관 규칙 설정에 대한 자세한 내용은 커스텀 보관 구성을 참조하세요.
로그 뷰
로그 뷰를 사용하면 로그 버킷에 저장된 로그 항목의 하위 집합에 대해서만 사용자에게 액세스 권한을 부여할 수 있습니다. 로그 뷰를 구성하는 방법과 특정 로그 뷰에 대한 액세스 권한을 부여하는 방법에 대한 자세한 내용은 로그 버킷에서 로그 뷰 구성을 참조하세요.
모든 로그 버킷에 대해 Cloud Logging은 해당 버킷에 저장된 모든 로그를 표시하는 _AllLogs 뷰를 자동으로 만듭니다. 또한 Cloud Logging은 _Default라는 _Default 버킷의 뷰도 만듭니다. _Default 버킷의 _Default 뷰에는 데이터 액세스 감사 로그를 제외한 모든 로그가 표시됩니다. _AllLogs 및 _Default 뷰는 수정 불가능하고 _Default 로그 뷰를 삭제할 수 없습니다.
커스텀 로그 뷰는 로그 데이터에 대한 액세스를 세부적으로 제어할 수 있는 고급 방법을 제공합니다. 예를 들어 중앙 Google Cloud 프로젝트의 모든 조직 로그를 저장하는 시나리오를 가정해 보겠습니다. 로그 버킷에는 여러 Google Cloud 프로젝트의 로그가 포함될 수 있으므로 다른 사용자가 로그를 볼 수 있는 Google Cloud 프로젝트를 제어하려 할 수 있습니다. 커스텀 로그 뷰를 사용하면 사용자 한 명에게 단일 Google Cloud 프로젝트의 로그에 대한 액세스 권한을 부여하면서 동시에 다른 사용자에게 모든 Google Cloud 프로젝트의 로그에 대한 액세스 권한을 부여할 수 있습니다.
Google Cloud 생태계에서 로그 사용
다음 섹션에서는 광범위한 Google Cloud에서 로그를 사용하는 방법을 설명합니다.
로그 기반 측정항목
로그 기반 측정항목은 로그 항목 콘텐츠에서 파생되는 Cloud Monitoring 측정항목입니다. 예를 들어 Cloud Logging이 Google Cloud 프로젝트의 측정항목 중 하나의 필터와 일치하는 Google Cloud 프로젝트의 로그 항목을 수신한 경우, 로그 항목이 측정항목 데이터에 계산됩니다.
로그 기반 측정항목이 시스템 또는 사용자에 의해 정의되었는지 여부에 따라 로그 기반 측정항목이 라우팅과 상호작용하는 방식이 달라집니다. 다음 섹션에서 이러한 차이점을 설명합니다.
로그 기반 측정항목 및 제외 필터
싱크 제외 필터는 로그 버킷에 저장된 로그만 계산하는 시스템 정의 로그 기반 측정항목에 적용됩니다.
사용자 정의 로그 기반 측정항목에는 싱크 제외 필터가 적용되지 않습니다. 로그가 Logging 버킷에 저장되지 않도록 제외하더라도 로그가 이러한 측정항목에서 계산될 수 있습니다.
로그 기반 측정항목의 범위
시스템에서 정의된 로그 기반 측정항목은 Google Cloud 프로젝트 수준에서 적용됩니다. 이러한 측정항목은 로그 라우터에서 계산되며 수신된 Google Cloud 프로젝트의 로그에만 적용됩니다.
사용자 정의 로그 기반 측정항목은 Google Cloud 프로젝트 수준 또는 특정 로그 버킷의 수준에 적용될 수 있습니다.
- 프로젝트 수준 측정항목은 시스템 정의 로그 기반 측정항목처럼 계산됩니다. 즉, 이러한 사용자 정의 로그 기반 측정항목은 수신되는 Google Cloud 프로젝트의 로그에만 적용됩니다.
버킷 범위 측정항목은 로그 항목의 출처가 된 Google Cloud 프로젝트에 관계없이 수신된 로그 버킷의 로그에 적용됩니다.
버킷 범위 로그 기반 측정항목을 사용하면 다음과 같은 경우에 로그를 평가할 수 있는 로그 기반 측정항목을 만들 수 있습니다.
- 한 프로젝트에서 다른 프로젝트의 버킷으로 라우팅된 로그입니다.
- 집계 싱크를 통해 버킷으로 라우팅되는 로그입니다.
자세한 내용은 로그 기반 측정항목 개요를 참조하세요.
지원되는 대상에서 로그 찾기
라우팅된 로그 항목의 형식에 관해 알아보고 로그가 대상에서 어떻게 구성되는지 알아보려면 싱크 대상의 로그 보기를 참조하세요.
일반 사용 사례
로그 라우팅 및 저장의 일반적인 사용 사례를 다루려면 다음 문서 및 튜토리얼을 참조하세요.
규정 준수 필요
데이터 거버넌스의 라우팅 사용에 대한 권장사항은 다음 문서를 참조하세요.
IAM으로 액세스 제어
Cloud Logging 데이터에 대한 액세스를 제어하기 위해 Identity and Access Management(IAM) 역할과 권한을 사용하는 방법은 IAM으로 액세스 제어를 참조하세요.
가격 책정
Cloud Logging은 로그를 지원되는 대상으로 라우팅하는 데 비용을 청구하지 않지만 대상에 요금이 부과될 수 있습니다.
_Required 로그 버킷을 제외하고 Cloud Logging은 로그를 로그 버킷으로 스트리밍하고 로그 버킷의 기본 보관 기간보다 긴 스토리지에 대해 요금을 청구합니다.
Cloud Logging은 로그 복사, 로그 범위 정의, 로그 탐색기 또는 로그 애널리틱스 페이지를 통해 실행되는 쿼리에 대해 요금을 부과하지 않습니다.
자세한 내용은 다음 문서를 참조하세요.
- Cloud Logging 가격 책정 요약
대상 비용:
- VPC 흐름 로그 생성 요금은 전송한 후 Cloud Logging에서 Virtual Private Cloud 흐름 로그를 제외할 때 적용됩니다.
다음 단계
Cloud Logging 데이터를 라우팅하고 저장하는 방법은 다음 문서를 참조하세요.
지원되는 대상에 로그 항목을 라우팅하기 위해 싱크를 만들려면 지원되는 대상으로 로그 라우팅을 참고하세요.
폴더 또는 조직의 리소스에서 로그 항목을 라우팅할 수 있는 집계 싱크를 만드는 방법을 알아보려면 조직 및 폴더 수준 로그를 수집하여 지원되는 대상으로 라우팅을 참고하세요.
로그 버킷에 저장된 로그 항목의 하위 집합에 대한 액세스 권한을 부여하는 방법을 알아보려면 로그 버킷에서 로그 뷰 구성을 참고하세요.
- Error Reporting은 로그 항목을 분석하고 오류를 보고할 수 있습니다. 로그 항목을 분석할 수 있는 시점에 관한 정보 등 이 서비스에 관한 자세한 내용은 Error Reporting 개요를 참고하세요.