Skip to content
cccskills
Official · GoogleFreePublished on GitHub

cloud-monitoring-metric-selection

Find relevant Google Cloud monitoring metrics for a service or resource. Retrieves current metric definitions through the API, filters them by the requested concepts, and presents selected metrics with their names, data types, units, and monitored resources.

OriginalShow the original description

Retrieve, query, and identify relevant Cloud Monitoring metric descriptors on Google Cloud for a service or resource (such as Compute Engine, Spanner, BigQuery, Cloud Run, Cloud SQL, Pub/Sub, Cloud Storage, etc.). Use when asked to find, list, search, or discover GCP metric types, names, kind/value schemas, or descriptors.

Run score Not tested

See how to install

Good for

  • Find CPU metrics for Compute Engine
  • Identify Cloud Storage write throughput and request metrics
  • Check metric data types and units
  • Compare relevant monitoring metrics across services

Files included (2)

  • SKILL.md9.9 KB
  • references/attribution.md1.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Metric Selection (Service Query & Local Keyword Filtering)

Use this skill to identify the most relevant Cloud Monitoring metric descriptors. It queries all metric descriptors for a target service from the API and filters them locally inside the agent's context using keyword matching.

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-monitoring-metric-selection)" and append agent-skills/1.0 (skill:cloud-monitoring-metric-selection) to User-Agent headers.

CRITICAL RULES

  • Always Query Live APIs: You MUST always retrieve the most up-to-date metric descriptors dynamically by calling the list_metric_descriptors MCP tool.
  • Mandatory Project ID and Resource Parameter Clarification: BEFORE calling any API tools (such as list_metric_descriptors), you MUST ensure the GCP Project ID is provided in the prompt, URI, or environment context. If the Project ID cannot be resolved, you MUST ask the user to clarify or provide it BEFORE executing API queries. Do NOT run API queries against unconfirmed default or placeholder project names (such as mock-project, my-project-id, unused, or YOUR_PROJECT_ID).
  • Fallback Reporting: If API calls fail and fallback sources (such as public docs) are used, you MUST state the error, the fallback source, and the risks of non-live data (such as potential staleness, missing custom metrics, or schema mismatches).

Workflow

Step 1: Verify & Auto-Configure MCP

  1. Check if any tool matching list_metric_descriptors (such as google-cloud-monitoring:list_metric_descriptors, mcp_google-cloud-monitoring_list_metric_descriptors, or a similar pattern) is available in your active toolset.

  2. Verify via Unique URL: To ensure you are calling the correct Cloud Monitoring tool, confirm that the underlying MCP server configuration points to: https://monitoring.googleapis.com/mcp.

  3. If the tool is missing:

    • Locate the MCP configuration file for the user's environment. Check common paths:

      • ~/.gemini/config/mcp_config.json
      • ~/.codeium/windsurf/mcp_config.json
      • cline_mcp_settings.json
      • claude_desktop_config.json
    • Directly update/merge the configuration file with the following server configuration. CRITICAL: Merge the JSON object to preserve any existing MCP servers in mcpServers. Do not overwrite the file.

      "google-cloud-monitoring": {
        "url": "https://monitoring.googleapis.com/mcp",
        "authProviderType": "google_credentials",
        "enabledTools": [
          "list_metric_descriptors"
        ]
      }
      
    • Print a clear message notifying the user that the google-cloud-monitoring MCP server has been configured, and request them to restart or start a new chat session to refresh tools. Stop calling further tools and end the turn.

Step 2: Analyze Request & Extract Keywords

  1. Resolve Project ID and Identifiers: Check for the GCP Project ID and resource identifiers in the prompt, resource URIs, or environment context. According to the CRITICAL RULES above, do NOT use placeholder project names.

  2. Identify Service Prefix: Map target GCP services to their standard prefix (such as compute, spanner, bigquery, storage).

  3. Extract Metric Concepts: Extract metric keywords from user prompt (such as "CPU", "memory", "bytes scanned", "latency", "connections") and map to search substrings.

Example Query Analysis:

  • User Prompt: "Check Cloud Storage bucket write throughput and request count"
  • Resource URI: //storage.googleapis.com/projects/my-project/buckets/my-bucket
  • Service Prefix: storage (mapped to storage.googleapis.com)
  • Metric Keywords: write, throughput, request, count
  • Mapped Substrings: write, throughput, request_count, count

Step 3: Query Metric Descriptors via list_metric_descriptors Tool

Query all metric descriptors for each identified service prefix using the list_metric_descriptors MCP tool (using pageSize: 200). Because Cloud Monitoring filters do not allow combining multiple metric.type restrictions with OR, you must initiate a separate query for each identified service prefix (either sequentially or in parallel).

If any response includes a nextPageToken, you MUST make consecutive follow-up calls passing pageToken until all remaining descriptors for that prefix are retrieved before filtering.

Filter Pattern Construction: Map the target service domain to its appropriate prefix style:

  1. Standard Google Cloud Services: starts_with("<service_prefix>.googleapis.com/") (such as bigquery.googleapis.com/, redis.googleapis.com/).
  2. Ops Agent (Guest OS): starts_with("agent.googleapis.com/") (for guest OS memory/disk metrics).
  3. Kubernetes / GKE Native: starts_with("kubernetes.io/")
  4. Istio Service Mesh: starts_with("istio.io/")
  5. Knative Serving / Autoscaler: starts_with("knative.dev/")
  6. Custom / External Metrics: Use starts_with("custom.googleapis.com/") or starts_with("external.googleapis.com/").

Example Tool Call Payload: If both Spanner and Compute Engine are targeted in the request, execute these two tool calls:

  1. Spanner query:
{
  "name": "projects/my-project-id",
  "filter": "metric.type = starts_with(\"spanner.googleapis.com/\")",
  "pageSize": 200
}
  1. Compute Engine query:
{
  "name": "projects/my-project-id",
  "filter": "metric.type = starts_with(\"compute.googleapis.com/\")",
  "pageSize": 200
}

Call the list_metric_descriptors tool with these payloads.

Step 4: Local Filtering & Fallback Protocol

Aggregate all descriptors returned from Step 3, and filter them locally inside your LLM context:

  1. Keyword Filtering: Filter the list by matching your target metric keywords (such as "cpu", "latency") against the type, displayName, and description fields of the descriptors.
  2. Resource Alignment: Check if the metric contains labels matching the target resource granularity (such as checking for a database label if targeting a database resource). Do not attempt to dynamically match resource type strings directly, as Cloud Monitoring resource mappings (like Spanner databases mapping to spanner_instance) can be counter-intuitive.

Troubleshooting & API Fallbacks

If any tool call fails, times out, or returns empty results, use these strategies:

  • Case A: API Syntax Error: Examine the error message, correct the filter syntax, and retry.
  • Case B: Timeout / Rate Limits: Retry the call once with a smaller page size (such as pageSize: 20).
  • Case C: Unrecoverable Failure / Empty List:
    1. Verify if the target service is enabled in the project.
    2. Search Google Cloud public documentation to verify standard metrics for the service.

Step 5: Output Selected Metrics

For each service domain, return only the 5-15 key metrics directly relevant to the user's intent.

You MUST report the selected metrics in clean Markdown tables, grouped by service (that is, one table per service prefix). The table MUST include the following columns: "Metric Type", "Display Name", "Description", "Metric Kind", "Value Type", "Unit", and "Monitored Resource Types". Map the fields from the Cloud Monitoring list_metric_descriptors tool call response objects directly to the table columns:

  • Metric Type: Map to the type field (for example, spanner.googleapis.com/instance/cpu/utilization).
  • Display Name: Map to the displayName field.
  • Description: Map to the description field.
  • Metric Kind: Map to the metricKind field (for example, GAUGE, DELTA, CUMULATIVE).
  • Value Type: Map to the valueType field (for example, INT64, DOUBLE, DISTRIBUTION, BOOL).
  • Unit: Map to the unit field (for example, 1, By, s, ms).
  • Monitored Resource Types: Map to the monitoredResourceTypes list field (for example, ["spanner_instance"]).

Example Output Table:

Metric TypeDisplay NameDescriptionMetric KindValue TypeUnitMonitored Resource Types
spanner.googleapis.com/instance/cpu/utilizationInstance CPU UtilizationFraction of allocated CPU currently in use.GAUGEDOUBLE1["spanner_instance"]

Reference Documentation & Links

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

agent-platform-alert-configuration

Official · GoogleFreeSummary

Create Terraform files that define alerts for AI agent latency, errors, token use, safety, security, and response quality. Check telemetry and existing policies first, then validate the generated configuration. Quality alerts require Vertex AI.

  • Configure alerts for agent latency and error rates
  • Monitor rapid increases in token usage
  • Monitor safety triggers and permission denials
google/skills21.5KUpdated Oct 24, 2026

agent-platform-deploy

Official · GoogleFreeSummary

Deploy Model Garden models to Agent Platform endpoints, the addresses used for model requests. Check supported hardware and estimated hourly costs, inspect deployment progress, test predictions, and remove deployed resources after use.

  • Choose a deployable model and supported hardware
  • Estimate hourly deployment costs before approval
  • Check deployment progress and test predictions
google/skills21.5KUpdated Oct 24, 2026

agent-platform-endpoint-management

Official · GoogleFreeSummary

Manages Agent Platform endpoints, the stable URLs used to serve online model predictions. It supports listing, inspecting, creating, updating, and deleting endpoints, plus troubleshooting permission errors, quota limits, and resources that are busy.

  • Listing endpoints and checking their configuration
  • Creating an endpoint before model deployment
  • Updating endpoint display names or labels
google/skills21.5KUpdated Oct 24, 2026

agent-platform-eval-flywheel

Official · GoogleFreeSummary

Evaluate AI models and agents on Google Cloud using test datasets and scoring criteria. Generate simulated user scenarios, analyze failures, and compare results across changes to guide improvements to prompts and code.

  • Build evaluation datasets from conversation logs
  • Generate simulated user scenarios
  • Choose scoring criteria for responses and tool use
google/skills21.5KUpdated Oct 24, 2026

agent-platform-inference

Official · GoogleFreeSummary

Call Gemini and OpenMaaS models such as Llama, DeepSeek, and Qwen through Google Cloud Agent Platform. Prepare authentication and SDK code, run prompts, configure connection endpoints, and troubleshoot common request errors.

  • Send a test prompt to Gemini
  • Call Llama or DeepSeek with the OpenAI SDK
  • Write code to call an existing custom endpoint
google/skills21.5KUpdated Oct 24, 2026

agent-platform-migrate-from-ai-studio

Official · GoogleFreeSummary

Guides migration from Google AI Studio’s Gemini API to Gemini Enterprise Agent Platform on Google Cloud, covering billing, access permissions, authentication, and connection settings for SDKs and supported agent tools.

  • Moving a Gemini application to Google Cloud
  • Using Google Cloud credits for Gemini API calls
  • Unifying agent authentication and billing
google/skills21.5KUpdated Oct 24, 2026

See all skills by google

Report a problem with this skill