azure-pg-flex-observability

Diagnose and govern Azure Database for PostgreSQL Flexible Server observability via Azure Monitor metrics, CLI, and Log Analytics KQL.

Updated Apr 11, 2026
One-click install
npx skills add https://github.com/lurodrisilva/personal-skills --skill azure-pg-flex-observability-lurodrisilva
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: azure-pg-flex-observability
Source: https://github.com/lurodrisilva/personal-skills/tree/main/platform-engineering/azure-pg-flex
Command: npx skills add https://github.com/lurodrisilva/personal-skills --skill azure-pg-flex-observability-lurodrisilva

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Azure Monitor returns errorCode=Success with empty timeseries for PostgreSQL Flexible Server Enhanced Metrics when the server-side collector is off, causing engineers to misdiagnose incidents, write broken jq pipelines, and author alerts against metrics that emit no data. ## Core Features & Use Cases - Two-layer metric model guidance: Detects the silent empty-timeseries trap and prescribes enabling metrics.collector_database_activity, pg_qs.query_capture_mode, and auto_explain.log_min_duration before incidents occur. - Correct API and CLI usage: Enforces api-version=2023-10-01, the metrics:getBatch regional endpoint for fleet queries, the 93-day retention bound, and null-coalescing jq patterns like (.timeseries[0].data // []). - Dual log surface playbook: Distinguishes downloadable Server Logs (7-day cap, post-mortem only) from Diagnostic Settings streamed to Log Analytics in resource-specific mode, with KQL recipes for error scans, wait stats, and autovacuum analysis. - Use Case: When a TPS metric returns empty during a CPU spike investigation, the skill directs you to enable the collector with one az postgres flexible-server parameter set command instead of re-querying wider time windows. ## Quick Start Ask the AI to diagnose why the tps and client_connections_active metrics are empty for your Azure PostgreSQL Flexible Server and to write the correct az rest query using the 2023-10-01 API version.

Frequently Asked Questions about azure-pg-flex-observability

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why does Azure Monitor return empty timeseries for Postgres Flexible Server tps metric?▼

The tps metric belongs to the Enhanced Metrics family, which only emits data when the server parameter metrics.collector_database_activity is set to ON. The API still returns errorCode=Success with an empty timeseries, so enable the collector with az postgres flexible-server parameter set rather than re-querying.

How do I query metrics for many Azure Postgres Flexible Servers at once?▼

Use the metrics:getBatch endpoint with a POST to https://<region>.metrics.monitor.azure.com instead of looping az rest over servers. Pass resource IDs in the request body, set metricnamespace to Microsoft.DBforPostgreSQL/flexibleServers, and use api-version=2023-10-01.

What api-version should I use for Azure Monitor metrics queries?▼

Use api-version=2023-10-01 for new metric queries, not the older 2018-01-01. The newer version supports rollupby and is within its supported migration window, while the older version lacks features and is deprecated for this use.

Does enabling metrics.collector_database_activity backfill historical data?▼

No, there is no backfill. Minutes before the collector was enabled remain null forever, so the parameter should be turned on routinely before incidents, not during an active investigation.

Why does my jq pipeline crash parsing Azure Monitor metric responses?▼

Mixed-metric responses include empty timeseries arrays for disabled-collector metrics, making .timeseries[0] evaluate to null. Always null-coalesce with (.timeseries[0].data // []) before iterating over data points.

What is the retention limit for Azure Monitor metrics on Postgres Flex?▼

Azure Monitor enforces a 93-day retention bound server-side. Queries against windows older than 93 days return HTTP 400 rather than silent zeros, so narrow the timespan or export to Log Analytics for longer retention.