Docs >
Database Monitoring >
Correlate Database Monitoring and Traces
This guide assumes that you have configured Database Monitoring and are using APM. Connecting APM and DBM injects APM trace identifiers into DBM data collection, which allows for correlation of these two data sources. This enables product features showing database information in the APM product, and APM data in the DBM product.
Before you begin
Supported databases
Postgres, MySQL, SQL Server, Oracle, MongoDB
Supported Agent versions
7.46+
Data privacy
Enabling SQL comment propagation results in potentially confidential data (service names) being stored in the databases which can then be accessed by other third parties that have been granted access to the database.
APM tracer integrations support a Propagation Mode, which controls the amount of information passed from applications to the database.
full mode sends full trace information to the database, allowing you to investigate individual traces within DBM. This is the recommended solution for most integrations.
service mode sends the service name, allowing you to understand which services are the contributors to database load.
disabled mode disables propagation and does not send any information from applications.
DD_DBM_PROPAGATION_MODE
Postgres
MySQL
SQL Server
Oracle
MongoDB
full
*
**
service
* Full propagation mode on Aurora MySQL requires version 3.
** Full propagation mode on Oracle is only supported when using Java.
Datadog recommends setting the obfuscation mode to obfuscate_and_normalize for Agent versions 7.63 and higher. Add the following parameter in the apm_config section of your APM Agent configuration file:
sql_obfuscation_mode: "obfuscate_and_normalize"
Changing the obfuscation mode may alter the normalized SQL text. If you have monitors based on SQL text in APM traces, you may need to update them.
Update your app dependencies to include dd-trace-go@v1.44.0 or greater. Note: This documentation uses v2 of the Go tracer, which Datadog recommends for all users. If you are using v1, see the migration guide to upgrade to v2.
go get github.com/DataDog/dd-trace-go/v2 # 2.x
Update your code to import the contrib/database/sql package:
import("database/sql""github.com/DataDog/dd-trace-go/v2/ddtrace/tracer"sqltrace"github.com/DataDog/dd-trace-go/contrib/database/sql/v2")funcmain(){// The first step is to set the dbm propagation mode when registering the driver. Note that this can also// be done on sqltrace.Open for more granular control over the feature.sqltrace.Register("postgres",&pq.Driver{},sqltrace.WithDBMPropagation(tracer.DBMPropagationModeFull))// Followed by a call to Open.db,err:=sqltrace.Open("postgres","postgres://pqgotest:password@localhost/pqgotest?sslmode=disable")iferr!=nil{log.Fatal(err)}// Then, we continue using the database/sql package as we normally would, with tracing.rows,err:=db.Query("SELECT name FROM users WHERE age=?",27)iferr!=nil{log.Fatal(err)}deferrows.Close()}
Follow the Java tracing instrumentation instructions and install the 1.11.0 version, or greater, of the Agent.
Enable the database monitoring propagation feature using one of the following methods:
Set the system property dd.dbm.propagation.mode=full
Set the environment variable DD_DBM_PROPAGATION_MODE=full
Full example:
# Start the Java Agent with the required system properties
java -javaagent:/path/to/dd-java-agent.jar -Ddd.dbm.propagation.mode=full -Ddd.integration.jdbc-datasource.enabled=true -Ddd.service=my-app -Ddd.env=staging -Ddd.version=1.0 -jar path/to/your/app.jar
Test the feature in your application:
publicclassApplication{publicstaticvoidmain(String[]args){try{Connectionconnection=DriverManager.getConnection("jdbc:postgresql://127.0.0.1/foobar?preferQueryMode=simple","user","password");Statementstmt=connection.createStatement();Stringsql="SELECT * FROM foo";stmt.execute(sql);stmt.close();connection.close();}catch(SQLExceptionexception){// exception logic}}}
Tracer versions 1.44 and above:
Enable the prepared statements tracing for Postgres using one of the following methods:
Set the system property dd.dbm.trace_prepared_statements=true
Set the environment variable export DD_DBM_TRACE_PREPARED_STATEMENTS=true
Note: The prepared statements instrumentation overwrites the Application property with the text _DD_overwritten_by_tracer, and causes an extra round trip to the database. This additional round trip normally has a negligible impact on the SQL statement execution time.
Enabling prepared statements tracing may cause increased connection pinning when using Amazon RDS Proxy, which reduces connection pooling efficiency. For more information, see Connection pinning on RDS Proxy.
Tracer versions below 1.44:
Prepared statements are not supported in full mode for Postgres and MySQL, and all JDBC API calls that use prepared statements are automatically downgraded to service mode. Since most Java SQL libraries use prepared statements by default, this means that most Java applications are only able to use service mode.
In your Gemfile, install or update dd-trace-rb to version 1.8.0 or greater:
source'http://rubygems.org'gem'datadog'# Use `'ddtrace', '>= 1.8.0'` if you're using v1.x# Depends on your usagegem'mysql2'gem'pg'
Enable the database monitoring propagation feature using one of the following methods:
Env variable:
DD_DBM_PROPAGATION_MODE=full
Option comment_propagation (default: ENV['DD_DBM_PROPAGATION_MODE']), for mysql2 or pg:
For MongoDB (requires dd-trace-py>=3.5.0), install pymongo:
pip install pymongo
Enable the database monitoring propagation feature by setting the following environment variable:
DD_DBM_PROPAGATION_MODE=full
Postgres example:
importpsycopg2POSTGRES_CONFIG={"host":"127.0.0.1","port":5432,"user":"postgres_user","password":"postgres_password","dbname":"postgres_db_name",}# connect to postgres dbconn=psycopg2.connect(**POSTGRES_CONFIG)cursor=conn.cursor()# execute sql queriescursor.execute("select 'blah'")cursor.executemany("select %s",(("foo",),("bar",)))
MongoDB example:
frompymongoimportMongoClient# Connect to MongoDBclient=MongoClient('mongodb://localhost:27017/')db=client['test_database']collection=db['test_collection']# Insert a documentcollection.insert_one({"name":"test","value":1})# Query documentsresults=collection.find({"name":"test"})fordocinresults:print(doc)
This feature requires automatic instrumentation to be enabled for your .NET service.
constpg=require('pg')consttracer=require('dd-trace').init({dbmPropagationMode:'full'})constclient=newpg.Client({user:'postgres',password:'postgres',database:'postgres'})client.connect(err=>{console.error(err);process.exit(1);});client.query('SELECT $1::text as message',['Hello world!'],(err,result)=>{// handle result
})
Explore the APM Connection in DBM
Attribute active database connections to the calling APM services
Break down active connections for a given host by the upstream APM services making the requests. You can attribute load on a database to individual services to understand which services are most active on the database. Pivot to the most active upstream service’s service page to continue the investigation.
Filter your database hosts by the APM services that call them
Quickly filter the Database List to display only the database hosts that your specific APM services depend on. Easily identify if any of your downstream dependencies have blocking activity that may impact service performance.
View the associated trace for a query sample
When viewing a Query Sample in Database Monitoring, if the associated trace has been sampled by APM, you can view the DBM Sample in the context of the APM Trace. This allows you to combine DBM telemetry, including the explain plan and historical performance of the query, alongside the lineage of the span within your infrastructure to understand if a change on the database is responsible for poor application performance.
Explore the DBM Connection in APM
Visualize the downstream database hosts of APM services
On the APM page for a given service, view the direct downstream database dependencies of the service as identified by Database Monitoring. Quickly determine if any hosts have disproportionate load that may be caused by noisy neighbors. To view a service’s page, click on the service in the Software Catalog to open a details panel, then click View Service Page in the panel.
Identify potential optimizations using explain plans for database queries in traces
View historical performance of similar queries to those executed in your trace, including sampled wait events, average latency, and recently captured explain plans, to contextualize how a query is expected to perform. Determine if the behavior is abnormal and continue the investigation by pivoting to Database Monitoring for additional context about the underlying database hosts.
Further Reading
Additional helpful documentation, links, and articles:
Seamlessly correlate DBM and APM telemetry to understand end-to-end query performanceBLOG