报告
Supabase 报告通过专用的服务器监控仪表板为你的项目提供全面的可观测性:
🌐 Supabase Reports provide comprehensive observability for your project through dedicated monitoring dashboards for servers:
- 数据库
- 认证
- 存储
- 实时
- API 系统
每个报告都提供自助调试工具,帮助你获得可操作的见解,用于优化性能和排查问题。
🌐 Each report offers self-debugging tools to gain actionable insights for optimizing performance and troubleshooting issues.
报告只适用于托管在 Supabase Cloud 平台上的项目,自行托管的实例无法使用。
🌐 Reports are only available for projects hosted on the Supabase Cloud platform and are not available for self-hosted instances.
使用报告 #
🌐 Using reports
你可以按时间范围筛选报告,以专注于特定时期。高级套餐可以访问更长的时间范围。
🌐 You can filter reports by time range to focus on a specific period. Higher-tier plans provide access to longer time ranges.
| 时间范围 | 免费 | 专业 | 团队 | 企业 |
|---|---|---|---|---|
| 最近10分钟 | ✅ | ✅ | ✅ | ✅ |
| 最近30分钟 | ✅ | ✅ | ✅ | ✅ |
| 最近60分钟 | ✅ | ✅ | ✅ | ✅ |
| 最近3小时 | ✅ | ✅ | ✅ | ✅ |
| 最近24小时 | ✅ | ✅ | ✅ | ✅ |
| 最近7天 | ❌ | ✅ | ✅ | ✅ |
| 最近14天 | ❌ | ❌ | ✅ | ✅ |
| 最近28天 | ❌ | ❌ | ✅ | ✅ |
API 网关 #
🌐 API gateway
API 网关报告会分析你项目的 API 层管理的性能和流量模式。
🌐 The API Gateway report analyzes performance and traffic patterns managed by your project's API layer.
| 图表 | 描述 | 关键见解 |
|---|---|---|
| 总请求量 | 整体 API 请求量 | 流量模式和增长趋势,包括热门接口 |
| 响应错误 | 带有 4XX 和 5XX 状态码的错误率 | API 可靠性和用户体验问题,包括热门接口 |
| 响应速度 | API 平均响应时间 | 性能瓶颈和优化目标,包括热门接口 |
| 网络流量 | 请求和响应的出口使用情况 | 数据传输模式和成本影响 |
认证 #
🌐 Auth
Auth 报告关注你在 Supabase 项目中的用户认证模式和行为。
🌐 The Auth reports focus on user authentication patterns and behaviors within your Supabase project.
| 图表 | 描述 | 主要见解 |
|---|---|---|
| 活跃用户 | 执行认证操作的独立用户数量 | 用户参与度和留存模式 |
| 按类型的登录尝试 | 使用的认证方法分类 | 密码、OAuth 与魔法链接的偏好 |
| 注册用户 | 新用户注册总数 | 增长趋势和入职流程表现 |
| API 网关认证错误 | 按状态码分组的错误率 | 认证摩擦和安全问题 |
| 密码重置请求 | 密码找回尝试的数量 | 用户体验痛点 |
认证 API 网关 #
🌐 Auth API Gateway
Auth API 网关报告主要关注与身份验证和用户管理相关的 API 请求。
🌐 The Auth API Gateway reports focus on API requests related to authentication and user management.
| 图表 | 描述 | 关键见解 |
|---|---|---|
| 总请求数 | 执行身份验证动作的独立用户数量 | 用户参与和留存模式,包括热门路径 |
| 响应错误 | 4XX 和 5XX 状态码的错误率 | API 可靠性和用户体验问题,包括热门路径 |
| 响应速度 | 身份验证请求的平均响应时间 | 性能瓶颈和优化机会,包括热门路径 |
| 网络流量 | 入站和出站使用量 | 数据传输成本和 CDN 效果 |
数据库 #
🌐 Database
数据库报告提供了对你的 Postgres 实例的健康状况和性能特性的全面了解。这些图表可以帮助你一目了然地发现性能瓶颈和资源限制。
🌐 The Database report provides a comprehensive view into your Postgres instance's health and performance characteristics. These charts help you identify performance bottlenecks and resource constraints at a glance.
以下图表适用于免费和专业计划:
🌐 The following charts are available for Free and Pro plans:
| 图表 | 可用计划 | 描述 | 主要见解 |
|---|---|---|---|
| 内存使用情况 | 免费版,专业版 | 数据库的 RAM 使用百分比 | 内存压力和资源利用率 |
| CPU 使用率 | 免费版, 专业版 | 平均 CPU 使用百分比 | CPU 密集型查询识别 |
| 磁盘 IOPS | 免费版,专业版 | 每秒读/写操作次数及其限制 | IO 瓶颈检测和工作负载分析 |
| 数据库连接 | 免费版,专业版 | 数据库的连接池连接数量 | 连接池监控 |
| 专用连接池 | 全部 | 客户端到 PgBouncer 的连接 | 专用连接池连接监控 |
| 共享池连接 | 全部 | 客户端对共享池的连接 | 共享池使用模式 |
| 共享池连接 | 全部 | 客户端对共享池的连接 | 共享池使用模式 |
| 磁盘使用情况 | 免费版,专业版 | 磁盘空间使用明细 | 存储容量规划 |
| 数据库大小 | 免费版, 专业版 | 数据库总大小及增长趋势 | 空间使用监控,包括最大表列表 |
高级遥测 #
🌐 Advanced Telemetry
以下图表提供了更高级、更详细的数据库性能视图,仅适用于团队、企业和平台计划。
🌐 The following charts provide a more advanced and detailed view of your database performance and are available only for Team, Enterprise, and Platform plans.
内存使用 #
🌐 Memory usage

| 组件 | 描述 |
|---|---|
| 已使用 | Postgres 和操作系统正在使用的内存 |
| 缓存 + 缓冲 | 用于页面缓存和操作系统缓冲的内存 |
| 空闲 | 可用的未分配内存 |
| 交换 | 当物理内存耗尽时使用的磁盘溢出空间 |
Swap 系列只会在系统进行交换时出现。Swap 是操作系统在物理内存满了之后用作溢出的磁盘空间。由于磁盘比内存慢得多,持续的 swap 活动表明内存压力较大,并且可能显著降低数据库性能。
🌐 The Swap series only appears when the system is swapping. Swap is disk space the operating system uses as an overflow when physical RAM is full. Because disk is much slower than RAM, sustained swap activity indicates memory pressure and can significantly degrade database performance.
它如何帮助调试问题:
🌐 How it helps debug issues:
| 问题 | 描述 |
|---|---|
| 内存压力检测 | 当空闲内存持续偏低时进行识别 |
| 缓存效果监控 | 监控缓存性能以优化查询 |
| 内存泄漏检测 | 检测低效的内存使用模式 |
| 交换活动监控 | 持续的交换使用表明 RAM 已耗尽,并且分页到磁盘正在降低性能 |
你可以采取的行动:
🌐 Actions you can take:
| 操作 | 描述 |
|---|---|
| 升级计算大小 | 增加可用内存资源 |
| 优化查询 | 降低高消耗查询的内存使用 |
| 调整 Postgres 配置 | 改善内存管理设置 |
| 实现应用缓存 | 添加查询结果缓存以降低内存负载 |
内存承诺 #
🌐 Memory commitment
内存承诺图显示了 Linux 内核向进程承诺了多少内存(Committed_AS),以及它愿意承诺的最大内存(CommitLimit)。它是内存不足风险的一个领先指标,而在内存使用图上是看不到的。
🌐 The Memory commitment chart shows how much memory the Linux kernel has promised to processes (Committed_AS) against the maximum it is willing to promise (CommitLimit). It is a leading indicator of out-of-memory risk that is not visible on the Memory usage chart.
当一个进程向内核请求分配内存时(例如通过 malloc、堆栈增长或 mmap),内存就被视为已承诺。内核会立即记录这个承诺,但只有在某个页面第一次被写入时才会分配物理页面。因此,已承诺的内存就是所有进程中所有未完成承诺的总和,无论这些页面是否已经被使用过。
🌐 Memory is committed when a process asks the kernel for an allocation (for example via malloc, a stack growth, or mmap). The kernel records the promise immediately, but only assigns physical pages when a page is first written. Committed memory is therefore the sum of every outstanding promise across every process, regardless of whether those pages have been touched yet.
| 组件 | 描述 |
|---|---|
| 已承诺 | 内核已经承诺给进程的总内存 (Committed_AS)。包括尚未被物理页支持的承诺。 |
| 承诺上限 | 内核允许承诺的最大内存 (CommitLimit)。来源于物理内存、交换空间以及内核的超量承诺比率。在此图表中充当危险阈值。 |
如何读它:
🌐 How to read it:
| 模式 | 含义 |
|---|---|
| 持续承诺远低于承诺上限 | 健康状态。连接数和查询量与计算层匹配。 |
| 承诺逐渐在几天或几周内上升 | 自然增长或内存泄漏。在使用量超过计算层之前,检查连接数、长期存在的预准备语句和扩展。 |
| 承诺峰值接近或超过承诺上限 | 风险状态。通常是连接风暴或几个大的并发查询。下一次峰值可能触发OOM杀手,导致Postgres崩溃。 |
| 持续承诺超过承诺上限 | 实例处于危险期。计划升级或在下一次内存不足事件前修复工作负载。 |
这对 Postgres 为什么重要:
🌐 Why this matters for Postgres:
- 每一个新的连接都是邮递员的
fork(),它会将 Committed_AS 大约增加shared_buffers的大小,直到写时复制页面发生分离。因此,连接突增可能会在物理内存耗尽之前就突破提交限制。 - 每个查询每个排序或哈希节点最多可以分配
work_mem。少数几个昂贵的并发查询可能会使提交量远高于内存使用图表显示的“已用”量。 - 当内核无法履行其承诺时,OOM 杀手会终止一个进程。在数据库服务器上,这通常是 Postgres 后端,或者更糟的是,postmaster,这会导致整个数据库宕机。
你可以采取的行动:
🌐 Actions you can take:
| 操作 | 描述 |
|---|---|
| 使用连接池 | 通过 Supavisor 或 PgBouncer 路由客户端,以限制由 fork 引起的提交压力。 |
降低 max_connections 或每个池的大小 | 降低并发后端的上限,这样高峰时就不会超过提交限制。 |
调优 work_mem | 在有大量并发查询的工作负载中,减少每次操作的内存分配。 |
| 升级计算资源 | 提高物理内存和提交限制,让工作负载可以有余量运行。 |
CPU 使用率 #
🌐 CPU usage

| 类别 | 描述 |
|---|---|
| 系统 | 内核操作的 CPU 时间 |
| 用户 | 数据库查询和用户进程的 CPU 时间 |
| IO等待 | 等待磁盘/网络 IO 的 CPU 时间 |
| 中断 | 处理中断的 CPU 时间 |
| 其他 | 处理杂项任务的 CPU 时间 |
它如何帮助调试问题:
🌐 How it helps debug issues:
| 问题 | 描述 |
|---|---|
| CPU 密集型查询识别 | 当用户 CPU 高时识别消耗大的查询 |
| IO 瓶颈检测 | 当 IOWait 升高时检测磁盘/网络问题 |
| 系统开销监控 | 监控资源竞争和内核开销 |
你可以采取的行动:
🌐 Actions you can take:
| 动作 | 描述 |
|---|---|
| 优化高 CPU 消耗的查询 | 针对导致用户 CPU 使用率高的查询 |
| 解决 IO 瓶颈 | 当 IOWait 高时,解决磁盘/网络问题 |
| 升级计算资源 | 增加可用的 CPU 容量 |
| 实现合适的索引 | 使用查询优化技术 |
每秒磁盘输入/输出操作(IOPS) #
🌐 Disk input/output operations per second (IOPS)

这张图显示了读写 IOPS,并用参考线显示你计算实例的最大 IOPS 容量。
🌐 This chart displays read and write IOPS with a reference line showing your compute size's maximum IOPS capacity.
它如何帮助调试问题:
🌐 How it helps debug issues:
| 问题 | 描述 |
|---|---|
| 磁盘 IO 瓶颈识别 | 识别磁盘 IO 何时成为性能瓶颈 |
| 工作负载模式分析 | 区分以读为主还是以写为主的操作 |
| 性能相关性 | 发现与性能问题相关的磁盘活动高峰 |
你可以采取的行动:
🌐 Actions you can take:
| 操作 | 描述 |
|---|---|
| 优化索引 | 通过更好的查询索引减少高读 IOPS |
| 考虑 只读副本 | 将读密集型工作负载分布到多个实例 |
| 批量写入操作 | 通过分组数据库写入减少写 IOPS |
| 升级计算实例 | 使用更大的计算实例提高 IOPS 限制 |
磁盘吞吐量 #
🌐 Disk throughput
适用于团队和企业计划。
🌐 Available on Team and Enterprise plans.
这张图显示了读写吞吐量(字节每秒),并有一条参考线显示你的计算大小的最大磁盘吞吐量。
🌐 This chart displays read and write throughput (bytes per second) with a reference line showing your compute size's maximum disk throughput.
它如何帮助调试问题:
🌐 How it helps debug issues:
| 问题 | 描述 |
|---|---|
| 吞吐量瓶颈识别 | 发现磁盘带宽什么时候达到饱和 |
| 工作负载模式分析 | 区分读密集型和写密集型的带宽使用 |
| 性能关联 | 将峰值与查询性能变化相关联 |
你可以采取的行动:
🌐 Actions you can take:
| 操作 | 描述 |
|---|---|
| 优化磁盘密集型查询 | 减少执行过多读写的查询 |
| 调整缓存和批处理 | 最小化重复磁盘访问,提高吞吐量余量 |
| 升级计算规范 | 提高持续工作负载的吞吐量限制 |
| 审查数据库设计 | 优化模式和查询模式以提高效率 |
| 添加策略性索引 | 使用合适的索引减少顺序扫描 |
磁盘容量 #
🌐 Disk size

| 组件 | 描述 |
|---|---|
| 数据库 | 你的实际数据库数据(表、索引)占用的空间 |
| WAL | 写前日志占用的空间 |
| 系统 | 系统操作保留的空间 |
它如何帮助调试问题:
🌐 How it helps debug issues:
| 问题 | 描述 |
|---|---|
| 空间使用监控 | 跟踪磁盘使用趋势 |
| 增长模式识别 | 找出需要关注的快速增长 |
| 容量规划 | 在达到存储限制前规划升级 |
你可以采取的行动:
🌐 Actions you can take:
| 操作 | 描述 |
|---|---|
| 运行 VACUUM 操作 | 回收死元组空间并优化存储 |
| 分析大表 | 使用像 table-sizes 这样的 CLI 命令来识别优化目标 |
| 实现数据归档 | 归档历史数据以减少活跃存储需求 |
| 升级磁盘大小 | 在接近容量限制时增加存储空间 |
查询性能 #
🌐 Query Performance
仪表板中指向 查询性能咨询页面 的链接,该页面提供了对慢数据库查询的详细分析
🌐 Links to the Query Performance Advisory page in the dashboard, which provides a detailed analysis of slow database queries
数据库连接 #
🌐 Database connections

| 连接类型 | 描述 |
|---|---|
| Postgres | 来自你应用的直接连接 |
| PostgREST | 来自 PostgREST API 层的连接 |
| Reserved | Supabase 服务的管理连接 |
| Auth | 来自 Supabase Auth 服务的连接 |
| Storage | 来自 Supabase 存储服务的连接 |
| Other roles | 各种其他数据库连接 |
它如何帮助调试问题:
🌐 How it helps debug issues:
| 问题 | 描述 |
|---|---|
| 连接池耗尽 | 在接近最大连接限制时识别 |
| 连接泄漏检测 | 发现没有正确关闭连接的应用 |
| 服务分布监控 | 监控不同 Supabase 服务的连接使用情况 |
你可以采取的行动:
🌐 Actions you can take:
| 操作 | 描述 |
|---|---|
| 升级计算容量 | 提高最大连接限制 |
| 实现 连接池 | 优化高直接连接使用时的连接管理 |
| 审查应用代码 | 确保正确处理和清理连接 |
专用 Pooler(PgBouncer)客户端连接 #
🌐 Dedicated Pooler (PgBouncer) Client Connections
适用于团队和企业计划。
🌐 Available on Team and Enterprise plans.
这张图显示了 PgBouncer 连接随时间的变化情况。
🌐 This chart displays the number of PgBouncer connections over time.
它如何帮助调试问题:
🌐 How it helps debug issues:
| 问题 | 描述 |
|---|---|
| 连接池耗尽 | 在接近最大连接限制时识别 |
| 连接泄漏检测 | 发现没有正确关闭连接的应用 |
| 服务分布监控 | 监控不同 Supabase 服务的连接使用情况 |
你可以采取的行动:
🌐 Actions you can take:
| 操作 | 描述 |
|---|---|
| 升级计算容量 | 提高最大连接限制 |
| 实现 连接池 | 优化高直接连接使用时的连接管理 |
| 审查应用代码 | 确保正确处理和清理连接 |
共享池 (Supavisor) 客户端连接 #
🌐 Shared Pooler (Supavisor) Client Connections
适用于团队和企业计划。
🌐 Available on Team and Enterprise plans.
这张图显示了Supavisor连接随时间的变化情况。
🌐 This chart displays the number of Supavisor connections over time.
它如何帮助调试问题:
🌐 How it helps debug issues:
| 问题 | 描述 |
|---|---|
| 连接池耗尽 | 在接近最大连接限制时识别 |
| 连接泄漏检测 | 发现没有正确关闭连接的应用 |
| 服务分布监控 | 监控不同 Supabase 服务的连接使用情况 |
你可以采取的行动:
🌐 Actions you can take:
| 操作 | 描述 |
|---|---|
| 升级计算容量 | 提高最大连接限制 |
| 实现 连接池 | 优化高直接连接使用时的连接管理 |
| 审查应用代码 | 确保正确处理和清理连接 |
磁盘使用 #
🌐 Disk Usage
数据库大小 #
🌐 Database size

| 组件 | 描述 |
|---|---|
| 数据库 | 你的实际数据库数据(表、索引)占用的空间 |
| WAL | 写前日志占用的空间 |
| 系统 | 系统操作保留的空间 |
它如何帮助调试问题:
🌐 How it helps debug issues:
| 问题 | 描述 |
|---|---|
| 空间使用监控 | 跟踪磁盘使用趋势 |
| 增长模式识别 | 找出需要关注的快速增长 |
| 容量规划 | 在达到存储限制前规划升级 |
你可以采取的行动:
🌐 Actions you can take:
| 操作 | 描述 |
|---|---|
| 运行 VACUUM 操作 | 回收死元组空间并优化存储 |
| 分析大表 | 使用像 table-sizes 这样的 CLI 命令来识别优化目标 |
| 实现数据归档 | 归档历史数据以减少活跃存储需求 |
| 升级磁盘大小 | 在接近容量限制时增加存储空间 |
边缘函数 #
🌐 Edge Functions
Edge Functions 报告提供了关于无服务器函数性能、执行模式以及 Supabase 全球边缘网络地区分布的洞察。
🌐 The Edge Functions report provides insights into serverless function performance, execution patterns, and regional distribution across Supabase's global edge network.
| 图表 | 描述 | 关键洞察 |
|---|---|---|
| 总边缘函数调用次数 | 函数响应代码和错误率 | 函数的可靠性和错误模式 |
| 边缘函数执行状态码 | 函数响应代码和错误率 | 函数的可靠性和错误模式 |
| 边缘函数执行时间 | 函数平均运行时间和性能表现 | 性能优化机会 |
| 按地区划分的边缘函数调用 | 函数调用的地理分布 | 全球使用模式和延迟优化 |
PostgREST#
PostgREST 报告提供了有关 RESTful API 性能、请求模式和响应特性的见解。
🌐 The PostgREST report provides insights into RESTful API performance, request patterns, and response characteristics.
| 图表 | 描述 | 关键见解 |
|---|---|---|
| 总请求数 | 对 PostgREST 端点的 HTTP 请求 | 与 WebSocket 活动结合的 API 使用情况 |
| 响应错误 | 4XX 和 5XX 状态码的错误率 | API 的可靠性和用户体验问题,包括最常访问的路由 |
| 响应速度 | PostgREST 请求的平均响应时间 | 性能瓶颈和优化机会,包括最常访问的路由 |
| 网络流量 | 入站和出站使用情况 | 数据传输成本和 CDN 效果 |
实时 #
🌐 Realtime
实时报告可以追踪你 Supabase 项目中的 WebSocket 连接、通道活动和实时事件模式。
🌐 The Realtime report tracks WebSocket connections, channel activity, and real-time event patterns in your Supabase project.
| 图表 | 描述 | 关键见解 |
|---|---|---|
| 已连接客户端 | 随时间变化的活跃 WebSocket 连接 | 并发用户活动与连接稳定性 |
| 广播事件 | 随时间广播事件 | 实时功能使用模式 |
| 出席事件 | 随时间变化的出席事件 | 实时功能使用模式 |
| Postgres 变更事件 | Postgres 随时间的变更事件 | 实时功能使用模式 |
| 通道加入率 | 新通道订阅频率 | 用户对实时功能的参与度 |
| 消息负载大小 | 发送的消息负载的中位大小 | 正在传输的负载大小 |
| 来自数据库复制延迟的广播 | 使用来自数据库的广播时,数据库提交到广播之间的中位延迟 | 来自数据库的广播延迟 |
| 读/写私有通道订阅 RLS 执行时间 | 授权私有通道的中位时间 | realtime.messages RLS 策略性能 |
| 总请求数 | 对实时端点的 HTTP 请求 | 与 WebSocket 活动一起的 API 使用情况 |
| 响应速度 | 实时 API 端点的性能 | 基础设施优化机会 |
实时 API 网关 #
🌐 Realtime API Gateway
实时 API 网关报告主要关注与实时功能相关的 API 请求。
🌐 The Realtime API Gateway reports focus on API requests related to Realtime functionality.
| 图表 | 描述 | 主要洞察 |
|---|---|---|
| 总请求数 | 对实时端点的 HTTP 请求 | API 使用情况以及 WebSocket 活动,包括热门路由 |
| 响应错误 | 对实时端点的 HTTP 请求 | API 使用情况以及 WebSocket 活动,包括热门路由 |
| 响应速度 | 实时 API 端点的性能 | 基础设施优化机会,包括热门路由 |
存储 #
🌐 Storage
存储报告让你可以了解你的 Supabase 存储是如何被使用的,包括请求模式、性能特点和缓存效果。
🌐 The Storage report provides visibility into how your Supabase Storage is being used, including request patterns, performance characteristics, and caching effectiveness.
| 图表 | 描述 | 关键洞察 |
|---|---|---|
| 总请求量 | 存储的整体请求量 | 流量模式和使用趋势,包括热门线路 |
| 响应速度 | 存储请求的平均响应时间 | 性能瓶颈和优化机会,包括热门线路 |
| 网络流量 | 入站和出站使用情况 | 数据传输成本和 CDN 效果 |
| 请求缓存 | 缓存命中率和未命中模式 | CDN 性能和成本优化,包括热门线路 |