• Home
  • Platform modules
  • Applications and Microservices
  • Databases
  • How database activity is monitored

How database activity is monitored

In monitoring databases, Dynatrace doesn't consider methods, but rather commits, queries, and modifications related to your database services. By monitoring such calls, Dynatrace is able to deliver automatic root-cause analysis for performance problems with your database services. For example, if your database queries or commits slow down, we'll notify you immediately. We'll even show you which services are impacted by the problem.

Database calls that are made through monitored Java, .NET, PHP and Node.js processes are monitored automatically as long as the interaction with the database relies on a supported database framework, such as JDBC, ADO.NET, or PDO. When OneAgent is installed on the host that runs your application server, Dynatrace ensures that all database statements are logged, as long as deep monitoring is active for the calling processes and the database request is appended to an existing PurePath® distributed trace. As soon as the first calls to your database are monitored, the Databases page is updated with the new database entry.

Database calls and PurePath® technology

The distributed trace of a database request shows a particular database statement executed by the application. Because the traces are captured within the application and not on the database itself, you will see database statements traces only if the application that makes them either sends distributed traces to the OpenTelemetry trace ingest or is monitored via the OneAgent. If there are no distributed traces already started by the said application, you can define a custom service. See the Method hotspots page to choose a method that is called before the database request in the same thread.

When monitoring database activity, Dynatrace shows you which database statements are executed most often and which statements take up the most time. You can also see which services execute the database statements. For example, Dynatrace knows automatically when a service begins sending too many database statements and pushes a database server beyond its capacity.

When a database-related problem is raised, for example due to a drop in response time, Dynatrace tells you if there is a correlation between the problem and any load increase on a related service, which may be the root cause of the problem.