查看路由到 Cloud Storage 的日志

本文档介绍了如何查找从 Cloud Logging 路由到 Cloud Storage 存储分区的日志条目。

日志条目每小时向 Cloud Storage 存储分区保存一批。第一批条目可能需要 2 到 3 个小时才会开始显示。

准备工作

如需了解接收器的概念讨论,请参阅路由和存储模型概览:接收器

如需了解如何路由日志,请参阅将日志路由到支持的目标位置

查看日志

如需查看路由到 Cloud Storage 的日志,请执行以下操作:

  1. 在 Google Cloud 控制台的导航面板中,选择 Cloud Storage,然后点击存储分区

    前往存储分区

  2. 选择您要用作路由目标位置的 Cloud Storage 存储桶。

组织日志

当您将日志路由到 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/) 中包含多个文件,其中每个文件都保存着在相应文件名中指定的时间段内路由的日志条目。系统会对这些文件进行分片,文件名均以分片编号 SnAnn = 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 条目的示例,请参阅日志条目整理

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

延迟的日志条目

路由的日志条目每小时向 Cloud Storage 存储桶保存一批。第一批条目可能需要 2 到 3 个小时才会开始显示。带有后缀 An(即“Append”)的路由日志文件分片用于保存延迟的日志条目。

如果目标位置发生中断,Cloud Logging 将缓冲数据,直到中断结束。

如果接收器的目标位置没有任何日志,请检查导出系统指标。导出系统指标指示路由了多少日志条目以及由于错误而丢弃了多少日志条目。如果导出系统指标指示没有日志条目被路由到目标位置,请检查您的过滤条件,以验证与过滤条件匹配的日志条目是否刚刚到达 Logging。

在 Google Cloud 控制台的导航面板中,选择 Logging,然后选择日志路由器

前往日志路由器

App Engine 日志条目

对于产生日志活动的请求,App Engine 还会将多个类型为 google.appengine.logging.v1.LogLine 的子条目(也称为 AppLog 或 AppLogLine)组合到类型为 google.appengine.logging.v1.RequestLog 的主日志条目下。每个日志行都有一个用于标识主条目的“请求 ID”。日志查看器会将日志行与请求日志条目一起显示。Logging 会尝试将所有日志行放入原始请求所在的批次,即使日志行的时间戳将它们放在下一批次也是如此。如果无法做到这一点,请求日志条目可能缺少某些日志行,并且在下一批次中可能会显示没有请求的“孤立”日志行。如果您需要尽量避免这种可能性,请准备好在处理日志后重新连接请求的各个部分。

问题排查

如果接收器的目标位置似乎缺少日志,或者您怀疑接收器未正确路由日志,请参阅对路由日志进行问题排查

价格

在将日志路由到受支持的目标位置时,Cloud Logging 不会产生费用;但是,目标位置可能会产生费用。除 _Required 日志存储桶外,Cloud Logging 会针对将日志流式传输到日志存储桶,以及对超出日志存储桶默认保留期限的存储收费。

Cloud Logging 不对日志复制或通过 Logs Explorer 页面或 Log Analytics 页面发出的查询收费。

有关详情,请参阅以下文档: