|
| 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