Google Cloud Networking Observability
GoogleOfficialPublished by Google
- Skill
- Tool integration
- Cloud and DevOps
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured approach for investigating Google Cloud networking issues. It leverages VPC Flow Logs, firewall logs, threat logs, and Cloud NAT logs to diagnose packet drops, latency, and connectivity failures. The agent follows a strict 'results-first' directive, prioritizing efficient data retrieval through BigQuery and Cloud Logging to provide conclusive answers without unnecessary exploration.
What it does
- Analyzes VPC Flow Logs for traffic patterns, volume trends, and dropped packets.
- Investigates firewall and threat logs to identify blocked connections or malicious traffic.
- Troubleshoots Cloud NAT port exhaustion and gateway performance.
- Performs path diagnostics using Connectivity Tests.
- Queries networking metrics for latency, throughput, and packet loss trends.
- Provides cost estimation for VPC Flow Logs.
When to use it
- When investigating unexplained network traffic drops or packet loss.
- To audit firewall rule effectiveness or identify blocked connection attempts.
- When troubleshooting port exhaustion issues on Cloud NAT gateways.
- To analyze network performance metrics like latency and throughput.
- When diagnosing routing or firewall misconfigurations between network endpoints.
Advantages
- Enforces a strict, efficient workflow that prevents redundant queries.
- Provides standardized procedures for log discovery and schema verification.
- Prioritizes high-volume analysis using BigQuery for faster insights.
- Includes specific guidance for cost estimation and path diagnostics.
- Ensures consistent attribution for all executed commands.
Usage examples
- “Why is my VM unable to reach the internet? Check for NAT port exhaustion.”
- The agent queries Cloud NAT logs for 'DROPPED' allocation status and reports if the specific VM is experiencing port exhaustion.
- “Show me the top talkers in my VPC over the last 6 hours.”
- The agent executes a BigQuery aggregation on VPC Flow Logs to identify and list the top source IPs by traffic volume.
- “Are there any firewall rules blocking traffic to my web server?”
- The agent inspects firewall logs for 'DENY' events matching the server's IP and reports the blocking rule.
- “Estimate the cost of enabling VPC Flow Logs for my project.”
- The agent uses the dedicated cost estimation reference to calculate and provide an expected cost based on current traffic patterns.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/google/google-cloud-networking-observability/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip google-cloud-networking-observability.zip -d .agents/skills
Documentation by Google
Google Cloud Networking Observability Expert
Attribution
For all gcloud CLI, REST API, and MCP attribution requirements when executing
commands with this skill, follow the instructions in
Usage Attribution.
🛑 Core Directive: Results First
Identify the Primary Source: Quickly determine if the user needs firewall logs, threat logs, Cloud NAT, VPC Flow logs, or metrics.
Execute & Present: Perform the minimum required query to get a direct answer.
Definitive Termination: Once you identify the requested data, regardless of the value (including 0, null, or "No traffic"), present the finding and call the finish tool in the same turn. Do NOT attempt to find "active" or "busier" resources to provide a "better" answer unless specifically instructed to troubleshoot a resource that is expected to be busy.
Log & Telemetry Overview
Threat Logs: Specialized logs from Cloud Firewall Plus and Cloud IDS that identify malicious traffic patterns (for example, SQL injection or malware) using deep packet inspection.
VPC Flow Logs: Capture sample IP traffic to and from network interfaces. Use for traffic analysis, volume trends, top talkers, dropped traffic, and packet loss.
Firewall Logs: Record connection attempts matched by firewall rules. Use to identify "DENY" events or verify "ALLOW" rules.
Cloud NAT Logs: Audit NAT translations. Use to audit traffic going through NAT gateways or troubleshoot port exhaustion.
Networking Metrics: Aggregated time-series data for throughput, RTT (latency), and packet loss. Use for historical trends and performance monitoring.
Connectivity Tests: Static analysis tool for path diagnostics. Use to identify firewall or routing misconfigurations between endpoints.
Procedures
0. Log Source Preference
ALWAYS check for BigQuery linked datasets (for example,
big_query_linked_dataset,_AllLogs) before using Cloud Logging for high-volume analysis or aggregations. This is the preferred method for finding trends or top-blocking rules.Schema & Sample Discovery: Before writing complex aggregations or filter queries in BigQuery or Cloud Logging, first inspect a single sample log record (
LIMIT 1with--format=jsoninbq query, or--limit=1ingcloud logging read) to verify the exact payload schema and field paths.Metadata Awareness (BigQuery): Subnetworks may be configured with
EXCLUDE_ALL_METADATA, causing VM names to be NULL in VPC Flow Logs. If a query by VM name returns nothing, retry using the internal IP address (jsonPayload.connection.src_ip).
1. Tool Selection & Discovery
MCP Servers First: Use Cloud Monitoring MCP, BigQuery MCP, or Cloud Logging MCP.
Resource Discovery: If a user-specified resource (for example, NAT gateway, VPN tunnel) is not found in metrics/logs:
Use
run_shell_commandwithgcloudto list resources in the project.Search Cloud Logging MCP for the resource name to find correct labels.
CLI Fallback: Use
gcloudorbqonly if MCP servers are unavailable. DO NOT use gcloud monitoring; it is restricted. Immediately use the curl templates in metrics-analysis.md.
2. Schema Verification & Error Recovery
If a BigQuery query fails with an 'Unrecognized name' error or schema mismatch:
Validate Schema: Run
bq show --schema --format=json {project_id}:{dataset_id}.{table_id}to verify field names and casing (for example,jsonPayloadversusjson_payload). 2. Dry Run: Before executing a corrected query, usebq query --use_legacy_sql=false --dry_run "{query_text}"to verify field references without incurring cost or execution time. 3. Retry: Apply identified fixes to the original query and execute.
3. Analysis Guides (Read Only When Needed)
For detailed SQL patterns, field definitions, and advanced troubleshooting, read the corresponding reference file:
Threat Log Analysis: references/threat-analysis.md
VPC Flow Analysis: references/vpc-flow-analysis.md
VPC Flow Logs Cost Estimation: references/vpc-flow-logs-cost-estimation.md
Cloud NAT Analysis: references/cloud-nat-analysis.md
Firewall Rule Analysis: references/firewall-analysis.md
Networking Metrics: references/metrics-analysis.md
Connectivity Test Analysis: references/connectivity-tests.md
CRITICAL: If the user asks for Cost Estimation, you MUST strictly use
references/vpc-flow-logs-cost-estimation.md. Do NOT read or usereferences/vpc-flow-analysis.mdfor cost estimation tasks.
Boundaries (CRITICAL)
ALWAYS present the direct answer as soon as it is identified.
NEVER run more than 2 exploratory queries before showing results.
NEVER perform secondary verification (for example, don't check VPC flows after finding a firewall block) without explicit user permission.
ALWAYS print the generated SQL for review before execution.
ALWAYS include a link to the Flow Analyzer in the Google Cloud Console.
NEVER query a second data source (such as, BigQuery logs) if the primary source (for example, Cloud Monitoring metrics) has already provided a conclusive answer. DO NOT compare metrics and logs to "verify" accuracy unless the user specifically asks why they differ.
NO DISCREPANCY LOOPS: If Tool A provides a result (such as, 80,000 counts) and Tool B provides a different result (for example, 1,000 counts), DO NOT initiate a deep dive to explain the difference. Present the result from the primary tool and STOP.
ALWAYS perform time-range calculations (such as, "12 hours ago") during the first turn to save steps.
Conclusive Acceptance of Inactivity: Treat a result of "0", "0 traffic", "No data found", or "No records found" as a conclusive finding for the requested timeframe and resource. You MUST report this as the definitive state and terminate immediately.
Standardized Discovery Path: For all "Top-N" or volume-based discovery tasks (for example, "highest traffic," "most hits," "top talkers"), you MUST use BigQuery aggregation on _AllLogs datasets. Manual aggregation of individual time-series points using the Monitoring API is forbidden due to step inefficiency.
Ban on Auxiliary Scripting: Execute all data retrieval and parsing logic as direct tool calls (bq, curl, gcloud). Do NOT write or execute local shell scripts (.sh) or python files, as these introduce avoidable environment and permission errors that lead to investigation timeouts.
Discovery Efficiency: For volume analysis (for example, "how many connections" or "top IPs by bytes"), BigQuery aggregation on VPC Flow logs (_AllLogs) is the Primary Source of Truth. If BigQuery data is available, it is conclusive. Do NOT query Monitoring API to "double check" BigQuery counts.
Files
- ATTRIBUTION.mdAdded by AutoGineer892 B
- LICENSELicence file added by AutoGineer11.1 KiB
- SKILL.md8.1 KiB
- references/attribution.md1.8 KiB
- references/cloud-nat-analysis.md2.7 KiB
- references/connectivity-tests.md1.4 KiB
- references/firewall-analysis.md3.0 KiB
- references/mcp-usage.md2.6 KiB
- references/metrics-analysis.md3.0 KiB
- references/threat-analysis.md5.7 KiB
- references/vpc-flow-analysis.md6.3 KiB
- references/vpc-flow-logs-cost-estimation.md11.8 KiB
references/vpc-flow-logs-cost-estimation.md
VPC Flow Logs Cost Estimation Reference
Use this reference to estimate the monthly cost of VPC Flow Logs across Subnetworks, VPCs, or entire Projects. This logic implements the cost estimation calculations for VPC Flow Logs using the standard tiered pricing model.
🤖 Agent / Gemini CLI Instructions
When a user requests a cost estimation, the agent MUST follow this procedure step-by-step.
[!CAUTION] STRICT SCRIPTING BAN (RUNAWAY PREVENTION):
DO NOT write or execute Python scripts or shell scripts saved on disk (e.g.,
.pyor.shfiles).DO NOT use command-line text filters like
grep,egrep,awk, orsedas they are restricted in this environment.For all text filtering, matching, and counting, you MUST pipe the output to
python3 -cand process the data stream in-memory.PYTHON LIMITATION: You CANNOT use backslashes inside f-string expressions. Bash will eat the escapes and cause a
SyntaxError.
❌ BAD:
print(f"Name: {v[\"name\"]}")✅ GOOD:
print(f"Name: {v['name']}")ORprint("Name: {}".format(v["name"]))PROJECT ID FORMAT: Always use the exact Project ID provided by the user (including any dashes like
my-project-id). Do not modify, strip dashes, or alter the formatting before making API calls.
You MUST execute all steps using ONLY direct tool calls (
gcloud,curl,jq) and usepython3 -corbconly as an in-memory calculator. You must manually filter the data and format the final markdown report in your response text.
Step 1: Scope & Capabilities (Boundaries)
Before starting, validate that the request is supported.
[!IMPORTANT] Supported Scopes: Subnetworks, VPC Networks, or the entire GCP Project.
ALWAYS reject cost estimation requests for Cloud VPN, Cloud Interconnect, or Organization-level configurations, and use the standardized refusal response.
ALWAYS show your step-by-step mathematical calculations in the final cost estimation report to ensure transparency and allow manual verification.
UNSUPPORTED Features & Scopes (Strictly Reject):
Cloud VPN (VPN Tunnels)
Cloud Interconnect (Interconnect attachments)
Organization-level configurations
Custom log aggregation intervals (other than default 5 seconds)
Custom metadata fields
Enterprise or Committed Use Discounts (estimates must use standard list prices only)
If the user requests estimation for an unsupported feature or resource, immediately respond with the exact refusal:
"I'm sorry, {feature_resource} is not supported. I only support estimation for Subnets, VPCs, or Projects."
Step 2: Configuration Defaults
If not specified by the user, use these default parameters:
Sampling Rate: 100% (
1.0multiplier).Metadata: Include Metadata (
True).If the user explicitly requests "No Metadata" or "Exclude Metadata", set Metadata to
False.
Step 3: Resource Resolution (Discover Target Subnets)
Resolve the target scope to identify the subnetworks we need to estimate and get the total count of subnetworks in that scope (needed for the inactive count in the report).
Use gcloud based on the scope:
Step 3.A: Subnetwork Scope (User specified a subnet)
If the user specified a subnet, but did not provide the VPC or Region, ask them for clarification using the Ambiguity response:
"I found multiple matches for {subnet_name}. Please specify the Region or VPC to continue."
Once all details are known, describe the subnet to verify it exists and get its ID:
gcloud compute networks subnets describe {subnet_name} --region={region} --project={project_id} --format="json(name, id, region, network)"If not found, immediately respond with: "I was unable to find {subnet_name}. Please verify the name and try again."
Total Subnets Count: 1
Step 3.B: VPC Scope (User specified a VPC)
Find all subnetworks in the VPC and get their details:
gcloud compute networks subnets list --filter="network:https://www.googleapis.com/compute/v1/projects/{project_id}/global/networks/{vpc_name}" --project={project_id} --format="json(name, id, region, network)" > {vpc_name}_subnets.jsonIf 0 subnetworks are found, immediately respond with: "I found no subnets for {vpc_name}. Nothing to estimate."
Total Subnets Count: Count the number of subnetworks returned in this list.
Step 3.C: Project Scope (User specified the entire project)
Find all subnetworks in the project and get their details:
gcloud compute networks subnets list --project={project_id} --format="json(name, id, region, network)" > {project_id}_subnets.jsonIf 0 subnetworks are found, immediately respond with: "I found no subnets for {project_id}. Nothing to estimate."
Total Subnets Count: Count the number of subnetworks returned in this list. Use this list to group the active vs inactive subnets by their VPC later in the report.
Step 4: Retrieve Metrics (Batch Query)
To avoid turn-limit timeouts on projects with many subnetworks, you MUST NOT query the Monitoring API in a loop. Instead, perform a single project-wide batch query and filter the results in-context.
Step 4.A: Calculate Time Window (Last 30 Days)
Use the terminal to calculate the RFC 3339 timestamps for 30 days ago and now:
project_id={project_id}
end_time=$(date -u +%Y-%m-%dT%H:%M:%SZ)
start_time=$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)Step 4.B: Execute Batch Query
Query the predicted log count for all subnetworks in the project in a single call, grouping by subnetwork. Format the output as clean JSON lines for easy reading:
URL="https://monitoring.googleapis.com/v3/projects/${project_id}/timeSeries?filter=metric.type%3D%22networking.googleapis.com/vpc_flow/predicted_max_vpc_flow_logs_count%22%20AND%20resource.type%3D%22gce_subnetwork%22&interval.startTime=${start_time}&interval.endTime=${end_time}&aggregation.alignmentPeriod=2592000s&aggregation.perSeriesAligner=ALIGN_SUM&aggregation.crossSeriesReducer=REDUCE_SUM&aggregation.groupByFields=resource.labels.subnetwork_name&aggregation.groupByFields=resource.labels.subnetwork_id&aggregation.groupByFields=resource.labels.location"
RESPONSE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token 2>/dev/null)" "$URL")
if echo "$RESPONSE" | grep -q "401"; then
curl -s -H "Authorization: Bearer $(gcloud auth application-default print-access-token 2>/dev/null)" "$URL" > ${project_id}_metrics.json
else
echo "$RESPONSE" > ${project_id}_metrics.json
fi
python3 -c '
import sys, json, os
try:
project_id = os.environ.get("project_id", "'"{project_id}"'")
data = json.load(open(f"{project_id}_metrics.json"))
for ts in data.get("timeSeries", []):
labels = ts.get("resource", {}).get("labels", {})
points = ts.get("points", [])
if points:
val_dict = points[0].get("value", {})
logs = val_dict.get("doubleValue", val_dict.get("int64Value", 0))
print(json.dumps({
"name": labels.get("subnetwork_name"),
"id": labels.get("subnetwork_id"),
"region": labels.get("location"),
"logs": int(logs)
}))
except Exception as e:
print(f"Error: {e}", file=sys.stderr)
'If the curl command returns an API error (e.g. UNAUTHENTICATED, ACCESS_TOKEN_TYPE_UNSUPPORTED), immediately respond with: "ERROR: Monitoring API Request failed. Please check your token/permissions." and STOP. Do not proceed to cost calculation.
This will return a list of active subnetworks (those with traffic). If a subnetwork is not in this list, its log count is 0.
Step 4.C: Filter Results In-Context
Match the active subnetworks from the query output against your target scope (from Step 3):
Project Scope: Use all subnetworks returned by the query.
VPC Scope: Keep only the subnetworks from the query whose
idornamematches the subnetworks list resolved for the VPC in Step 3.Subnetwork Scope: Keep only the single subnetwork specified by the user.
Any target subnetwork not present in the query output has 0 logs (No traffic).
Step 5: Cost Calculations (CLI Calculator)
To prevent arithmetic errors, you MUST use python3 -c as an in-memory calculator to perform all mathematical steps.
Step 5.A: Determine Parameters
Sampling Rate: $S$ (e.g.,
1.0for 100%,0.5for 50%)Bytes per Log: $B = 1418$ (if Metadata=True) else $B = 542$ (if Metadata=False)
Step 5.B: Calculate Subnetwork Volume
For each active subnetwork in your filtered list, calculate the volume in GB:
python3 -c "print(({L_raw} * {S} * {B}) / (1024**3))"Keep track of these individual $V_{subnet}$ values for the report breakdown.
Step 5.C: Calculate Aggregate Totals & Tiered Pricing
Sum all effective logs ($L_{raw} \times S$) to get $L_{total}$. Sum all $V_{subnet}$ to get $V_{total}$.
Run the following Python command (filling in $V_{total}$ and $L_{total}$) to calculate the exact tiered pricing matching the original agent logic:
python3 -c '
total_gb = {V_total}
total_logs = {L_total}
# Tiered Generation Pricing (Network Telemetry)
remaining_gb = total_gb
generation_cost = 0.0
TIB = 1024.0
# Tier 1: 0-10 TiB @ $0.25/GB
tier1_limit = 10 * TIB
tier1_volume = min(remaining_gb, tier1_limit)
generation_cost += tier1_volume * 0.25
remaining_gb -= tier1_volume
if remaining_gb > 0:
# Tier 2: 10-30 TiB @ $0.15/GB
tier2_limit = 20 * TIB
tier2_volume = min(remaining_gb, tier2_limit)
generation_cost += tier2_volume * 0.15
remaining_gb -= tier2_volume
if remaining_gb > 0:
# Tier 3: 30-50 TiB @ $0.075/GB
tier3_limit = 20 * TIB
tier3_volume = min(remaining_gb, tier3_limit)
generation_cost += tier3_volume * 0.075
remaining_gb -= tier3_volume
if remaining_gb > 0:
# Tier 4: > 50 TiB @ $0.05/GB
generation_cost += remaining_gb * 0.05
# Storage Pricing (Cloud Logging)
storage_cost = total_gb * 0.25
total_cost = generation_cost + storage_cost
print(f"TOTAL_LOGS: {total_logs:,.0f}")
print(f"TOTAL_GB: {total_gb:.4f}")
print(f"GEN_COST: {generation_cost:.4f}")
print(f"STORE_COST: {storage_cost:.4f}")
print(f"TOTAL_COST: {total_cost:.4f}")
'Step 6: Format Report
Format your final report exactly like this. You must sort the VPCs alphabetically, and sort the subnets within each VPC by Monthly Volume (GB) descending.
Active Subnets: Show their logs and volume in the table.
Inactive Subnets: Do not list them in the table. Instead, calculate
N = Total Subnets Count - Active Subnets Countand show them in the note*(Note: N other subnets...)*.
**VPC Flow Logs Cost Estimation Report**
**Scope:** [Scope Name, e.g., Project 'my-project' or VPC 'my-vpc']
**Configuration:** Sampling [Sampling Rate]%, Metadata: [Yes/No]
**Summary:**
- **Total Monthly Logs:** [TOTAL_LOGS]
- **Total Monthly Data Volume:** [TOTAL_GB] GB
- **Estimated Monthly Cost:**
- **Generation (Network Telemetry):** $[GEN_COST]
- **Storage (Cloud Logging):** $[STORE_COST]
- **Total List Price:** $[TOTAL_COST]
**Detailed Breakdown:**
### VPC: [VPC Name]
| Subnet Name | Region | Monthly Logs | Monthly Volume (GB) |
| :--- | :--- | :---: | :---: |
| [subnet-a] | [us-central1] | [L_eff formatted] | [V_subnet formatted to 4 decimals] |
*(Note: [N] other subnets in the '[VPC Name]' VPC showed no traffic during the analysis period.)*
---
**DISCLAIMER:** This is an estimation only.
1. **Unsupported Resources:** Interconnects and VPNs are excluded from this estimate.
2. **Aggregation:** This assumes the default 5s aggregation interval; volumes may vary with custom intervals.
3. **Pricing:** Estimates use standard list prices and do not include enterprise or committed use discounts.
4. **Analysis period:** Based on a 30-day analysis period.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.
Needs: Needs an MCP server, Needs Python
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
- Publisher
- Google (Official)
- Source
- google/skills · skills/cloud/google-cloud-networking-observability · 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 google-cloud-networking-observability.zip