Get seamless correlation between your applications and database performance with SQL query commenting. This mechanism allows the New Relic Distribution of OpenTelemetry (NRDOT) database receiver to identify exactly which service is responsible for specific database load, slow queries, or blocking events.
Important
New Relic links New Relic Application Performance Monitoring (New Relic APM) and database entities by matching your application's database connection address and port against the database monitoring agent's connection address and port. This linking works reliably when both sides report the exact same address and port. However, automatic linking may fail if your application routes traffic through a load balancer or proxy, or if the two components use different address formats (such as an IP address versus a domain name).
Prerequisites
- Java agent: Version
9.1.0or later. - .NET agent: Version
10.52.0or later.
Enable APM-DB correlation for Java agent
To enable this correlation, add the sql_metadata_comments property to the transaction_tracer section of your Java agent configuration file (newrelic.yml). For more information, refer to the Java agent configuration documentation.
transaction_tracer: sql_metadata_comments: nr_service_guidEnable APM-DB correlation for .NET agent
To enable this correlation, add the sqlMetadataComments property to the transactionTracer section of your .NET agent configuration file (newrelic.config). For more information, refer to the .NET agent configuration documentation.
How it works
When your application sends a query to the database, the APM agent automatically prepends an APM entity GUID into the SQL text as a comment. This common industry practice doesn't affect the execution logic of your SQL statements.
- Comment prepending: The APM agent prepends a comment string to the outgoing SQL (for example,
/* nr_service_guid="MTE2MDAzMTl8QVBNfEFQUExJ" */ SELECT * FROM orders...). - Execution: The database executes the query as usual. The comment's stored in the database's internal performance schemas (like
sys.dm_exec_requestsorv$session). - Extraction: The database receiver fetches these queries (active, slow, or blocking).
- Enrichment: The receiver parses the comment, extracts the
nr_service_guid, and attaches it as a dimension to your database metrics.
Benefits of service tagging
Prepending service metadata gives you high-fidelity visibility into your database ecosystem:
- Service-level attribution: Instantly see which microservice is responsible for a spike in database CPU or memory
- Refined slow query analysis: Filter slow query logs by
client_nameto understand if a database bottleneck is isolated to a specific application version - Blocking and deadlock resolution: Quickly identify the "owner" of a blocking query to expedite cross-team troubleshooting
Security and performance impact
We've designed this mechanism to be invisible to your database operations:
Feature | Impact detail |
|---|---|
Execution logic | The database engine's optimizer ignores SQL comments |
Database overhead | The addition of a short string (typically less than 50 characters) has negligible impact on network bandwidth or memory |
Data privacy | Only the service GUID is inserted. No sensitive application data or user context is included in the comment |
Secret management
You can use two secure methods for managing sensitive credentials (such as database passwords) in the NRDOT Collector configuration. Choose the method that best aligns with your infrastructure and security policies.