本文档介绍如何查找从 Cloud Logging 路由到受支持的目标位置的日志条目：
| 目标 | 路由频率 |
|---|---|
| Cloud Storage 存储桶 | 每小时批次 |
| BigQuery 表 | 近乎实时 |
| Pub/Sub 主题 | 近乎实时 |
| Cloud Logging 存储分区 | 近乎实时 |
| 第三方目标平台 (Splunk) | 近乎实时 |
如需查看接收器的概念讨论，请参阅路由和存储概览：接收器。
如需了解如何路由日志，请参阅配置和管理接收器。
Cloud Storage
若要在 Cloud Storage 中查看路由的日志，请执行以下操作：
转到 Google Cloud 控制台中的 Cloud Storage 浏览器：
选择您要用作路由目标位置的 Cloud Storage 存储桶。
如需详细了解如何在 Cloud Storage 存储桶中组织日志，请参阅本文档中的组织 Cloud Storage。
路由频率
日志条目每小时向 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.5 GiB。
对于接收器包含完全相同或重叠的查询的情况，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（世界协调时间）表示。
其 receiveTimestamp 位于 timestamp 的 60 分钟校准时段内的日志条目将写入主分片文件。例如，其 timestamp 为 08:00:00 且 receiveTimestamp 为08:10:00 的日志条目将存储在主分片文件中。
这些文件的后缀中包含一个带编号的主分片：_Sn.json。
其 timestamp 位于不同于 receiveTimestamp 的 60 分钟校准时段内的日志条目将写入附加分片文件。例如，其 timestamp 为 08:00:00 且 receiveTimestamp 为 09:10:00 的日志条目将存储在附加分片文件中。
这些文件的后缀中包含一个带编号的附加 _An:Unix_timestamp.json 分片。
例如，如果日志条目的 timestamp 介于 08:00:00 和 08:59:59 之间，但其 receiveTimestamp 位于不同的 60 分钟校准时段内，则日志项目将写入带有 _An:Unix_timestamp.json 后缀的文件中，其中 Unix 时间戳表示文件路由到 Cloud Storage 的时间。如果日志条目的 timestamp 为 08:50:00，且 receiveTimestamp 为 09:10:00，并于 2021 年 3 月 25 日 09:15:00 进行路由，则将写入附加文件，如下所示：
08:00:00_08:59:59_A0:1616681700.json
要获取所有日志条目，您必须读取每个时间段的所有分片，在本示例中为文件分片 0 和 1。每个时间段内写入的文件分片数可能会因日志条目数而变化。
在各个分片文件中，日志条目作为一个 LogEntry 对象列表进行存储。如需查看 syslog 条目的示例，请参阅本文档中的 LogEntry 类型。
请注意，这些文件中日志条目的排序顺序并不统一，也无法以其他方式保证排序顺序。
过滤
如需查看将日志路由到 Cloud Storage 的过滤条件示例，请参阅示例查询。
BigQuery
若要在 BigQuery 中查看路由的日志，请执行以下操作：
转到 Google Cloud 控制台中的 BigQuery 页面：
选择用作接收器目标位置的数据集。
选择数据集的一个表。日志条目显示在详细信息标签页中，您也可以通过查询表来返回数据。
如需了解表的组织方式，请参阅表组织。
如需了解路由日志条目字段的命名方式，请参阅日志的 BigQuery 架构。
路由频率
创建新表时，由于 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 查询语法，请参阅查询参考。表通配符函数（允许您跨多个表进行查询）以及展平运算符（允许您显示重复字段中的数据）特别有用。
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 流式传输的路由日志，请执行以下操作：
转到 Google Cloud Console 中的 Pub/Sub 页面：
针对日志接收器中使用的主题查找或创建订阅，并从中提取日志条目。您可能需要等待一段时间，新的日志条目才会发布。
如需详细了解如何在 Pub/Sub 中组织日志，请参阅本文档中的组织日志。
路由频率
将日志路由到 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 可与第三方（如 Splunk）进行日志集成。如需查看当前的集成列表，请参阅合作伙伴了解 Google Cloud 的运维套件集成。
您通过 Pub/Sub 主题路由日志，而第三方通过订阅相同的主题来接收日志。
要执行集成，您需要执行如下操作：
从第三方获取一个基于其 Google Cloud 项目创建的 Google Cloud 服务帐号名称，例如
12345-xyz@developer.gserviceaccount.com。您将使用此名称向第三方授予接收日志的权限。在包含日志的项目中，启用 Pub/Sub API。
-
启用 Pub/Sub API。
创建一个 Pub/Sub 主题。您可以在配置日志接收器时创建主题，也可以按照以下步骤创建主题：
- 转到 Pub/Sub 主题列表。
选择创建主题，并输入主题名称，例如
projects/my-project-id/topics/my-pubsub-topic。您需要将日志路由到此主题。发送到该主题的每条消息都包含 Pub/Sub 消息
attributes中路由的日志条目的时间戳；例如："attributes": { "logging.googleapis.com/timestamp": "2018-10-01T00:00:00Z" }点击创建。
授权 Logging 将日志路由到该主题。如需查看相关说明，请参阅为 Pub/Sub 设置权限。
授权第三方订阅主题：
- 在 Google Cloud Console 中，停留在项目的 Pub/Sub 主题列表。
- 选择新主题。
- 选择权限。
- 输入第三方的服务帐号名称。
- 在选择角色菜单中，选择 Pub/Sub Subscriber。
- 点击添加。
向第三方提供 Pub/Sub 主题的名称；例如
projects/my-project-number/topics/my-pubsub-topic。第三方先订阅该主题，然后您才能开始路由。在第三方订阅主题后，开始路由日志：
- 在包含要路由的日志的项目中，点击搜索查询框上方的创建导出。此操作将打开修改导出设置面板。
- 输入接收器名称。
- 在接收器服务菜单中，选择 Cloud Pub/Sub。
- 在接收器目标位置菜单中，选择第三方将订阅的 Pub/Sub 主题。
- 选择创建接收器。
- 此时会出现一个对话框并显示已创建接收器消息。此消息表示您已成功创建接收器，且该接收器有权将未来的匹配日志写入您选择的目标位置。
您的第三方应该立即开始接收日志条目。
如需了解使用 Pub/Sub 的常见日志路由场景，请参阅“路由到 Cloud Logging 的设计模式：日志记录导出场景”。
Cloud Logging
日志存储分区是 Google Cloud 项目中用于存储日志数据的 Cloud Logging 存储容器。您可以创建日志接收器，将所有或一部分日志路由到 Cloud Logging 中的任何存储桶。这种灵活性让您可以选择将日志存储到哪个 Cloud 项目中，以及与其一起存储哪些其他日志。
如需了解如何创建并列出与 Cloud 项目关联的日志存储分区，请参阅配置和管理日志存储分区。
组织日志条目
Logging 日志条目是类型为 LogEntry 的对象。
具有相同日志类型的日志条目（在 LogEntry 参考中称为 [LOG_ID]）通常具有相同的格式。下表显示了日志条目示例：
syslog
Compute Engine syslog 是由日志记录代理 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"
}
}
Splunk
Logging 通过 Pub/Sub 主题路由日志来支持与 Splunk 集成。如需了解如何创建 Pub/Sub 主题并授权 Splunk 订阅该主题，请参阅第三方与 Pub/Sub 集成。
延迟的日志条目
路由的日志条目每小时向 Cloud Storage 存储桶保存一批。第一批条目可能需要 2 到 3 个小时才会开始显示。带有后缀 An（即“Append”）的路由日志文件分片用于保存延迟的日志条目。
如果目标位置发生中断，Cloud Logging 将缓冲数据，直到中断结束。
如果接收器的目标位置没有任何日志，请检查导出系统指标。导出系统指标指示路由了多少日志条目以及由于错误而丢弃了多少日志条目。如果导出系统指标指示没有日志条目路由到目标位置，请检查过滤条件以验证与过滤条件匹配的日志条目是否刚刚出现在 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 流日志生成费用。