The Grafana Zabbix plugin is two programs in one repository

What the datasource adds on top of raw Zabbix metrics

The feature list in the README is short enough to read closely, and two items stand out as genuinely Zabbix specific rather than generic Grafana functionality. The first is the Triggers panel, which displays active problems rather than numbers. In a monitoring system where Zabbix holds the alerting rules, this is the piece that brings an operator's existing mental model into the dashboard instead of asking them to rebuild it as Grafana alerts.

The second is metric processing functions applied after the query returns: Avg, Median, Min, Max, Multiply, Summarize, Time shift and Alias. These sit between Zabbix and the panel, which matters because Zabbix history storage has different resolution and retention characteristics from a time series database. Time shift in particular is the kind of function that exists because comparing two Zabbix series at different offsets is awkward, and the plugin puts it in the panel rather than in your head.

Also worth noting for anyone assembling a mixed estate: the README states you can combine metrics from multiple data sources in the same dashboard or the same graph. Zabbix metrics can therefore sit beside Prometheus metrics on one panel, which is the usual reason to adopt this plugin rather than staying inside the Zabbix frontend.

Installing the datasource and the name mismatch to expect

Installation is a single CLI call, and the identifier is worth noting because it does not match the repository name:

grafana cli plugins install alexanderzobnin-zabbix-app

The repository lives under the grafana organisation and the README badge points at a maintained release stream, but the plugin identifier remains `alexanderzobnin-zabbix-app`, and the documentation URL is built from that same identifier. Anyone writing provisioning files, Terraform or a dashboard JSON export needs the plugin id, not the GitHub path, so the mismatch is a routine source of confusion on a first install.

The README then sends you to two separate destinations. Configuring the data source is one page, and the step by step getting started guide is another. There is also a live demo instance at play.grafana-zabbix.org, which is the fastest way to see what the Triggers panel and the processing functions actually look like before you have a Zabbix server to point at.

Why there is a Go backend behind a TypeScript frontend

This is the structural fact that explains the rest. Grafana datasources are split into a frontend running in the browser and an optional backend process running next to the Grafana server, and this plugin uses both. The repository tree has the usual TypeScript layout at `src/`, with `tests/`, `playwright.config.ts`, `webpack.config.ts` and `jest.config.js` on the frontend side. Alongside it sits `pkg/`, a Go module, plus a `Magefile.go` and `go.mod`.

The Go module declares its path as `github.com/alexanderzobnin/grafana-zabbix`, so the Go import path did not move when the repository moved into the Grafana organisation. That is harmless in practice because it is internal to the build, but it is the kind of detail that confuses anyone grepping for the backend source.

Its dependency list explains what the backend actually does. It pulls in the Grafana plugin SDK for Go, a JSON parser, `regexp2` for the regular expression based multi-metric selection the README advertises, an in-process cache, and the Prometheus client library. Those last two are the interesting ones: a cache means repeated panel refreshes can be served locally, and the Prometheus client means the backend can expose its own metrics rather than being a black box inside Grafana.

The frontend side is pinned to Grafana 13.1.1 packages and React 18.3.1, with rxjs 7.8.2 for the query stream. Those pins are the upgrade constraint: the plugin tracks the Grafana major version closely, which is the right call for compatibility and the reason a big Grafana jump wants a plugin release checked first.

Bearer tokens and how the plugin handles Zabbix permissions

One feature deserves its own paragraph because it is the one with real architectural consequences. The README describes per user authentication using Bearer tokens, so that Grafana respects the RBAC on Zabbix.

The alternative would be a single shared Zabbix account configured on the data source, which is simpler to set up and quietly wrong: everyone viewing the dashboard would see whatever that one account can see, and no Zabbix role would be honoured. Forwarding each Grafana user's own credentials makes the Zabbix permission model the effective one, so a viewer without access to a host does not gain access by being in the Grafana organisation.

The trade is that this path talks to Zabbix per user rather than per data source, so Zabbix has to accept the tokens and the token has to be supplied somehow, whether by the user, by a login flow, or by an external system. That mechanism is a configuration question rather than a code one, and the configuration page is where it is answered. What matters for an evaluation is knowing that the simple shared-account setup and the correct RBAC setup are not the same configuration.

The compose stack that development and end to end tests share

The repository ships a canonical environment described in its own comments as a real Zabbix backend plus Grafana with the plugin, seeded with deterministic fixture data, used both for local development and by the Playwright workflow. Bringing it up is an npm script:

npm run server
docker compose --file ./devenv/default/docker-compose.yml down

The compose file is more informative than it looks. It pins a PostgreSQL 18 image by digest and raises `max_connections` to 200, which is a Zabbix requirement rather than a Grafana one. The Zabbix version is switchable through the `ZABBIX_VERSION` variable and defaults to 7.0, described in the file as the latest LTS. Separate services run the Zabbix server and the Zabbix web frontend, both on the PostgreSQL images.

The dependency graph is the part that shows real care. Grafana waits for the Zabbix web service to report healthy and for a data loader service to complete successfully, so tests never run against an empty backend. Without that ordering, a flaky suite that only looks like a plugin bug is a common and expensive way to lose an afternoon.

Testing runs on three layers. Jest covers frontend units, Playwright drives the browser through the end to end path against that seeded environment, and the Makefile runs the Go suite under the race detector with a coverage profile written to `tmp/coverage/golang/`. The `test:ci` npm script and the `test-ci` make target are what continuous integration calls.

Cross compiled binaries and what the release cadence suggests

Because there is a Go backend, distribution is not a single JavaScript bundle. The Makefile builds the frontend with webpack and the backend with mage, and the dist targets cross compile the backend with `CGO_ENABLED=0` across several platforms, including dedicated targets for armv6, armv7 and arm64 on Linux, darwin and FreeBSD:

env CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6 go build -ldflags="-s -w" -o ./dist/gpx_zabbix-plugin_linux_arm ./pkg

The output filename pattern is what a Grafana plugin archive expects, so this build output is not an internal artifact but the shipped one. Turning off cgo is required for cross compilation and also means the backend has no cgo-backed dependencies to worry about on unusual architectures.

The release rhythm suggests a maintained project. Version 6.6.0 shipped on 2026-07-30, 6.7.0 on 2026-09-10 and 6.8.0 on 2026-09-21, with the last push on 2026-09-28. The package manifest already reads 6.8.1, which is the normal state for a repository between releases.

One more detail is easy to miss and says something about how the project is worked on now. The tree contains `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, a `.claude/` directory and a `.codex/` directory, alongside `cspell.config.json` and a spellchecker npm script. Instructions for several coding agents are committed to the repository as first class files, which tells you that a good share of the maintenance work is expected to happen through automated tooling with those documents as the brief.

Editorial conclusion

This plugin is worth adopting when Zabbix is already your monitoring system of record and you want its problem and metric history inside Grafana without migrating the data. The cost is a second runtime and a second set of version constraints, because the Go binary is cross compiled for Linux, macOS, Windows and FreeBSD while the frontend tracks Grafana package versions. Check two things before committing: whether your Zabbix version matches what the shipped backend was built against, and whether the Bearer token flow fits your user provisioning. Both are decisions the README does not make for you, and both surface in the configuration guide.

Frequently asked questions

Official sources

1. grafana/grafana-zabbix on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases