使用导出的日志

本页面介绍了如何在 Cloud Storage、BigQuery、Pub/Sub 和 Cloud Logging 中查找和使用导出的日志条目。

如需从概念上大致了解如何使用 Cloud Logging 导出日志，请参阅日志导出概览。

Cloud Logging

如需了解如何使用 Cloud Logging 导出日志，请参阅以下页面：

Cloud Storage

若要在 Cloud Storage 中查看导出的日志，请执行以下操作：

  1. 在 Cloud Console 中转到 Cloud Storage 浏览器：

    转到 Cloud Storage 浏览器

  2. 选择用于日志导出的存储分区。

如需详细了解如何在存储分区中整理日志，请转到本页中的整理 Cloud Storage。

导出日志的可用情况

如果没有任何导出的日志，请检查导出系统指标。导出系统指标可以告诉您导出了多少日志条目以及由于错误而丢弃了多少日志条目。如果导出系统指标指示未导出任何日志条目，请检查导出查询以验证与查询匹配的日志条目是否刚刚出现在 Logging 中：

转到“日志导出”

日志条目每小时向 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（世界协调时间）起的一个小时内所有实例的 syslog 日志条目。日志条目时间戳以 UTC 表示。

如需获取所有日志条目，您必须读取每个时间段的所有分片，在本示例中为文件分片 0 和 1。每个时间段内写入的文件分片数可能会因日志条目数而变化。

在各个分片文件中，日志条目作为一个 LogEntry 对象列表进行存储。如需查看 syslog 条目的示例，请转到本页面中的 LogEntry 类型。

请注意，这些文件中日志条目的排序顺序并不统一，也无法以其他方式保证排序顺序。

查询

如需了解将日志导出到 Cloud Storage 的查询示例，请转到示例查询。

BigQuery

若要在 BigQuery 中查看导出的日志，请执行以下操作：

  1. 转到 Cloud Console 中的 BigQuery 页面。

    转到 BigQuery

  2. 选择用作接收器目标位置的数据集。

  3. 选择数据集的一个表。日志条目显示在详细信息标签页中，您也可以通过查询表来返回数据。

如需了解详情，请转到整理表，了解表的整理方式；请转到导出日志和 BigQuery 架构，了解导出的日志条目字段的命名方式。

导出日志的可用情况

如果没有任何导出的日志，请检查导出系统指标。导出系统指标可以告诉您导出了多少日志条目以及由于错误而丢弃了多少日志条目。如果导出系统指标指示未导出任何日志条目，请检查导出查询以验证与查询匹配的日志条目是否刚刚出现在 Logging 中：

转到“日志导出”

创建新表时，由于 Logging 会将日志条目导出到 BigQuery，新表可能需要几分钟时间才会显示第一批日志条目。后续日志条目通常会在一分钟之内出现。如需了解详情，请参阅下面的整理表。

整理表

将日志导出到 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 2017-12-31T23:59:59.999Z compute_googleapis_com_activity_log_20171231

1：日志条目时间戳以 UTC（世界协调时间）表示。

架构和字段

导出日志的 BigQuery 表架构基于 LogEntry 类型的结构和日志负载的内容。您可以在 BigQuery 网页界面中选择包含导出日志条目的表，从而查看表架构。

用于表示复杂日志条目负载的 BigQuery 表架构可能令人费解，此外，导出的审核日志使用一些特殊的命名规则。如需了解详情，请参阅导出的日志的 BigQuery 架构。

查询

如需了解将日志导出到 BigQuery 的查询示例，请转到示例查询。

如需详细了解 BigQuery 查询语法，请参阅查询参考。表通配符函数（支持跨多个表进行查询）以及 Flatten 运算符（支持显示重复字段中的数据）特别有用。

Compute Engine 日志查询示例

以下 BigQuery 查询可检索数天内多种日志类型的日志条目：

  • 该查询搜索日志 syslog 和 apache-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

我们建议使用 Pub/Sub 将 Cloud Logging 日志与第三方软件集成。

导出到 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 与第三方集成

Logging 可与第三方进行日志集成。如要查看当前的集成列表，请参阅合作伙伴了解 Google Cloud 的运维套件集成。

您通过 Pub/Sub 主题导出日志，而第三方通过订阅同一主题来接收日志。

如需执行集成，您需要执行以下操作：

  1. 从第三方获取一个基于其 Google Cloud 项目创建的 Google Cloud 服务帐号名称，例如 12345-xyz@developer.gserviceaccount.com。您将使用此名称向第三方授予接收日志的权限。

  2. 在包含日志的项目中，

  3. 启用 Pub/Sub API。

    启用 API

  4. 创建一个 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 设置权限。

  5. 授权第三方订阅主题：

    1. 保留在 Cloud Console 中的项目的 Pub/Sub 主题列表中。
    2. 选择新主题。
    3. 选择权限。
    4. 输入第三方的服务帐号名称。
    5. 在选择角色菜单中，选择 Pub/Sub Subscriber。
    6. 点击添加。

  6. 向第三方提供 Pub/Sub 主题的名称；例如 projects/my-project-number/topics/my-pubsub-topic。第三方先订阅该主题，然后您才能开始导出。

  7. 在第三方订阅主题后，开始导出日志：

    1. 在包含要导出的日志的项目中，点击搜索查询框上方的创建导出。此操作将打开修改导出设置面板：

      “修改导出设置”面板

    2. 输入接收器名称。

    3. 在接收器服务菜单中，选择 Cloud Pub/Sub。

    4. 在接收器目标位置菜单中，选择第三方将订阅的 Pub/Sub 主题。

    5. 选择创建接收器，以开始导出。

    6. 将出现一个已创建接收器对话框。这表示您已成功创建导出接收器，且该接收器有权将未来的匹配日志写入您选择的目标位置。

您的第三方应该立即开始接收日志条目。

日志条目对象

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 中的日志条目包含 protoPayload 字段，此字段保存着类型为 RequestLog 的对象：

{
  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"
 }
}

延迟的日志条目

导出的日志条目每小时向 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 流日志生成费用。