skills cloud-logging-query-generationGCE 上第三方应用日志的 LQL 查询完整参考Apache、Nginx、MySQL 等 24 类模板【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文围绕 query_third_party.md 这一服务级参考文档系统讲解 Google Cloud Logging日志查询语言 LQL中针对 Compute Engine 实例上第三方应用日志的查询模板覆盖 Apache、Nginx、MySQL、PostgreSQL、MongoDB、RabbitMQ 等 24 类日志来源的完整 LQL 写法、log_id()与logName两种筛选模式的区别、PROJECT_ID占位符的替换规则以及如何结合 skill 主文件的语法核心规则写出可复制、可运行的查询。文档定位cloud-logging-query-generation skill 的第三方服务参考当前仓库是一个 Google 产品 Agent Skills 集合见 README.md其中cloud-logging-query-generationskill 的职责是“从自然语言生成正确的 Logging Query LanguageLQL查询用于查询日志数据或排障”见 SKILL.md 的 frontmatter 描述。该 skill 采用“主文件 按服务拆分参考文件”的组织方式。SKILL.md明确要求在生成查询前必须先阅读目标服务的参考文件因为 LQL 的 schema 和resource.type取值是服务相关的并给出了 20 个服务的强制映射表。其中第三条就是本文的主角Third Party (for example, Nginx, Apache) → query_third_party.md因此query_third_party.md的定位是当查询目标落在“非 Google 自研”的应用日志上时Web 服务器、数据库、消息队列、CRM、配置管理工具等必须从这份文件里选取对应的模板而不是凭经验猜测resource.type或logName。查询的两种核心模式通读 query_third_party.md 可以发现24 个查询模板虽然针对的应用不同但结构上只有两种模式全部以resource.typegce_instance作为统一前缀即“日志来自某台 GCE 虚拟机”。模式一基于 log_id() 的精确筛选15 类无占位符这类日志syslog、authlog 及各类应用日志在 Cloud Logging 中有固定的日志 ID直接调用内置函数log_id()匹配“非 URL 编码的日志 ID”函数定义见 api_reference.md 的“Additional built-in functions”一节。这类模板不需要替换任何变量可原样使用应用LQL 查询Cassandraresource.typegce_instance AND log_id(cassandra)Jenkinsresource.typegce_instance AND log_id(jenkins)Joomlaresource.typegce_instance AND log_id(joomla)Linux syslogsresource.typegce_instance AND log_id(syslog)Mediawikiresource.typegce_instance AND log_id(mediawiki)memcachedresource.typegce_instance AND log_id(memcached)MongoDBresource.typegce_instance AND log_id(mongodb)MySQLresource.typegce_instance AND log_id(mysql)PostgreSQLresource.typegce_instance AND log_id(postgresql)Redmineresource.typegce_instance AND log_id(redmine)Slow MySQL queriesresource.typegce_instance AND log_id(mysql-slow)Solrresource.typegce_instance AND log_id(solr)SugarCRMresource.typegce_instance AND log_id(sugarcrm)Tomcatresource.typegce_instance AND log_id(tomcat)Zookeeperresource.typegce_instance AND log_id(zookeeper)其中log_id(mysql-slow)值得单独注意它筛选的是 MySQL 慢查询日志与常规log_id(mysql)是不同的日志通道排查慢 SQL 时应优先使用它。模式二基于 logName 的完整资源名筛选8 类需替换 PROJECT_ID这一类日志的日志名是带有完整资源路径前缀的模板通过logName:子串匹配来锁定因此必须替换PROJECT_ID原文档在每一节均以 “Variables to replace:PROJECT_ID” 明确标注resource.typegce_instance AND logName:projects/PROJECT_ID/logs/chef-完整的 8 个模板以 原文 为准应用LQL 查询Chefresource.typegce_instance AND logName:projects/PROJECT_ID/logs/chef-Gitlabresource.typegce_instance AND logName:projects/PROJECT_ID/logs/gitlab-Jettyresource.typegce_instance AND logName:projects/PROJECT_ID/logs/jetty-Magento原文标题写作 Magnetoresource.typegce_instance AND logName:projects/PROJECT_ID/logs/magneto-Nginxresource.typegce_instance AND logName:projects/PROJECT_ID/logs/nginx-Puppetresource.typegce_instance AND logName:projects/PROJECT_ID/logs/puppet-RabbitMQresource.typegce_instance AND logName:projects/PROJECT_ID/logs/rabbitmq-Saltresource.typegce_instance AND logName:projects/PROJECT_ID/logs/salt-注意两个细节冒号操作符:是子串搜索不是精确相等LQL 比较操作符定义见 api_reference.md 的“Comparison operators”一节。因此logName:projects/PROJECT_ID/logs/nginx-匹配的是日志资源名中包含该子串的所有日志——末尾的-前缀设计正是为了兼容带时间戳/主机后缀的日志名。占位符规则SKILL.md的“输出格式与占位符”规则要求凡缺失的必填标识符如项目 ID用尖括号大写占位符PROJECT_ID表示但若该过滤条件并非严格必需则必须整体省略含占位符的整行过滤否则会漏掉日志。上述 8 个模板中logName路径是查询成立的结构性必需项故占位符必须保留并替换为真实项目 ID。特例Apache 的双通道 OR 查询Apache 是唯一既不用log_id()也不需要项目 ID 的特例模板用OR同时命中访问日志与错误日志两个通道resource.typegce_instance AND (logName:/apache-access OR logName:/apache-error)这里用括号显式分组是刻意为之——SKILL.md的“核心规则”第一条要求“始终使用括号对表达式分组并显式强制优先级”。从 api_reference.md 可知AND在空格分隔的表达式之间可省略、NOT可用-替代但本 skill 的规范是显式书写AND/OR且全大写以保证生成结果对人类审阅者无歧义。字符串与操作符的硬性语法约定无论使用哪种模板SKILL.md的“Core rules”都对 LQL 的书写形式做了强约束这直接决定了 24 个模板的可复制性字符串一律使用双引号禁用单引号含特殊字符斜杠、点的字段路径必须整体加引号例如labels.compute.googleapis.com/resource_id见 api_reference.md “Escaping, quotes and case sensitivity”布尔操作符全大写AND、OR、NOT字段路径大小写敏感jsonPayload.endTime与jsonPayload.end_time是不同字段缺失字段的布尔语义字段整体缺失时等值比较返回 false、否定比较返回 trueNOT missingFieldx为 TRUE而missingField!x为 FALSE——排查“为什么查不到某类日志”时需警惕这一点注释以--开头的单行注释是 LQL 中唯一可携带说明文字的方式SKILL.md要求使用SEARCH()全局搜索时必须在查询顶部加注释说明原因。模板之外的进阶写法结合 SEARCH、正则与时间范围24 个模板都只做了“来源过滤”实际排障还需要在模板之上叠加条件。以下写法均可在 api_reference.md 中找到语法依据可与本文模板直接组合1. 关键字全局搜索字段结构未知时的兜底SKILL.md的“Handling Unknown Schemas”规则规定若参考文件中查不到目标字段的 schema不要臆造jsonPayload.*结构改用SEARCH()在正确的resource.type内做全局关键字搜索。例如在 Nginx 日志里找 502-- 第三方应用参考中无精确 schema使用全局关键字搜索 resource.typegce_instance AND logName:projects/my-project-id/logs/nginx- AND SEARCH(502)SEARCH()的要点见 api_reference.md参数必须是单个字符串字面量、不能把布尔表达式直接当参数传应写SEARCH(OOM) OR SEARCH(Out of memory)、大小写不敏感、按 token 分词带反引号的精确短语如SEARCH(exact phrase match)强制 token 顺序与相邻。2. 正则匹配RE2LQL 正则使用 RE2 语法、大小写敏感、默认不锚定。例如从慢查询模板中筛出耗时字段包含特定前缀的行resource.typegce_instance AND log_id(mysql-slow) AND textPayload ~ Query_time: [0-9]\\.[0-9]{3,}~也支持右侧多值labels.env ~ (^prod.*server OR ^staging.*server)。3. 时间范围resource.typegce_instance AND log_id(postgresql) AND timestamp 2026-09-01T00:00:00Z时间戳须符合严格 RFC 3339 格式也可用日期简写timestamp 2026-09-01。与 Compute Engine 参考文档的交叉印证query_third_party.md中所有模板共享resource.typegce_instance前缀这一选择可与同目录的 query_compute_engine.md 相互印证。该文档在“Base schema and structural patterns”一节明确gce_instance是最常见的资源类型适用于分析运行中 VM 的 Guest OS、启动控制台或生命周期事件Guest OS 与应用日志通常经 Ops Agent 摄入按log_id(syslog)、log_id(authlog)或自定义文件log_id过滤原始日志内容位于textPayload非结构化或jsonPayload结构化字段。这与第三方模板的分工完全一致query_third_party.md的log_id(syslog)、log_id(mysql)等模板正是 Ops Agent 摄入通道下的应用日志过滤。需要说明的是本 skill 文档只覆盖“查询侧”的过滤条件——模板能返回结果的前提是对应的第三方应用日志已通过 Ops Agent 等机制以约定日志名摄入 Cloud Logging文档本身未涉及摄入配置这属于 cloud-logging-configuration-basics 与 cloud-logging-cross-project-configuration 两个 skill 的范畴。另外SKILL.md在“Common pitfalls”中特别警告对gce_instance资源不要拿实例名去比较实例 ID——实例名是字符串如my-instance实例 ID 是纯数字若只有名称应使用SEARCH(my-instance)或resource.labels.instance_name。这与 query_compute_engine.md 中 host error 等示例使用resource.labels.instance_idINSTANCE_ID占位为数字 ID的写法互为补充给第三方日志模板追加实例维度过滤时务必用对字段类型。典型组合示例将本文模板、实例过滤、关键字搜索和时间范围组合起来一个完整的“某台 VM 上 Nginx 出现 500 的最近 24 小时日志”查询如下my-project-id与实例 ID 需替换为实际值resource.typegce_instance AND logName:projects/my-project-id/logs/nginx- AND resource.labels.instance_id1234567890123456789 AND SEARCH(500) AND timestamp 2026-09-11T00:00:00Z生成此类查询时的自检清单依据 SKILL.md 各规则字符串是否全部使用双引号、AND/OR/NOT是否全大写resource.type是否取自参考文件而非猜测本文 24 个模板统一为gce_instance所有PROJECT_ID占位符是否已替换非必需过滤是否已整体省略若使用了SEARCH()是否按规范加了--注释说明实例过滤用对了字段名称用SEARCH()/instance_nameID 用instance_id。小结query_third_party.md 为 24 类常见第三方应用日志提供了可直接套用的 LQL 模板15 类通过log_id()精确命中且零占位符8 类通过logName:projects/PROJECT_ID/logs/...子串匹配需替换项目 IDApache 则以双通道OR查询为特例。配合 SKILL.md 的语法核心规则与 api_reference.md 的SEARCH()、RE2 正则、时间范围等进阶语法即可把这些基础过滤模板扩展为覆盖“来源 实例 关键字 时间”四维度的生产级排障查询。该 skill 的边界也需牢记它只服务于 Cloud Logging 的日志查询生成不用于查询 SQL 或 Cloud Spanner 等数据库。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考