How Grafana connects to an existing Zabbix estate
The supported way to build Grafana dashboards on an existing Zabbix estate is the Zabbix app plugin, alexanderzobnin-zabbix-app, which queries the Zabbix API. Grafana reads from Zabbix through that API, and an optional direct database connection can be added for queries the API cannot serve well. The plugin is an *app plugin*, so it must be installed and then enabled in Grafana before any Zabbix data source can be configured. Zabbix itself is not changed: no agent, template or server setting has to be modified to make the data visible, because the plugin only reads what the API already exposes to the user it authenticates as.
The plugin covers the functions most teams ask for first: metrics queries with template variables for host groups, hosts and items, a problems panel that shows current problems and triggers, SLA data for IT services, annotations created from Zabbix events, and alerting from Grafana on the queried metrics. Each of these depends on what the API user can see, so the decision that shapes the whole integration is the scope of that account. Confirm which host groups the dashboards must cover, and give the account read permission on those groups only. Confirm the Grafana version you run against the plugin's stated minimum before installation, and confirm the Zabbix version against the plugin release notes, since the Zabbix line in use determines which API behavior and database options apply.
Choose between the API path and the direct database path early, because they carry different risks. The API path respects Zabbix user permissions and needs no database credentials in Grafana, which suits most estates. The direct database connection can return data the API does not expose conveniently, but it bypasses Zabbix permission checks and adds a read-only database account to manage, so it should be justified by a specific panel or query. Ask the team that owns Zabbix to confirm the server version, the API endpoint Grafana can reach, and whether a separate integration user is permitted under their access policy before any dashboard work starts.
What the integration needs before installation
The Zabbix app plugin depends on four things lining up: a Grafana version that supports it, a Zabbix server that exposes its API, a read-only Zabbix user scoped to the right host groups, and network paths that let Grafana reach those services. Confirm each one in your own environment before you install anything.
Grafana version floor
The Zabbix data source requires Grafana 11.6.0 or later. Check the version your team runs today, and if it is older, plan the Grafana upgrade as its own step before the plugin work. Also check which Grafana edition and packaging you use (Debian or Ubuntu packages, RHEL, containers or Helm), because the upgrade path and the plugin install steps differ between them. Confirm the version with the Grafana upgrade notes for your target release.
Zabbix API access
The plugin reads metrics, problems, triggers, SLA data and events through the Zabbix API, so the Zabbix server must expose that API to Grafana. Confirm that the API endpoint is reachable from the Grafana host, that the web frontend and API are served over the protocol you intend to use, and that no proxy or firewall rule blocks the API path. Ask the Zabbix administrator who owns the frontend configuration to confirm the endpoint URL before you configure the data source.
Read-only Zabbix user
Create a dedicated Zabbix user for Grafana with read permissions only on the host groups you plan to query. Permissions in Zabbix are granted per host group through user groups, so a user with access to everything will expose data that dashboards do not need. Keep the user out of administrative roles, and record which host groups it covers so that a dashboard missing data can be traced to the permission boundary rather than to the plugin.
Database connection path
The direct database connection is optional, but if you use it, Grafana needs a network path to the Zabbix database host and a read-only database account. Decide before installation whether dashboards need that path at all, since the API covers most panels. If you do open it, restrict the source address to the Grafana hosts and confirm the database engine and version with the Zabbix administrator, because the supported database list depends on the Zabbix release.
Zabbix release and database match
The Zabbix version and its database must both appear on the Zabbix requirements page for the release you run. Check the Zabbix server release, the database engine and its version, and whether the environment uses high availability or proxies. Support windows differ by release, so note the full and limited support dates for your version and compare them with your upgrade plan. Confirm all of these in your own environment, not from memory of an earlier release.
Network paths and firewall rules
List every connection the Grafana host needs before the change request: outbound HTTP or HTTPS to the Zabbix frontend and API, optional database access, and any name resolution the endpoint requires. Plan for the Zabbix server and any proxies that Grafana does not call directly but that feed the data. Record the source addresses, ports and TLS certificate chain so that the network team can approve the rules once instead of during the installation window.
Configuration sequence for the Zabbix app plugin
This sequence takes a Grafana instance from no Zabbix connection to a working data source, a dedicated read-only API user and first dashboards with a problems panel. Each step ends with a check you can run before moving on.
Confirm Grafana and Zabbix versions
Before installing anything, confirm that your Grafana version is 11.6.0 or later and that your Zabbix server is reachable with API access enabled. The Zabbix data source requires this Grafana floor, so an older instance has to be upgraded first. Record the Zabbix version too, because the API and database requirements differ across Zabbix releases, and check the supported database versions for your Zabbix build. Done means you have written down both versions and can open the Zabbix frontend and its API endpoint from the Grafana host.
Install the Zabbix app plugin
Install the plugin with alexanderzobnin-zabbix-app as the plugin ID, using the method your deployment already uses, such as the Grafana CLI, a container image that bundles plugins, or a provisioned plugin directory. The plugin is an app plugin, so it is not active the moment the files arrive. Check that the plugin appears in Grafana's plugin catalog or plugin directory on the host. Done means the plugin is present with a version string, even though it is not yet enabled.
Enable the app after installation
Open the plugin's configuration page in Grafana as an administrator and enable the app. Until it is enabled, its data source type and its panels do not appear when you create dashboards, which is a common cause of confusion during first setup. If your instance loads plugins from a configuration file, confirm that plugin allow-listing does not block the app ID. Done means the Zabbix app shows as enabled and the Zabbix data source type is available in the data source picker.
Create a dedicated read-only Zabbix API user
In Zabbix, create a user for Grafana with read permissions only, and give it read access to the host groups you intend to chart. Do not reuse an administrator account or a personal login. Document the user, the host groups, and the authentication method you choose, and confirm the user's permissions in the Zabbix frontend by logging in as that user and browsing the intended host groups. Ask your Zabbix administrator to confirm how Zabbix authentication settings apply to API logins, including any LDAP or SAML behavior on the Zabbix side. Done means the Grafana user can see the target host groups and nothing outside them.
Create the Zabbix data source connection
Add a new data source of type Zabbix in Grafana. Enter the Zabbix API URL, which normally ends in the api_jsonrpc.php path on your Zabbix frontend, then supply the read-only user's credentials. Choose the authentication options that match how your Zabbix frontend is served, including TLS settings for internal certificates. Store the password in Grafana's data source secure fields rather than in plain configuration. Done means the form saves without errors and the stored URL points to the Zabbix API, not the general frontend page.
Test the connection and host group access
Use the data source Save and test action. A successful result confirms that Grafana reached the API and that the credentials were accepted. Then open Explore or a new panel, select the Zabbix data source, and browse the host group list. The groups you granted should appear, and groups you did not grant should not. If the test fails, check the URL path, TLS trust, and the API user's login status in Zabbix before changing anything else. Done means the test passes and the expected host groups appear in the query editor.
Build the first metrics dashboard
Create a dashboard with a time series panel that uses the Zabbix data source. Pick a known host in one of the granted host groups, select an item such as CPU or memory utilization that the host's template provides, and run the query. Add a template variable for host group and host if you expect operators to switch between systems. Done means the panel returns data points for the known host over the selected time range, which confirms that item queries and time handling work end to end.
Add the problems panel and verify active problems
Add a Zabbix problems panel to the same dashboard and scope it to the same host group. Compare the displayed problems with the Problems view in the Zabbix frontend for the same user and host group. The two lists should match in severity and host name. If the panel is empty while Zabbix shows problems, recheck the host group scope and the user's read permissions. Done means the problems panel reproduces the Zabbix Problems view for the scoped group, and you have recorded that comparison as evidence for the handover.
Zabbix objects mapped to Grafana panels and features
This table maps each Zabbix object to the Grafana panel, view or alert type that displays it, and notes whether the API user's host group permissions or a direct database connection controls what appears. Read the last two columns first when you plan the service account, because they decide whether a dashboard shows complete data or silently shows less.
| Zabbix object | Grafana feature | Depends on API user host groups | Needs direct database connection |
|---|---|---|---|
| Host groups | Query editor group filter and template variables | Yes | No |
| Hosts | Host filter, template variables and host-scoped metric panels | Yes | No |
| Items and metric values | Time series panels and metric queries through the API | Yes | No |
| Triggers | Trigger queries and trigger-based alert conditions | Yes | No |
| Problems | Problems panel listing current and recent problems | Yes | No |
| Events | Annotations created from Zabbix events on time series panels | Yes | No |
| IT services and SLA data | SLA views for service availability over a chosen period | Yes | No |
| Historical values beyond API limits | Long-range queries that the direct database connection serves | Not applicable | Yes |
| Alert rules | Grafana alert rules evaluated against Zabbix metric queries | Yes | Not applicable |
Why API permissions decide what dashboards show
The Zabbix plugin only sees what the Zabbix user it authenticates as is allowed to read. A missing host group permission does not produce an error. It produces empty panels, and an operator looking at a blank graph can easily assume the host is healthy or has no data. Before building any dashboard, confirm that the API user has read permission on every host group the dashboards will query, and test the scope with a known host in each group. The Grafana Zabbix data source documentation describes the read permission requirement, and the Zabbix authentication documentation explains how user roles and group permissions are assigned in the Zabbix frontend.
Plan the user's role and host group scope as a design step, not an afterthought. List the host groups behind each dashboard, decide which of them the Grafana instance may query, and map those groups to a Zabbix user role that grants read access without write or administrative rights. Confirm with the Zabbix administrators whether the role also needs access to problems, triggers and IT services, since the SLA and problems panels depend on those objects as well as on hosts. Expect the scope to change as new host groups are added, so agree who updates the permissions and how that change is tested before it reaches production dashboards.
A single shared service user for the whole Grafana instance is simple to run, but it is a security and audit decision to confirm with the Zabbix administrators rather than assume. One shared user means every Grafana viewer inherits the same Zabbix visibility, so per-team dashboards cannot be restricted through Zabbix permissions alone, and Zabbix audit logs will show one identity for all Grafana queries. The alternative is several narrower users, one per audience, which adds credential rotation work. Record the decision, the reason for it and the host groups each identity can read, so the Zabbix and Grafana owners can review it together.
Securing the Zabbix connection
The Zabbix data source gives Grafana a standing read path into your monitoring estate, so its access needs to be scoped deliberately. The cards below cover the Zabbix account, how Grafana stores its credentials, who can change the connection, the database path if you use one, and the Grafana settings that protect the instance itself.
Dedicated read-only Zabbix user
Create a separate Zabbix user for Grafana rather than reusing an administrator or an engineer's account. Grant it read permission only on the host groups its dashboards query, because the Zabbix data source needs read access to those groups and nothing more. Scope the user to the smallest set of groups that covers the planned panels, and review it whenever a new host group is added. Confirm the exact permission model for your Zabbix version in the authentication documentation before you assign roles.
Credentials in Grafana secrets
Enter the Zabbix API credentials into the data source's secure fields so Grafana stores them encrypted rather than in plain configuration. Avoid putting them in provisioning files committed to version control, and if you provision the data source as code, inject the secret from your secret store at startup. Rotate the Zabbix user's password on a schedule and after any staff change that touched the connection.
Restricting who can edit the data source
Anyone who can edit a data source can change its URL, credentials or query target, so limit that permission to a small platform group. Dashboard editors can still build panels on the connection without being able to alter how Grafana authenticates to Zabbix. Check this in your access model before onboarding dashboard authors, and confirm which role controls data source administration in your edition.
Least-privilege database users
If you use the direct database connection, create a dedicated read-only database user limited to the Zabbix tables the panels query. Do not reuse the account the Zabbix server uses to write history and trends, because a compromised Grafana could then alter monitoring data. Verify the database version and grants against the Zabbix requirements for your database engine, and test that the account cannot write.
Grafana security hardening settings
Apply the Grafana hardening controls to the instance that will reach Zabbix: secure and SameSite cookies, a Content Security Policy, Trusted Types, hidden version strings for unauthenticated users, authentication on the metrics endpoint, and domain verification against DNS rebinding. These settings protect the Grafana instance holding the Zabbix credentials. Review each one against your reverse proxy and TLS setup before enabling it in production.
Questions buyers ask before connecting Grafana to Zabbix
What drives the effort of connecting Grafana to an existing Zabbix estate?
The effort depends mostly on how much of the Zabbix estate you want to show and how well it is already organized. The main drivers are the number of host groups and templates to cover, how consistent item and trigger naming is across teams, and how many dashboards and template variables you need. Grafana itself must be running at version 11.6.0 or later for the Zabbix data source plugin, so an older Grafana install adds an upgrade step. Plan for plugin installation, enabling the Zabbix app plugin after installation, creating a Zabbix API user, testing each panel type you need, and documenting the result. Ask any partner to price these components separately in the written scope.
Can our own team connect Grafana to Zabbix without an outside partner?
A team with Grafana and Zabbix experience can usually complete a basic connection alone, because the plugin is installed, enabled and pointed at the Zabbix API with a read-only user. The harder parts are permission design, dashboard standards, alerting decisions and verification across your host groups. Check whether your staff have time for those tasks and whether they know both platforms well enough to troubleshoot API and permission errors. An outside partner can take on the build as a fixed-scope engagement with written deliverables, or support your team on specific parts such as access design or documentation.
What do our Zabbix administrators need to provide?
Your Zabbix administrators need to create or approve a dedicated Zabbix user for Grafana with read permissions on the host groups the dashboards will query. The Zabbix data source docs require API access and read permissions on those host groups, so administrators should confirm the API endpoint is reachable from the Grafana server and that the user cannot change configuration. They also need to confirm which Zabbix version is in use, since Zabbix 7.0 and later have different release and support timelines, and share the list of host groups, templates and problem severities that matter to each team. Agree on who owns the API user and its password rotation.
Is the direct database connection required for Grafana and Zabbix?
No. The Zabbix plugin can query metrics, problems, triggers, SLA data and annotations through the Zabbix API, and the direct database connection is an optional feature. Use the API path as the default because it respects Zabbix user permissions and needs no database credentials on the Grafana side. Consider the direct database connection only when a specific panel needs data that the API does not serve well and your DBA team accepts a read-only account with narrow grants. Confirm supported database versions in the Zabbix requirements before enabling it, since MySQL, MariaDB, PostgreSQL and TimescaleDB each have version ranges.
How does Grafana alerting differ from Zabbix's own alerts?
Zabbix alerts are triggered from Zabbix items and triggers and sent through Zabbix actions, while Grafana alerting evaluates queries on the data source and sends notifications through Grafana's own routing. The Zabbix plugin supports alerting, so you can build rules on metrics that Zabbix already collects. Decide which system owns each alert to avoid duplicate pages. Keep critical infrastructure alerts in Zabbix where its escalation and maintenance logic is already tested, and use Grafana alerts for cross-source views or for teams that work mainly in dashboards. Document the ownership rule before go-live, and check the Grafana Alerting high availability settings if you run more than one Grafana server.
What does a Zabbix support subscription cover, and what does it not cover?
A Zabbix support subscription covers vendor technical support for Zabbix itself, with tiers from Silver to Global that differ in hours and response times. Zabbix states its open source software has no license fee, no device limits and no feature gates, so support is a service purchase, not a license. A subscription does not cover the Grafana server, the Grafana Zabbix plugin, your dashboard design, your API user permissions or any custom integration work. Ask Zabbix which tier matches your hours and response needs, and ask any implementation partner which Grafana and plugin issues it will handle under its own scope.
Which Zabbix version should we plan around before the build starts?
Choose the Zabbix version based on its life cycle, because your dashboards and plugin behavior must be tested against it. Zabbix 7.0 LTS was released on 4 June 2024 with full support until 30 June 2027, and Zabbix 7.4 was released on 1 July 2025. Zabbix 8.0 LTS is planned for Q4 2026. If you run an older 6.0 LTS release, note that its limited support ends on 28 February 2027. Confirm the planned upgrade path with your Zabbix administrators, because a Zabbix upgrade can require a plugin or dashboard check in Grafana.
Common Zabbix connection failures and fixes
This table lists the failures teams most often hit when Grafana talks to Zabbix, with the likely cause and fix for each. Read it by symptom: find the empty panel, error or duplicate alert you see, then check the cause column before changing settings.
| Symptom | Likely cause | Fix |
|---|---|---|
| Empty panels for some hosts | The Zabbix user lacks read permission on the host groups the dashboard queries | Grant read access to every queried host group in Zabbix user permissions, then reload the dashboard and confirm the group appears in the query editor |
| Plugin shows a version or compatibility error | Grafana is older than the minimum version the Zabbix data source requires | Upgrade Grafana to 11.6.0 or later, then update the Zabbix app plugin to a release built for that Grafana version and restart the server |
| Plugin missing or not loading | The app plugin was installed but never enabled | Enable the Zabbix app plugin in the Grafana plugin settings, then add the data source and run Test to confirm the connection |
| Authentication or connection failed at test | Wrong API URL path, expired or incorrect credentials, or API access disabled for the user | Check the API endpoint URL, confirm the Zabbix user and password or token, and verify the account is allowed API access in Zabbix |
| Slow dashboards on large item sets | Queries span thousands of items, long time ranges or many template variables | Narrow host group and item filters, reduce time ranges, limit template variable values and set dashboard refresh intervals to match data needs |
| Duplicate alert notifications in HA Grafana | Each Grafana node evaluates alert rules and sends notifications independently | Follow the Grafana high availability alerting guidance, configure alerting so only one node sends notifications, and test with a controlled alert |
| Direct database connection errors | Database user lacks read privileges on Zabbix tables, or the database host, port or TLS settings are wrong | Create a read-only database user with select rights on the Zabbix schema, confirm network access from Grafana, and check the connection settings against the database requirements |
Keeping Grafana and Zabbix available together
Availability is the first thing to plan for, because the two systems fail over on different clocks. Zabbix server supports a native high availability cluster in which several server nodes share one database, one node is active and the others stand by. Failover starts when the active node exceeds a configurable failover delay, which can be set anywhere from 10 seconds to 15 minutes. Decide that value with your operations team before go-live, since a short delay causes more switchovers during brief network interruptions and a long one leaves monitoring blind for longer. Confirm which Zabbix server and database versions your estate runs against the Zabbix high availability documentation, because the cluster behavior is tied to the server configuration you deploy.
On the Grafana side, high availability requires two or more active-active servers behind a load balancer, sharing a MySQL or PostgreSQL database. SQLite is not suitable for production or high availability, so the database choice is a prerequisite rather than an option to add later. Auth tokens are stored in the database so users can reach any node. Alerting needs additional configuration to avoid duplicate notifications from several nodes, and Grafana Live has limitations in a high availability setup. Plan the database, load balancer and alert routing together, and treat the Grafana cluster and the Zabbix cluster as separate failure domains with their own monitoring.
Before you rely on either cluster, test the failure you actually expect. Stop the active Zabbix server node during a controlled window and record how long panels show stale or no data, whether the Zabbix data source reconnects without a manual Grafana change, and whether problem and trigger panels still reflect current state after recovery. Confirm the same for a Grafana node restart behind the load balancer. Ask your Zabbix partner or the Grafana documentation what happens to annotations and alert evaluation during the switch, and document the expected dashboard behavior so on-call staff know whether a gap is a monitoring fault or an expected failover.
How DeployOpen scopes and delivers the Zabbix integration
DeployOpen plans, builds, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Grafana and Zabbix integration runs in your cloud accounts, data centers or air-gapped network. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory the Zabbix version, database backend, host groups and templates that Grafana will query.
- Agree which panels, problem views, SLA reports and annotations the written scope covers.
- Confirm the Grafana version, plugin installation path and the Zabbix API user permissions needed.
How we build
- Install and enable the Zabbix app plugin, then verify the data source connects to the Zabbix API.
- Build dashboards for metrics, problems and triggers, with template variables scoped to host groups.
- Test alert rules and event annotations against known Zabbix events before they reach on-call channels.
How we hand over
- Document the data source configuration, API user permissions, dashboard ownership and alert routing.
- Provision data sources and dashboards as code where your Grafana setup supports it, so changes stay reviewable.
- Walk your operators through dashboard use, troubleshooting steps and the upgrade checks for Grafana and the plugin.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover plugin and Grafana upgrades, checks after Zabbix version changes and dashboard maintenance.
- Confirm response expectations and included upgrade work in the written retainer scope before signing.
