本文档介绍了如何查找您从中路由的日志条目 将 Cloud Logging 导入 Cloud Storage 存储分区。
日志条目每小时向 Cloud Storage 存储分区保存一批。第一批条目可能需要 2 到 3 个小时才会开始显示。
准备工作
有关接收器的概念性讨论,请参阅 路由和存储模型概览:接收器。
如需了解如何路由日志,请参阅 将日志路由到支持的目标位置。
查看日志
如需查看路由到 Cloud Storage 的日志,请执行以下操作:
-
在 Google Cloud 控制台中,转到存储分区页面:
如果您使用搜索栏找到此页面,请选择子标题为 Cloud Storage。
选择您要用作路由目标位置的 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/
) 中包含多个文件,其中每个文件都保存着在相应文件名中指定的时间段内路由的日志条目。系统会对这些文件进行分片,文件名均以分片编号 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
条目的示例,请参阅
日志条目组织。
请注意,这些文件中日志条目的排序顺序并不统一,也无法以其他方式保证排序顺序。
延迟的日志条目
路由的日志条目每小时向 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 不会对复制日志、定义日志范围或通过日志浏览器或 Log Analytics 页面发出的查询收费。
有关详情,请参阅以下文档:
- Cloud Logging 价格摘要
目标位置费用:
- 如果您在发送 Virtual Private Cloud 流日志后又从 Cloud Logging 中排除这些日志,则需支付 VPC 流日志生成费用。