Zabbix Azure Monitoring: What Works, What Doesn't, and When to Walk Away

Zabbix is one of the best open-source monitoring platforms for on-prem infrastructure. The moment you point it at Azure PaaS services — App Services, Functions, Logic Apps — things fall apart. Not because Zabbix is bad. Because Azure’s platform services weren’t what Zabbix was built to monitor, and the gap between “we have an Azure template” and “we can actually monitor our Azure environment” is wider than the documentation suggests.

This is a common pain point for teams running hybrid environments, and it’s worth understanding exactly where the boundaries are before you invest in a monitoring architecture that can’t see half your workloads.

What Zabbix Monitors in Azure Natively

Starting with Zabbix 7.x, the “Azure by HTTP” template suite covers more ground than most people realize. These templates authenticate via a service principal with Reader role access and pull metrics through the Azure Monitor REST API using OAuth 2.0. No agents required — it’s pure HTTP-based polling.

Out of the box, you get native templates for:

Virtual Machines — CPU, memory, disk, network metrics
VM Scale Sets — instance-level and aggregate performance data
Azure SQL — DTU consumption, storage, deadlocks across Serverless, DTU-based, and Managed Instance types
MySQL and PostgreSQL Flexible Servers — connections, storage, compute
Cosmos DB — request units, availability, latency
Storage Accounts — capacity, transactions, latency by API operation
Cost Management — budget tracking and spend alerts

Setup is straightforward: register an app in Entra ID, assign it the Reader role on the subscriptions you want to monitor, plug the client ID, secret, and tenant ID into the Zabbix template macros, and you’re pulling metrics within minutes. For organizations whose Azure footprint is mostly VMs and managed databases, this works well.

The PaaS Gap

Here’s where it breaks down. There are no native Zabbix templates for:

App Services — no CPU percentage, memory working set, request counts, HTTP 5xx rates, or response times
Azure Functions — no execution counts, duration, failure rates
Logic Apps — no run success/failure metrics
API Management — no request throughput, backend latency, or capacity metrics
Event Hubs and Service Bus — no message counts, throttled requests, or queue depth

For organizations running modern Azure workloads — and most are deploying more PaaS, not less — this is a critical gap. You can see your VMs fine. You’re blind to the application layer sitting on top of them.

Three Approaches People Try (and Their Trade-offs)

Teams committed to Zabbix usually end up building custom solutions for PaaS monitoring. Each approach has real trade-offs.

1. Cron scripts pushing to Zabbix Sender

The simplest approach: write a script that calls the Azure Monitor API, parses the response, and pushes values to Zabbix via zabbix_sender. Works for monitoring a handful of specific resources. Falls apart at scale — you’re hard-coding service names, managing one-off scripts per resource type, and there’s no per-service polling interval control. When someone spins up a new App Service, your monitoring doesn’t know about it until you update the script.

2. External checks with macros

More structured than raw scripts. You define external check items in Zabbix with macros for subscription ID, resource group, and resource name, making the checks templatizable. The problem is performance: every external check spawns a process on the Zabbix server or proxy. At volume — say, 50+ App Services each with 6-8 metrics — you’re spawning hundreds of processes per polling interval. Zabbix’s own documentation warns about this bottleneck.

3. LLD + Trapper items (the scalable approach)

The most robust option if you’re committed to Zabbix for PaaS. A script running outside Zabbix (on a VM, in a container, wherever) queries the Azure Resource Graph API to discover resources, then pulls metrics from Azure Monitor and pushes them to Zabbix via trapper items. Low-Level Discovery handles new resources automatically — no manual config changes when someone deploys a new App Service.

This works. It’s also a custom software project. You’re writing discovery rules, maintaining API authentication, handling pagination, managing rate limits, and debugging metric extraction failures. That’s a meaningful ongoing maintenance burden for something that other tools do natively.

The Azure SQL Problem

Azure SQL deserves its own callout because it’s the most common source of monitoring headaches, even with native templates.

The issue: Azure SQL comes in fundamentally different flavors — Serverless (auto-pause, dynamic compute), DTU-based (fixed performance tiers), and Managed Instance (full SQL Server engine in a managed wrapper). Each type exposes different metrics through the Azure Monitor API, and some API calls that work on one type fail silently on another.

Common failures include:

Serverless databases that auto-pause stop emitting metrics entirely — Zabbix sees this as a data gap, not a paused database
Scaling events change resource object names in the API, breaking monitoring configurations that reference the old resource ID
DTU vs vCore metrics use different measurement units and API paths, so a template that works for one type returns errors for the other

If you’re running a mix of SQL types (and most organizations are), expect to spend time tuning template macros and adding preprocessing steps to handle the inconsistencies.

When Zabbix Is the Right Call

The monitoring tool landscape for Azure looks like this:

	Best For	Azure PaaS Coverage	Cost	Self-Hosted
Zabbix	Hybrid on-prem + Azure IaaS	Limited (VMs, SQL, storage)	Free (OSS) + infra costs	Yes
Azure Monitor	Native Azure services	Full	Pay-per-use (can get expensive)	No
Datadog	Multi-cloud, full-stack observability	Extensive	Per-host + per-metric pricing	No
Prometheus + Grafana	Kubernetes-native workloads	Moderate (via exporters)	Free (OSS) + infra costs	Yes

The decision matrix:

Hybrid on-prem + Azure VMs — Zabbix wins. Unified dashboard for physical servers, network gear, and Azure VMs with low total cost of ownership. This is Zabbix’s sweet spot.
Azure PaaS-heavy environments — Azure Monitor or Datadog. The native integration eliminates the custom scripting tax entirely.
Kubernetes-native workloads — Prometheus + Grafana. Purpose-built for container orchestration metrics.
Compliance environments (GCC High, IL4/IL5) — Zabbix for infrastructure monitoring paired with Azure Monitor for PaaS. Zabbix stays inside your boundary; Azure Monitor handles the platform layer. This dual-stack approach is common in defense contractor environments where you need both infrastructure visibility and PaaS telemetry.

Making Zabbix Work If You’re Committed

If Zabbix is your platform and you’re extending it into Azure PaaS, these practices will save you pain:

Deploy Zabbix proxies in Azure — Put proxies in the same region as your monitored resources to reduce API latency and keep polling traffic off your WAN link
Use LLD + trappers for PaaS — Don’t fight the external check performance wall. Run discovery scripts externally and push via trappers
Implement throttling preprocessing — Azure Monitor API has rate limits (12,000 requests per hour per subscription). Add preprocessing steps that throttle polling intervals based on resource count
Test template compatibility before production — Stand up each Azure SQL type in a dev subscription and validate that the templates actually return data for your specific configuration
Monitor your monitoring — Set up alerts on Zabbix item error rates. A template that silently fails is worse than no template at all

Bottom Line

Zabbix is an excellent monitoring platform for Azure IaaS and hybrid environments. For PaaS-heavy workloads, you’re looking at either a significant investment in custom scripting and ongoing maintenance, or pairing Zabbix with Azure Monitor to cover the gaps.

There’s no shame in a dual-stack approach. The organizations with the best visibility into their Azure environments usually aren’t running a single tool — they’re running the right tool for each layer.

If you’re designing a monitoring architecture for a hybrid Azure environment — especially one with compliance requirements — let’s talk. We’ll help you figure out where Zabbix fits, where it doesn’t, and what fills the gaps.