bigquery-observability
Skill240 starsChanged 5 months agoApache-2.0View on GitHub
Provides data-retrieval best practices, tool selection guidance, and performant SQL query syntax for BigQuery telemetry across INFORMATION_SCHEMA, Cloud Monitoring, and the REST API. Use when the telemetry to fetch is already known, selecting telemetry tools, writing performant INFORMATION_SCHEMA queries, retrieving telemetry for diagnosing single-job performance bottlenecks, investigating slot contention, job concurrency and queue latency, analyzing reservation capacity, utilization and autoscaling saturation, or auditing capacity-based and on-demand compute and storage resource billable usage. Don't use for root-cause diagnosis or symptom troubleshooting when the cause is unknown (use bigquery-troubleshooting first), or for writing or optimizing business logic SQL (use bigquery-optimization).
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- google/skillsedited, first seen Sep 29, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- google/skills★ 24k83% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository39 other files it gives its agents.
- accidental-data-loss-preventionSkill
- bigquery-ai-mlSkill
- bigquery-bigframesSkill
- bigquery-data-transfer-serviceSkill
- bigquery-graph-authorSkill
- bigquery-graph-querySkill
- bigquery-optimizationSkill
- bigquery-troubleshootingSkill
- bigtable-basicsSkill
- building-data-appsSkill
- cloud-databases-onboardingSkill
- dak-setupSkill
- data-autocleaningSkill
- dataform-bigquerySkill
- dbt-bigquerySkill
- discovering-gcp-data-assetsSkill
- enforcing-resource-attributionSkill
- federate-lakehouse-catalogSkill
- gcp-composer-troubleshootingSkill
- gcp-dataflowSkill
- gcp-data-pipelinesSkill
- gcp-managed-airflow-dag-authoringSkill
- gcp-managed-airflow-migrationsSkill
- gcp-managed-airflow-recommendationsSkill
- gcp-managed-spark-upgradesSkill
- gcp-pipeline-orchestrationSkill
- gcp-pipeline-resource-provisioningSkill
- gcp-spark-observabilitySkill
- gcp-sparkSkill
- gcp-spark-troubleshootingSkill
- gcs-security-assessmentSkill
- google-cloud-storage-basicsSkill
- google-cloud-storage-bucket-architectSkill
- google-cloud-storage-fuseSkill
- managing-python-dependenciesSkill
- ml-best-practicesSkill
- notebook-guidanceSkill
- resolving-mcp-region-configsSkill
- schema-mappingSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 1 is distinctive, and 10 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 46
Diagnostic Transition Logic: If no job-level issues are found (e.g.
- Very specific: line 54
Every query against a BigQuery INFORMATION_SCHEMA view must be qualified with either a region qualifier or a dataset qualifier, optionally …
- Very specific: line 98
When constructing INFORMATION_SCHEMA queries, always select the scope and view variant with the least IAM permission requirement that …
- Very specific: line 102
User-Level over Project-Level (
_BY_USER): When diagnosing queries or sessions executed by the current user, use _BY_USER (e.g. - Very specific: line 110
Dataset-Level over Region/Project-Level: When querying table metadata, columns, or views for a specific dataset, qualify with {dataset_id} …
- Very specific: line 114
Project-Level over Org/Folder-Level (
_BY_PROJECT): Always start with project-scoped views before escalating to _BY_FOLDER or … - Very specific: line 128
Mandatory Partition & Time Filtering: Always filter on creation_time (e.g., creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 …
- Very specific: line 131
Script Wrapper Exclusion: Add AND (statement_type != 'SCRIPT' OR statement_type IS NULL) when aggregating compute spend to avoid …
- Very specific: line 134
Column Pruning: Never use SELECT * against INFORMATION_SCHEMA.
- Very specific: line 136
Dry Run & Cost Estimation: Use a dry run (bq query --dry_run --use_legacy_sql=false "{query}" or API dryRun=true) before executing complex …
- Distinctive: line 140
Empty Regional Scope (0 Rows): If the execution location matches the qualifier, but the project has no datasets or jobs in that region, the …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
BigQuery Observability
Tool Selection
<!-- mdformat off -->| Tool | Primary Use Cases | Strengths & Capabilities | When to Avoid / Limitations |
INFORMATION_SCHEMA (I_S) | Historical analysis, cohort comparison (normalized_literals), discovery of fast/slow windows, reservation/project timelines, multi-job aggregates, cost/billing tracing. | Flexible SQL querying across JOBS, JOBS_TIMELINE, and RESERVATIONS; supports custom time windows and grouping. | Avoid for high-frequency real-time polling or single-job point-lookups (can consume slots and take seconds to execute). |
REST API (jobs.api / reservation.api) | Single-job point-lookup, real-time stage bottleneck diagnosis, automated pipeline status checks, reservation/capacity commitment configuration inspection (reservations.get, reservations.list). | Zero-SQL overhead, fast REST/CLI point-lookups (bq show -j, bq show --reservation), instant access to performanceInsights, queryPlan, and structural metadata. | Avoid for aggregate analysis across thousands of jobs, cross-project historical comparison, or system timeline aggregations. |
Cloud Monitoring (Metrics Explorer / Charts) | Real-time alerting, fleet-wide dashboards, continuous slot utilization tracking, high-level SLA/SLO monitoring. | Out-of-the-box charts for slot utilization, query throughput, PENDING queue depth, and execution latency; low-latency alerting without running queries. | Avoid for SQL-level debugging, individual query text inspection, or stage-level execution detail. |
<!-- mdformat on -->Workflow
Single-Job Point-Lookup (Zero-SQL Overhead): For single-job slowness or inspection, always prioritize the REST API or CLI (
bq show -j) first. It provides zero-SQL overhead and fast point-lookups for internal stage bottlenecks (performanceInsights,queryPlan, shuffle spill).bq show --location={location} -j {project_id}:{job_id}- Diagnostic Transition Logic: If no job-level issues are found (e.g. no
clear internal bottlenecks), the investigation should transition to
system-level
INFORMATION_SCHEMAqueries (such asJOBS_TIMELINEorRESERVATIONS_TIMELINE) to check for broader issues like slot contention, queueing delay, or noisy neighbors.
Best Practices for Writing INFORMATION_SCHEMA Queries
Every query against a BigQuery INFORMATION_SCHEMA view must be qualified with
either a region qualifier or a dataset qualifier, optionally prefixed by
a project qualifier.
Qualification Syntax & Scope Matching
Region-Qualified Syntax:
`{project_id}`.`region-{region}`.INFORMATION_SCHEMA.{view}Example:
`my-project`.`region-us`.INFORMATION_SCHEMA.JOBSApplies to: Regional telemetry views (
JOBS*,JOBS_TIMELINE*,RESERVATIONS*,CAPACITY_COMMITMENTS*,TABLE_STORAGE*,STREAMING_TIMELINE*). The client query execution location MUST match theregion-{region}qualifier (or BigQuery throws:Not found: Table {project_id}:region-{region}.INFORMATION_SCHEMA.{view} was not found in location {location}).Dataset-Qualified Syntax:
`{project_id}`.`{dataset_id}`.INFORMATION_SCHEMA.{view}Example:
`my-project`.`analytics`.INFORMATION_SCHEMA.TABLESApplies to: Dataset-scoped views (
PARTITIONS,SEARCH_INDEXES*,ROW_ACCESS_POLICIES). Never useregion-with dataset views.- Dual-Scoped Views: Views like
TABLES,COLUMNS,COLUMN_FIELD_PATHS,VIEWS,ROUTINES, andVECTOR_INDEXEScan be qualified with either{dataset_id}orregion-{region}depending on whether dataset or region-wide analysis is required. - Project Qualifier (
{project_id}): Optional. If omitted, queries default to the project in which the query is executing. Specifying a project qualifier on organization-level views (e.g.JOBS_BY_ORGANIZATION) has no impact on results.
Principle of Least Privilege & Scope Selection
When constructing INFORMATION_SCHEMA queries, always select the scope and
view variant with the least IAM permission requirement that satisfies the
analytical need:
- User-Level over Project-Level (
_BY_USER): When diagnosing queries or sessions executed by the current user, use_BY_USER(e.g.JOBS_BY_USER,SESSIONS_BY_USER). This requires onlybigquery.jobs.list(granted viaroles/bigquery.user), avoiding the need forbigquery.jobs.listAllorroles/bigquery.admin. IfJOBS_BY_USERalso returns403 Access Denied(e.g. when the caller only holdsroles/bigquery.jobUser, which grantsbigquery.jobs.createbut notbigquery.jobs.list), fall back tobq ls -j -n {max_results} {project_id}for a zero-compute CLI job listing. - Dataset-Level over Region/Project-Level: When querying table metadata,
columns, or views for a specific dataset, qualify with
{dataset_id}rather thanregion-{region}when project-level metadata access is restricted. Dataset-scoped queries require permissions only on that target dataset. - Project-Level over Org/Folder-Level (
_BY_PROJECT): Always start with project-scoped views before escalating to_BY_FOLDERor_BY_ORGANIZATION. Folder and organization queries require broad folder/org IAM permissions (bigquery.jobs.listAllorbigquery.tables.listat the Org/Folder node). - Metadata Roles over Data Roles: For table and storage introspection,
prefer
roles/bigquery.metadataViewer(which providesbigquery.tables.getandbigquery.tables.list) overroles/bigquery.dataViewerorroles/bigquery.dataOwnerwhen data read access (bigquery.tables.getData) is not needed. (Note:INFORMATION_SCHEMA.PARTITIONSuniquely requiresbigquery.tables.getData).
Execution Guardrails & Query Invariants
- Mandatory Partition & Time Filtering: Always filter on
creation_time(e.g.,creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 DAY)) orusage_dateto avoid full metadata table scans. - Script Wrapper Exclusion: Add
AND (statement_type != 'SCRIPT' OR statement_type IS NULL)when aggregating compute spend to avoid double-counting parent scripts and child jobs. - Column Pruning: Never use
SELECT *againstINFORMATION_SCHEMA; only project required columns. - Dry Run & Cost Estimation: Use a dry run (
bq query --dry_run --use_legacy_sql=false "{query}"or APIdryRun=true) before executing complex queries, multi-view joins, or large scans to validate syntax and estimatetotalBytesProcessedat zero cost. - Empty Regional Scope (0 Rows): If the execution location matches the qualifier, but the project has no datasets or jobs in that region, the query succeeds and returns 0 rows. Never assume 0 rows means 0 usage—always verify the target dataset locations.
- Non-Hierarchical Region Scope: Region qualifiers are not hierarchical.
Multi-regions do not encompass single regions (e.g.
region-usreturns only multi-regionUSmetadata and does not include single regions likeregion-us-central1). - No Multi-Region Aggregation in SQL: Region qualifiers cannot be joined
cross-region in a single query (e.g.
region-uscannot joinregion-eu). - Uncached Execution & Minimum Scan Size:
INFORMATION_SCHEMAquery results are never cached. On-demand queries incur a minimum of 10 MB of data processing charges per execution.
Domain References & SQL Queries
Telemetry Query Guides
- On-Demand Compute: Billed Bytes
(
references/compute_ondemand_billable.md): Authoritative Golden CTE (bytes_billed_cte), timezone-aligned billing date extraction (PST8PDT), BQML CREATE_MODEL 50x multiplier rules, script wrapper deduplication, and row-level security (RLS) masking checks. - Capacity Compute: Billable Slots & Commitments
(
references/compute_capacity_billable.md): Query templates for auditing billable capacity hours across 1-Year/3-Year commitments, uncovered baseline PAYG slots, and dynamic autoscaling hours. - Storage Footprints & Usage (Bytes Stored)
(
references/storage_footprints.md): Storage snapshot queries, compression ratio calculations, Time Travel / Fail-Safe churn, daily average GiB time-integrals, billing model evaluation, and search index coverage.
Performance & Troubleshooting Guides
- Job Performance Queries (
references/job_performance_queries.md): Queries for evaluating individual and aggregate job performance, stage bottleneck flags, comparable jobs via normalized literals (query_info.query_hashes.normalized_literals), BI Engine acceleration, metadata cache (cmeta) acceleration, search index usage, materialized view rewrite usage, and execution variance outliers. - Resource Contention Queries
(
references/resource_contention_queries.md): Queries for diagnosing slot contention, queue latency, per-minute concurrency/queue timelines, and 1-second reservation slot saturation. - Capacity & Configuration Queries
(
references/capacity_and_configuration_queries.md): Queries for evaluating second-by-second baseline/max capacity ceilings, autoscaling saturation timelines, and auditing configuration changes (RESERVATION_CHANGES_BY_PROJECT,ASSIGNMENT_CHANGES_BY_PROJECT).
Schema Dictionaries (Column Definitions & Units)
- Compute & Capacity Schema Dictionary (
references/schema_compute.md): Complete column dictionary, physical units, and least-privilege IAM roles for all compute, job, session, reservation, capacity commitment, and assignment views (JOBS*,JOBS_TIMELINE*,SESSIONS_BY_USER,SESSIONS_BY_PROJECT,RESERVATIONS*,RESERVATION_CHANGES*,RESERVATIONS_TIMELINE*,CAPACITY_COMMITMENTS*,CAPACITY_COMMITMENT_CHANGES_BY_PROJECT,ASSIGNMENTS*,ASSIGNMENT_CHANGES_BY_PROJECT). - Storage & Data Catalog Schema Dictionary
(
references/schema_storage.md): Complete column dictionary, physical units, and least-privilege IAM roles for all table storage, partition, column, snapshot, dataset, constraint, and replication views (TABLE_STORAGE*,TABLE_STORAGE_USAGE_TIMELINE*,TABLES*,TABLE_OPTIONS,COLUMNS,COLUMN_FIELD_PATHS,PARTITIONS,VIEWS,MATERIALIZED_VIEWS,TABLE_SNAPSHOTS*,TABLE_CONSTRAINTS,KEY_COLUMN_USAGE,SCHEMATA*,SCHEMATA_OPTIONS,SCHEMATA_REPLICAS*,SCHEMATA_LINKS,SHARED_DATASET_USAGE). - Platform, Governance & Ingestion Schema Dictionary
(
references/schema_others.md): Complete column dictionary, physical units, and least-privilege IAM roles for all remaining views including Access Control (OBJECT_PRIVILEGES,ROW_ACCESS_POLICIES,ROW_ACCESS_POLICY_OPTIONS), Streaming Ingestion (STREAMING_TIMELINE_BY_PROJECT*,WRITE_API_TIMELINE_BY_PROJECT*), Configuration Options (PROJECT_OPTIONS*,EFFECTIVE_PROJECT_OPTIONS,ORGANIZATION_OPTIONS*,ORGANIZATION_OPTIONS_CHANGES), Insights & Recommendations (RECOMMENDATIONS*,INSIGHTS), and Indexes/BI Engine/Routines (SEARCH_INDEXES*,SEARCH_INDEX_COLUMNS,SEARCH_INDEX_OPTIONS,VECTOR_INDEXES*,VECTOR_INDEX_COLUMNS,VECTOR_INDEX_OPTIONS,BI_CAPACITIES,BI_CAPACITY_CHANGES,ROUTINES*,ROUTINE_OPTIONS,PARAMETERS).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

