Agent Skills
› google/skills
› cloud-logging-query-generation
cloud-logging-query-generation
GitHub根据自然语言生成 Google Cloud Logging 的 LQL 查询语句，适用于日志查询与调试。严格遵循语法规范，自动处理缺失参数并插入占位符，禁止用于其他数据库。
Trigger Scenarios
需要查询 Google Cloud 日志数据
正在调试系统问题需检索日志
Install
npx skills add google/skills --skill cloud-logging-query-generation -g -y
SKILL.md
Frontmatter
{
"name": "cloud-logging-query-generation",
"description": "Generates Logging Query Language (LQL) queries for Google Cloud Logging from natural language. Use this skill when you need to query log data or when you are debugging issues. You can filter log data by Google Cloud service. Don't use this skill to query other databases, such as SQL or Spanner."
}
Generate Logging Query Language queries
Use this skill to generate correct Logging Query Language (LQL) queries for Cloud Logging.
Core rules
-
Strict syntax requirements:
- Always use double quotes (
") for string literals. Do not use single quotes ('). - Write boolean operators in all capitals:
AND,OR,NOT. - Always use parentheses to group terms and explicitly enforce precedence.
- Always use double quotes (
-
Common pitfalls:
- Instance ID vs. Instance Name: For the
gce_instanceresource type, do NOT compare instance names to instance IDs. Instance names are strings (for example,my-instance). Instance IDs are numeric. If you only have the name, then search by instance name,SEARCH("my-instance"), or useresource.labels.instance_nameif that label is available for the resource. - Resource Type Accuracy: Do not guess resource types. You must look
up the correct
resource.typevalue in the service-specific reference files. For example, useinternal_http_lb_rulefor Internal HTTP(S) Load Balancer rules when filtering by forwarding rule name or region (instead ofhttp_load_balancer).
- Instance ID vs. Instance Name: For the
-
Output format and placeholders:
- Output only the raw LQL query text. Do not include conversational
filler. Do not wrap the query in markdown code blocks unless explicitly
requested by the user. Valid LQL comments (using
--) are allowed, and are the ONLY acceptable way to include explanations or warnings. - Never block on missing variables. If the user's request lacks
specific identifiers (like a project ID, instance name, or IP address),
do not ask them for clarification. Instead, insert uppercase placeholder
strings wrapped in angle brackets (for example,
"<PROJECT_ID>","<YOUR_SERVICE_NAME>") directly into the query.
- Output only the raw LQL query text. Do not include conversational
filler. Do not wrap the query in markdown code blocks unless explicitly
requested by the user. Valid LQL comments (using
-
Preferred fields:
- Include
resource.typeandlog_idrestrictions when the query targets specific Google Cloud services or resources. Global queries (for example, "latest error logs") do not require these restrictions.
- Include
Detailed reference
Refer to references/api_reference.md for LQL syntax rules, including
Operators, NULL handling, SEARCH, and Regex.
Service reference files
Before generating a query, you MUST read the examples for the specific service.
LQL schemas and resource.type values are service-specific.
For the following services, read the exact file listed:
- App Engine
- BigQuery
- Cloud Functions
- Cloud Observability (Monitoring, Logging, Trace)
- Cloud Run
- Cloud Source Repositories
- Cloud SQL
- Cloud Storage
- Cloud Tasks
- Compute Engine (GCE)
- Dataflow
- Dataproc
- Deployment Manager
- Kubernetes Engine (GKE)
- IAM & Service Accounts
- Networking (VPC, Load Balancing, and others)
- Security (Audit logging)
- Service Usage (Enable/Disable API, Quotas)
- Spanner
- Third Party (for example, Nginx, Apache)
For Google Cloud services that aren't listed: If the service is not listed above, write the LQL query based on your general knowledge.
Query generation rules
- Resource Types: Explicitly define the
resource.typein your queries when focusing on specific services. For some queries, you may need to search across multiple types (for example,resource.type=("bigquery_project" OR "bigquery_dataset")). - Audit and admin logs: Google Cloud Audit logs (Admin Activity, Data
Access) always follow a standard structure inside
protoPayload. If the user asks for logs about who created, updated, or deleted a resource, or an API being called:- Do NOT fall back to
SEARCH(). Instead, useprotoPayload.methodName. - Construct the method name by guessing the service and the verb. Example:
protoPayload.methodName:"compute.instances.insert". - Always use the colon operator (
:) instead of equals (=) formethodName. The colon operator results in substring matching, which is the only feasible option when the exact API string isn't known. - For generic API enable/disable events, use
resource.type="audited_resource".
- Do NOT fall back to
- Handling Unknown Schemas (Crucial): If the user asks to filter by a
specific field or condition, and if you cannot find a matching example or
schema in the reference files, then you must generate a query using global
search.
- Only specify
jsonPayload.*orprotoPayload.*field structures when you are certain of their exact name. - Use the
SEARCH()function to find the keyword globally within the correctresource.type. - Agent Prompt to User: When delivering a query that uses
SEARCH, you MUST add an LQL comment (using--) at the top of the query indicating you used a global keyword search because the exact schema wasn't in your references. Do NOT output conversational text, strictly adhere to the Output Format rule.
- Only specify
Supporting links
Version History
- 513a7a5 Current 2026-07-19 19:03
