Cloud Functions 日志查询 LQL 实战基于 cloud-logging-query-generation 技能构建 1st Gen 与 2nd Gen 函数查询【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills在 cloud-logging-query-generation 技能中Cloud Functions 服务日志的 LQLLogging Query Language查询参考文档 query_cloud_functions.md 专门解决一个高频排障场景如何为 Cloud Functions 的日志写出正确的过滤条件。本文以该文档为核心完整继承其针对 1st Gen 与 2nd Gen 两代函数给出的资源类型、Log ID、执行关联Execution Correlation等基础模式并结合同技能的 SKILL.md 语法规范与 api_reference.md 语法参考进行扩充帮助你在 Cloud Logging 中精准定位某一函数的调用错误、按函数名与区域定向过滤并用 Trace ID 关联单次并发执行的全部日志。一、技能背景从自然语言到 LQLSKILL.md 定义了该技能的整体职责把自然语言需求转换为正确的 Cloud Logging LQL 查询并按服务拆分了多份参考文件——其中 Cloud Functions 对应的正是 references/query_cloud_functions.mdCloud Run 对应 references/query_cloud_run.md。在写任何 Cloud Functions 查询之前必须遵守该技能声明的核心语法约束这些约束决定了下文中所有查询的写法字符串字面量一律使用双引号禁止使用单引号。布尔运算符必须全大写AND、OR、NOT。始终使用括号分组显式控制优先级——例如 2nd Gen 错误查询中三个log_id()条件必须用括号包成一个 OR 组。优先在查询中限定resource.type与log_id仅当查询针对特定服务时“最近所有错误日志”这类全局查询则不需要。变量占位符采用尖括号大写形式如PROJECT_ID且若某字段并非查询必需应整行省略占位符而不是保留一个永远匹配不上的占位过滤器。二、基础 Schema两代函数的日志结构差异Cloud Functions 的日志结构在 1st Gen 与 2nd Gen 之间存在显著差异这是写查询前必须先判断的第一件事——两代函数使用完全不同的resource.type和log_id。1st Gen Functions1st Gen 函数有独立的监控资源类型其核心模式如下要素取值用途Resource Typeresource.typecloud_function圈定 1st Gen 函数日志Log IDlog_id(cloudfunctions.googleapis.com/cloud-functions)指定 Cloud Functions 平台日志流执行关联labels.execution_idEXECUTION_ID过滤出同一次调用的全部日志定向过滤resource.labels.function_nameFUNCTION_NAME、resource.labels.regionREGION定位到具体函数与区域也就是说1st Gen 下找出某个函数的某一次执行的错误有两条路径按函数名区域定向或拿到execution_id后做精确的执行级关联。2nd Gen FunctionsCloud Run Functions2nd Gen 函数原生运行在 Cloud Run 基础设施上因此它没有独立的资源类型而是共享标准 Cloud Run schema与 query_cloud_run.md 中cloud_run_revision的 Service 模式一致并且存在并发请求日志交错的问题。其核心模式为Resource Typeresource.typecloud_run_revisionLog ID 分三类用途log_id(run.googleapis.com/requests)—— 调用遥测延迟、HTTP 状态码、请求 URL 等由 Cloud Run 网关产生的路由元数据log_id(run.googleapis.com/stdout)与log_id(run.googleapis.com/stderr)—— 应用容器自己打印的标准输出/错误输出。执行关联最可靠的方式是通过 Trace IDtraceprojects/PROJECT_ID/traces/TRACE_ID。仅当你的运行时 SDK 确实会显式注入该字段时才退而求其次使用labels.execution_id作为备选。定向过滤注意 label 名称与 1st Gen 不同——使用resource.labels.service_nameFUNCTION_NAME与resource.labels.locationREGION而不是function_name/region。这一以 Trace 而非 execution_id 关联并发执行的策略与 Cloud Run 参考文档 中的结论一致Cloud Run 天然处理并发请求用简单的 execution ID label 做关联通常被视为反模式应当改用trace字符串匹配来串联单次请求的requests日志与其产生的stdout/stderr日志。三、可直接使用的示例查询原文档给出了两条无需替换变量的现成查询分别覆盖两代函数的执行错误排查场景。查询 1st Gen Cloud Functions 的执行错误需替换变量无resource.typecloud_function AND log_id(cloudfunctions.googleapis.com/cloud-functions) AND severity ERROR解读三段条件分别限定资源类型、日志流、严重度severity ERROR使用数值比较运算符会同时命中ERROR与CRITICAL等更高级别。这是在全项目范围内扫描所有 1st Gen 函数执行错误的基线查询。查询 2nd Gen Cloud Functions 的执行错误需替换变量无resource.typecloud_run_revision AND (log_id(run.googleapis.com/stdout) OR log_id(run.googleapis.com/stderr) OR log_id(run.googleapis.com/requests)) AND severity ERROR解读与 1st Gen 查询的关键差别在于——2nd Gen 的错误可能出现在应用输出stdout/stderr也可能出现在网关遥测requests中因此必须用括号把三个log_id()条件组合成一个 OR 组再与其余条件做 AND这正是 SKILL.md 中始终用括号显式分组规则的典型落地。定向到具体函数基于基础模式组合原文档给出的定向条件可以进一步组合为可复制的查询模板。例如定位某区域下指定 1st Gen 函数的全部日志resource.typecloud_function AND resource.labels.function_nameFUNCTION_NAME AND resource.labels.regionREGION2nd Gen 对应写法注意 label 名差异resource.typecloud_run_revision AND resource.labels.service_nameFUNCTION_NAME AND resource.labels.locationREGION按照 SKILL.md 的占位符规则如果用户没有指定区域应当直接省略resource.labels.region这一行而不是填入REGION占位符——因为占位符会作为显式过滤器生效导致日志被漏掉。四、基于 LQL 语法参考的查询扩展技巧api_reference.md 提供了 LQL 的完整语法细节配合 Cloud Functions 的 schema 可以构造更精细的查询全局关键字搜索当你在参考文档中找不到所需字段的确切结构时SKILL.md 要求改用全局SEARCH()而不是猜字段名。例如在 2nd Gen 函数的应用输出里找包含某条错误信息的日志resource.typecloud_run_revision AND log_id(run.googleapis.com/stderr) AND SEARCH(timeout)按 SKILL.md 要求使用SEARCH()兜底时应在查询顶部加一行--注释说明因参考文件中缺少确切 schema 而采用了全局关键字搜索。限定字段的定向搜索SEARCH()可指定搜索范围例如只在文本负载中搜索SEARCH(textPayload, hello world)且参数必须是单个字符串字面量、不能传入布尔表达式。正则匹配RE2 语法、大小写敏感、默认不加锚点。例如匹配特定函数的错误resource.labels.function_name ~ ^my-func.*若需要大小写不敏感可写~ (?i)keyword。时间范围timestamp 2023-11-29T23:00:00Z严格 RFC 3339或日期快捷形式timestamp 2023-11-29可追加到上述任意查询后缩小排查窗口。空值与字段存在性显式 JSON null 用NULL_VALUE判断字段缺失时否定比较为真而等值比较为假NOT missingFieldx为 TRUEmissingField!x为 FALSE用:*通配判断字段是否存在例如labels.execution_id:*可用于先探测某批日志是否携带该关联标签。五、实操在 Cloud Logging 中运行这些查询打开 Cloud Logging 的 Logs Explorer切换到Logs advanced query高级查询模式——LQL 仅在此模式下可用Express 模式只提供有限的过滤控件。粘贴上文查询占位符按实际值替换或按规则整行删除并设置合适的时间范围。排查某次具体调用的完整链路时先运行requests日志流查询定位到目标请求日志记下其trace字段值再用traceprojects/PROJECT_ID/traces/TRACE_ID作为过滤条件即可把该次执行在stdout/stderr中产生的全部输出聚合出来——这是对 2nd Gen 并发交错日志最有效的关联手段。若需要复用可将查询保存为 Logs Explorer 的查询配置或直接在日志查询界面分享。六、延伸阅读SKILL.md —— 技能总体规则、占位符约定与未知 schema 时降级为 SEARCH策略api_reference.md —— LQL 运算符、SEARCH、正则、时间戳与内置函数log_id、source、sample、cast、ip_in_net等的完整语法参考query_cloud_run.md —— Cloud Run Services/Jobs 的cloud_run_revision/cloud_run_jobschema与 2nd Gen 函数日志直接对应query_audit_logs.md —— 若需排查谁创建/删除了某个函数等审计事件应使用其中的protoPayload模式而非本文的运行时日志模式。适用前提与限制本文所有resource.type、log_id、label 名称均以 query_cloud_functions.md 在当前仓库中的内容为准2nd Gen 的labels.execution_id备选方案仅在运行时 SDK 显式注入该字段时可用具体行为取决于你所使用的函数运行时与 SDK 版本。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
