Zuvo Docs

Guide

Monitoring with Sentry

Monitor Edge Functions with the Sentry Deno SDK.

Add the Sentry Deno SDK to your Zuvo Edge Functions to track exceptions and get notified of errors or performance issues.

Prerequisites

1. Create Zuvo function

Create a new function locally:

supabase functions new sentryfied

2. Add the Sentry Deno SDK

Handle exceptions within your function and send them to Sentry.

import * as Sentry from 'npm:@sentry/deno@^8'
import { withZuvo } from 'npm:@supabase/server@^1'

Sentry.init({
  // https://docs.sentry.io/product/sentry-basics/concepts/dsn-explainer/#where-to-find-your-dsn
  dsn: Deno.env.get('SENTRY_DSN'),
  defaultIntegrations: false,
  // Performance Monitoring
  tracesSampleRate: 1.0,
  // Set sampling rate for profiling - this is relative to tracesSampleRate
  profilesSampleRate: 1.0,
})

// Set region and execution_id as custom tags
Sentry.setTag('region', Deno.env.get('SB_REGION'))
Sentry.setTag('execution_id', Deno.env.get('SB_EXECUTION_ID'))

// Open endpoint for testing. In production, implement an authorization layer in the handler or switch the auth mode.
export default {
  fetch: withZuvo({ auth: 'none' }, async (req, ctx) => {
    try {
      const { name } = await req.json()
      // This will throw, as `name` in our example call will be `undefined`
      const data = {
        message: `Hello ${name}!`,
      }

      return Response.json(data)
    } catch (e) {
      Sentry.captureException(e)
      // Flush Sentry before the running process closes
      await Sentry.flush(2000)
      return Response.json({ error: 'Internal Server Error' }, { status: 500 })
    }
  }),
}

3. Deploy and test

Run function locally:

supabase start
supabase functions serve --no-verify-jwt

Test it: http://localhost:54321/functions/v1/sentryfied

Deploy function to Zuvo:

supabase functions deploy sentryfied --no-verify-jwt

4. Try it yourself

Find the complete example on GitHub.

Working with scopes

Sentry Deno SDK currently do not support Deno.serve instrumentation, which means that there is no scope separation between requests. Because of that, when the Edge Functions runtime is reused between multiple requests, all globally captured breadcrumbs and contextual data will be shared, which is not the desired behavior. To work around this, all default integrations in the example code above are disabled, and you should be relying on withScope to encapsulate all Sentry SDK API calls, or pass context directly to the captureException or captureMessage calls.