내보낸 로그 사용

이 페이지에서는 Cloud Logging에서 내보낸 로그 항목을 찾고 사용하는 방법을 설명합니다.

로그 항목을 내보내려면 내보낼 로그 항목을 선택하는 필터를 작성하고 다음 옵션에서 대상 위치를 선택해야 합니다.

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

필터와 대상은 싱크라고 하는 객체에 보관됩니다. Google Cloud 프로젝트, 조직, 폴더, 결제 계정에서 싱크를 만들 수 있습니다.

Cloud Logging을 사용한 로그 내보내기 개념의 개요는 로그 내보내기 개요를 참조하세요.

로그 내보내기

Cloud Logging에서 싱크를 만들어 로그를 내보내는 방법에 대한 안내는 다음 페이지를 참조하세요.

Cloud Storage

Cloud Storage에서 내보낸 로그를 보려면 다음 안내를 따르세요.

  1. Cloud Console에서 Cloud Storage 브라우저로 이동합니다.

    Cloud Storage 브라우저로 이동

  2. 로그 내보내기에 사용할 Cloud Storage 버킷을 선택합니다.

Cloud Storage 버킷에서 로그를 구성하는 방법에 대한 자세한 내용은 이 페이지의 Cloud Storage 구성을 참조하세요.

내보낸 로그 사용 가능 여부 확인

내보낸 로그가 없으면 내보내기 시스템 측정항목을 확인하세요. 내보내기 시스템 측정항목은 내보낸 로그 항목의 수와 오류로 인해 중단된 항목의 수를 각각 알려줍니다. 내보내기 시스템 측정항목에 내보낸 로그 항목이 없는 것으로 나타나면 필터를 확인하여 필터와 일치하는 로그 항목이 최근 Logging에 전달되었는지 파악하세요.

로그 라우터로 이동

로그 항목은 1시간 배치 단위로 Cloud Storage 버킷에 저장됩니다. 항목이 최초로 표시되기까지 2~3시간이 걸릴 수 있습니다.

내보낸 로그 구성

Cloud Storage 버킷에 로그를 내보내면 Logging이 버킷에 파일 집합을 작성합니다.

파일은 로그 유형과 날짜를 기준으로 한 디렉토리 계층구조로 구성됩니다. 로그 유형은 LogEntry 참조에서는 [LOG_ID]로 불리며 syslog처럼 간단한 이름이거나 appengine.googleapis.com/request_log처럼 복합적인 이름일 수 있습니다. 이러한 로그가 my-gcs-bucket이라는 버킷에 저장되었다면 디렉터리 이름은 다음 예시와 같이 지정됩니다.

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

단일 Cloud Storage 버킷에는 여러 리소스 유형의 로그가 포함될 수 있습니다. 각 파일은 약 3.5GiB입니다.

Logging은 동일하거나 중복된 쿼리가 포함된 싱크에서 제공되는 로그 항목의 중복 삭제를 보장하지 않으므로 이러한 싱크의 로그 항목이 Cloud Storage 버킷에 여러 번 작성될 가능성이 있습니다.

리프 디렉터리(DD/)에는 여러 개의 파일이 포함되어 있으며 각 파일에는 파일 이름에 지정된 기간 동안 내보낸 로그 항목이 보관됩니다. 파일은 샤딩되고 샤딩된 파일의 이름은 Sn 또는 An(n=0, 1, 2 등)과 같은 샤드 번호로 끝납니다. 예를 들어 my-gcs-bucket/syslog/2015/01/13/ 디렉터리에 다음과 같은 파일 두 개가 저장되어 있을 수 있습니다.

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

이러한 두 파일 모두에는 08:00:00 UTC부터 08:59:59 UTC까지 한 시간 동안 모든 인스턴스에 대한 syslog 로그 항목이 포함됩니다. 로그 항목 타임스탬프는 UTC(협정 세계시)로 표시됩니다.

timestamp의 60분 정렬 기간 내에 receiveTimestamp로 도착하는 로그 항목은 기본 샤드 파일에 기록됩니다. 예를 들어 timestamp가 08:00:00이고 receiveTimestamp가 08:10:00인 로그 항목은 기본 샤드 파일에 저장됩니다.

이러한 파일에는 서픽스에 숫자로 표시된 기본 샤드가 포함됩니다. _Sn.json.

receiveTimestamp 대신 다른 60분 정렬 기간의 timestamp로 도착하는 로그 항목은 부록 샤드 파일에 기록됩니다. 예를 들어 timestamp가 08:00:00이고 receiveTimestamp가 09:10:00인 로그 항목은 부록 샤드 파일에 저장됩니다.

이러한 파일에는 서픽스에 숫자로 표시된 부록 샤드가 포함됩니다. _An.json:Unix_timestamp.

예를 들어 로그 항목에 08:00:00에서 08:59:59 사이의 timestamp가 포함되지만 다른 60분 정렬 기간의 receiveTimestamp_An.json:Unix_timestamp 서픽스로 파일에 기록된 경우, 여기서 Unix 타임스탬프는 파일이 Cloud Storage로 내보내진 시간을 식별합니다. 로그 항목에서 timestamp가 08:50:00이고 receiveTimestamp가 09:10:00이며, 2021년 3월 25일 09:15:00에 내보내졌으면 부록 파일이 다음과 같이 기록됩니다.

08:00:00_08:59:59_A0.json:1616681700

모든 로그 항목을 가져오려면 매 기간의 모든 분할을 읽어야 합니다(이 경우에는 파일이 0과 1로 분할됨). 작성된 파일 샤드 수는 로그 항목의 볼륨에 따라 각 시기마다 다를 수 있습니다.

샤딩된 개별 파일 내의 로그 항목은 LogEntry 객체 목록으로 저장됩니다. syslog 항목의 예시는 이 페이지의 LogEntry 유형을 참조하세요.

파일 내 로그 항목의 정렬 순서는 통일되거나 달리 보장되지 않습니다.

필터

Cloud Storage로 로그를 내보내는 필터의 예시는 샘플 쿼리를 참조하세요.

BigQuery

BigQuery에서 내보낸 로그를 보려면 다음 안내를 따르세요.

  1. Cloud Console에서 BigQuery 페이지로 이동합니다.

    BigQuery로 이동

  2. 싱크의 대상으로 사용할 데이터세트를 선택합니다.

  3. 데이터세트 테이블 중 하나를 선택합니다. 세부정보 탭에서 로그 항목을 보거나 테이블을 쿼리하여 데이터를 반환할 수 있습니다.

테이블의 구성 방식을 알아보려면 테이블 구성을 참조하고, 내보낸 로그 항목 필드의 이름 지정 방식을 알아보려면 내보낸 로그의 BigQuery 스키마를 참조하세요.

내보낸 로그 사용 가능 여부 확인

내보낸 로그가 없으면 내보내기 시스템 측정항목을 확인하세요. 내보내기 시스템 측정항목은 내보낸 로그 항목의 수와 오류로 인해 중단된 항목의 수를 각각 알려줍니다. 내보내기 시스템 측정항목에 내보낸 로그 항목이 없는 것으로 나타나면 필터를 확인하여 필터와 일치하는 로그 항목이 최근 Logging에 전달되었는지 파악하세요.

로그 라우터로 이동

Logging에서 BigQuery로 로그 항목을 내보낼 때 새 테이블이 생성되는 경우 새 테이블에 첫 번째 로그 항목이 나타나기 시작하려면 몇 분 정도 걸릴 수 있습니다. 이후에는 일반적으로 1분 이내에 로그 항목이 나타납니다. 자세한 내용은 아래의 테이블 구성을 참조하세요.

테이블 구성

BigQuery 데이터세트로 로그를 내보낼 때 Logging은 내보낸 로그 항목을 저장하기 위해 날짜가 지정된 테이블을 만듭니다. 항목의 로그 이름과 타임스탬프1를 기반으로 이름이 지정된 테이블에 로그 항목이 배치됩니다. 다음 표는 로그 이름과 타임스탬프를 테이블 이름에 매핑하는 데 걸리는 시간의 예시를 보여줍니다.

로그 이름 로그 항목 타임스탬프1 BigQuery 테이블 이름
syslog 2017-05-23T18:19:22.135Z syslog_20170523
apache-access 2017-01-01T00:00:00.000Z apache_access_20170101
compute.googleapis.com/activity_log 2018-08-19T12:11:35.220Z compute_googleapis_com_activity_log_20171231

1로그 항목 타임스탬프는 UTC(협정 세계시)로 표시됩니다.

스키마 및 필드

내보낸 로그의 BigQuery 테이블 스키마는 LogEntry 유형의 구조와 로그 페이로드의 콘텐츠에 기반합니다. BigQuery Web UI에서 내보낸 로그 항목이 있는 테이블을 선택하면 테이블 스키마를 볼 수 있습니다.

복잡한 로그 항목 페이로드를 나타내는 데 사용되는 BigQuery 테이블 스키마는 헷갈릴 수 있으며 내보낸 감사 로그에는 특별한 이름 지정 규칙이 사용됩니다. 자세한 내용은 내보낸 로그의 BigQuery 스키마를 참조하세요.

쿼리

BigQuery로 로그를 내보내는 쿼리의 예시는 샘플 쿼리를 참조하세요.

BigQuery 쿼리 구문에 대한 자세한 내용은 쿼리 참조를 확인하세요. 특히 테이블 와일드 카드 함수는 여러 테이블에 대한 쿼리를 만드는 데, Flatten 연산자는 반복되는 필드의 데이터를 표시하는 데 유용합니다.

샘플 Compute Engine 로그 쿼리

다음 BigQuery 쿼리는 여러 날짜와 여러 로그 유형의 로그 항목을 가져옵니다.

  • 쿼리는 지난 3일 동안의 syslogapache-access 로그를 검색합니다. 즉, 2015년 2월 23일에 실행한 쿼리에는 2월 21일과 2월 22일에 수신된 모든 로그 항목과 2월 23일 쿼리가 생성된 시간까지 수신된 모든 로그 항목이 포함됩니다.

  • 쿼리는 단일 Compute Engine 인스턴스 1554300700000000000의 결과를 가져옵니다.

SELECT
  timestamp AS Time,
  logName as Log,
  textPayload AS Message
FROM
  (TABLE_DATE_RANGE(my_bq_dataset.syslog_,
    DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP())),
  (TABLE_DATE_RANGE(my_bq_dataset.apache_access_,
    DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP()))
WHERE
  resource.type == 'gce_instance'
  AND resource.labels.instance_id == '1554300700000000000'
ORDER BY time;

다음은 몇 가지 출력 행의 예시입니다.

Row | Time                    | Log                                         | Message
--- | ----------------------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------
 5  | 2015-02-21 03:40:14 UTC | projects/project-id/logs/syslog             | Feb 21 03:40:14 my-gce-instance collectd[24281]: uc_update: Value too old: name = 15543007601548826368/df-tmpfs/df_complex-used; value time = 1424490014.269; last cache update = 1424490014.269;
 6  | 2015-02-21 04:17:01 UTC | projects/project-id/logs/syslog             | Feb 21 04:17:01 my-gce-instance /USR/SBIN/CRON[8082]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
 7  | 2015-02-21 04:49:58 UTC | projects/project-id/logs/apache-access      | 128.61.240.66 - - [21/Feb/2015:04:49:58 +0000] "GET / HTTP/1.0" 200 536 "-" "masscan/1.0 (https://github.com/robertdavidgraham/masscan)"
 8  | 2015-02-21 05:17:01 UTC | projects/project-id/logs/syslog             | Feb 21 05:17:01 my-gce-instance /USR/SBIN/CRON[9104]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
 9  | 2015-02-21 05:30:50 UTC | projects/project-id/log/syslogapache-access | 92.254.50.61 - - [21/Feb/2015:05:30:50 +0000] "GET /tmUnblock.cgi HTTP/1.1" 400 541 "-" "-"

샘플 App Engine 로그 쿼리

다음 BigQuery 쿼리는 지난 달에 실패한 App Engine 요청을 가져옵니다.

SELECT
  timestamp AS Time,
  protoPayload.host AS Host,
  protoPayload.status AS Status,
  protoPayload.resource AS Path
FROM
  (TABLE_DATE_RANGE(my_bq_dataset.appengine_googleapis_com_request_log_,
    DATE_ADD(CURRENT_TIMESTAMP(), -1, 'MONTH'), CURRENT_TIMESTAMP()))
WHERE
  protoPayload.status != 200
ORDER BY time

일부 결과는 다음과 같습니다.

Row | Time                    | Host                                  | Status | Path
--- | ----------------------- | ------------------------------------- | ------ | ------
 6  | 2015-02-12 19:35:02 UTC | default.my-gcp-project-id.appspot.com |    404 | /foo?thud=3
 7  | 2015-02-12 19:35:21 UTC | default.my-gcp-project-id.appspot.com |    404 | /foo
 8  | 2015-02-16 20:17:19 UTC | my-gcp-project-id.appspot.com         |    404 | /favicon.ico
 9  | 2015-02-16 20:17:34 UTC | my-gcp-project-id.appspot.com         |    404 | /foo?thud=%22what???%22

Pub/Sub

Cloud Logging 로그를 타사 소프트웨어와 통합할 때는 Pub/Sub를 사용하는 것이 좋습니다.

Pub/Sub로 내보낸 로그는 일반적으로 몇 초 내에 사용할 수 있으며 로그의 99%는 60초 이내에 사용할 수 있습니다.

내보낸 로그가 Pub/Sub를 통해 스트리밍되는 것을 확인하려면 다음 안내를 따르세요.

  1. Cloud Console의 Pub/Sub 페이지로 이동합니다.

    Pub/Sub로 이동

  2. 로그 내보내기에 사용된 주제에 대한 구독을 찾거나 만들고 여기에서 로그 항목을 가져옵니다. 새로운 로그 항목이 게시될 때까지 기다려야 할 수도 있습니다.

Pub/Sub에서 로그를 구성하는 방법에 대한 자세한 내용은 이 페이지의 내보낸 로그 구성을 참조하세요.

내보낸 로그 사용 가능 여부 확인

내보낸 로그가 없으면 내보내기 시스템 측정항목을 확인하세요. 내보내기 시스템 측정항목은 내보낸 로그 항목의 수와 오류로 인해 중단된 항목의 수를 각각 알려줍니다. 내보내기 시스템 측정항목에 내보낸 로그 항목이 없는 것으로 나타나면 필터를 확인하여 필터와 일치하는 로그 항목이 최근 Logging에 전달되었는지 파악하세요.

로그 라우터로 이동

Pub/Sub 주제로 로그를 내보내면 Logging에서 해당 로그 항목을 받는 즉시 Pub/Sub 메시지로 각 로그 항목을 게시합니다.

내보낸 로그 구성

각 메시지의 data 필드는 base64로 인코딩된 LogEntry 객체입니다. 예를 들어 Pub/Sub 구독자는 로그 항목을 수신하는 주제에서 다음과 같은 객체를 가져올 수 있습니다. 여기에 나와 있는 객체에는 하나의 메시지가 있는 목록이 포함되어 있습니다. 그러나 로그 항목이 여러 개인 경우에는 Pub/Sub에서 여러 메시지를 반환할 수 있습니다. 예시를 쉽게 읽을 수 있도록 data 값(약 600자)과 ackId 값(약 200자)이 단축 표시되었습니다.

{
 "receivedMessages": [
  {
   "ackId": "dR1JHlAbEGEIBERNK0EPKVgUWQYyODM...QlVWBwY9HFELH3cOAjYYFlcGICIjIg",
   "message": {
    "data": "eyJtZXRhZGF0YSI6eyJzZXZ0eSI6Il...Dk0OTU2G9nIjoiaGVsbG93b3JsZC5sb2cifQ==",
    "attributes": {
     "compute.googleapis.com/resource_type": "instance",
     "compute.googleapis.com/resource_id": "123456"
    },
    "messageId": "43913662360"
   }
  }
 ]
}

data 필드를 디코딩하고 형식을 지정하면 다음과 같은 LogEntry 객체를 얻게 됩니다.

{
  "log": "helloworld.log",
  "insertId": "2015-04-15|11:41:00.577447-07|10.52.166.198|-1694494956",
  "textPayload": "Wed Apr 15 20:40:51 CEST 2015 Hello, world!",
  "timestamp": "2015-04-15T18:40:56Z",
  "labels": {
    "compute.googleapis.com\/resource_type": "instance",
    "compute.googleapis.com\/resource_id": "123456"
  },
  "severity": "WARNING"
  }
}

Pub/Sub로 제3자 통합

Logging은 Splunk와 같은 타사와의 로깅 통합을 지원합니다. 현재 통합 목록은 파트너에서 Google Cloud의 작업 제품군 통합을 참조하세요.

Pub/Sub 주제를 통해 로그를 내보내면 제3자가 동일한 주제를 구독하여 로그를 수신합니다.

통합을 수행하려면 일반적으로 다음과 같은 작업을 수행해야 합니다.

  1. Google Cloud 프로젝트에서 생성한 Google Cloud 서비스 계정 이름을 제3자로부터 가져옵니다. 예를 들면 12345-xyz@developer.gserviceaccount.com입니다. 이 이름을 사용하여 제3자에 로그를 수신할 수 있는 권한을 제공합니다.

  2. 로그가 포함된 프로젝트에서

  3. Pub/Sub API를 사용 설정합니다.

    API 사용 설정

  4. 를 사용합니다.

  5. Pub/Sub 주제를 만듭니다. 로그 싱크를 구성할 때 만들거나 다음 단계를 따르면 됩니다.

    1. Pub/Sub 주제 목록으로 이동합니다.
    2. 주제 만들기를 선택하고 주제 이름을 입력합니다. 예를 들면 projects/my-project-id/topics/my-pubsub-topic입니다. 이 주제로 로그를 내보냅니다.

      주제로 전송한 각 메시지에는 Pub/Sub 메시지 attributes의 내보낸 로그 항목에 대한 타임스탬프가 포함됩니다. 예를 들면 다음과 같습니다.

      "attributes": {
        "logging.googleapis.com/timestamp": "2018-10-01T00:00:00Z"
      }
      
    3. 만들기를 클릭합니다.

    4. Logging을 승인하여 주제로 로그를 내보냅니다. 자세한 내용은 Pub/Sub의 권한 설정을 참조하세요.

  6. 주제를 구독하도록 제3자를 승인합니다.

    1. Cloud Console에서 프로젝트의 최신 Pub/Sub 주제 목록 정보를 받습니다.
    2. 새로운 주제를 선택합니다.
    3. 권한을 선택합니다.
    4. 제3자의 서비스 계정 이름을 입력합니다.
    5. 역할 선택 메뉴에서 Pub/Sub 구독자를 선택합니다.
    6. 추가를 클릭합니다.
  7. 제3자에게 Pub/Sub 주제의 이름을 제공합니다. 예를 들면 projects/my-project-number/topics/my-pubsub-topic입니다. 제3자가 해당 주제를 구독해야 내보내기를 시작할 수 있습니다.

  8. 제3자가 주제를 구독하면 로그 내보내기를 시작합니다.

    1. 내보낼 로그가 포함된 프로젝트에서 검색어 상자 위에 있는 내보내기 만들기를 클릭합니다. 그러면 내보내기 수정 패널이 열립니다.
    2. 싱크 이름을 입력합니다.
    3. 싱크 서비스 메뉴에서 Cloud Pub/Sub를 선택합니다.
    4. 싱크 대상 메뉴에서 제3자가 구독한 Pub/Sub 주제를 선택합니다.
    5. 싱크 만들기를 선택하여 내보내기를 시작합니다.
    6. 싱크 생성됨 대화상자가 나타납니다. 그러면 앞으로 일치하는 로그를 내가 선택한 대상에 작성할 수 있는 권한과 함께 내보내기 싱크가 성공적으로 만들어진 것입니다.

제3자가 즉시 로그 항목을 수신하기 시작합니다.

Pub/Sub를 사용한 일반적인 로깅 내보내기 시나리오에 대한 자세한 내용은 Cloud Logging으로 내보내기 위한 설계 패턴: 로깅 내보내기 시나리오를 참조하세요.

Cloud Logging

로그 버킷은 로그 데이터를 보관하 Google Cloud 프로젝트의 Cloud Logging 스토리지 컨테이너입니다. 로그 싱크를 만들어 로그 전체 또는 하위 집합을 로그 버킷으로 라우팅할 수 있습니다. 이를 통해 로그가 저장되는 Cloud 프로젝트와 함께 저장되는 다른 로그를 유연하게 선택할 수 있습니다.

Google Cloud 프로젝트와 연결된 로그 버킷을 만들고 나열하는 방법에 대한 안내는 버킷 관리를 참조하세요.

로그 항목 조직

Logging 로그 항목은 LogEntry 유형의 객체입니다.

로그 유형(LogEntry 참조의 [LOG_ID]라고도 함)이 같은 로그 항목은 대개 형식도 동일합니다. 다음 표는 샘플 로그 항목을 보여줍니다.

syslog

Compute Engine syslog은 가상 머신 인스턴스에서 실행되는 Logging 에이전트인 google-fluentd에서 생성되는 커스텀 로그 유형입니다.

{
  logName: "projects/my-gcp-project-id/logs/syslog",
  timestamp: "2015-01-13T19:17:01Z",
  resource: {
    type: "gce_instance",
    labels: {
      instance_id: "12345",
      zone: "us-central1-a",
      project_id: "my-gcp-project-id"
    }
  },
  insertId: "abcde12345",
  textPayload: "Jan 13 19:17:01 my-gce-instance /USR/SBIN/CRON[29980]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)"
}

request_log

App Engine의 request_log에는 RequestLog 유형의 객체를 보유하는 protoPayload 필드가 포함된 로그 항목이 있습니다.

{
  logName: "projects/my-gcp-project-id/logs/appengine.googleapis.com%2Frequest_log",
  timestamp: "2015-01-13T19:00:39.796169Z",
  resource: {
    type: "gae_app",
    labels: {
      module_id: "default",
      zone: "us6",
      project_id: "my-gcp-project-id",
      version_id: "20150925t173233"
    }
  }
  httpRequest: {
    status: 200
  }
  insertId: "abcde12345",
  operation: {
    id: "abc123",
    producer: "appengine.googleapis.com/request_id",
    first: true,
    last: true
  }
  protoPayload: {
    @type: "type.googleapis.com/google.appengine.logging.v1.RequestLog"
    versionId: "20150925t173233",
    status: 200,
    startTime: "2017-01-13T19:00:39.796169Z",
    # ...
    appId: "s~my-gcp-project-id",
    appEngineRelease: "1.9.17",
  }
}

activity

activity 로그는 관리자 활동 감사 로그입니다. 페이로드는 AuditLog 유형의 JSON 표현입니다.

{
 logName: "projects/my-gcp-project-id/logs/cloudaudit.googleapis.com%2Factivity"
 timestamp: "2017-04-22T13:41:32.245Z"
 severity: "NOTICE"
 resource: {
  type: "gce_instance"
  labels: {
   instance_id: "2403273232180765234"
   zone: "us-central1-b"
   project_id: "my-gcp-project-id"
  }
 }
 insertId: "54DC1882F4B49.A4996C2.6A02F4C1"
 operation: {
  id: "operation-1492868454262-54dc185e9a4f0-249fe233-f73d472a"
  producer: "compute.googleapis.com"
  last: true
 }
 protoPayload: {
  @type: "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail: "649517127304@cloudservices.gserviceaccount.com"
  }
  requestMetadata: {…}
  serviceName: "compute.googleapis.com"
  methodName: "v1.compute.instances.delete"
  resourceName: "projects/my-gcp-project-id/zones/us-central1-b/instances/abc123"
 }
}

로그 항목의 전달 지연

내보낸 로그 항목은 1시간마다 일괄적으로 Cloud Storage 버킷에 저장됩니다. 첫 번째 항목이 나타나기 시작하려면 2~3시간이 걸릴 수 있습니다. An('Append') 서픽스가 추가된 내보낸 로그 파일 샤드에는 늦게 전달된 로그 항목이 포함됩니다.

내보내기 대상이 중단되면 중단 문제가 해소될 때까지 Cloud Logging에서 데이터를 버퍼링합니다.

App Engine 로그 항목

App Engine은 google.appengine.logging.v1.LogLine 유형의 하위 항목(AppLog 또는 AppLogLine이라고도 함) 여러 개를 로그 활동의 원인인 요청의 기본 google.appengine.logging.v1.RequestLog 유형 로그 항목 아래에 결합합니다. 각 로그 줄에는 기본 항목을 식별하는 '요청 ID'가 있습니다. 로그 탐색기는 요청 로그 항목이 포함된 로그 줄을 표시합니다. Logging은 타임스탬프가 다음 배치에 넣더라도 원래 요청이 있는 배치에 모든 로그 줄을 넣으려고 시도합니다. 시도가 실패하는 경우 요청 로그 항목에 일부 로그 줄이 누락될 수 있으며 다음 배치에 요청 없이 '분리된' 로그 줄이 생길 수 있습니다. 이러한 가능성이 문제가 된다면 로그를 처리할 때 요청 조각을 다시 연결해야 할 수 있습니다.

가격 책정

내보낸 로그에는 Cloud Logging 요금이 청구되지 않지만 대상 요금이 청구될 수 있습니다. 자세한 내용은 해당 제품의 가격 책정 페이지를 참조하세요.

Virtual Private Cloud 흐름 로그를 전송한 후 Cloud Logging에서 제외하면 대상 요금 외에 VPC 흐름 로그 생성 요금이 부과됩니다.