Zabbix Summit 2026

Zabbix Summit 2026

spectroman
spectroman
33 views

From Cars to Volcanos: Monitoring Ideas That May Give You an Advantage

Back on stage at a Zabbix event, this time at the Zabbix Summit 2026 in Riga (7-9 October), main track, 20 minutes. The deck I carried with me had a slightly cheekier name than the agenda did — "Is this cheating? Ideas that may give you advantage… over mere mortals" — and that question is the whole point of the talk.

Not monitoring of datacenters. Not uptime of production clusters. Monitoring of life: the stuff that is sitting around you, refusing to tell you what it is doing.


It Started With 10 Fingers

Skills and capacity evolve with the tech you use. For maths we all start with ten fingers, and then we move on:

  • Abacus
  • Calculators
  • Computers in general
  • Smartphones
  • Smartwatches
  • …and in my household, my wife, who controls the money and is therefore the purest source of truth

Every one of those steps felt like cheating to whoever came before it. The question I wanted to put to the room is where Zabbix sits on that list.


Chapter 1: Web-the-Check-Out or BUST

Remember the supply chain of a few years ago? Chips were scarce, nothing was in stock, waiting lists everywhere, and the only way to buy anything was to refresh a product page until your finger fell off.

I don't refresh pages. I have a monitoring server for that.

The first version was pure, old-school Zabbix web scenario:

  1. A web check that logs into the shop's product page
  2. A step in that scenario looking for the out-of-stock string
  3. A trigger that fires when that string is gone
flowchart LR WS[Zabbix Web Scenario] -->|step: fetch product page| P[Shop product page] P -->|required string present| OOS[Out of stock - no problem] P -->|required string missing| T[Trigger fires] T --> N[Notification to me] N --> CO[Check out before the humans do]

Months later the trigger went off. Stock replenished, mission accomplished, checkout time. One alert, one purchase, zero page refreshing.


What Changed: Zabbix Grew Up

The web has moved on, and so has Zabbix. Worth putting side by side:

Then Now
Basic HTML, then PHP (2000+) Client-side everything
Server-side rendering APIs and microservices (2010+)
Zabbix web scenario web.page.get, HTTP agent item
Single items Item prototypes, preprocessing, low-level discovery
Scraping strings out of HTML O.M.G. J.S.O.N.

That last line is the one that changes what is possible. Once a shop exposes its stock through an API, you are no longer scraping a page — you are querying a structured document, and Zabbix is very good at taking those apart.


Chapter 2: Building an IKEA Kitchen (A Real Nightmare)

Same problem, bigger stakes. An IKEA kitchen is hundreds of article numbers, and in the middle of a supply crunch half of them are on backorder. The house had a deadline. The kitchen did not care.

The manual version of this project is three steps:

  1. Make the project on IKEA
  2. Make the project for the builders
  3. Six months before the house is ready, buy the kitchen (or not, because nothing is available)

The Zabbix version is rather more satisfying:

  1. Work out what I need — the article numbers that matter
  2. Make Zabbix see it — an HTTP agent item against the availability API
  3. Focus the JSON — preprocessing to cut the payload down to the part that matters
  4. Discovery based on JSON — low-level discovery over the response
  5. Extract the store IDs — so I can ask about the shops I can actually drive to
  6. Build the item from that ID, fetching another part of the same JSON

Step 6 is where the whole thing hinges, and it is a single line of JSONPath:

$.[?(@.classUnitKey.classUnitCode == '{#STORE_ID}')].availableForClickCollect.first()

Read it right to left: for the store that discovery just found, give me the click-and-collect availability, and take the first value. That {#STORE_ID} macro is what turns one item into one item per shop, automatically.

flowchart TD API[IKEA availability API] -->|HTTP agent item| RAW[Raw JSON] RAW -->|preprocessing: JSONPath| FOCUS[Only the stock section] FOCUS -->|low-level discovery| LLD["Discovered stores: {#STORE_ID}"] LLD -->|item prototype| ITEM["availableForClickCollect per store"] ITEM -->|trigger prototype| TRG[Available! Go and get it] TRG --> ME[Notification + Magic Mirror]

The JSONPath preprocessing documentation is worth a read if you want to build the same thing — the function support in there is what makes .first() and friends possible.

Problem averted, item available. But that raises the honest question I put to the audience: is it really visible, and will I react in time? I do not glue my face to a monitor waiting for a trigger. Which is where the rest of the house comes in.


Chapter 3: Zabbix as an IoT Broker

If Zabbix already knows something, every other screen in the house should be able to know it too.

I wrote a MagicMirror module (it lives with the others at magicmirror.builders) that reads Zabbix triggers and puts them on the mirror in the hallway. Stock alert, house alert, anything — it is on the glass I look at while brushing my teeth. I have written that part up separately in Zabbix Alerts on Magic Mirror and Zabbix Graphs on Magic Mirror.

Once the mirror is a display for Zabbix, the obvious next move is to give Zabbix more to say. Sensors around the house, Raspberry Pis collecting, Zabbix storing everything.

flowchart TD subgraph House["Around the house"] INV[Solar inverter] BME[BME280 sensors] ADSB[ADS-B receiver] CAR[Car API] end RPI[Raspberry Pi + Zabbix agent] INV --> RPI BME --> RPI ADSB --> RPI CAR --> RPI RPI -->|items, preprocessing, triggers| ZBX[Zabbix Server] ZBX --> DASH[Dashboards] ZBX --> MM[Magic Mirror] ZBX --> NOTIF[Notifications]

Solar Power: Talking to the Inverter

The inverter sits on its own LAN with a wireless and an RJ45 leg, speaks its own protocol, and has a Python library. So the agent side is a user parameter wrapping a short script that dumps everything as JSON in one go, and Zabbix pulls the values apart with dependent items.

#!/usr/bin/python3.8

from huawei_solar import HuaweiSolar
from time import sleep
import json
import re

listtraps = ['model_name', ...]

inverter = HuaweiSolar('192.168.200.1', port="6607")  # replace with the correct address

json_output = {}

for trap in listtraps:
    reg_state = "^state_.*"
    json_output[trap] = str(inverter.get(trap).value)

print(json.dumps(json_output))

One poll, one JSON document, as many items as you care to carve out of it. The same pattern as the kitchen, pointed at the roof.


Temperature, Humidity, Pressure, Air Quality

The environmental side runs on BME280 sensors on Raspberry Pis, collected by a Python script, at one minute resolution. Fluctuation on the pressure reading sits around ±2 hPa, which matters for what comes next.

For air quality I hold the readings against the World Health Organization guidelines:

Particulate Threshold
PM 2.5 25 µg/m³ over 24h
PM 10 50 µg/m³ over 24h

Normalisation, or: sensors lie sometimes

Cheap sensors emit peaks. A single bogus spike will light up a trigger and teach everyone in the house to ignore alerts, which is worse than having none. Zabbix preprocessing earns its place here: validate that a value is in a sane range, discard or clamp what is not, and smooth the synthetic peaks before they ever reach a trigger.

The pressure trick

This one gets a reaction from every audience. When atmospheric pressure moves more than 20 hPa in 24 hours, it means one of two things: a major storm or a serious weather change is coming — or it is about to trigger a migraine in people sensitive to pressure swings. My wife is one of them. A monitoring system that warns her before her head does is not a gimmick.


Dashboards, Planes and Cars

The rest of the talk was the fun inventory:

  • Zabbix dashboards for systems — the normal half of my life
  • Zabbix dashboards for the environment — the house, the roof, the air
  • ADS-B collecting and monitoring — aircraft transponders picked up at home, collected and graphed like any other metric
  • Automotive API observation — the car has an API, therefore the car is a host

None of this is what Zabbix was designed for. All of it works, because an item is an item and a trigger is a trigger, whether the thing on the other end is a database or a heat pump or a Boeing passing overhead.


So… Is It Cheating?

New tools, advanced social living… or cheating?

Zabbix lets you collect data easily, evaluate it, and make sense of the world around you. You end up with an edge over the people who did not build the same informational advantage — knowing a product is back in stock before the shop announces it, knowing the kitchen can finally be ordered, knowing the storm is coming before the sky says so.

It feels a lot like cheating at life. I am entirely comfortable with that.


Conference Page — Zabbix Summit 2026

At the Youtube

Related Posts

Zabbix Alerts on Magic Mirror
MagicMirrorJavaScriptzabbix

Zabbix Alerts on Magic Mirror

Magic Mirror Module that reads and displays Zabbix Alerts / Triggers

3/27/2026Read More →
Zabbix Conference 2013
zabbixlinuxperlmonitoring

Zabbix Conference 2013

Long-Short story of Perobbix a Oracle Database Monitoring tool for Zabbix

4/30/2026Read More →
Zabbix Summit 2019
monitoringzabbixlinuxMysqlElasticsearch

Zabbix Summit 2019

Describing a Multi-datacenter project with Zabbix and FOSS eco-system

5/23/2026Read More →