The Zabbix Agent 2 service on a Windows server was repeatedly becoming unresponsive and eventually crashing. The issue caused intermittent monitoring interruptions and required further investigation through Event Viewer messages and Zabbix Agent 2 logs to better understand why the service was no longer responding properly.

While monitoring a Windows server with Zabbix Agent 2, we encountered repeated crashes of the agent service accompanied by the following Event Viewer message:

A timeout (30000 milliseconds) was reached while waiting for a transaction response from the Zabbix Agent 2 service.

A few moments later, Windows reported:

The Zabbix Agent 2 service terminated unexpectedly.

Initial Hypothesis

The first assumption was that a plugin or item was taking too long to execute, causing the agent to become unresponsive. A natural idea was therefore to increase the timeout value. Here the official documentation for the PluginTimout.

Inside the Zabbix Agent 2 configuration, we identified the following parameter:

### Option:PluginTimeout
# Timeout for connections with external plugins.
## Mandatory: no
# Range: 1-30
# Default: <Global timeout>
# PluginTimeout=

However, this parameter only supports values between 1 and 30 seconds.

This raised an important question:

If a timeout already exists, why does the entire agent still become blocked and eventually crash?

Understanding the Problem

Zabbix Agent 2 uses a plugin-based architecture written in Go.
Unlike isolated external processes, many plugins run inside the same agent process.

This means that if a plugin becomes blocked:

• worker threads remain occupied
• new requests start queuing
• the agent gradually stops responding
• Windows eventually considers the service frozen

The 30-second timeout seen in Event Viewer is actually the Windows Service Control Manager (SCM) timeout, not a protection mechanism for the plugin itself.

In other words:

• the plugin blocks first
• the agent becomes unresponsive
• Windows waits 30 seconds
• Windows kills the service

Investigating the Logs

The Zabbix Agent 2 logs quickly pointed toward the real culprit.

[WindowsPerfMon] failed to get performance counters data:'cannot collect value No data to return.'

This indicated that the agent was struggling to collect Windows Performance Counters.

The most important recurring message was:

[WindowsPerfInstance] Cannot refresh object cache:Unable to connect to the specified computer or the computer is offline.

This error appeared continuously for several days.

The key observation here is that the agent was running locally, so the message below should never normally appear:

Unable to connect to the specified computer

This strongly suggested:

• an invalid or corrupted performance counter
• a problematic PerfMon object
• or a failing wildcard instance (Process(*), LogicalDisk(*), etc.)

Agent Becoming Non-Responsive

Later in the logs, additional symptoms appeared:

failed to accept an incoming connection:accept tcp [::]:10050:acceptex: The I/O operation has been aborted because of either a thread exit or an application request.

At this stage, the agent was no longer able to accept incoming connections because its internal workers were saturated or blocked.

This confirmed that the issue was not a traditional crash, but rather a thread starvation / blocking situation.

Why the Existing 30s Timeout Was Not Enough

An important misunderstanding was clarified during the investigation.

The default timeout value of 30 seconds does not immediately protect the agent.

Instead:

• the plugin may block for the full 30 seconds
• multiple blocked requests accumulate
• worker threads remain occupied
• the agent becomes globally unresponsive

By the time Windows notices the issue, the agent is already effectively frozen.

The Solution: Reduce PluginTimeout

Instead of increasing the timeout, the correct approach was to reduce it significantly.

The following configuration was applied:

PluginTimeout=15

This acts as a protection mechanism inside the agent itself.

With this configuration:

• problematic plugin executions are aborted quickly
• blocked threads are released faster
• the agent remains responsive
• only the affected items temporarily fail

Conclusion

The issue was not caused by the timeout itself.

The real root cause was a problematic WindowsPerfInstance plugin execution blocking the Zabbix Agent 2 internal workers.

Reducing the plugin timeout from 30 seconds to 15 seconds prevented the entire agent from becoming unresponsive while still allowing the monitoring system to recover automatically when the plugin started responding again.

This is a good example of why increasing timeouts is not always the right solution. Sometimes, shorter timeouts are actually what keeps a monitoring agent stable.

You can find other blogs regarding Zabbix or database administration or other topics at this link: dbi blogs

L’article Zabbix Agent 2 service terminated unexpectedly on Windows server est apparu en premier sur dbi Blog.

Monitoring Microsoft SQL Server database files is an important part of infrastructure supervision.
A database reaching its storage limit can rapidly lead to application outages, transaction failures, or even complete service interruptions.

The Initial Problem

In SQL Server, retrieving file information is relatively simple when working directly inside SQL Server Management Studio

• database file size,
• used space,
• free space,
• auto-growth configuration,
• or maximum file size

A common query used by many DBAs is the following:

USE [TEST]

GO

SELECT
  DB_NAME(database_id) AS DBName,
  Name AS Logical_Name,
  Physical_Name AS [PhysicalName],
  CAST(ROUND(((size)/128/1024), 2) AS float) AS [SizeGB],
  CAST(ROUND((CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128/1024), 2) AS float) AS [SpaceUsedGB],
  CAST(ROUND((size/128/1024 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128/1024), 2) AS float) AS [FreeSpaceGB],
  ROUND(ISNULL(((CAST((fileproperty(name, 'SpaceUsed'))/128/1024 as float)) / NULLIF((CAST(size/128/1024 as float)), 0)), 0)*100, 2) as [SpaceUsed%],
  CASE WHEN [max_size] = -1 THEN [max_size] ELSE CAST(ROUND(((max_size)/128/1024), 2) AS float) END AS [MaxSizeGB],
  CAST(ROUND((max_size/128/1024 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128/1024), 2) AS float) AS [FreeSpaceGBtoMaxSize],
  ROUND(ISNULL(((CAST((fileproperty(name, 'SpaceUsed'))/128/1024 as float)) / NULLIF((CAST(max_size/128/1024 as float)), 0)), 0)*100, 2) as [SpaceUsed%toMaxSize]
FROM sys.master_files
WHERE DB_NAME(database_id) = 'TEST'
ORDER BY Logical_Name

The initial query works perfectly for manual analysis in SQL Server Management Studio.
However, integrating it into Zabbix becomes more complicated because sys.database_files only returns information from the current database context.

This means the query must be executed individually for every database using:

USE [DatabaseName]

In small environments this remains manageable, but in larger infrastructures containing dozens or even hundreds of databases, maintaining static queries quickly becomes impractical.

To automate this process, we use:

sp_MSforeachdb

This SQL Server procedure dynamically executes the same query across every database on the instance.

Example:

EXEC sp_MSforeachdb '
USE [?]

SELECT
    DB_NAME(),
    name,
    physical_name
FROM sys.database_files
'

The ? placeholder is automatically replaced by the database name during execution, allowing SQL Server to iterate through all databases dynamically.

At first glance, this seems to solve the problem entirely.
However, another limitation quickly appears: sp_MSforeachdb returns one independent result set per database.

Instead of producing a single structured dataset, SQL Server generates multiple separate tables:

Database 1 result
-----------------
file1
file2

Database 2 result
-----------------
file1
file2

While this output remains perfectly readable for a DBA inside SQL Server Management Studio, it becomes difficult to exploit inside Zabbix, especially for Low-Level Discovery and dependent items.

To solve this limitation, we redesigned the query architecture to centralize all results into a single temporary table, allowing Zabbix to consume one normalized dataset fully compatible with automatic discovery and scalable monitoring.

Why Zabbix Cannot Easily Use This Output

Zabbix works much better when:

• the result is normalized,
• the structure is predictable,
• and all rows belong to a single dataset.

With multiple independent result sets:

• Low-Level Discovery becomes difficult,
• JSON conversion becomes complicated,
• dependent items cannot parse values correctly,
• preprocessing becomes unreliable.

The issue is therefore no longer the database context itself. The issue becomes the query output structure.

Building a Zabbix-Compatible Query

To make the output usable inside Zabbix, the query had to be redesigned completely.

The objective was no longer simply to retrieve MSSQL file information, but to transform multiple independent database results into a single normalized dataset compatible with Low-Level Discovery.

The new query therefore introduces three important concepts:

• dynamic iteration through all databases using sp_MSforeachdb,
• centralized data collection using a global temporary table,
• and a final unified output consumable by Zabbix dependent items.

The core logic becomes inside the sp_MSforeachdb execution.

INSERT INTO ##Results

Each database inserts its rows into the same centralized structure instead of returning independent result sets.

At the end of the execution, the query simply returns:

SELECT * FROM ##Results

The final output is now normalized instead of multiple disconnected tables.

The complete query

SET NOCOUNT ON;

DECLARE @Granularity VARCHAR(10) = NULL
DECLARE @Database_Name sysname = NULL
 
DECLARE @SQL VARCHAR(5000)

IF EXISTS (SELECT NAME FROM tempdb..sysobjects WHERE NAME = '##Results')
BEGIN
    DROP TABLE ##Results
END

CREATE TABLE ##Results (
    [Database Name] sysname,
    [File Name] sysname,
    [Physical Name] NVARCHAR(260),
    [File Type] VARCHAR(4),
    [Total Size in Bytes] BIGINT,
    [Available Space in Bytes] BIGINT,
    [Growth Units] VARCHAR(20),
    [Max File Size in Bytes] BIGINT
)

SELECT @SQL =
'USE [?] 
INSERT INTO ##Results(
    [Database Name],
    [File Name],
    [Physical Name],
    [File Type],
    [Total Size in Bytes],
    [Available Space in Bytes],
    [Growth Units],
    [Max File Size in Bytes]
)
SELECT 
    DB_NAME(),
    [name],
    physical_name,
    CASE type
        WHEN 0 THEN ''Data''
        WHEN 1 THEN ''Log''
    END,

    -- TOTAL SIZE (bytes) SAFE
    CAST(size AS BIGINT) * 8 * 1024,

    -- FREE SPACE (bytes) SAFE
    (CAST(size AS BIGINT) - CAST(FILEPROPERTY([name], ''SpaceUsed'') AS BIGINT)) * 8 * 1024,

    -- GROWTH
    CASE is_percent_growth
        WHEN 1 THEN CAST(growth AS varchar(20)) + ''%''
        ELSE CAST(CAST(growth AS BIGINT) * 8 * 1024 AS varchar(20))
    END,

    -- MAX SIZE (bytes) SAFE
    CASE max_size
        WHEN -1 THEN NULL
        WHEN 268435456 THEN NULL
        ELSE CAST(max_size AS BIGINT) * 8 * 1024
    END

FROM sys.database_files
ORDER BY type, file_id
'

EXEC sp_MSforeachdb @SQL

-- =========================
-- RESULTATS
-- =========================

IF @Database_Name IS NULL
BEGIN
    IF @Granularity = 'Database'
    BEGIN
        SELECT
            T.[Database Name],

            T.[Total Size in Bytes] AS [DB Size (Bytes)],
            T.[Available Space in Bytes] AS [DB Free (Bytes)],
            T.[Consumed Space in Bytes] AS [DB Used (Bytes)],

            D.[Total Size in Bytes] AS [Data Size (Bytes)],
            D.[Available Space in Bytes] AS [Data Free (Bytes)],
            D.[Consumed Space in Bytes] AS [Data Used (Bytes)],
            CEILING(CAST(D.[Available Space in Bytes] AS decimal(20,2)) / NULLIF(D.[Total Size in Bytes],0) * 100) AS [Data Free %],

            L.[Total Size in Bytes] AS [Log Size (Bytes)],
            L.[Available Space in Bytes] AS [Log Free (Bytes)],
            L.[Consumed Space in Bytes] AS [Log Used (Bytes)],
            CEILING(CAST(L.[Available Space in Bytes] AS decimal(20,2)) / NULLIF(L.[Total Size in Bytes],0) * 100) AS [Log Free %]

        FROM
        (
            SELECT [Database Name],
                SUM([Total Size in Bytes]) AS [Total Size in Bytes],
                SUM([Available Space in Bytes]) AS [Available Space in Bytes],
                SUM([Total Size in Bytes] - [Available Space in Bytes]) AS [Consumed Space in Bytes]
            FROM ##Results
            GROUP BY [Database Name]
        ) T

        INNER JOIN
        (
            SELECT [Database Name],
                SUM([Total Size in Bytes]) AS [Total Size in Bytes],
                SUM([Available Space in Bytes]) AS [Available Space in Bytes],
                SUM([Total Size in Bytes] - [Available Space in Bytes]) AS [Consumed Space in Bytes]
            FROM ##Results
            WHERE [File Type] = 'Data'
            GROUP BY [Database Name]
        ) D ON T.[Database Name] = D.[Database Name]

        INNER JOIN
        (
            SELECT [Database Name],
                SUM([Total Size in Bytes]) AS [Total Size in Bytes],
                SUM([Available Space in Bytes]) AS [Available Space in Bytes],
                SUM([Total Size in Bytes] - [Available Space in Bytes]) AS [Consumed Space in Bytes]
            FROM ##Results
            WHERE [File Type] = 'Log'
            GROUP BY [Database Name]
        ) L ON T.[Database Name] = L.[Database Name]

        ORDER BY T.[Database Name]
    END
    ELSE
    BEGIN
        SELECT
            [Database Name],
            [File Name],
            [Physical Name],
            [File Type],
            [Total Size in Bytes] AS [DB Size (Bytes)],
            [Available Space in Bytes] AS [DB Free (Bytes)],
            CEILING(CAST([Available Space in Bytes] AS decimal(20,2)) / NULLIF([Total Size in Bytes],0) * 100) AS [Free Space %],
            [Growth Units],
            [Max File Size in Bytes] AS [Grow Max Size (Bytes)]
        FROM ##Results
    END
END
ELSE
BEGIN
    IF @Granularity = 'Database'
    BEGIN
        SELECT
            T.[Database Name],

            T.[Total Size in Bytes] AS [DB Size (Bytes)],
            T.[Available Space in Bytes] AS [DB Free (Bytes)],
            T.[Consumed Space in Bytes] AS [DB Used (Bytes)],

            D.[Total Size in Bytes] AS [Data Size (Bytes)],
            D.[Available Space in Bytes] AS [Data Free (Bytes)],
            D.[Consumed Space in Bytes] AS [Data Used (Bytes)],
            CEILING(CAST(D.[Available Space in Bytes] AS decimal(20,2)) / NULLIF(D.[Total Size in Bytes],0) * 100) AS [Data Free %],

            L.[Total Size in Bytes] AS [Log Size (Bytes)],
            L.[Available Space in Bytes] AS [Log Free (Bytes)],
            L.[Consumed Space in Bytes] AS [Log Used (Bytes)],
            CEILING(CAST(L.[Available Space in Bytes] AS decimal(20,2)) / NULLIF(L.[Total Size in Bytes],0) * 100) AS [Log Free %]

        FROM
        (
            SELECT [Database Name],
                SUM([Total Size in Bytes]) AS [Total Size in Bytes],
                SUM([Available Space in Bytes]) AS [Available Space in Bytes],
                SUM([Total Size in Bytes] - [Available Space in Bytes]) AS [Consumed Space in Bytes]
            FROM ##Results
            WHERE [Database Name] = @Database_Name
            GROUP BY [Database Name]
        ) T

        INNER JOIN
        (
            SELECT [Database Name],
                SUM([Total Size in Bytes]) AS [Total Size in Bytes],
                SUM([Available Space in Bytes]) AS [Available Space in Bytes],
                SUM([Total Size in Bytes] - [Available Space in Bytes]) AS [Consumed Space in Bytes]
            FROM ##Results
            WHERE [File Type] = 'Data'
              AND [Database Name] = @Database_Name
            GROUP BY [Database Name]
        ) D ON T.[Database Name] = D.[Database Name]

        INNER JOIN
        (
            SELECT [Database Name],
                SUM([Total Size in Bytes]) AS [Total Size in Bytes],
                SUM([Available Space in Bytes]) AS [Available Space in Bytes],
                SUM([Total Size in Bytes] - [Available Space in Bytes]) AS [Consumed Space in Bytes]
            FROM ##Results
            WHERE [File Type] = 'Log'
              AND [Database Name] = @Database_Name
            GROUP BY [Database Name]
        ) L ON T.[Database Name] = L.[Database Name]

        ORDER BY T.[Database Name]
    END
    ELSE
    BEGIN
        SELECT
            [Database Name],
            [File Name],
            [Physical Name],
            [File Type],
            [Total Size in Bytes] AS [DB Size (Bytes)],
            [Available Space in Bytes] AS [DB Free (Bytes)],
            CEILING(CAST([Available Space in Bytes] AS decimal(20,2)) / NULLIF([Total Size in Bytes],0) * 100) AS [Free Space %],
            [Growth Units],
            [Max File Size in Bytes] AS [Grow Max Size (Bytes)]
        FROM ##Results
        WHERE [Database Name] = @Database_Name
    END
END

DROP TABLE ##Results

Discovery in Zabbix

Once the query has been implemented in Zabbix, the next step is to create a Low-Level Discovery (LLD) rule in order to automatically discover databases and files, then generate the associated dependent items and triggers dynamically.

A dedicated blog explaining how to configure Low-Level Discovery in Zabbix is available here: Create DISCO Put the link here

Conclusion

Monitoring MSSQL database files in Zabbix can become challenging when working with multiple databases and dynamic environments.
While the initial query is perfectly suitable for manual analysis, its structure and dependency on the current database context make it difficult to integrate directly into Zabbix.

By using sp_MSforeachdb together with a centralized temporary table, we can transform multiple independent result sets into a single normalized dataset fully compatible with Zabbix Low-Level Discovery and dependent items.

This approach provides a scalable and reusable solution capable of automatically monitoring database and log file growth across an entire SQL Server instance while significantly reducing manual configuration and maintenance efforts.

L’article Monitoring MSSQL Database Files in Zabbix est apparu en premier sur dbi Blog.

Monitoring a PostgreSQL environment involves much more than simply checking whether the database is running. In a modern high availability architecture, multiple components work together to keep the service available and stable.

In this article, we will explain how to monitor a PostgreSQL cluster environment with Zabbix:

• PostgreSQL
• Patroni
• HAProxy
• ETCD
• Keepalived

The goal of this blog is to provide a simple and clear overview that can be understood by both beginners and experienced administrators.

PostgreSQL High Availability Architecture

A typical PostgreSQL high availability environment often contains several components:

In a PostgreSQL HA environment, monitoring only the database is not enough because every component directly impacts cluster stability and application availability. Moreover, a failures in components like HAProxy, ETCD, or Keepalived can directly impact application availability and cluster stability. Comprehensive monitoring ensures the entire ecosystem remains healthy and operational.

Monitoring PostgreSQL with Zabbix

Zabbix already provides an official PostgreSQL template.

This template allows administrators to monitor:

• Database availability
• Connections
• Transactions
• Cache hit ratio
• Replication status
• Locks
• Deadlocks
• Database size
• Query statistics
• WAL activity
• Performance metrics

Therefore, using the official template is usually the fastest and easiest way to start monitoring PostgreSQL.

ETCD

Zabbix already provides an official template for ETCD monitoring.

The template uses HTTP Agent items to collect metrics directly from the /metrics endpoint exposed by ETCD.

In addition, the template works without external scripts and uses Prometheus-style metrics collection.

The official template already includes many useful triggers and metrics for monitoring ETCD health, performance, and cluster activity.

HAProxy

HAProxy plays a critical role in a PostgreSQL high availability environment, ensuring that client connections are automatically routed to the correct PostgreSQL node and maintaining application connectivity during failovers.

Zabbix already provides an official HAProxy monitoring template that can be used as a base for monitoring and customization: HAProxy by HTTP

The number of active servers in HAProxy is also monitored by the template. However, the template does not create a trigger by default for this metric. This means that a backend could lose one or more active servers without generating any alert in Zabbix. For this reason, it is highly recommended to create custom triggers on this item to immediately detect backend availability issues and avoid unnoticed service degradation.

To implement this properly, a new macro should be created in the template to define the minimum expected number of active servers. Then, a custom trigger must be added on the item prototype available in the Low-Level Discovery (LLD) section of the template. Consequently, Zabbix can automatically monitor and alert on all discovered HAProxy backends.

Patroni

Zabbix does not directly include Patroni monitoring in the standard PostgreSQL templates.

One approach is to use the Zabbix Systemd template, which allows monitoring of services running on the server. In this case, it is simply necessary to filter on the patroni service name to verify that the service is active.

Another approach is to create a custom item in a template using a Zabbix agent item with the following key:

net.tcp.service["{$HAPROXY.STATS.SCHEME}","{$HAPROXY.STATS.HOST}","{$HAPROXY.STATS.PORT.PATRONI}"]

This item performs a direct HTTP TCP connection test on port 5000, which is commonly used by the Patroni API. This configuration allows Zabbix to verify that the Patroni service responds correctly and remains reachable.

Additionally, combining both monitoring methods significantly improves monitoring reliability.

Monitoring Keepalived

Keepalived monitoring is not included by default in the standard Zabbix templates.
To properly monitor the VIP management layer, administrators should create custom items whether the Virtual IP (VIP) is correctly present on one of the cluster nodes.

A common approach is to create three different items:

• Two items using the net.tcp.service key to test TCP connectivity for:
  • the READ-ONLY access
  • the READ-WRITE access
• One additional item using a system.run command to directly verify the VIP status on the server.

Together, these checks help ensure that:

• the VIP is correctly assigned
• the PostgreSQL services are reachable
• the failover mechanism is working properly

Finally, administrators should create the appropriate triggers for these items in order to immediately detect VIP failover or connectivity issues.

Conclusion

In conclusion, monitoring PostgreSQL alone is not enough in a high availability environment.

A complete monitoring strategy must include:

• PostgreSQL
• Patroni
• HAProxy
• ETCD
• Keepalived

Using Zabbix with both official and custom templates provides a centralized and efficient monitoring solution.

The PostgreSQL template available in Zabbix already offers excellent database monitoring capabilities.

Additional templates for ETCD and HAProxy help extend monitoring to the full HA architecture and improve visibility across the entire platform.

As a result, this approach helps administrators detect failures earlier, improve troubleshooting, and ensure better service availability.

If you need you can try other blogs regarding Zabbix or postgreSQL here: dbi Blog

L’article Zabbix – Monitoring full cluster Patroni/PostgreSQL est apparu en premier sur dbi Blog.

In this article, we will see how to monitor Oracle backups using Zabbix and the Oracle plugin available with Zabbix Agent 2.

This guide assumes that:

• ARCHIVELOG mode is already enabled,
• RMAN backups are already configured,
• and Zabbix Agent 2 is already installed on the Oracle server.

Setup Zabbix agent 2

By default, the Oracle template provided with Zabbix does not include items dedicated to backup monitoring.
To achieve this, we will use the Oracle plugin feature called CustomQueries. You can find the documentation for this plugin on the official web-site.

The approach is straightforward:

• create custom SQL queries,
• store them locally on the database server,
• and let Zabbix execute them periodically

First, create a directory that will contain your monitoring SQL scripts:

mkdir -p /etc/zabbix/oracle/sql 

chmod 755 -R /etc/zabbix/oracle/sql

Create a SQL script that returns the timestamp of the latest level 0 backup.

vi /etc/zabbix/oracle/sql/last_inc0.sql

SELECT
    CAST(((CAST(BS.COMPLETION_TIME AS DATE) - DATE '1970-01-01') * 86400) AS NUMERIC) AS LAST_INC0
FROM
    V$BACKUP_SET BS
WHERE
    BS.INCREMENTAL_LEVEL = 0
ORDER BY
    BS.COMPLETION_TIME DESC
FETCH FIRST 1 ROWS ONLY;

This query retrieves the completion time of the latest RMAN level 0 backup. Then, it converts the value into Unix epoch format, which makes preprocessing and trigger calculations much easier inside Zabbix.

You can easily adapt this query to monitor:

• archive log backups,
• level 1 incremental backups,
• controlfile backups,
• or even backup duration.

Configure the Oracle Plugin

Now edit the Oracle plugin configuration file:

vi /etc/zabbix/zabbix_agent2.d/plugins.d/oracle.conf

Plugins.Oracle.CustomQueriesPath=/etc/zabbix/oracle/sql/

With this configuration, the Oracle plugin knows exactly where to find your custom SQL scripts.

Afterward, restart the Zabbix Agent 2 service:

systemctl restart zabbix-agent2

Setup Zabbix template

In your Oracle template, create a new Zabbix agent item using the following key:

oracle.custom.query[“{$ORACLE.CONNSTRING}”,”{$ORACLE.USER}”,”{$ORACLE.PASSWORD}”,”{$ORACLE.SERVICE}”,last_inc0]

Make sure that:

• the query name matches your SQL file name (last_inc0.sql),
• and the preprocessing steps are correctly configured.

Once the item becomes active, Zabbix immediately starts collecting the timestamp of the latest level 0 backup.

• And now you can see your last backup time. Then you just have to create a trigger with this item and you have finished !

Conclusion

By using custom Oracle queries with Zabbix Agent 2, you can quickly extend the default Oracle monitoring capabilities with very little configuration effort.

More importantly, this approach helps you detect backup issues early before the FRA fills up and impacts production systems.

Because the solution remains fully customizable, you can easily extend it later to monitor additional RMAN metrics that match your operational requirements.

You can find other blog regarding Zabbix with this link.

L’article Zabbix – Oracle backups monitoring est apparu en premier sur dbi Blog.