Add instrumentation for `postgres` package

[tcurdt]

Problem Statement

As a developer I would like postgresjs queries to be instrumented.

Solution Brainstorm

As discussed on discord...

https://github.com/porsager/postgres is a popular postgres client library
I would be great if it also would be supported for auto instrumentation

Side note: For a sveltekit project it's not super easy to use instrumentation via --import as everything gets bundled by default.

[Lms24]

Hi, thanks for writing in!

It appears as if there's no official Otel instrumentation for postgres. A quick Google search reveals this one but it's rather old by now: https://github.com/tomsanbear/opentelemetry-instrumentation-postgres

We can look into creating one. I'll backlog this for now.

Side note: For a sveltekit project it's not super easy to use instrumentation via --import as everything gets bundled by default.

Yup that's a good point and most definitely on our radar (but priorities, time, the usual).

More specifically, there are two problems:

1. initing the SDK early enough for most Otel instrumentation to work is a pain because --import can't be set on all deployment providers (e.g. Netlify). I have a rough idea how SvelteKit can be a better citizen here but this most definitely requires framework changes.
2. SvelteKit bundling all its deps by default completely kills the chance of getting instrumentation as OpenTelemetry "listens" for import statements.

Regarding 2, You can try to mark postgres as an external dependency so that vite doesn't bundle it. I haven't tried this myself though so I'd also be curious if this solves it.

[tcurdt]

I have a rough idea how SvelteKit can be a better citizen here but this most definitely requires framework changes.

As in SvelteKit changes?

You can try to mark postgres as an external dependency so that vite doesn't bundle it. I haven't tried this myself though so I'd also be curious if this solves it.

For now I switched to manual instrumentations - but those span don't show up either :-(

Should I open a support case for that?

[tcurdt]

It seems like this is the right place to init

https://svelte.dev/docs/kit/hooks#Shared-hooks-init

import * as db from '$lib/server/database';
import type { ServerInit } from '@sveltejs/kit';

export const init: ServerInit = async () => {
    await db.connect();
};

...not sure if that's enough

[Lms24]

As in SvelteKit changes?

yes. NextJS exposes a framework-native way where users can init the SDK in a special instrumentation.ts file. The framework then takes care of ensuring that this file is built and evaluated before the rest of the server code is imported. I believe SvelteKit (or any meta framework for that matter) needs to expose a similar mechanism. Otherwise, users are stuck with figuring a way out to --import the file)

It seems like this is the right place to init

Unfortunately, the SvelteKit init hook is not the right place. This happens too late.

In a nutshell, there are two ways how you can ensure that you init early enough in ESM-based frameworks:

1. Use --import instrument.ts (which is really tricky with meta frameworks and cloud providers abstracting infra stuff away from users)
2. So something like this:

// index.js
import * as Sentry from '@sentry/sveltekit'
Sentry.init({...});
// or any OpenTelemetry SDK for that matter

await import('./actualServerEntryPoint')

Since await import is evaluated at runtime, the SDK could already register the ESM loader hook beforehand, meaning all subsequent import statements in the server code go through OpenTelemetry's instrumentation and get instrumented correctly.

[Lms24]

For now I switched to manual instrumentations - but those span don't show up either :-(
Should I open a support case for that?

This shouldn't happen. Can you open a separate issue in this repo? Please fill out the issue template so that we know how you set up and configure the SDK. Thanks! I wanna avoid conflating this one more as the main request here is to add instrumentation for postgres (which is independent of any SvelteKit-specific issue).