用自然语言生成 Google Cloud Logging…

当你需要查询 Google Cloud Logging 日志数据或排查问题时，把自然语言请求转成正确的 Logging Query Language (LQL) 查询。

适用场景

解决思路

1. 严格遵循语法：字符串字面量一律用双引号（"），不要用单引号（'）。
2. 布尔运算符全部大写：AND、OR、NOT。
3. 始终用括号对条件分组并显式声明优先级。
4. 避免常见陷阱——区分 Instance ID 与 Instance Name：对 gce_instance 资源类型，不要把实例名与实例 ID 比较；实例名是字符串（如 my-instance），实例 ID 是数字；若只有名称，用 SEARCH("my-instance") 或使用 resource.labels.instance_name（若该资源有此标签）。
5. 避免常见陷阱——资源类型要准确：不要猜测 resource.type，必须在对应服务的参考文件中查找正确的 resource.type 值；例如按转发规则名或区域过滤 Internal HTTP(S) Load Balancer 规则时用 internal_http_lb_rule（而不是 http_load_balancer）。
6. 输出格式：只输出原始 LQL 查询文本，不要加对话性内容；除非用户明确要求，不要用 markdown 代码块包裹查询；允许使用合法的 LQL 注释（--），且这是唯一可接受的解释或警告方式。
7. 不要因缺少变量而阻塞：若用户请求缺少具体标识符（如 project ID、实例名、IP 地址），不要请求澄清；若该变量是功能性查询所必需（如区域日志的 log bucket 名），插入用尖括号包裹的大写占位符字符串（如 "<PROJECT_ID>"）。
8. 关键：若为省略的变量加入占位符，它会成为显式过滤器导致漏掉日志；因此若某字段并非严格必需，必须整条省略包含该占位符的过滤条件/行。例如用户未指定实例时完全省略 resource.labels.instance_id="..."；但在构造区域日志桶查询且 project ID 严格必需时，必须包含带占位符的 logName=".../projects/<PROJECT_ID>/..."。
9. 优先字段：当查询针对特定 Google Cloud 服务或资源时，加入 resource.type 和 log_id 限制；全局查询（如“最新错误日志”）不需要这些限制。
10. 生成查询前必须阅读对应服务的参考文件：LQL schema 和 resource.type 值是服务特定的；不要只读到文件中的 Base Schema 就停止，必须确认是否有状态跟踪（如 previousState）或资源特定 log ID 等特殊要求（在 schema 块下方的段落或具体查询示例中）。
11. 按服务读取指定文件：App Engine→references/query_app_engine.md；BigQuery→references/query_bigquery.md；Cloud Deployment Manager→references/query_deployment_manager.md；Cloud Functions→references/query_cloud_functions.md；Cloud Observability (Monitoring, Logging, Trace)→references/query_cloud_observability.md；Cloud Run→references/query_cloud_run.md；Cloud Source Repositories→references/query_cloud_source_repositories.md；Cloud Spanner→references/query_spanner.md；Cloud SQL→references/query_cloud_sql.md；Cloud Storage→references/query_cloud_storage.md；Cloud Tasks→references/query_cloud_tasks.md；Compute Engine (GCE)→references/query_compute_engine.md；Dataflow→references/query_dataflow.md；Dataproc→references/query_dataproc.md；Kubernetes Engine (GKE)→references/query_gke.md；IAM & Service Accounts→references/query_iam.md；Networking (VPC, Load Balancing, and others)→references/query_networking.md；Security (Audit logging)→references/query_security.md；Service Usage (Enable/Disable API, Quotas)→references/query_service_usage.md；Third Party (for example, Nginx, Apache)→references/query_third_party.md。
12. 未列出的 Google Cloud 服务：若服务不在上述列表中，基于你的通用知识编写 LQL 查询。
13. 查询生成规则——资源类型：针对特定服务时显式定义 resource.type；某些查询可能需要跨多个类型搜索（如 resource.type=("bigquery_project" OR "bigquery_dataset")）。
14. 查询生成规则——审计与管理日志：若用户要求 audit logs、admin logs、API logs，或关于谁创建/更新/删除/读取/访问资源的日志，必须阅读 references/query_audit_logs.md 获取正确的 protoPayload schema 路径和常见示例。
15. 若审计日志没有列出的具体示例，通过组合服务与动词猜测 protoPayload.methodName；猜测时必须使用作用域 SEARCH() 函数（如 SEARCH(protoPayload.methodName, "compute.instances.insert")）而不是精确匹配运算符（=），以避免版本前缀不匹配；不要使用冒号运算符（:），因为它可能导致子串误报。
16. 对于通用 API 启用/禁用事件（如某服务被禁用），始终使用 resource.type="audited_resource"。
17. 处理未知 schema（关键）：若用户要求按某字段或条件过滤，而在参考文件中找不到匹配示例或 schema，则必须生成使用全局搜索的查询。
18. 仅在确定字段确切名称时才指定 jsonPayload.* 或 protoPayload.* 字段结构。
19. 使用 SEARCH() 函数在正确的 resource.type 内全局查找关键字。
20. 强制 LQL 注释：交付使用 SEARCH 的查询时，必须在查询顶部添加 LQL 注释（用 --）说明因参考中没有确切 schema 而使用了全局关键字搜索；不要输出对话性文本，严格遵守输出格式规则。
21. 参考链接：Cloud Logging query language 文档 https://docs.cloud.google.com/logging/docs/view/logging-query-language；Monitored resource types catalog https://docs.cloud.google.com/logging/docs/api/v2/resource-list；Cloud Logging query library https://docs.cloud.google.com/logging/docs/view/query-library。

适用边界 · 注意事项

• 不要用此技能查询其他数据库，如 SQL 或 Cloud Spanner。
• 不要猜测 resource.type 值，必须在服务参考文件中查找。
• 不要因缺少变量而向用户请求澄清或阻塞输出。