Learn Zabbix - Monitoring Infrastructure: Network, Cloud & Applications

#Introduction

For twelve episodes, you've monitored Linux hosts. Episode 13 widens the scope to the whole infrastructure: network devices that can't have an agent installed, cloud platforms that are abstracted, applications that only speak HTTP, and containers that come and go. Zabbix handles all of this through a combination of protocols and templates.

This is the widest-scope episode in the third phase. The goal isn't to memorize every template, but to understand the pattern: how Zabbix talks to devices that have no agent, and how official templates map external platforms into Zabbix objects.

#Network Monitoring with SNMP

#SNMP v1, v2c, and v3

Network devices — switches, routers, firewalls — generally can't have a Zabbix agent installed. The standard protocol used is SNMP:

• v1: an old version, with community strings as credentials.
• v2c: the most common, efficient and widely supported.
• v3: with authentication and encryption, recommended for production.

SNMP items use OIDs, not keys. An OID like 1.3.6.1.2.1.1.3.0 represents device uptime.

#Testing the SNMP Connection

Before adding an SNMP host to Zabbix, test access from the server:

snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.1

The command snmpwalk -v2c -c public 192.168.1.1 displays all variables under a given OID. If snmpwalk succeeds, the SNMP host is ready to be added to Zabbix; if not, the problem is in the credentials, SNMP version, or reachability.

#ICMP Ping and Network Performance

For network availability and quality, Zabbix provides ICMP items: icmpping for status, icmppingloss for the percentage of lost packets, and icmppingsec for latency. These items are collected by the server with no agent at all — the cheapest way to monitor devices that don't support SNMP. The average icmppingsec value can be used in a network quality trigger, for example when latency crosses a certain threshold.

#Cloud and Application Monitoring

#Cloud Platform Templates

Zabbix provides official templates for AWS, Azure, and GCP. These templates use API integrations: Zabbix pulls metrics from the cloud provider and converts them into items. Instead of monitoring instances one by one, you monitor managed metrics such as load balancers, managed databases, and autoscaling groups.

Usually you'll need to provide credentials or a role with read-only permission in the cloud account, such as an AWS IAM role or an Azure service principal. Complete configuration depends on the provider, but the general pattern is the same: the template collects metrics, preprocessing cleans them, and triggers assess the thresholds.

#Application Monitoring: HTTP, JMX, and Databases

Modern applications are monitored through several paths:

• HTTP agent: requests an API endpoint and checks the status code, response time, or parses JSON.
• JMX: Java metrics via the Zabbix Java gateway for JVM-based applications.
• Database monitoring: database-type items execute SQL queries against MySQL or PostgreSQL.

curl -s -o /dev/null -w "%{http_code}" https://app.example.com/health

The command curl -s -o /dev/null -w "%{http_code}" only prints the HTTP status code. An HTTP agent item in Zabbix does the same thing periodically — and feeds application availability triggers.

JVM applications, meanwhile, use the Zabbix Java gateway to fetch JMX metrics. Make sure the gateway is running before enabling JMX items:

systemctl status zabbix-java-gateway

The command systemctl status zabbix-java-gateway shows the gateway status. Without an active gateway, JMX items will show collection errors in Latest data.

#Container Monitoring

#Docker and Kubernetes

Containers demand dynamic discovery, and this is where episode 11's LLD shines. The Docker by Zabbix agent 2 template uses agent2 plugins to collect container metrics: CPU, memory, network, and status. The Kubernetes template monitors the cluster through nodes, pods, and the API server.

node → kubelet + pod metrics on the node
pod  → status and resource usage
cluster → API server availability and latency

Kubernetes metrics require an agent service running inside the cluster. The deployment details depend on the Zabbix version, but the official template provides complete instructions and ready-to-use items. Keep in mind that container metrics are collected per namespace — Zabbix can distinguish resources used by containers from resources used by hosts separately.

#Building a Multi-Layer Strategy

Real infrastructure needs a combination of all paths:

• Agent for hosts that can have an agent installed.
• SNMP and ICMP for network devices.
• HTTP, JMX, and database queries for applications.
• Cloud templates for managed services.
• LLD + container templates for Docker and Kubernetes.

Each path has an official template that can be a starting point. What determines monitoring quality isn't how many protocols are used, but how accurately you choose the right path for each layer.

#Closing

Episode 13 widened the monitoring scope: SNMP v1/v2c/v3 and ICMP for networks, AWS/Azure/GCP templates for cloud, HTTP and JMX for applications, and Docker and Kubernetes templates for containers.

Key takeaways:

• Network devices are monitored with SNMP; test first with snmpwalk.
• ICMP ping is the cheapest way to monitor availability and network quality.
• Cloud templates leverage provider APIs for managed metrics.
• HTTP agent, JMX, and database monitoring cover the application layer.
• Containers use LLD and Docker or Kubernetes templates.

In the next episode 14 we'll discuss Zabbix API and automation — the JSON-RPC protocol, authentication with API tokens, host, item, trigger, and alert operations via the API, and automation with zabbix-cli, Terraform, and Python pyzabbix.