google-cloud-networking-observability — Claude Code skill: install
Investigate Google Cloud network logs, metrics, and connectivity paths. Use it to trace packet drops, firewall blocks, or routing problems.
npx skills add google/skills --skill google-cloud-networking-observability -a claude-codeWhat google-cloud-networking-observability does
The skill analyzes VPC Flow Logs, firewall and Cloud NAT events, threat logs, and networking metrics for throughput, latency, and packet loss. It uses Connectivity Tests for static path diagnostics, including checks for firewall and routing misconfigurations. A separate guide covers VPC Flow Logs cost estimation.
Its procedures use Cloud Monitoring MCP, BigQuery MCP, or Cloud Logging MCP first, with gcloud or bq as CLI fallbacks when MCP servers are unavailable. Before complex queries, the skill calls for checking a sample record and validating the schema. It also asks to show generated SQL before execution and to stop once a source provides a conclusive answer.
Install it for Google Cloud network investigations, not routine VM management. The npx skills add install command requires an environment with npx; which MCP or CLI tools are usable depends on what is available to the agent.
What it helps with
- trace dropped traffic to its logged cause
- find firewall rules that deny connections
- audit Cloud NAT translations or investigate port exhaustion
- compare packet loss with latency and throughput metrics
- check a network path with Connectivity Tests
Example prompts for the agent
- Inspect VPC Flow Logs and find why traffic to this VM was dropped.
- Review Cloud NAT logs for signs of port exhaustion.
- Run Connectivity Tests for the path between these endpoints and report routing issues.
How to install google-cloud-networking-observability
1Skills CLI (Vercel)
npx skills add google/skills --skill google-cloud-networking-observability -a claude-code2Manually: put the files in place
~/.claude/skills/google-cloud-networking-observability/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/google-cloud-networking-observability/
1Skills CLI (Vercel)
npx skills add google/skills --skill google-cloud-networking-observability -a codex2Manually: put the files in place
.agents/skills/google-cloud-networking-observability/SKILL.mdFor all projects use ~/.agents/skills/
Manually: put the files in place
.cursor/skills/google-cloud-networking-observability/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install google/skills google-cloud-networking-observability2Manually: put the files in place
.github/skills/google-cloud-networking-observability/SKILL.md1Skills CLI (Vercel)
npx skills add google/skills --skill google-cloud-networking-observability -a gemini-cli2Platform CLI
gemini skills install https://github.com/google/skills --path skills/cloud/google-cloud-networking-observabilityManually: put the files in place
.devin/skills/google-cloud-networking-observability/SKILL.mdThe legacy .windsurf/skills/ path still works
Claude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set172
The whole set →Similar
Questions about google-cloud-networking-observability
How do I install google-cloud-networking-observability in Claude Code?
Run npx skills add google/skills --skill google-cloud-networking-observability -a claude-code.
What does google-cloud-networking-observability do?
It analyzes Google Cloud network logs and metrics, and uses Connectivity Tests for path diagnostics. It is intended for network observability work, not general VM management.
Which data sources can the skill use?
It prioritizes Cloud Monitoring MCP, BigQuery MCP, and Cloud Logging MCP. If MCP servers are unavailable, it can fall back to gcloud or bq.
Source text
SKILL.md · Apache-2.0
---
name: google-cloud-networking-observability
metadata:
version: "1.0.5"
category: Compute
description: >-
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.
---
# 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](references/attribution.md).
## 🛑 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](references/mcp-usage.md#cloud-monitoring-mcp),
[BigQuery MCP](references/mcp-usage.md#bigquery-mcp), or
[Cloud Logging MCP](references/mcp-usage.md#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](references/mcp-usage.md#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](references/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:
- **Threat Log Analysis**:
[references/threat-analysis.md](references/threat-analysis.md)
- **VPC Flow Analysis**:
[references/vpc-flow-analysis.md](references/vpc-flow-analysis.md)
- **VPC Flow Logs Cost Estimation**:
[references/vpc-flow-logs-cost-estimation.md](references/vpc-flow-logs-cost-estimation.md)
- **Cloud NAT Analysis**:
[references/cloud-nat-analysis.md](references/cloud-nat-analysis.md)
- **Firewall Rule Analysis**:
[references/firewall-analysis.md](references/firewall-analysis.md)
- **Networking Metrics**:
[references/metrics-analysis.md](references/metrics-analysis.md)
- **Connectivity Test Analysis**:
[references/connectivity-tests.md](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 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](https://console.cloud.google.com/net-intelligence/flow-analyzer).
- **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.
© google · Apache-2.0 · google/skills