Generated banner for Google Cloud Networking Observability
Generated logo for Google Cloud Networking Observability

Google Cloud Networking Observability

GoogleOfficialPublished by Google

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

From the author

Investigates Google Cloud networking issues by analyzing GCP logs, metrics, and diagnostics. Use when investigating dropped network traffic, packet drops, drop reasons, VPC Flow Logs (including Private Service Connect / PSC, serverless / App Engine Direct VPC, and cost estimation), NAT, firewall, or threat logs, querying latency and throughput metrics, or running Connectivity Tests for path diagnostics. Don't use for generic VM management or non-observability tasks.
— the description by Google

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

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/google/google-cloud-networking-observability/download
  2. Unzip 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

  1. Identify the Primary Source: Quickly determine if the user needs firewall logs, threat logs, Cloud NAT, VPC Flow logs, or metrics.

  2. Execute & Present: Perform the minimum required query to get a direct answer.

  3. 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 1 with --format=json in bq query, or --limit=1 in gcloud 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:

    1. Use run_shell_command with gcloud to list resources in the project.

    2. Search Cloud Logging MCP for the resource name to find correct labels.

  • CLI Fallback: Use gcloud or bq only 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:

  1. Validate Schema: Run bq show --schema --format=json {project_id}:{dataset_id}.{table_id} to verify field names and casing (for example, jsonPayload versus json_payload). 2. Dry Run: Before executing a corrected query, use bq 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:

CRITICAL: If the user asks for Cost Estimation, you MUST strictly use references/vpc-flow-logs-cost-estimation.md. Do NOT read or use references/vpc-flow-analysis.md for 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

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., .py or .sh files).

  • DO NOT use command-line text filters like grep, egrep, awk, or sed as they are restricted in this environment.

  • For all text filtering, matching, and counting, you MUST pipe the output to python3 -c and 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']}") OR print("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 use python3 -c or bc only 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.0 multiplier).

  • 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.json

If 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.json

If 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 id or name matches 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.0 for 100%, 0.5 for 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 Count and 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
Google
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