- \n
- What is database monitoring?<\/a><\/li>\n
- Why database monitoring is important<\/a><\/li>\n
- Database Performance Monitoring vs Database Activity Monitoring<\/a><\/li>\n
- Key metrics in database monitoring<\/a><\/li>\n
- Monitoring by database type<\/a><\/li>\n
- Common issues detected by monitoring<\/a><\/li>\n
- Best practices for monitoring databases<\/a><\/li>\n
- What a database monitoring tool should include<\/a><\/li>\n
- Database monitoring, observability and CMDB<\/a><\/li>\n
- How Pandora FMS helps monitor databases<\/a><\/li>\n
- Frequently asked questions<\/a><\/li>\n
- Conclusion<\/a><\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=”3_4″ _builder_version=”4.27.0″ _module_preset=”default” custom_css_main_element=”z-index:0!important;” global_colors_info=”{}”][et_pb_text admin_label=”seccion” module_id=”1″ module_class=”ittopicscontent” _builder_version=”4.27.5″ _module_preset=”default” z_index=”0″ custom_margin=”0px||0px||true|false” custom_padding=”0px||0px||false|false” hover_enabled=”0″ custom_css_main_element=”font-family:%22Pandora-Light%22;” locked=”off” global_colors_info=”{}” sticky_enabled=”0″]When John Lennon sang that living is easy with eyes closed, it was clear he did not work in technology, where blindness is the opening verse of disaster. You cannot manage what you cannot see<\/strong>. That is why the first priority in IT is to gain full clarity over what is happening across our infrastructure. And within that infrastructure, the database is one of the most critical subsystems<\/strong>. Hence the importance of monitoring it.
\nIf the database goes down, the domino effect that ruins our week begins, because the next things to collapse are the applications, then customers, reports, automations and, finally, the morale and sanity of the on-call rotation.
\nThat is why this guide covers what database monitoring is, which metrics to track, which issues it detects<\/strong>, which best practices to apply and how it fits into our global observability strategy.
\nWith it, we will own a Palantir that will allow us to know everything and, more importantly, act in time before the inevitable sparks turn into a fire.<\/p>\nWhat is database monitoring?<\/h2>\n
Let us begin with the unavoidable theory.
\nDatabase monitoring consists of continuously supervising the availability, performance, queries, connections, storage, replication, errors and capacity<\/strong> of the engines that support our critical data. The goal is to detect issues before they affect the service<\/strong>.
\nOr, put another way, to be The Catcher in the Rye and not wait until the user kindly shouts at us that the website is crawling. Before reaching that point, monitoring should allow us to detect and correct.<\/p>\n![](\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\")
<\/p>\nGeneral and consolidated view of MySQL in Pandora FMS, enabling fast visual control of database status<\/p>\n
Why database monitoring is important<\/h2>\n
The reasons are as obvious as they are often ignored:<\/p>\n
- \n
- Reduce service outages:<\/strong> by detecting connection saturation before it collapses the service.<\/li>\n
- Detect any degradation before it reaches the user<\/strong>: for example, a query that goes from 50 ms to 800 ms is a warning to act on before it becomes an issue.<\/li>\n
- Avoid storage saturation<\/strong>: because disk space usually fills up slowly when nobody is watching, rather than striking all at once.<\/li>\n
- Optimize queries and resources:<\/strong> by identifying the queries that are choking the database engine.<\/li>\n
- Anticipate capacity issues<\/strong>: knowing how much time we have left before arguing with finance to get more hardware or a scale-out.<\/li>\n
- Reduce MTTR<\/strong>: mainly by helping the team stop fighting fires blindfolded.<\/li>\n
- Understand dependencies<\/strong> between database, application, server and network.<\/li>\n<\/ul>\n
The concept of the \u201cBlack Box\u201d is currently fashionable in IT and, without monitoring, the database becomes one<\/strong> that only shows signs of life when it stops showing them. At that point, all that is left is to run in with a defibrillator like in those medical series where everyone ends up involved with everyone else.<\/p>\n
Database Performance Monitoring vs Database Activity Monitoring<\/h2>\n
When database monitoring enters the conversation, these two approaches usually come with it, and it is worth understanding them without mixing them up:<\/p>\n
- \n
- Database Performance Monitoring (DPM)<\/strong>: monitoring focused on performance and operations. It tracks latencies, slow queries, throughput, connections, locks, CPU, memory, disk and network usage, replication, storage and availability. In other words, this is what is usually understood as \u201cdatabase monitoring\u201d.<\/li>\n
- Database Activity Monitoring (DAM)<\/strong>: in this case, monitoring is focused on activity, security and auditing. It observes data access, users and sessions, sensitive queries, unauthorized changes, anomalous behavior and regulatory compliance.<\/li>\n<\/ul>\n
Knowing this, this guide focuses on the first approach, DPM, covering performance, availability and operations<\/strong>, although it is worth noting that activity monitoring is also part of a complete strategy when regulatory or audit requirements are involved.<\/p>\n
Key metrics in database monitoring<\/h2>\n
<\/p>\nSelection of metrics in Pandora FMS for monitoring an Oracle database<\/p>\n
In practice, monitoring provides metrics, but of course, life has always had its hierarchies, and not all of them should carry the same weight in our decisions.
\nThat, and the fact that a dashboard full of charts nobody looks at is just expensive noise.
\nThat is why this is the wheat we need to separate from the chaff and always keep under control.<\/p>\nAvailability and service status<\/h3>\n
The first thing to monitor is whether the databases are running, obviously. This involves key indicators such as:<\/p>\n
- \n
- Uptime<\/strong> or engine availability.<\/li>\n
- Response to health checks<\/strong>.<\/li>\n
- Connection errors<\/strong>.<\/li>\n
- Status<\/strong> of nodes or instances in a cluster.<\/li>\n<\/ul>\n
Performance<\/h3>\n
Beyond simply running, we are paid to make them run efficiently<\/strong> and not drag their feet when processing queries. This involves monitoring metrics such as:<\/p>\n
- \n
- Latency<\/strong> of those queries.<\/li>\n
- Average response time<\/strong> and 95th\/99th percentile.<\/li>\n
- Slow queries<\/strong>.<\/li>\n
- Throughput<\/strong> in queries per second.<\/li>\n
- Locks, deadlocks and waits<\/strong>.<\/li>\n<\/ul>\n
Resource usage<\/h3>\n
Effectiveness and efficiency are not the same thing, and we want both, so running fast should not mean processors without running processors hotter than the sun<\/strong> or burning through RAM that\u2019s currently worth more than my kidneys..
\nFor that, we monitor:<\/p>\n- \n
- CPU<\/strong> consumed by the engine.<\/li>\n
- Memory<\/strong> used and free (buffer pool and cache).<\/li>\n
- Disk<\/strong> (free space, IOPS, latency, etc.).<\/li>\n
- Network<\/strong> (traffic and errors).<\/li>\n<\/ul>\n
Connections and sessions<\/h3>\n
Here, what matters is the who, how and how much of usage<\/strong>, which means knowing:<\/p>\n
- \n
- Active connections<\/strong> and configured maximums.<\/li>\n
- Connection pool saturation<\/strong>.<\/li>\n
- Blocked<\/strong> or waiting sessions.<\/li>\n<\/ul>\n
Storage and growth<\/h3>\n
Databases tend to do the same as me, mysteriously pack on the pounds<\/strong>, especially when nobody is watching what I do.
\nTo prevent our databases from taking over everything like the tribbles from Star Trek, we need to monitor:<\/p>\n- \n
- Size<\/strong> of databases and tables.<\/li>\n
- Growth<\/strong> per unit of time.<\/li>\n
- Free space<\/strong> in tablespaces or volumes.<\/li>\n
- Index status<\/strong> (usage, fragmentation).<\/li>\n
- Log volume<\/strong> (transactional and application logs).<\/li>\n<\/ul>\n
Replication, clustering and high availability<\/h3>\n
These indicators are essential in modern database management monitoring<\/strong>:<\/p>\n
- \n
- Replication lag<\/strong> to prevent users from accessing outdated data.<\/li>\n
- Replica status<\/strong> and whether they are online, delayed or down.<\/li>\n
- Failover and switchovers<\/strong> for failures, emergencies or maintenance.<\/li>\n
- Node synchronization<\/strong> to verify data consistency between nodes and ensure that quorum is active to maintain system integrity.<\/li>\n<\/ul>\n
Backups and recovery<\/h3>\n
No matter how good and fast we are, disaster will eventually catch up with us, so we also need to be humble and work with a safety net, not just a network, although that too.
\nTo do this, we must monitor:<\/p>\n- \n
- The status of the latest backup<\/strong>.<\/li>\n
- Age of the last successful backup<\/strong>, which is what truly feeds our Recovery Point Objective (RPO).<\/li>\n
- Errors<\/strong> in backup processes.<\/li>\n
- Duration of the latest test restore<\/strong>. This is the honest way to validate the RTO (Recovery Time Objective), because a backup that cannot be restored is a false illusion of security.<\/li>\n<\/ul>\n
Monitoring by database type<\/h2>\n
<\/p>\nPandora FMS monitoring a timeless corporate classic, an IBM DB2 database<\/p>\n
Just as metrics are not all the same, neither are databases<\/strong>. Each data model therefore requires its own monitoring approach<\/strong>.
\nAlthough I cannot go into full detail on each one here (well, I could, but this would turn into The NeverEnding Story), you have a complete guide to the types of databases<\/a>. There, we cover the taxonomy, while here we focus on what to monitor in each case.
\nAs we will see, some things are common to all databases, such as availability or latency, for example, while others are more specific to the type of database, such as traversal or traversal time when dealing with graph databases.<\/p>\nRelational databases<\/h3>\n
Here we include MySQL, PostgreSQL, Oracle, SQL Server or MariaDB<\/strong>, and it is rare for our IT infrastructure not to have one of these (or, rather, several).
\nHere, the focus should be on:<\/p>\n- \n
- Slow<\/strong> queries.<\/li>\n
- Locks.<\/li>\n
- Connections<\/strong>.<\/li>\n
- Indexes.<\/li>\n
- Replication<\/strong>.<\/li>\n
- Storage.<\/li>\n
- Transactions.<\/li>\n<\/ul>\n
Of course, the first step to get started is their official documentation: PostgreSQL<\/a>, MySQL<\/a>, SQL Server<\/a> and Oracle<\/a>.<\/p>\n
Document-oriented NoSQL databases<\/h3>\n
In this case, names such as MongoDB, Couchbase or RavenDB<\/strong> come to mind. Here, it is essential to monitor:<\/p>\n
- \n
- Operations<\/strong> per second.<\/li>\n
- Memory usage.<\/li>\n
- Replication<\/strong>.<\/li>\n
- Indexes.<\/li>\n
- Query<\/strong> times.<\/li>\n
- Errors.<\/li>\n
- Collection<\/strong> growth.<\/li>\n<\/ul>\n
For this, MongoDB has specific documentation<\/a>, and in this guide on how to monitor RavenDB<\/a>, we go into detail to give you a hand.
\nOn the other hand, if you want a broader view of the non-relational side of databases, this guide to NoSQL databases<\/a> provides a useful overview of the landscape.<\/p>\nKey-value and cache databases<\/h3>\n
Redis or Riak<\/strong> enter the field in this case, and we need to keep a close eye on:<\/p>\n
- \n
- Memory<\/strong> consumed.<\/li>\n
- Key expiration<\/strong> by TTL (expired keys).<\/li>\n
- Evictions<\/strong> due to memory pressure, which, be careful, are not the same as expirations.<\/li>\n
- Cache hits and misses.<\/li>\n
- Persistence.<\/li>\n
- Connections.<\/li>\n
- Latency<\/strong>.<\/li>\n<\/ul>\n
- Key expiration<\/strong> by TTL (expired keys).<\/li>\n
- Age of the last successful backup<\/strong>, which is what truly feeds our Recovery Point Objective (RPO).<\/li>\n
- Replica status<\/strong> and whether they are online, delayed or down.<\/li>\n
- Growth<\/strong> per unit of time.<\/li>\n
- Connection pool saturation<\/strong>.<\/li>\n
- Memory<\/strong> used and free (buffer pool and cache).<\/li>\n
- Average response time<\/strong> and 95th\/99th percentile.<\/li>\n
- Response to health checks<\/strong>.<\/li>\n
- Database Activity Monitoring (DAM)<\/strong>: in this case, monitoring is focused on activity, security and auditing. It observes data access, users and sessions, sensitive queries, unauthorized changes, anomalous behavior and regulatory compliance.<\/li>\n<\/ul>\n
- Detect any degradation before it reaches the user<\/strong>: for example, a query that goes from 50 ms to 800 ms is a warning to act on before it becomes an issue.<\/li>\n
- Why database monitoring is important<\/a><\/li>\n
![](\"https:\/\/pandorafms.com\/wp-content\/uploads\/2024\/12\/agentes-y-modulos-mysql.png\")
<\/p>\n![](\"https:\/\/pandorafms.com\/wp-content\/uploads\/2025\/08\/Oracle-032025.png\")
<\/p>\n![](\"https:\/\/pandorafms.com\/wp-content\/uploads\/2025\/08\/metricas-aws-b.png\")
<\/p>\n![](\"https:\/\/pandorafms.com\/wp-content\/uploads\/2026\/06\/Captura-pfms.png\")
<\/p>\n