cloud-monitoring

name	cloud-monitoring
description	🐉 Skill for interacting with Google Cloud Monitoring (CM) via APIs to avoid large context bloat. Produces nice short synoptic "gists" of graphs
metadata	{"author":"Riccardo Carlesso","version":"0.2.17"}
tools	["mcp_google-monitoring_get_alert","mcp_google-monitoring_get_alert_policy","mcp_google-monitoring_get_dashboard","mcp_google-monitoring_list_alert_policies","mcp_google-monitoring_list_alerts","mcp_google-monitoring_list_dashboards","mcp_google-monitoring_list_metric_descriptors","mcp_google-monitoring_list_timeseries","mcp_google-monitoring_query_range"]

Cloud Monitoring

⚠️ PREREQUISITE: google-monitoring MCP Server This skill relies on the google-monitoring MCP server being installed and active. Before proceeding with monitoring tasks, assert that the required MCP tools (e.g., mcp_google-monitoring_query_range) are available. If they are missing, immediately inform the user and recommend they enable the MCP server (they can use the gcp-mcp-setup skill if available).

This skill provides utilities for analyzing and extracting data from Google Cloud Monitoring (CM).

Best Practices

• Avoid Context Bloat: Cloud Monitoring API responses can be massive. Do not try to read raw JSON responses directly into the LLM context. Try to delegate to a SubAgent anything which pulls monitoring data as they tend to bloat the context.
• Use Export Scripts: If you pull monitoring data, make sure to surface this final data (in CSV format) using the scripts/export_timeseries_to_csv.py Python script to surface important stats like AVG, Max, Min and a simplified text-graph of the system (see references/sample_output_dual_metrics.csv) . Also report back that stats header to the main agent, together with any interesting insights you might have found.
• Metadata Headers: Exported data should contain metadata (time ranges, metric names) at the top of the file so that the context of "when" the data was pulled is never lost, as now() changes over time.
• Target Workloads: Focus your monitoring extractions primarily on GKE and Cloud Run environments. Generic time-series extractions should still allow filtering by specific resources.
• Paired Metrics Comparison: The extraction script supports querying multiple metrics simultaneously. For apples-to-apples comparisons, try these recommended pairs:
  • Network I/O: compute.googleapis.com/instance/network/received_bytes_count vs compute.googleapis.com/instance/network/sent_bytes_count
  • Disk I/O: compute.googleapis.com/instance/disk/read_bytes_count vs compute.googleapis.com/instance/disk/write_bytes_count
  • Cloud Run Traffic: run.googleapis.com/request_count vs run.googleapis.com/response_latencies
  • GKE Memory vs CPU: kubernetes.io/container/memory/used_bytes vs kubernetes.io/container/cpu/core_usage_time

Available Tools

• scripts/export_timeseries_to_csv.py: Fetches time-series data for specified metric(s) and time range, outputting a CSV file with metadata headers. Supports extracting two or more variables for direct correlation and comparison. This is an amazing synoptic you can surface to the user
  • It's very effective particularly to share the "Sparkline" / ASCII Art part showing in TEXT the graphical shape of the curve (e.g., |█▇▆▇ ▂▃ ▂ ▂|). This is very useful for humans for rapid visual feedback! Use csv_to_sparkline.py from monitoring-graphs to recreate it for arbitrary CSVs.
• scripts/setup-frontend-slo.sh: A bash script to automatically set up a 99.9% availability SLO using Log-based Metrics for a 'frontend' service. (See scripts/README.md for full manual).