mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 17:35:10 +03:00
## Summary - Renames the **Telemetry** nav section to **Monitoring and Debugging** (nav label + sidebar title) - Rewrites the section overview (`telemetry.mdx`) as a clean navigation page using `ContentListings` — three panels (Debugging / Monitoring / AI & automation) with no how-to prose - Adds new `telemetry.data.ts` content-listings data file with three groups registered in `index.ts` - Adds a new **Debugging** guide (`debugging.mdx`) — request-stack model, symptom-to-layer router with troubleshooting links for every service, logging guidance - Adds cross-links between `debugging.mdx`, `logs.mdx`, and `advanced-log-filtering.mdx` - Adds a new **AI agents and MCP** page (`ai-agents.mdx`) — MCP tools table, `get_logs` usage, debugging skill workflow - Restructures sidebar into three groups: **Debugging** / **Monitoring** / **AI & automation** ## Motivation - No central entry point existed for debugging — content was scattered across products with no index - The overview page had almost no links for agents to follow - The section name "Telemetry" caused confusion (also used for CLI usage telemetry) - Unblocks the `supabase` debugging skill, which routes agents to this section as its source of truth ## Test plan - [ ] `/docs/guides/telemetry` — three ContentListings panels render, no prose how-to text - [ ] `/docs/guides/telemetry.md` (markdown) — clean link list, navigable by LLMs - [ ] `/docs/guides/telemetry/debugging` — renders correctly, symptom table links resolve - [ ] `/docs/guides/telemetry/ai-agents` — new page renders correctly - [ ] Sidebar shows 3 groups: Debugging / Monitoring / AI & automation - [ ] All cross-links between debugging, logs, and advanced-log-filtering resolve <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary - **New Features** - Added new documentation coverage for AI agent–assisted monitoring and debugging, including an observability-driven troubleshooting workflow. - **Documentation** - Updated the “Telemetry” area to “Monitoring and Debugging” with a refreshed landing page and reorganized sections (Debugging, Monitoring, and AI). - Revised the debugging and logs guides to improve step-by-step guidance and highlight advanced log filtering. - **Navigation** - Renamed and restructured the top-level navigation entry to reflect the new Monitoring and Debugging content layout. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com>
108 lines
5.4 KiB
Plaintext
108 lines
5.4 KiB
Plaintext
---
|
|
id: 'connection-management'
|
|
title: 'Connection management'
|
|
description: 'Managing connections'
|
|
subtitle: 'Using your connections resourcefully'
|
|
---
|
|
|
|
## Connections
|
|
|
|
Every [Compute Add-On](/docs/guides/platform/compute-and-disk) has a pre-configured direct connection count and Supavisor pool size. This guide discusses ways to observe and manage them resourcefully.
|
|
|
|
### Configuring Supavisor's pool size
|
|
|
|
You can change how many database connections Supavisor can manage by altering the pool size in the "Connection pooling" section of the [Database Settings](/dashboard/project/_/database/settings):
|
|
|
|

|
|
|
|
The general rule is that if you are heavily using the PostgREST database API, you should be conscientious about raising your pool size past 40% of the Database Max Connections. Otherwise, you can commit 80% to the pool. This leaves adequate room for the Authentication server and other utilities.
|
|
|
|
These numbers are generalizations and depends on other Supabase products that you use and the extent of their usage. The actual values depend on your concurrent peak connection usage. For instance, if you were only using 80 connections in a week period and your database max connections is set to 500, then realistically you could allocate the difference of 420 (minus a reasonable buffer) to service more demand.
|
|
|
|
## Monitoring connections
|
|
|
|
### Capturing historical usage
|
|
|
|
#### Dashboard monitoring charts
|
|
|
|
<Image
|
|
alt="Database client connections chart"
|
|
|
|
src={{
|
|
dark: '/docs/img/database/reports/db-connections-chart-dark.png',
|
|
light: '/docs/img/database/reports/db-connections-chart-light.png',
|
|
}}
|
|
width={2062}
|
|
height={608}
|
|
/>
|
|
|
|
For Teams and Enterprise plans, Supabase provides Advanced Telemetry charts directly within the Dashboard. The `Database client connections` chart displays historical connection data broken down by connection type:
|
|
|
|
- **Postgres**: Direct connections from your application
|
|
- **PostgREST**: Connections from the PostgREST API layer
|
|
- **Reserved**: Administrative connections for Supabase services
|
|
- **Auth**: Connections from Supabase Auth service
|
|
- **Storage**: Connections from Supabase Storage service
|
|
- **Other roles**: Miscellaneous database connections
|
|
|
|
This chart helps you monitor connection pool usage, identify connection leaks, and plan capacity. It also shows a reference line for your compute size's maximum connection limit.
|
|
|
|
For more details on using these monitoring charts, see the [Reports guide](/docs/guides/monitoring-and-debugging/reports#advanced-telemetry).
|
|
|
|
#### Grafana Dashboard
|
|
|
|
Supabase offers a Grafana Dashboard that records and visualizes over 200 project metrics, including connections. For setup instructions, check the [metrics docs](/docs/guides/monitoring-and-debugging/metrics).
|
|
|
|
Its "Client Connections" graph displays connections for both Supavisor and Postgres
|
|

|
|
|
|
### Observing live connections
|
|
|
|
`pg_stat_activity` is a special view that keeps track of processes being run by your database, including live connections. It's particularly useful for determining if idle clients are hogging connection slots.
|
|
|
|
Query to get all live connections:
|
|
|
|
```sql
|
|
SELECT
|
|
pg_stat_activity.pid as connection_id,
|
|
ssl,
|
|
datname as database,
|
|
usename as connected_role,
|
|
application_name,
|
|
client_addr as IP,
|
|
query,
|
|
query_start,
|
|
state,
|
|
backend_start
|
|
FROM pg_stat_ssl
|
|
JOIN pg_stat_activity
|
|
ON pg_stat_ssl.pid = pg_stat_activity.pid;
|
|
```
|
|
|
|
Interpreting the query:
|
|
|
|
| Column | Description |
|
|
| ------------------ | --------------------------------------------------- |
|
|
| `connection_id` | connection id |
|
|
| `ssl` | Indicates if SSL is in use |
|
|
| `database` | Name of the connected database (usually `postgres`) |
|
|
| `usename` | Role of the connected user |
|
|
| `application_name` | Name of the connecting application |
|
|
| `client_addr` | IP address of the connecting server |
|
|
| `query` | Last query executed by the connection |
|
|
| `query_start` | Time when the last query was executed |
|
|
| `state` | Querying state: active or idle |
|
|
| `backend_start` | Timestamp of the connection's establishment |
|
|
|
|
The username can be used to identify the source:
|
|
|
|
| Role | API/Tool |
|
|
| ---------------------------- | ------------------------------------------------------------------------- |
|
|
| `supabase_admin` | Used by Supabase for monitoring and by Realtime |
|
|
| `authenticator` | Data API (PostgREST) |
|
|
| `supabase_auth_admin` | Auth |
|
|
| `supabase_storage_admin` | Storage |
|
|
| `supabase_replication_admin` | Synchronizes Read Replicas |
|
|
| `postgres` | Supabase Dashboard and External Tools (e.g., Prisma, SQLAlchemy, PSQL...) |
|
|
| Custom roles defined by user | External Tools (e.g., Prisma, SQLAlchemy, PSQL...) |
|