내보낸 로그 사용

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

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

Cloud Logging

Cloud Logging을 사용하여 로그를 내보내는 방법에 대한 자세한 내용은 다음 페이지를 참조하세요.

Cloud Storage

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

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

    Cloud Storage 브라우저로 이동

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

버킷에서 로그가 어떻게 구성되어 있는지에 대한 자세한 내용은 이 페이지의 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/

한 버킷에 여러 리소스 유형의 로그가 포함될 수 있습니다.

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

이러한 두 파일에는 0800 UTC부터 1시간 사이에 발생한 모든 인스턴스의 syslog 로그 항목이 포함됩니다. 로그 항목 타임스탬프는 UTC(협정 세계시)로 표시됩니다.

모든 로그 항목을 가져오려면 각 시기에 해당하는 모든 샤드를 읽어야 합니다(이 경우에는 파일 샤드 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. 로그 내보내기에 사용된 주제에 대한 구독을 찾거나 만들고 여기에서 로그 항목을 가져옵니다. 새로운 로그 항목이 게시될 때까지 기다려야 할 수도 있습니다.

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

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

내보낸 로그가 없으면 내보내기 시스템 측정항목을 확인하세요. 내보내기 시스템 측정항목은 내보낸 로그 항목의 수와 오류로 인해 중단된 로그 항목의 수를 각각 알려줍니다. 내보내기 시스템 측정항목에 내보낸 로그 항목이 없는 것으로 나타나면 내보내기 쿼리를 확인하여 쿼리와 일치하는 로그 항목이 최근 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은 제3자와의 로깅 통합을 지원합니다. 현재 통합 목록은 파트너에서 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자가 즉시 로그 항목을 수신하기 시작합니다.

로그 항목 객체

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

가격 책정

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

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