Skip to content

Commit 601c959

Browse files
authored
Merge pull request #23309 from newrelic/db-pp
Updates: MSSQL and Oracle DB Otel docs
2 parents 53aef36 + 764becc commit 601c959

File tree

4 files changed

+5040
-0
lines changed

4 files changed

+5040
-0
lines changed
Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
---
2+
title: "Database service identification with NRDOT"
3+
tags:
4+
- OpenTelemetry
5+
- OpenTelemetry Collector
6+
- NRDOT
7+
- Database
8+
- APM
9+
- Service correlation
10+
metaDescription: Correlate APM and database performance using service identification and secure credential management with New Relic's Distribution of OpenTelemetry (NRDOT).
11+
freshnessValidatedDate: never
12+
---
13+
14+
<Callout title="Preview">
15+
16+
We're still working on this feature, but we'd love for you to try it out!
17+
18+
This feature is currently provided as part of a preview pursuant to our [pre-release policies](/docs/licenses/license-information/referenced-policies/new-relic-pre-release-policy/).
19+
20+
</Callout>
21+
22+
Get seamless correlation between your applications and database performance with SQL query commenting. This mechanism allows the New Relic's Distribution of OpenTelemetry (NRDOT) database receiver to identify exactly which service is responsible for specific database load, slow queries, or blocking events.
23+
24+
25+
## Prerequisites [#prerequisites]
26+
27+
* Java agent version `9.1.0` or later.
28+
29+
30+
### Enable APM-DB correlation for Java agent [#enable-correlation]
31+
32+
To enable this correlation, add the `sql_metadata_comments` property to the `transaction_tracer` section of your your Java agent configuration file (`newrelic.yml`). For more information, refer to the [Java agent configuration documentation](/docs/apm/agents/java-agent/configuration/java-agent-configuration-config-file/).
33+
34+
```yaml
35+
transaction_tracer:
36+
sql_metadata_comments: nr_service_guid
37+
```
38+
39+
40+
## How it works [#how-it-works]
41+
42+
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.
43+
44+
1. **Comment prepending**: The APM agent prepends a comment string to the outgoing SQL (for example, `/* nr_service_guid="MTE2MDAzMTl8QVBNfEFQUExJ" */ SELECT * FROM orders...`).
45+
2. **Execution**: The database executes the query as usual. The comment's stored in the database's internal performance schemas (like `sys.dm_exec_requests` or `v$session`).
46+
3. **Extraction**: The database receiver fetches these queries (active, slow, or blocking).
47+
4. **Enrichment**: The receiver parses the comment, extracts the `nr_service_guid`, and attaches it as a dimension to your database metrics.
48+
49+
## Benefits of service tagging [#benefits]
50+
51+
Prepending service metadata gives you high-fidelity visibility into your database ecosystem:
52+
53+
* **Service-level attribution**: Instantly see which microservice is responsible for a spike in database CPU or memory
54+
* **Refined slow query analysis**: Filter slow query logs by client_name to understand if a database bottleneck is isolated to a specific application version
55+
* **Blocking and deadlock resolution**: Quickly identify the "owner" of a blocking query to expedite cross-team troubleshooting
56+
57+
## Security and performance impact [#security-performance]
58+
59+
We've designed this mechanism to be "invisible" to your database operations:
60+
61+
<table>
62+
<thead>
63+
<tr>
64+
<th>Feature</th>
65+
<th>Impact detail</th>
66+
</tr>
67+
</thead>
68+
<tbody>
69+
<tr>
70+
<td>Execution logic</td>
71+
<td>SQL comments are ignored by the database engine's optimizer</td>
72+
</tr>
73+
<tr>
74+
<td>Database overhead</td>
75+
<td>The addition of a short string (typically less than 50 characters) has negligible impact on network bandwidth or memory</td>
76+
</tr>
77+
<tr>
78+
<td>Data privacy</td>
79+
<td>Only the service GUID is inserted. No sensitive application data or user context is included in the comment</td>
80+
</tr>
81+
</tbody>
82+
</table>
83+
84+
## Secret management [#secret-management]
85+
86+
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.
87+
88+
### AES encryption (platform agnostic) [#aes-encryption]
89+
90+
This method lets you store encrypted credentials directly in your configuration files, supporting version control (GitOps) workflows.
91+
92+
* **How it works**: Sensitive strings are encrypted using AES-256 (GCM mode) offline. The collector decrypts them at runtime using a master key stored in the server's environment variables
93+
* **Security benefit**: Configuration files can be safely shared or committed to repositories without exposing plain-text passwords
94+
* **Best for**: Hybrid/multi-cloud environments, local development, or Windows servers where OCI Vault integration isn't feasible
95+
96+
#### Example configuration
97+
98+
```yaml
99+
receivers:
100+
newrelicoracledb/cdb:
101+
endpoint: "10.x.x.36:1521"
102+
# Credentials are encrypted using the offline helper tool
103+
username: "${aes:YOUR_ENCRYPTED_USERNAME_STRING}"
104+
password: "${aes:YOUR_ENCRYPTED_PASSWORD_STRING}"
105+
service: "DB1104.privatesubnet.oracledb.oraclevcn.com"
106+
collection_interval: 15s
107+
```
108+
109+
### AWS Secrets Manager [#aws-secrets-manager]
110+
111+
This method lets you securely retrieve credentials directly from AWS Secrets Manager at runtime, completely eliminating the need to store passwords in your configuration files.
112+
113+
* **How it works**: The NRDOT Collector uses an AWS IAM Role to automatically authenticate and fetch the required secrets from AWS Secrets Manager during startup
114+
* **Security benefit**: No sensitive data is ever stored on disk or in version control. Access is strictly governed by AWS IAM policies, and database credentials can be rotated centrally without needing to update or deploy new configuration files
115+
* **Best for**: Production environments running natively on AWS where centralized secret management, compliance auditing, and automated rotation are required
116+
117+
#### Example configuration
118+
119+
```yaml
120+
receivers:
121+
newrelicoracledb/pdb:
122+
endpoint: "10.x.x.36:1521"
123+
# Syntax: ${secretsmanager:SecretName#JSONKey}
124+
username: "${secretsmanager:oracle/credentials#username}"
125+
password: "${secretsmanager:oracle/credentials#password}"
126+
service: "PDBTEST"
127+
```
128+
129+
**Note**: Set the AWS Region:
130+
131+
```bash
132+
export AWS_REGION=your-aws-region
133+
```

0 commit comments

Comments
 (0)