mirror of
https://github.com/supabase/supabase.git
synced 2026-10-08 02:45:07 +03:00
Saxon FletcherandClaude Opus 5
32341830b3
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. Yes. ## What kind of change does this PR introduce? Documentation update. ## What is the current behavior? The observability overview and access page overlap; configuration interrupts querying; related guides send log queries to the old editor. ## What is the new behavior? The observability overview and navigation follow the same four sections: Read project data, Detect and diagnose, Hire an agent, and Configure and export. The overview absorbs the redundant access page, with permanent redirects for both HTML and Markdown URLs. “Query logs with SQL” owns ClickHouse querying through MCP, the Management API, and Explorer with query source Logs. Logging configuration moves to its own guide; sources, captured headers, and limits live in the field reference. Inspection links to canonical diagnostic SQL. Related Storage and database guides use the replacement Explorer workflow and retain existing anchors where headings move. ## Additional context Validation: Markdown generation, docs typecheck, targeted ESLint, formatting, and content-listing tests. Browser overview/navigation checked; old HTML and Markdown URLs return 308, and the new configuration page returns 200 in both formats. Three ClickHouse examples and the Postgres configuration query ran in a disposable container sandbox. Changed pages have no MDX lint violations; repository-wide existing failures remain. Self-review: the Management API request was verified against its published schema but not sent to a hosted project. Realtime ingestion and hosted logging configuration still need a hosted smoke check. No compatibility path for the deprecated logs engine is documented. Stage 2 of 3; depends on stage 1. Stack: #50073 → #50074 → #50075. Production docs build also passes at the stack tip after standard reference generation. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Reorganized observability guidance around reading data, detecting issues, diagnosing problems, agent setup, and exporting data. - Added a guide for configuring Postgres and Realtime logging. - Updated log investigation instructions to use Explorer, SQL queries, and clearer filters. - Added log source, field, and captured-header references. - Improved advisor guidance and database performance troubleshooting. - Added redirects for moved observability content. - **Accessibility** - Improved screen-reader labels for copy and feature-selection controls. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
48 lines
2.7 KiB
Plaintext
48 lines
2.7 KiB
Plaintext
---
|
|
title: 'Configure logging'
|
|
description: 'Record additional Postgres and Realtime events for an investigation'
|
|
---
|
|
|
|
This guide explains how to record events that are not logged by default. Logging changes affect future events; they cannot recover past activity. Keep the scope limited to the investigation, because recorded statements and messages can contain sensitive values.
|
|
|
|
## Postgres connections
|
|
|
|
To record connection and authentication events, follow [Postgres connection logging](/docs/guides/platform/postgres-connection-logging). Note the current setting before changing it.
|
|
|
|
After enabling logging, open a new database connection and find its event in [Logs](/dashboard/project/_/logs) with **Log Type** set to **Postgres** and **Connection logs** enabled. Restore the previous setting when the investigation is complete, unless continued logging is required.
|
|
|
|
## Postgres statements
|
|
|
|
1. Enable [pgAudit](/docs/guides/database/extensions/pgaudit#enable-the-extension).
|
|
2. Select the statement classes and session or role scope in [pgAudit configuration](/docs/guides/database/extensions/pgaudit#configure-the-extension). Record the previous setting first. API traffic through PostgREST uses the `authenticator` role.
|
|
3. Run an authorized operation in the configured scope, then find its audit event in [Logs](/dashboard/project/_/logs) with **Log Type** set to **Postgres**.
|
|
4. Restore the previous logging configuration when finished.
|
|
|
|
Session settings apply only to that database connection. Studio queries do not maintain a persistent session. For persistent logging, follow the role-scoped instructions in the pgAudit guide.
|
|
|
|
### Messages from database functions
|
|
|
|
Whether a `RAISE` message reaches Postgres logs depends on `log_min_messages`. Read the current value from a database connection:
|
|
|
|
```sql
|
|
show log_min_messages;
|
|
```
|
|
|
|
Allow a few minutes for messages to appear. See [Postgres message levels](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-MIN-MESSAGES) before changing the threshold; their ordering differs from client message levels.
|
|
|
|
## Realtime connections
|
|
|
|
Realtime does not log new WebSocket connections or channel joins by default. Enable connection logging for the client under investigation:
|
|
|
|
```javascript
|
|
import { createClient } from '@supabase/supabase-js'
|
|
|
|
const supabase = createClient('https://your-project.supabase.co', 'sb_publishable_...', {
|
|
realtime: { params: { log_level: 'info' } },
|
|
})
|
|
```
|
|
|
|
Reconnect that client and join a channel, then inspect **Realtime** events in [Logs](/dashboard/project/_/logs). Remove `log_level: 'info'` and recreate the client to restore the default behavior.
|
|
|
|
For truncation and capture constraints, see [Log sources and fields](/docs/guides/observability/log-field-reference#capture-limits).
|