Zabbix 7.0 Synthetic Monitoring: A Game Changer for Web Performance Testing

Zabbix 7.0 Synthetic Monitoring: A Game Changer for Web Performance Testing

Good morning everyone, I'm Dimitri Bellini, and welcome back to Quadrata! This is my channel dedicated to the open-source world and the IT topics I'm passionate about – and hopefully, you are too.

In today's episode, we're diving back into our friend Zabbix, specifically version 7.0, to explore a feature that I genuinely believe is a game-changer in many contexts: Synthetic Monitoring. This powerful capability allows us to simulate and test complex user interaction scenarios on our websites, corporate pages, and web applications. Ready to see how it works? Let's jump in!

What Exactly is Synthetic Monitoring in Zabbix 7.0?

As I briefly mentioned, synthetic monitoring is a method used to simulate how a real user interacts with a web page or application. This isn't just about checking if a page loads; it's about mimicking multi-step journeys – like logging in, navigating through menus, filling out forms, or completing a checkout process.

While this concept might seem straightforward, having it seamlessly integrated into a monitoring solution like Zabbix is incredibly valuable and not always a given in other tools. (1:09-1:16)

The Key Ingredients: Zabbix & Selenium

To make this magic happen, we need a couple of key components:

• 
  Zabbix Server or Proxy (Version 7.0+): This is our central monitoring hub.


• 
  Selenium: This is the engine that drives the browser simulation. I strongly recommend running Selenium within a Docker container, ideally on a machine separate from your Zabbix server for better resource management.

Selenium is a well-established framework (known for decades!) that allows us to automate browsers. One of its strengths is the ability to test using different browsers like Chrome, Edge, Firefox, and even Safari, ensuring your site works consistently across platforms. Zabbix interacts with Selenium via the WebDriver API, which essentially acts as a remote control for the browser, allowing us to send commands without writing complex, browser-specific code.

For our purposes, we'll focus on the simpler Selenium Standalone setup, specifically using the Chrome browser container, as Zabbix currently has the most robust support for it.

How the Architecture Works

The setup is quite logical:

1. Your Zabbix Server (or Zabbix Proxy) needs to know where the Selenium WebDriver is running.


2. Zabbix communicates with the Selenium container (typically on port 4444) using the WebDriver protocol.


3. Selenium receives instructions from Zabbix, executes them in a real browser instance (running inside the container), and sends the results back.

If you need to scale your synthetic monitoring checks, using Zabbix Proxies is an excellent approach. You can dedicate specific proxies to handle checks for different environments.

The Selenium Docker container also provides useful endpoints:

• 
  Port 4444: Besides being the WebDriver endpoint, it often hosts a web UI to view the status and current sessions.


• 
  Port 7900 (often): Provides a VNC/web interface to visually watch the browser automation in real-time – fantastic for debugging!

Setting Up Your Environment

Getting started involves a couple of configuration steps:

1. Zabbix Configuration

You'll need to edit your zabbix_server.conf or zabbix_proxy.conf file and set these parameters:

• 
  WebDriverURL=http://:4444/wd/hub (Replace with the actual IP/DNS of your Selenium host)


• 
  StartBrowserPollers=1 (Start with 1 and increase based on workload)

Remember to restart your Zabbix server or proxy after making these changes.

2. Installing the Selenium Docker Container

Running the Selenium Standalone Chrome container is straightforward using Docker. Here’s a typical command:

docker run -d -p 4444:4444 -p 7900:7900 --shm-size="2g" --name selenium-chrome selenium/standalone-chrome:latest

• 
  -d: Run in detached mode.


• 
  -p 4444:4444: Map the WebDriver port.


• 
  -p 7900:7900: Map the VNC/debug view port.


• 
  --shm-size="2g": Allocate shared memory (important for browser stability, especially Chrome).


• 
  --name selenium-chrome: Give the container a recognizable name.


• 
  selenium/standalone-chrome:latest: The Docker image to use. You can specify older versions if needed.

Crafting Your Monitoring Scripts with JavaScript

The heart of synthetic monitoring in Zabbix lies in JavaScript. Zabbix utilizes its familiar JavaScript engine, now enhanced with a new built-in object: browser.

This browser object provides methods to interact with the web page via Selenium:

• 
  browser.Navigate('https://your-target-url.com'): Opens a specific URL.


• 
  browser.FindElement(by, target): Locates an element on the page. The by parameter can be methods like browser.By.linkText('Click Me'), browser.By.tagName('button'), browser.By.xpath('//div[@id="login"]'), browser.By.cssSelector('.submit-button').


• 
  element.Click(): Clicks on a previously found element.


• 
  browser.CollectPerfEntries(): Gathers performance metrics and, crucially, takes a screenshot of the current page state.

The output of these scripts is a JSON object containing performance data (response times, status codes, page weight) and the screenshot encoded in Base64.

Testing Your Scripts

You can test your JavaScript code before deploying it in Zabbix:

• 
  Zabbix Web Interface: The item configuration page has a "Test" button.


• 
  zabbix_js Command-Line Tool: Useful for quick checks and debugging.

  zabbix_js --webdriver http://:4444/wd/hub -i your_script.js -p 'dummy_input' -t 60

  
  (Remember to provide an input parameter -p even if your script doesn't use it, and set a reasonable timeout -t. Piping the output to jq (| jq .) makes the JSON readable.
  

Visualizing the Results in Zabbix

Once your main "Browser" item is collecting data (including the Base64 screenshot), you can extract specific pieces of information using:

• 
  Dependent Items: Create items that depend on your main Browser item.


• 
  Preprocessing Steps: Use JSONPath preprocessing rules within the dependent items to pull out specific metrics (e.g., $.steps[0].responseTime).


• 
  Binary Item Type: Zabbix 7.0 introduces a binary item type specifically designed to handle data like Base64 encoded images.

This allows you to not only graph performance metrics but also display the actual screenshots captured during the check directly in your Zabbix dashboards using the new Item History widget. Seeing a visual snapshot of the page, especially when an error occurs, is incredibly powerful for troubleshooting!

Looking Ahead

Synthetic monitoring in Zabbix 7.0 is a fantastic addition, opening up new possibilities for ensuring application availability and performance from an end-user perspective.

Here at Quadrata, we're actively exploring ways to make creating these JavaScript scenarios even easier for everyone. We might even have something to share at the Zabbix Summit this year, so stay tuned!