OpenTelemetry Postgres Instrumentation for Node.js

This module provides automatic instrumentation for the pgmodule, which may be loaded using the @opentelemetry/sdk-trace-node package and is included in the @opentelemetry/auto-instrumentations-node bundle.

If total installation size is not constrained, it is recommended to use the @opentelemetry/auto-instrumentations-node bundle with @opentelemetry/sdk-node for the most seamless instrumentation experience.

Compatible with OpenTelemetry JS API and SDK 1.0+.

Installation

npm install --save @opentelemetry/instrumentation-pg

Supported Versions

• pg versions >=8.0.3 <9
• pg-pool versions >=2.0.0 <4

Usage

const { PgInstrumentation } = require('@opentelemetry/instrumentation-pg');
const { NodeTracerProvider } = require('@opentelemetry/sdk-trace-node');
const { registerInstrumentations } = require('@opentelemetry/instrumentation');

const provider = new NodeTracerProvider();
provider.register();

registerInstrumentations({
  instrumentations: [
    new PgInstrumentation(),
  ],
});

PgInstrumentation contains both pg and pg.Pool so it will be instrumented automatically.

Span Types Created

This instrumentation creates the following span types:

| Span Name | Description | When Created | | --------- | ----------- | ------------ | | pg.query:<OPERATION> <database> | Database query execution | When client.query() is called | | pg.connect | Client connection to database | When new Client().connect() is called directly | | pg-pool.connect | Pool connection acquisition wait time | When acquiring a connection from pg-pool |

The pg-pool.connect spans measure the time spent waiting to acquire a connection from the pool. This can be valuable for identifying connection pool exhaustion or sizing issues. However, in high-throughput scenarios where connections are readily available, these spans may add noise with minimal diagnostic value. Consider using the requireParentSpan option or sampling strategies if pool connect spans become excessive.

PostgreSQL Instrumentation Options

PostgreSQL instrumentation has few options available to choose from. You can set the following:

| Options | Type | Description | | ------- | ---- | ----------- | | enhancedDatabaseReporting | boolean | If true, additional information about query parameters and results will be attached (as attributes) to spans representing database operations | | requestHook | PgInstrumentationExecutionRequestHook (function) | Function for adding custom span attributes using information about the query being issued and the db to which it's directed | | responseHook | PgInstrumentationExecutionResponseHook (function) | Function for adding custom span attributes from db response | | requireParentSpan | boolean | If true, requires a parent span to create new spans (default false) | | addSqlCommenterCommentToQueries | boolean | If true, adds sqlcommenter specification compliant comment to queries with tracing context (default false). NOTE: A comment will not be added to queries that already contain -- or /* ... */ in them, even if these are not actually part of comments |

Semantic Conventions

Prior to version 0.55.0, this instrumentation created spans and metrics targeting an experimental semantic convention Version 1.27.0.

Database semantic conventions (semconv) were stabilized in v1.34.0, and a migration process was defined. @opentelemetry/instrumentation-pg versions 0.55.0 and later include support for migrating to stable Database semantic conventions, as described below. The intent is to provide an approximate 6 month time window for users of this instrumentation to migrate to the new Database semconv, after which a new minor version will use the new semconv by default and drop support for the old semconv.

To select which semconv version(s) is emitted from this instrumentation, use the OTEL_SEMCONV_STABILITY_OPT_IN environment variable.

• database: emit the new (stable) v1.34.0+ semantics
• database/dup: emit both the old v1.27.0 and the new (stable) v1.34.0+ semantics
• By default, if OTEL_SEMCONV_STABILITY_OPT_IN includes neither of the above tokens, the old v1.27.0 semconv is used.

Attributes collected

| v1.27.0 semconv | v1.34.0 semconv | Short Description | | ----------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------ | | db.connection_string | Removed | String used to connect to the database | | db.user | Removed | User used to connect to the database | | db.name | Removed, integrated into the new db.namespace | The name of the database. | | (not included) | db.namespace | The name of the database, fully qualified within the server address and port. | | db.statement | db.query.text | The database query being executed. | | db.system | db.system.name | The database management system (DBMS) product as identified by the client instrumentation. | | net.peer.port | server.port | Remote port number. | | net.peer.name | server.address | Remote hostname or similar. |

Metrics Exported:

• db.client.operation.duration

Upgrading Semantic Conventions

When upgrading to the new semantic conventions, it is recommended to do so in the following order:

1. Upgrade @opentelemetry/opentelemetry-instrumentation-pg to the latest version
2. Set OTEL_SEMCONV_STABILITY_OPT_IN=database/dup to emit both old and new semantic conventions
3. Modify alerts, dashboards, metrics, and other processes to expect the new semantic conventions
4. Set OTEL_SEMCONV_STABILITY_OPT_IN=database to emit only the new semantic conventions

This will cause both the old and new semantic conventions to be emitted during the transition period.

Useful links

• For more information on OpenTelemetry, visit: https://opentelemetry.io/
• For more about OpenTelemetry JavaScript: https://github.com/open-telemetry/opentelemetry-js
• For help or feedback on this project, join us in GitHub Discussions

License

Apache 2.0 - See LICENSE for more information.