Česky na konci článku.
For years, database monitoring was mostly about answering simple questions:
Is the database up?
Is CPU high?
Are there blocking sessions?
Is there enough disk space?
Are backups running?
That is no longer enough.
Modern database platforms are becoming part of distributed systems where an incident rarely belongs to the database alone.
A slow API request may be caused by an application timeout.
The application timeout may be caused by connection pool exhaustion.
The connection pool may be caused by a database query waiting on I/O.
And the I/O problem may be caused by another workload running on the same platform.
The DBA therefore needs more than database metrics.
From monitoring to observability
Traditional monitoring tells us that something is wrong.
Observability should help us understand why.
For a database platform, this means connecting multiple signals:
- database metrics
- wait events
- SQL execution
- application latency
- logs
- traces
- operating system metrics
- storage performance
- network behaviour
- replication status
- connection pool utilisation
The goal is not to collect everything.
The goal is to connect the right information.
Oracle is moving in this direction
Oracle’s current observability direction combines database operational intelligence with AI assistance and agentic capabilities.
At the same time, Oracle Database supports OpenTelemetry-based distributed tracing and correlation between database activity, logs and application traces.
This is important because database performance cannot always be understood from inside the database.
A query may be fast when executed manually but slow from the application.
A database may show normal CPU utilisation while users experience high latency.
A RAC cluster may be healthy while one application is suffering from a specific workload problem.
Observability connects these layers.
PostgreSQL needs the same discipline
The PostgreSQL ecosystem is moving in the same direction.
Prometheus and Grafana are widely used for infrastructure and database metrics.
Query-level monitoring provides another layer of information.
But metrics alone are not enough.
A graph showing increased latency is useful.
Knowing which queries caused the latency is better.
Knowing which application transaction generated those queries is better still.
And knowing why the workload changed is what allows the DBA to prevent the next incident.
AI will not replace database engineering
This is where I think the DBA role is often misunderstood.
AI can help analyse large amounts of telemetry.
It can identify unusual behaviour.
It can suggest possible causes.
It can help generate SQL or diagnostic commands.
But production database engineering still requires judgement.
A database engineer has to understand:
- availability requirements
- recovery objectives
- data consistency
- workload characteristics
- HA architecture
- replication
- storage behaviour
- application dependencies
- operational risk
The difficult part is not finding a possible explanation.
The difficult part is deciding whether that explanation is actually safe to act on.
The new DBA skill set
The modern DBA increasingly needs to understand both database internals and the systems around them.
That means knowing how to work with:
Database
Oracle, PostgreSQL, SQL, execution plans, wait events, replication and HA.
Infrastructure
Linux, storage, networking, virtualization and cloud platforms.
Observability
Prometheus, Grafana, logs, metrics, traces and correlation.
Automation
Shell, Python, Ansible and repeatable operational processes.
Reliability
SLOs, incident response, RCA, disaster recovery and failure testing.
The DBA is therefore moving closer to the Database Reliability Engineer.
The best monitoring system is not the one with the most dashboards
A platform with 500 dashboards is not necessarily observable.
Good observability should answer a small number of important questions quickly:
What changed?
When did it change?
What was affected?
Why was it affected?
Is the problem inside the database or outside it?
Can we safely fix it?
And how do we prevent it from happening again?
That is the difference between monitoring and observability.
The future DBA will not simply watch databases.
The future DBA will understand the entire path from application request to database operation and back again.
That is where database reliability engineering begins.
About
Tomáš Solař is a Senior Database Engineer / Database Reliability Consultant specializing in Oracle and PostgreSQL, high availability, performance engineering, automation and production reliability.
20+ years of database engineering • 200+ customer engagements • Oracle RAC & Data Guard • PostgreSQL HA • Performance Tuning • Automation • Database Reliability
Z DBA se stává Observability Engineer
Po mnoho let bylo monitorování databází založeno především na jednoduchých otázkách:
Je databáze dostupná?
Je vysoké využití CPU?
Jsou blokované sessions?
Je dostatek místa na disku?
Probíhají zálohy?
To už dnes nestačí.
Moderní databázové platformy jsou součástí distribuovaných systémů, kde incident jen málokdy vzniká pouze v databázi.
Pomalý požadavek API může být způsoben timeoutem aplikace.
Timeout aplikace může být způsoben vyčerpáním connection poolu.
Vyčerpaný connection pool může být způsoben databázovým dotazem čekajícím na I/O.
A problém s I/O může být způsoben jinou zátěží běžící na stejné platformě.
DBA proto potřebuje víc než pouze databázové metriky.
Od monitoringu k observabilitě
Tradiční monitoring nám řekne, že je něco špatně.
Observabilita by nám měla pomoci pochopit proč.
U databázové platformy to znamená propojit několik různých signálů:
- databázové metriky
- wait events
- SQL execution
- aplikační latenci
- logy
- traces
- metriky operačního systému
- výkon storage
- síťové chování
- stav replikace
- využití connection poolů
Cílem není sbírat úplně všechno.
Cílem je propojit správné informace.
Oracle se ubírá tímto směrem
Oracle v současnosti rozšiřuje oblast observability o AI asistenci a agentic capabilities v Enterprise Manageru.
Současně Oracle Database podporuje distributed tracing založený na OpenTelemetry a korelaci databázové aktivity s logy a aplikačními traces.
To je důležité, protože výkon databáze nelze vždy pochopit pouze uvnitř databáze.
Dotaz může být při ručním spuštění rychlý, ale z aplikace pomalý.
Databáze může mít normální využití CPU, zatímco uživatelé přesto pociťují vysokou latenci.
RAC cluster může být technicky zdravý, zatímco konkrétní aplikace trpí problémem způsobeným určitým workloadem.
Observabilita umožňuje tyto vrstvy propojit.
Stejný princip platí pro PostgreSQL
Stejným směrem se vydává také PostgreSQL ekosystém.
Prometheus a Grafana se běžně používají pro monitoring infrastruktury a databází.
Další vrstvu poskytuje monitoring jednotlivých dotazů a workloadu.
Ani samotné metriky ale nestačí.
Graf ukazující zvýšenou latenci je užitečný.
Vědět, které SQL dotazy latenci způsobily, je lepší.
Vědět, která aplikační transakce tyto dotazy vytvořila, je ještě lepší.
A pochopit, proč se workload změnil, nám umožní zabránit dalšímu incidentu.
AI nenahradí database engineering
Právě zde podle mě často dochází k nesprávnému pochopení role DBA.
AI může pomoci analyzovat obrovské množství telemetry.
Může identifikovat neobvyklé chování.
Může navrhnout možné příčiny problému.
Může pomoci vytvořit SQL nebo diagnostické příkazy.
Produkční database engineering ale stále vyžaduje lidský úsudek.
DBA musí rozumět například:
- požadavkům na dostupnost
- recovery objectives
- konzistenci dat
- charakteru workloadu
- HA architektuře
- replikaci
- chování storage
- závislostem aplikací
- provoznímu riziku
Nejtěžší částí není najít možné vysvětlení.
Nejtěžší je rozhodnout, zda je toto vysvětlení skutečně správné a zda je bezpečné podle něj jednat.
Nový skillset DBA
Moderní DBA musí stále více rozumět nejen databázovým interním mechanismům, ale také systémům, které databázi obklopují.
To znamená znalost oblastí jako:
Database
Oracle, PostgreSQL, SQL, execution plans, wait events, replikace a HA.
Infrastructure
Linux, storage, networking, virtualizace a cloudové platformy.
Observability
Prometheus, Grafana, logy, metriky, traces a jejich korelace.
Automation
Shell, Python, Ansible a opakovatelné provozní procesy.
Reliability
SLO, incident response, RCA, disaster recovery a testování selhání.
Role DBA se tak stále více přibližuje roli Database Reliability Engineera.
Nejlepší monitoring není ten, který má nejvíce dashboardů
Systém s 500 dashboardy nemusí být vůbec dobře observabilní.
Dobrá observabilita by měla rychle odpovědět na několik zásadních otázek:
Co se změnilo?
Kdy se to změnilo?
Co bylo ovlivněno?
Proč to bylo ovlivněno?
Je problém uvnitř databáze, nebo mimo ni?
Můžeme problém bezpečně opravit?
A především:
Jak zabráníme tomu, aby se incident opakoval?
To je rozdíl mezi monitoringem a observabilitou.
Budoucí DBA nebude pouze sledovat databáze.
Bude rozumět celé cestě od požadavku aplikace přes databázovou operaci až zpět k aplikaci.
A právě zde začíná Database Reliability Engineering.
About
Tomáš Solař je Senior Database Engineer / Database Reliability Consultant se zaměřením na Oracle a PostgreSQL, vysokou dostupnost, performance engineering, automatizaci a produkční spolehlivost.
20+ let database engineering • 200+ zákaznických engagementů • Oracle RAC & Data Guard • PostgreSQL HA • Performance Tuning • Automation • Database Reliability