mirror of
https://github.com/supabase/supabase.git
synced 2026-10-11 04:15:04 +03:00
drafts new blog post
This commit is contained in:
Paul Copplestone committed
1 parent
080f1e05bd
commit
aecfb7084b
1 file changed
+104
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: 'Supabase Reports and Metrics'
|
||||
description: We're exposing a full set of metrics in your projects, so that you can build better (and faster) products for your users.
|
||||
author: div_arora
|
||||
author_url: https://github.com/darora
|
||||
author_image_url: https://github.com/darora.png
|
||||
authorURL: https://github.com/darora
|
||||
image: auth-v2/supabase-auth-v2-og.jpg
|
||||
thumb: auth-v2/supabase-auth-v2-cover.jpg
|
||||
tags:
|
||||
- launch-week
|
||||
- reports
|
||||
- database
|
||||
date: '2021-07-29'
|
||||
toc_depth: 3
|
||||
---
|
||||
|
||||
Supabase offers a supercharged Postgres instance, along with a set of complementary services that make it easy to build mobile or web applications.
|
||||
Today, we're exposing a full set of metrics in your projects, so that you can build better (and faster) products for your users.
|
||||
|
||||
## Reports page
|
||||
|
||||
We have added a new "Reports" section. You can view up to one month of data including API requests across all of Supabase's core pillars,
|
||||
Database, Auth and Storage, and also a couple of instance health metrics. We've included CPU usage and Memory usage for now,
|
||||
with a lot more on the way.
|
||||
|
||||
|
||||
|
||||
The charts are built with [Recharts](https://recharts.org/en-US), an MIT-licensed React chart library chosen for it's ease of use.
|
||||
We'll add customizable charts in the future, so we'd love to hear any libraries you'd like to see in Supabase in the future.
|
||||
|
||||
Currently it's one configurable report per project, accessible and editable by all team members. In the next few weeks,
|
||||
we'll expand to unlimited reports per project, with longer date range options, new layout configurations, report templates,
|
||||
stacked charts and private/public visibility across your project's members.
|
||||
|
||||
## New Project Home page
|
||||
|
||||
Every project now has a new home screen with a weekly overview of important metrics, and included usage bars for Database storage,
|
||||
number of Auth users, and Storage space.
|
||||
|
||||
And we're just getting warmed up. Over the next few months you'll see more project information, notifications, and highlights so
|
||||
that you can monitor your project health at a glance.
|
||||
|
||||
|
||||
|
||||
## Observability and Usage Metrics
|
||||
|
||||
tbd
|
||||
|
||||
|
||||
|
||||
## Building a metrics pipeline
|
||||
|
||||
"If you can't measure it, you can't improve it."
|
||||
|
||||
### Full control, full responsibility
|
||||
|
||||
When developers build services and applications on top of Supabase, relying on the platform's reliability and performance.
|
||||
Product observability is critical, as it allows developers to make decisions on where to spend their optimization dollars,
|
||||
and to get ahead of possible issues before they become showstoppers.
|
||||
|
||||
At Supabase, each project is provisioned with a Postgres cluster, and a suite of associated services that add, ahem,
|
||||
supa-powers to the database.
|
||||
|
||||
|
||||
|
||||
Our users get liberal access to each of these services - you can use PostgREST for a RESTful API, Realtime to listen to changes in your Postgres instance, or even just open a raw connection to the database. While this makes for an extremely flexible offering, it presents a diverse cast of [foot-guns](https://en.wiktionary.org/wiki/footgun). Want to mess with Realtime? Why not bulk-insert millions of records on tables you've configured it to watch? Feel like taking out your entire database? Just connect to it and run a wildly inefficient query!
|
||||
|
||||
We're continuously rolling out protections to mitigate failure scenarios and to minimize the blast radius. However, given the power and flexibility exposed via our services and the diverse workloads they support, our users remain best positioned to make the call on what's reasonable for their project. As such, we're also working on exposing as much data as possible to them.
|
||||
|
||||
### Gathering relevant metrics
|
||||
|
||||
Given the setup described above, there are two major categories of metrics that we care about. There's metrics pertinent to the services mentioned ("Project Metrics") that get spun up for each project (e.g. the number of active connections to the db), and there's metrics for the underlying infrastructure (e.g. system health). Most of the time, our users shouldn't have to care about the latter, though the nature of leaky abstractions dictates that sometimes they become relevant to Project Metrics as well.
|
||||
|
||||
In order to build a comprehensive view of the project's health, each services needs to be instrumented along with their underlying infrastructure. We're looking at hundreds of thousands of targets at our current scale (likely approaching millions in the near future) each of them presenting hundreds of metrics of interest (every minute!).
|
||||
|
||||
To buy ourselves some headroom, we built a federated approach: we run instances of our monitoring systems in each geographical region we operate in. This provides a natural dimension for sharding, while reducing the latency for everyone. We run [Prometheus](https://prometheus.io/) out of inertia, soon to be [VictoriaMetrics](https://victoriametrics.com/). The monitoring instances scrape data from a number of exporters that are bundled into each of our projects. A small subset of the metrics collected get aggregated to a centralized VictoriaMetrics instance for easier cohort analysis.
|
||||
|
||||
|
||||
|
||||
### Available Sources and Metrics
|
||||
|
||||
To start with, we're focusing on metrics a few of the most pertinent metrics:
|
||||
|
||||
- The `[pg_stat_statements](https://www.postgresql.org/docs/13/pgstatstatements.html)` extension now comes enabled out of the box.
|
||||
- Our new dashboards now expose:
|
||||
- Database metrics: CPU and RAM usage
|
||||
- API Requests: Ingress, Egress, `GET`, `POST`, `PATCH`, `PUT`, `OPTIONS`, and all requests.
|
||||
- Storage Requests: Ingress, Egress, `GET`, `POST`, `PATCH`, `PUT`, `OPTIONS`, and all requests.
|
||||
- Auth Requests: Ingress, Egress, `GET`, `POST`, `PATCH`, `PUT`, `OPTIONS`, and all requests.
|
||||
- Coming soon:
|
||||
- Number of active connections to your database.
|
||||
- Various detailed stats from `pg_stat_statements`, `pg_stat_bgwriter`, `pg_stat_database`, `pg_stat_database_conflicts`.
|
||||
- System level metrics like CPU, memory and disk utilization.
|
||||
|
||||
## What's next?
|
||||
|
||||
Where to begin?
|
||||
|
||||
- Multiple reports per project: we've started with just one report per projects, but in the next few weeks we'll allow you to create as many as you want.
|
||||
- More metrics: we're just getting started (especially database related statustics using `pg_stat_statements` and connection info).
|
||||
- Granularity: project statistics will come down to hourly.
|
||||
- Longer time periods: view historical data going back several months.
|
||||
- Interactive widgets: view-only reports are fine, but we wouldn't be a SQL startup if we didn't allow you to write your own queries,
|
||||
Reference in new issue
Block a user