Generated banner for Cloud Logging Query Generation
Generated logo for Cloud Logging Query Generation

Cloud Logging Query Generation

GoogleOfficialPublished by Google

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • No issues found

From the author

Generates Logging Query Language (LQL) queries for Cloud Logging on Google Cloud 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 Cloud Spanner.
— the description by Google

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill assists users in constructing precise Logging Query Language (LQL) queries for Google Cloud Logging. It provides structured guidance on syntax, resource types, and field filtering to help users debug issues or analyze log data. The skill adheres to specific formatting rules, including the use of double quotes for strings, capitalized boolean operators, and explicit grouping with parentheses. It also includes logic for handling audit logs and global keyword searches when specific schemas are unavailable.

What it does

  • Translates natural language requests into valid LQL queries.
  • Provides syntax enforcement for boolean operators and string literals.
  • Identifies correct resource types for various Google Cloud services.
  • Handles audit and admin log queries using specific protoPayload schemas.
  • Generates global search queries using the SEARCH function when schemas are unknown.
  • Applies mandatory attribution headers for direct CLI or API interactions.

When to use it

  • When you need to filter or search through Google Cloud logs.
  • When debugging specific service issues and requiring log data.
  • When you are unsure of the correct LQL syntax or resource type for a specific service.
  • When you need to extract audit logs for security or operational review.

Advantages

  • Reduces manual effort in writing complex LQL syntax.
  • Ensures adherence to Google Cloud logging best practices.
  • Provides service-specific guidance for accurate filtering.
  • Maintains consistent attribution for observability operations.

Usage examples

“Show me all error logs for my GCE instance named web-server-01.”
resource.type="gce_instance" AND resource.labels.instance_name="web-server-01" AND severity>=ERROR
“Find audit logs for BigQuery dataset deletions.”
resource.type="bigquery_dataset" AND protoPayload.methodName="google.cloud.bigquery.v2.DatasetService.DeleteDataset"

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/google/cloud-logging-query-generation/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip cloud-logging-query-generation.zip -d .agents/skills

Documentation by Google

Generate Logging Query Language queries

Use this skill to generate correct Logging Query Language (LQL) queries for Cloud Logging.

Attribution

MUST READ: Before executing any gcloud, REST API, or MCP command, you MUST read Usage Attribution. For commands executed directly in the terminal (never in generated scripts, Terraform, or user code), prefix gcloud with CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:cloud-logging-query-generation)" and append agent-skills/1.0 (skill:cloud-logging-query-generation) to User-Agent headers.

Core rules

  1. 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.

  2. Common pitfalls:

    • Instance ID vs. Instance Name: For the gce_instance resource 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 use resource.labels.instance_name if that label is available for the resource.

    • Resource Type Accuracy: Do not guess resource types. You must look up the correct resource.type value in the service-specific reference files. For example, use internal_http_lb_rule for Internal HTTP(S) Load Balancer rules when filtering by forwarding rule name or region (instead of http_load_balancer).

  3. 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. If the variable is required for a functional query (like a log bucket name for a regional log), insert an uppercase placeholder string wrapped in angle brackets (for example, "<PROJECT_ID>"). CRITICALLY: If you include a placeholder for a variable the user omitted, it will act as an explicit filter that causes logs to be missed. Therefore, you MUST omit the entire filter/line containing the placeholder if the field is not strictly required. For example, completely omit resource.labels.instance_id="..." if the user didn't specify an instance, but you MUST include logName=".../projects/<PROJECT_ID>/..." with a placeholder if constructing a regional log bucket query where a project ID is strictly required.

  4. Preferred fields:

    • Include resource.type and log_id restrictions when the query targets specific Google Cloud services or resources. Global queries (for example, "latest error logs") do not require these restrictions.

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. Do not stop reading after finding the Base Schema in the file. You must verify if there are specific requirements for state tracking (like previousState) or resource-specific log IDs detailed in the paragraphs or specific query examples below the schema block.

For the following services, read the exact file listed:

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

  1. Resource Types: Explicitly define the resource.type in 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")).

  2. Audit and Admin Logs: If the user asks for audit logs, admin logs, API logs, or logs about who created, updated, deleted, read, or accessed a resource:

    • You MUST read references/query_audit_logs.md for the correct protoPayload schema paths and common examples.

    • If a specific example is not listed, guess the protoPayload.methodName by combining the service and verb. When guessing, you MUST use the scoped SEARCH() function (e.g., SEARCH(protoPayload.methodName, "compute.instances.insert")) instead of the exact match operator (=) to avoid version prefix mismatches. Do NOT use the colon operator (:) as it may cause substring false positives.

    • For generic API enable/disable events (e.g., a service was disabled), always use resource.type="audited_resource".

  3. 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.* or protoPayload.* field structures when you are certain of their exact name.

    • Use the SEARCH() function to find the keyword globally within the correct resource.type.

    • Mandatory LQL Comment: 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.

Files

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Google
Publisher
Google (Official)
Source
google/skills · skills/cloud/cloud-logging-query-generation · commit 2194d3b
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google or Google.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download cloud-logging-query-generation.zip