Zabbix database monitoring with agent 2 plugins

Zabbix agent 2 includes several database plugins in the agent binary, among them MySQL, Oracle and Redis. Since Zabbix 6.0, some plugins are loadable plugins that you install separately, and the list includes MongoDB, MSSQL and PostgreSQL. The same split applies to other plugins such as Ember+ and NVIDIA GPU. Before you design packaging, confirm the current plugin list and the package names for your operating system in the Zabbix agent 2 plugins documentation, because the built-in and loadable sets are what determine your work.

A loadable plugin adds an operational step that a built-in plugin does not. You must install a package for each host that runs the database, keep its version matched to the agent 2 version, and include it in every agent upgrade. A plugin that lags behind the agent can fail to start or fail to collect data, so the upgrade runbook should name the plugin package alongside the agent and test both together in a staging environment before rollout. Ask your Zabbix support provider or review the release notes for each upgrade to confirm which plugin versions the agent expects.

The most common gap appears when a host image lacks the loadable plugin. The agent starts without errors, the host shows as available, and the database items on a PostgreSQL or MSSQL host return unsupported or no data. Unless someone checks item states, the gap can stay hidden until a database outage goes unreported. Include the plugin in the golden image, add a check that confirms the plugin is present, and create a test item for each loadable plugin so that a missing package shows up as a problem during provisioning rather than during an incident.

Inventory each database host before you plan packaging. For each host, record the engine, the exact version, the agent 2 version, whether the engine's plugin is built in or loadable, the source of the package, and whether the image already includes it. For example, a host running PostgreSQL and Redis (illustrative) needs the loadable PostgreSQL plugin and uses the built-in Redis plugin, so the packaging list has one extra item for that host. Engine version matters too, because PostgreSQL 14 and the other supported lines have different end-of-support dates, and that affects the upgrade plan for the same hosts.

Before you build PostgreSQL items in Zabbix, confirm which major version you run and whether it will still be supported for the life of the monitoring design. The supported majors are 18, 17, 16, 15 and 14. According to the PostgreSQL versioning policy, PostgreSQL 14 is supported until November 12, 2026, PostgreSQL 15 until November 11, 2027, PostgreSQL 16 until November 9, 2028, PostgreSQL 17 until November 8, 2029 and PostgreSQL 18 until November 14, 2030. Versions 13 and earlier are unsupported. Plan your monitoring review around these dates, because a major upgrade is the change most likely to alter what the PostgreSQL plugin reads.

Minor releases are the routine case. PostgreSQL minor releases never change the internal storage format, so applying one means replacing the executables and restarting the server. In most environments the monitoring role, its grants and the agent 2 PostgreSQL plugin configuration carry over unchanged. Still, confirm after each minor patch that the agent's connection check and a sample of items return values, since a restart can expose a changed connection setting or an expired password that was not visible before.

Major upgrades need more care. The PostgreSQL upgrading documentation describes three routes: dump and restore with pg_dumpall, pg_upgrade, and logical replication. Each route can change the statistics views and system catalogs that the plugin queries, and a new major version can add, rename or reshape columns. After cutover, check the templates and items that depend on those views, not only whether the server answers. Look for items in a not-supported state, values that have flatlined at zero and triggers that never fire.

PostgreSQL 18 changes the upgrade calculation somewhat. Its pg_upgrade retains planner statistics across major upgrades, which means the optimizer does not start cold, and it adds parallel jobs and a --swap option. That helps query performance after cutover but does not remove the need to verify monitoring, because the catalog changes are separate from the statistics. If you move to PostgreSQL 18, compare the item keys in your existing templates against the new server's views before the cutover window closes.

Logical replication is the option when downtime must be minimal. The PostgreSQL documentation states that it works between different major versions and allows a major upgrade with only several seconds of downtime. The monitoring cost is a second cluster with its own agent configuration, so the new instance needs the monitoring role, items and triggers before the switch. Whichever route you take, rerun item discovery and review every trigger after any major change, and record the result so the next upgrade starts from a verified baseline.

Do not treat a database item as reliable until someone has checked its value against the database it describes. Start with a per-engine test pass. For each MySQL, PostgreSQL, MongoDB, MSSQL, Oracle and Redis target, run the relevant agent 2 plugin item through the Zabbix frontend test or the agent's test mode, and confirm that it returns a value of the expected type with no error text. Record the plugin name, the agent 2 build, the connection parameters and the key used. For PostgreSQL, MongoDB and MSSQL, also confirm that the loadable plugin is installed on the agent host and loads without error, because a missing plugin often looks like an item that simply never receives data.

Next, compare the returned values with a direct query on the same database, run by a DBA or an engineer with equivalent read access. Choose a small set of items that cover different behavior, such as connection counts, uptime, database size, replication state or cache hit figures. Run the native query at about the same moment as the agent test, then note whether the two results agree within the tolerance your team sets for that metric. Where they differ, check the item's units, its preprocessing steps and the monitoring account's privileges before changing any threshold.

Then check discovery and per-database items. Where a template uses low-level discovery to create items for each database, schema or instance, compare the discovered list with the databases the engine reports, and confirm that excluded system or test databases are absent by design. Confirm that the monitoring user can see every database it should, since a restricted account can produce a complete-looking list that omits some databases without any error. Finally, run a controlled trigger test: cause a known, harmless condition in a non-production environment or an agreed window, confirm that the problem opens with the expected severity, that notifications reach the right people, and that the problem resolves when the condition clears.

The reason for this effort is that unverified items fail in two directions. A broken item can leave a silent gap, where a database is down or unreachable and no problem is raised because no data arrives to evaluate. A misread item can produce false problems, which train operators to ignore alerts. Keep the verification record with the host configuration and the date each check was run, and repeat the relevant checks after plugin, agent or database upgrades. This record gives operations reviews concrete evidence of what was tested, what was found and what was accepted as a known limitation, and it shows auditors how monitoring coverage was confirmed.