A database is one of the most critical components of every application. Yet in many large environments, IT monitoring stops at CPU, RAM, and disk layers. What remains invisible includes what is happening inside the database itself: how long queries take, whether locks are blocking transactions, or how table sizes are growing.

However, this is only part of the problem. The second, often overlooked dimension is monitoring precision. It is quite common for organizations to monitor databases, but in a limited way without understanding the specific mechanisms of a given database engine or the application that uses it. Effective database monitoring is not about collecting every possible metric, but about observing the right aspects that truly matter for a specific system.

This article shows how to build visibility of the data layer - from database monitoring mechanisms (not only ODBC), through operational metrics, to a full observability architecture.

What exactly is ODBC?

ODBC is something like a universal translator between applications and databases.

Imagine you go shopping and in each store the seller speaks a different language - in one Japanese, in another Arabic, and in yet another Spanish. To buy anything, you would need to know all these languages. But you don’t have to worry about that because you have a translator with you who knows them all. You always speak Polish to them, and they communicate with each store. That is exactly how ODBC works. The software always “speaks” in the same way, and ODBC translates it into the language of a specific database.

Database monitoring via ODBC is no longer as widely used as it once was. Today, native plugins are increasingly used instead of a universal translator, you have a dedicated specialist who knows the store inside out, knows where the warehouse is, knows the owner, and can ask about things a generic translator would never understand.

Why database monitoring is not just “is the server alive”?

Imagine a production environment in a bank. All hosts are green, CPU at 30%, disk has plenty of free space. Meanwhile, a customer transfer takes 12 seconds instead of 2. The helpdesk receives the first tickets after 40 minutes. The IT team begins analysis without any data about what actually happened inside the database.

This is not an abstract scenario. It is reality in environments where monitoring covers infrastructure but ignores the data layer. The database server is running, but the database is not.

Three real consequences of lack of database visibility

SLA violations without a visible cause

A series of small, unrelated events, such as a query taking three times longer or a lock held too long, accumulates into an SLA breach. Without database-level information, correlation with other metrics and logs is impossible.

No root-cause analysis after an incident

When an outage ends, the question arises: “What caused it?” Without historical data layer metrics, the answer is: “We don’t know.” Such RCA does not lead to any operational improvement.

Reactivity instead of proactivity

The team learns about the problem from a user or customer, not from the monitoring system. In 24/7 environments, this model generates real costs: downtime in banking or telecom can mean tens of thousands of PLN per hour.

Database monitoring mechanisms

Among available database monitoring mechanisms, there are several approaches that can be used individually or together depending on requirements and environment.

Native plugins and database agents

Modern monitoring platforms such as Zabbix offer native support for popular database engines through dedicated plugins and modules.

ODBC (Open Database Connectivity)

A standard interface for communicating with databases, independent of the database vendor. It is especially useful where dedicated integration is not available.

Database APIs and system views

Database engines expose diagnostic views and APIs. Direct querying of these APIs provides the most detailed information about database state.

Precise monitoring = standard + application context

Effective database monitoring requires understanding the mechanisms of a specific engine and adapting monitoring scope to the application that uses it.

Level 1 – database engine standard

Each database engine has a set of metrics that should be monitored regardless of context. For example, in MSSQL these include buffer cache hit ratio, page life expectancy, etc. These metrics form a baseline visibility layer applied to every instance of a given engine.

Level 2 – application-specific optimization

The same database engine can behave very differently depending on the application using it. For example, an MSSQL database supporting an ERP system requires a different monitoring profile than one supporting a high-frequency transactional system.

What to monitor - i.e. which metrics matter operationally?

Technical configuration is less than half the success. The key is what is being monitored. The most common mistake is trying to monitor everything at once. In enterprise deployments, it is recommended to start with five metrics that provide immediate operational value:

• Availability and response time: Longer response times are usually the first signal of problems, visible dozens of minutes before an incident.
• Long-running queries: Queries exceeding a defined threshold may indicate indexing issues, locking, or sudden data growth.
• Locks and deadlocks: Locks blocking multiple threads simultaneously are often the most common cause of gradual performance degradation.
• Database size and free space: Running out of table space leads to immediate transaction failures.
• Replication lag: Delay between primary and replica precedes availability issues and is a key indicator in high-availability environments.

Once these metrics are monitored, the scope can be extended to additional indicators such as cache hit ratio.

Where tools alone are not enough: enterprise scale

Simple monitoring via ODBC and native plugins works well for a few databases. The problem appears at enterprise scale: dozens of databases, multiple database technologies, different teams responsible for different systems.

Problem 1 – metric overload

Database metrics live in a different place than application server metrics and load balancer logs. When a user reports that “the application is slow,” there is no single view that correlates an 8-second SQL query, CPU spike on the application server, and a series of 500 errors. Analysis requires manual switching between tools and time-based correlation.

Problem 2 – lack of transaction context

A metric may say: “12 queries are taking too long.” But it does not say which queries, which application they belong to, which users are affected, or which code paths triggered them. Full diagnosis requires a tool that traces a transaction from the application layer down to the database call—Application Performance Monitoring (APM).

Problem 3 – alert fatigue in multi-database environments

With 50 databases and 10 metrics per database, you get 500 potential alerts. Without intelligent grouping, prioritization, and suppression, the operations team drowns in notifications and stops responding effectively. Monitoring tools alone do not solve this. An alert architecture is required: what escalates, to whom, in what order, and with what context.

Signals that database monitoring needs architecture, not just configuration:

• You operate a complex database environment (e.g. separate databases for billing, logging, etc.)
• You use more than one database system (e.g. Oracle + PostgreSQL + MSSQL simultaneously)
• Different teams are responsible for different databases without a shared operational visibility layer
• Database incidents take longer than 15 minutes to diagnose due to lack of data
• SLA reporting does not include database layer data, only infrastructure data

Architecture of full data visibility

Full visibility of the data layer in an enterprise environment requires three components working together - not three separate tools working in isolation.

Layer 1 – database operational metrics

The monitoring tool queries the database via ODBC or plugins and collects real-time quantitative metrics: numbers, states, sizes. This layer answers questions such as: how much, how big, how fast, is it available. It forms the basis for threshold alerts and long-term trend analysis.

Layer 2 – APM: tracing queries down to application code

Application Performance Monitoring concerns the application, not the database. The APM agent (available for Java, Python, .NET, Node.js, and others) captures every SQL query executed by the application: where it came from, how long it took, and in which business transaction context. It connects metrics with actual application calls.

Layer 3 – Central operational dashboard

The visualization layer aggregates data from both sources, ODBC metrics and APM, into a single operational view. SRE teams and IT leadership see the same real-time picture: database health, anomalies, trends, and active incidents.

How Hawatel implements database monitoring in enterprise environments?

The architecture described in this article is not theory. It is a proven approach implemented for enterprise clients in banking, telecom, and utilities, where database monitoring must run continuously and provide real-time data.

For the metrics layer, we use Zabbix, a proven, scalable open-source monitoring platform. Zabbix offers native support for popular database engines through dedicated plugins, and where native integration is not available or a unified multi-engine layer is required, it also supports ODBC.

For visualization and operational dashboards, we use Grafana - a central observability hub that aggregates metrics and logs into one coherent view. One screen for SRE, IT leadership, and CISO.

Hawatel is a certified Zabbix partner in Poland. Our deployments cover environments of 500+ hosts. Every database monitoring implementation ends with documented architecture and knowledge transfer to the client team.

Database monitoring in enterprise environments is not a tooling issue. It is an observability architecture issue. And that is the difference between reactive monitoring and proactive management of a critical environment.

Do you operate a multi-database environment? Let’s talk about monitoring architecture!