Error Reporting 会汇总您正在运行的云中产生的错误 服务。这些错误是由 Error Reporting API 或推断 在 Error Reporting 检查日志条目时的常见错误, 例如堆栈轨迹Error Reporting 对错误分组 它们的根本原因相同。
系统会自动启用 Error Reporting。
Error Reporting 每小时采集最多 1,000 个错误样本。 在达到此上限后,系统将估算显示的计数。为避免错过太多事件 Error Reporting 样本最多 每小时 100 次错误,并继续推算计数。
Error Reporting 分析日志条目时
Error Reporting 是一项全球性服务, Cloud Logging,并且可以在满足以下所有条件时分析日志条目:
- Assured Workloads 已停用。如需了解详情,请参阅 Assured Workloads 概览。
- 在存储日志条目的所有日志存储桶中停用了客户管理的加密密钥 (CMEK)。关于如何 确定日志存储桶的 CMEK 配置,请参阅 验证密钥的启用状态。
- 日志存储桶满足以下任一条件:
- 日志存储桶存储在日志条目来源的项目中。
- 日志条目已路由到某个项目,然后该项目存储了这些日志条目 存储在自己的日志存储桶中
错误如何分组
Error Reporting 在评估日志条目时,会忽略 符合以下条件的日志条目:
- 在 App Engine 标准环境中,忽略严重性标记为低于
ERROR
的错误。 - 不归用户所有的堆栈帧(例如,属于公共库的堆栈帧)已被忽略。
- 将一个或多个堆栈帧的所有重复序列替换为该序列的单个匹配项。
- 移除编译器引入的方法和符号。
接下来,Error Reporting 按照以下规则对错误进行分组:
- 将类型相同且堆栈类似的异常分在同一组。
- 对于通常与发生异常的源位置无关的异常,忽略堆栈轨迹。
- 如果不存在异常堆栈的错误是由
相同的日志条目,近似于报告的来源位置
来自 (
reportLocation
)。
具体而言,以下分组规则会按照如下顺序应用:
错误类型 | 分组依据 |
---|---|
由环境中的一般问题引发的错误。
例如,特定于 App Engine 的问题: com.google.apphosting.runtime.HardDeadlineExceededError com.google.appengine.api.datastore.DatastoreTimeoutException Java 问题: java.util.concurrent.CancellationException |
按异常类型分组。 |
堆栈轨迹错误。如果是嵌套异常,则考虑最内层的异常。
例如: runtime error: index out of range package1.func1() file1:20 package2.func2() file2:33 |
按异常类型和 5 个最顶层的帧分组。 |
没有堆栈轨迹但带有消息的错误。
例如: runtime error: index out of range func1() |
按消息和函数名称(如果有)分组。仅考虑消息的前 3 个字面量标记。在左侧的示例中,这些标记分别为 runtime 、error 和 index 。 |
数据地区化
如果您为数据驻留或影响级别 4 (IL4) 要求设置了 Assured Workloads,Google Cloud 会自动停用错误报告。
在 Cloud Logging 中,您可以通过路由方式来将日志区域化 特定位置在错误组页面上, Error Reporting 根据 包含日志条目的日志存储桶的区域。 由于 Error Reporting 是一项全球性服务,因此错误组 可以从任何区域访问此行为不可配置。