本文へ移動
cccskills
無料GitHub で公開

bigquery-troubleshooting

Provides diagnostic workflows and step-by-step root-cause analysis procedures for actively broken, failing, or slow BigQuery jobs, execution graph and query plan stage bottlenecks, system performance issues, or unexpectedly expensive workloads. Use when interpreting symptoms, isolating bottlenecks, diagnosing cost spikes (on-demand query spend, capacity slot autoscaling, storage growth), execution graph stages or substep variables, identifying root causes, and determining remediation steps. Don't use for writing or optimizing SQL, proactive capacity planning, or storage layout design (use bigquery-optimization), or when the user already knows which telemetry they want and just needs the query (use bigquery-observability).

インストール方法を見る

含まれるファイル(7)

  • SKILL.md9.9 KB
  • references/cost_compute_capacity.md16.2 KB
  • references/cost_compute_ondemand.md16.1 KB
  • references/cost_storage.md17.7 KB
  • references/performance_config_changed.md6.1 KB
  • references/performance_resource_contention.md11.0 KB
  • references/query_plan_execution_graph.md10.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

BigQuery Troubleshooting

Prerequisites & Environment Setup

Before running diagnostic queries or investigating incident telemetry:

  1. Google Cloud SDK: Ensure the Google Cloud SDK is installed and configured.

  2. Project Selection: Set the active Google Cloud project:

    gcloud config set project {project_id}
    
  3. API Enablement: Ensure BigQuery and Cloud Monitoring APIs are enabled:

    gcloud services enable bigquery.googleapis.com monitoring.googleapis.com
    
  4. Authentication: Authenticate the environment:

    • CLI commands (bq show -j): gcloud auth login
    • SDKs and automated diagnostic scripts: gcloud auth application-default login
    • Service accounts: Set GOOGLE_APPLICATION_CREDENTIALS="/path/to/key.json"
  5. Billing & IAM Roles:

    • Verify an active Google Cloud Billing account is attached to {project_id}.
    • Ensure appropriate IAM roles:
      • roles/bigquery.jobUser: Executing diagnostic queries.
      • roles/bigquery.resourceViewer or roles/bigquery.admin: Inspecting reservation and job execution telemetry.
      • roles/monitoring.viewer: Cloud Monitoring metrics.
      • roles/billing.viewer: Cloud Billing reports and cost attribution.
  6. Companion Skills Installation: This skill is part of a 3-pillar operations suite (bigquery-observability, bigquery-optimization, bigquery-troubleshooting). If any companion skill is not yet installed in your environment, install the full suite:

    npx skills add google/skills --skill bigquery-observability --skill bigquery-optimization --skill bigquery-troubleshooting
    

    (If bigquery-observability is not installed, use the self-contained baseline formulas and query templates provided directly in the reference sections below).

Workflow

  1. Scope & Symptom Identification: Identify the primary symptom, target project_id, region, reservation_id, or job_id, and domain (Performance, Compute Cost, or Storage Cost). If the request falls outside incident diagnosis or asks for a sibling domain, follow Routing Boundaries below.
  2. Telemetry Tool Selection: Follow the tool-selection guidance in bigquery-observability (bigquery_observability) to select the appropriate telemetry interface (REST API bq show --location={location} -j {project_id}:{job_id} for single-job stage bottlenecks vs. INFORMATION_SCHEMA for system-wide factors). Diagnostic workflows, symptom-to-cause mappings, key tables/fields, CLI triage commands, and remediation levers are fully defined in this skill. For pre-composed SQL query templates and full schema dictionaries, consult bigquery-observability.
  3. Open-Ended Triage (Stage 1 Baseline Scan & Conversational Gate): When the user inquiry is open-ended or vague (e.g. "Why is BigQuery slow today?" or "Why did my bill spike?"), execute a bounded high-level baseline scan to isolate the affected domain before drilling into deep-dive diagnostics:
    • Bounded Initial Scan: Follow the baseline scan guidance in the corresponding domain reference under Domain References. Ensure initial queries are strictly bounded (e.g. 7-day Period-over-Period with partition and job-type filters; for unspecified cost spikes, scan the 3 primary vectors: On-Demand TiB, Capacity slot-hours, and Storage GiB) to keep diagnostic telemetry overhead minimal.
    • Conversational Gate: Factually summarize high-level baseline findings first and propose 2–3 focused drill-down options rather than dumping downstream sub-vector queries unsolicited.
  4. Domain Deep Dive & Comparative Analysis: Execute the step-by-step diagnostic workflow defined in the corresponding domain reference file listed under Domain References below, then run the corresponding query from bigquery-observability following its INFORMATION_SCHEMA best practices to isolate the root cause via comparative analysis against a normal baseline.

Performance Context: The Relativity of "Slow"

Performance is relative. Always approach performance troubleshooting as a comparative exercise: identify a comparable past execution, compare the statistics, and isolate which dimension shifted between a fast baseline and the slow execution:

  • Data Processed: Data volume increase, partition/cluster pruning changes, data skew, input record amplification.
  • Underlying Definitions: View changes, schema modifications.
  • System Contention: Noisy neighbors, saturated capacity (>95% slot utilization), idle slot availability, concurrent query spikes.
  • Configuration Changes: Slot capacity/autoscale max slots changes, expired capacity commitments, idle slot setting changes, or reservation reassignments.

Cost Context: The 4-Step Diagnostic Funnel

Cost troubleshooting requires tracing physical resource consumption (Slot-Hours, TiB Billed, GiB Stored) rather than fluctuating contract rates:

  1. Gather: Determine scope and pull 7-day PoP (or explicit MoM / 180-day) baseline metrics.
  2. Isolate: Pinpoint whether spend surged from query volume, a single "Bully Query", BQML 50x multipliers, uncovered PAYG baselines, autoscaling bursts, 90-day storage timer resets, or physical Fail-Safe retention drain.
  3. Explain: Correlate with administrative events (INFORMATION_SCHEMA.RESERVATION_CHANGES, INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES_BY_PROJECT, INFORMATION_SCHEMA.SCHEMATA_OPTIONS, or actor user_email / query_hash).
  4. Remediate: Deliver actionable levers (partition filter enforcement, query caps, commitment purchases, or Time Travel reduction).

Domain References

Performance Troubleshooting

  • Resource Contention & Performance Slowness (references/performance_resource_contention.md): Diagnostic workflows for isolating single-job stage bottlenecks (slot_contention, spill_to_disk), cohort baseline comparisons (normalized_literals), incident window discovery, 1-second reservation slot saturation, timeframe contention comparisons, fleet performance variance, and table-level concurrency.
  • Capacity & Configuration Changes (references/performance_config_changed.md): Diagnostic workflows for auditing reservation slot_capacity and autoscale.max_slots edits, tracking active capacity commitment timelines, diagnosing reservation assignment modifications, and evaluating autoscaling headroom saturation.
  • Execution Graph & Query Plan Troubleshooting (references/query_plan_execution_graph.md): Diagnostic workflows for investigating single-job stage bottlenecks (bq show point-lookups), isolating slowest stages (end_ms - start_ms), diagnosing join explosions (records_written >> records_read, high_cardinality_joins), shuffle spills (shuffle_output_bytes_spilled), and partition skew, substep intermediate variable disambiguation ($1, $2), mandatory bytes scanned vs records read corrections, and UI execution graph grounding concepts.

Cost Troubleshooting

  • On-Demand Compute Costs (references/cost_compute_ondemand.md): Diagnostic workflows for unpartitioned runaway scans (the "Bully Query"), hidden Row-Level Security (RLS) redaction gaps, BigQuery ML (BQML) 50x model training rate multipliers, and user/service account query quotas.
  • Capacity (Editions) Compute Costs (references/cost_compute_capacity.md): Diagnostic workflows for uncovered baseline slot penalties (baseline > commitments), reservation baseline reductions triggering autoscale surges (RESERVATION_BASELINE_CHANGED), autoscaler thrashing from batch cron spikes, and serverless Apache Spark stored procedure slot-hours.
  • Storage Footprint & Retention Costs (references/cost_storage.md): Diagnostic workflows for historical partition 90-day timer resets (the DML trap), unpartitioned table active data traps, physical Time Travel and Fail-Safe churn on daily overwrites, and dropped table Fail-Safe drain periods.

Routing Boundaries

If a user request shifts outside incident diagnosis during troubleshooting, execute the corresponding handoff:

  • SQL Query Optimizations: When the user asks to optimize the SQL query (e.g., rewriting joins or eliminating SELECT *), hand off to bigquery-optimization.
  • Raw Telemetry & Schema Retrieval: When the user asks for standalone INFORMATION_SCHEMA queries without an active performance regression or incident (e.g. general telemetry queries), hand off to bigquery-observability.
  • Proactive Capacity & Storage Planning: When the user requests future reservation sizing, commitment purchasing, or storage billing model evaluations, hand off to bigquery-optimization.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Configures best-practice alerting policies for AI agents using OpenTelemetry (OTel) metrics, generating output as Terraform (.tf) configuration files. Use when analyzing, writing, or deploying alerting policies to monitor agent latency, error rates, token usage, and quality metrics. Don't use for standard infrastructure monitoring unrelated to AI agents, or when the agent is not instrumented with OpenTelemetry (for Reliability, Cost, Safety, Security alerts). NOTE: Reliability, Cost, Safety, and Security alerts use generic OTel metrics and work across runtimes (such as Cloud Run, Vertex AI). Quality alerts rely on Vertex AI Online Monitors and are strictly bound to Vertex AI deployments.

日本語の概要は準備中です。原文の説明を表示しています。

google/skills2.1万2026年10月10日 更新

Deploy open models or custom weights from Model Garden to Agent Platform endpoints, check the status of an in-progress deployment operation, or clean up resources by undeploying models and deleting endpoints. Use when asked to actively deploy a model, list the Model Garden CATALOG of available models, check if a specific model is deployable (`gcloud ai model-garden models list-deployment-config`), query deployment cost, troubleshoot deployment errors (like quota limits), or undeploy/clean up endpoints. Also use when copying and deploying a 1P Tuned Model. Don't use for pure listing/discovery questions of the form "is X deployed?", "list my endpoints", or "which regions have models running?" — for those use `agent-platform-endpoint-management`. Don't use for running model evaluations (use `agent-platform-eval-flywheel` skill).

日本語の概要は準備中です。原文の説明を表示しています。

google/skills2.1万2026年10月10日 更新

Manages Agent Platform serving endpoints. Use when you need to create, list, describe, update, or delete serving endpoints for model deployment on Agent Platform. Also use when troubleshooting endpoint permission, quota, or resource busy errors. Don't use for deploying models to endpoints or for running model evaluations.

日本語の概要は準備中です。原文の説明を表示しています。

google/skills2.1万2026年10月10日 更新

Measures and improves the quality of AI models and agents on Google Cloud using the Eval Quality Flywheel methodology. Use when generating synthetic user scenarios, evaluating an agent or model, building an eval dataset, picking or writing evaluation metrics, analyzing failures, comparing results before and after a fix, or when guidance is needed on Agent Platform eval methodology — including dataset schema, LLM-as-judge scoring, and common failure causes. For fine-tuning, use agent-platform-tuning. For general production deployment, use agent-platform-deploy.

日本語の概要は準備中です。原文の説明を表示しています。

google/skills2.1万2026年10月10日 更新

Connects to and performs inference with Google Cloud Agent Platform GenAI models, including First-Party Gemini models and Third-Party OpenMaaS models (Llama, DeepSeek, Qwen, etc.). Use when asked to perform inference, ask a model a question, run a test prompt, execute chat completions, or generate code for calling Gemini or OpenMaaS models, authenticate with GenAI SDK, OpenAI SDK, or legacy Agent Platform SDK, configure base URLs and global/regional endpoints, or troubleshoot 429 Resource Exhausted (DSQ), 400 User Validation, or 404 Not Found errors. Don't use for deploying models to endpoints or for running model evaluations.

日本語の概要は準備中です。原文の説明を表示しています。

google/skills2.1万2026年10月10日 更新

Guides agents and users through migrating from Gemini API in Google AI Studio to Gemini Enterprise Agent Platform (formerly Vertex AI). Use this skill when moving applications to Google Cloud, to leverage Cloud credits, or to unify inferencing with other Cloud infrastructure (IAM, billing, telemetry).

日本語の概要は準備中です。原文の説明を表示しています。

google/skills2.1万2026年10月10日 更新

google のスキルをすべて見る

このスキルの問題を報告する