Tag Archives: Zabbix 7.0 LTS

An Introduction to Browser Monitoring

Post Syndicated from Alexander Petrov-Gavrilov original https://blog.zabbix.com/an-introduction-to-browser-monitoring/29245/

Website and web application monitoring can vary from simple use cases to complex multi-step scenarios. To fully cover the scope of modern website monitoring requirements, Zabbix has introduced Browser item, a new item type that brings with it multiple accompanying improvements for simulating browser behavior and collecting website metrics.

What is browser monitoring?

Browser monitoring allows users to monitor complex websites and web applications using an actual browser. It involves the constant tracking and analysis of the performance, reliability, and functionality of a website or web application from a real user perspective. This process ensures that key pages, features, and user navigation work as expected. By monitoring critical pages and flows specific to different businesses, companies can ensure optimal user experience, resolve potential or ongoing issues, and proactively address any potential problems.

Browser monitoring can be split into two main approaches:

  • Browser real user monitoring – Monitors how your web page or web application is performing, using real user data to analyze overall performance and user experience.
  • Browser synthetic monitoring – Analyzes application availability and performance, using scheduled testing to analyze website availability and emulate real user experience.

Since Zabbix is not a real person (yet) but is fully capable of emulating real user behavior on a website very precisely, we will focus on browser synthetic monitoring.

What business goals can we achieve with browser monitoring?

There are a multitude of goals that can be achieved, depending on what business we are running or expect to monitor, but some examples include:

Improving user experience

Browser monitoring helps ensure that users have a fast, smooth, and reliable experience on a website or web application. A positive user experience leads to higher user satisfaction and a greater likelihood of repeated visits or purchases.

Ensuring cross-browser and cross-device compatibility

Users access websites from a host of browsers and devices. Browser monitoring helps to detect compatibility issues that could affect certain users (e.g., JavaScript errors on specific browsers or layout shifts on mobile). By monitoring these scenarios, we can deliver a consistent experience across platforms, which is essential as multi-device usage continues to grow.

E-commerce checkout monitoring

Retailers can ensure a smooth checkout process by monitoring page load times, form interactions, and payment processing to confirm that users can easily complete purchases.

Form performance

Browser monitoring makes it easy to detect any issues preventing form completion, such as slow response times or broken validation. It also ensures a smooth, error-free experience to improve lead capture and gain more conversions.

Subscription renewal page monitoring

Subscription-based businesses rely on customers regularly renewing or upgrading their plans. Monitoring the subscription renewal page for load speed, usability, and any payment processing issues is essential, as issues on this page can directly the amount of renewals and lead to customer loss. 

Supporting portal uptime

Many businesses provide a customer support portal where users can submit requests or use a knowledge database. Downtime or slow response times can lead to frustrated customers and an increased number of complaints.

How to set up browser monitoring

There are a lot of goals we can reach, but the question remains – how can we reach them with Zabbix?  The answer is that we can use the already mentioned and newly introduced browser item.

Browser item configuration window

Browser items gather information by running custom JavaScript code and fetching data via HTTP or HTTPS protocols. These items can mimic browser activities like clicking buttons, typing text, navigating across webpages, and performing other user interactions within websites or web applications.

Along with the script, users can specify optional parameters (name-value pairs) and set a timeout limit for the actions. But before we can actually use the item, we will need to configure Zabbix server or Zabbix proxy with a WebDriver, so that Zabbix can actually control browser trough scripts.

What is a WebDriver? A WebDriver controls a browser directly, mimicking user interactions through a local machine or on a remote server, enabling full browser automation. The term WebDriver includes both the language-specific bindings and the individual browser control implementations, often simply called WebDriver. WebDriver is designed to offer a straightforward and streamlined programming interface trough an object-oriented API which efficiently manages and drives browser actions.

In this guide, for instance, we’ll use a WebDriver with Chrome within a Docker container and make a script that includes actions like button clicks and text entry.

WebDriver installation

One of the simplest ways to install a WebDriver is to use containers. To install a chrome WebDriver on a local or remote machine, you can use Docker or any other preferred container engines:

# podman run --name webdriver -d \
-p 4444:4444 \
-p 7900:7900 \
--shm-size="2g" \
--restart=always -d docker.io/selenium/standalone-chrome:latest

Port 4444 will be the port on which the WebDriver will be listening and port 7900 will be used by NoVNC, which allows us to observe browser behavior in case a browser with a GUI is used.

Zabbix server/proxy configuration

After WebDriver is installed, we need to set up the communication between Zabbix and the driver. This can be done by editing the Zabbix server/proxy configuration file and updating the following parameters:

### Option: WebDriverURL
#       WebDriver interface HTTP[S] URL. For example http://localhost:4444 used with 
#       Selenium WebDriver standalone server.
#
# WebDriverURL=
WebDriverURL=http://localhost:4444

### Option: StartBrowserPollers
#       Number of pre-forked instances of browser item pollers.
#
# Range: 0-1000
# StartBrowserPollers=1
StartBrowserPollers=5

With the configuration parameters in place, we will now configure our Browser item to collect and monitor the list of upcoming Zabbix trainings from the training schedule page.

Creating a host

First, we need to navigate to the “Data collection” > “Hosts” section and create a host that represents our web page. This is more than anything – a logical representation. This means we don’t need any specific interfaces or additional configuration. The host in our example will look like this:

Training page monitoring host
Creating a browser item

Since the data collection is done by items, we need to navigate to the “Items” section on the “Zabbix training schedule” host and create an item with the type “Browser.” It should look something like this:

Training schedule browser item

Now comes the most important part – creating the script to monitor the schedule. Click on the “Script” field.

First, we will need to define what browser we will use, and any extra options we might want to specify, like screen resolution or whether the browser should run in headless mode or not. This can be done using the Browser object. The Browser object manages WebDriver sessions and initializes a session upon creation, then terminates it upon destruction. A single script can support up to four Browser objects.

var browser, result;
var  opts = Browser.chromeOptions();
opts.capabilities.alwaysMatch['goog:chromeOptions'].args = []
browser = new Browser(opts);
browser.setScreenSize(Number(1980), Number(1020));

In this snippet, we defined that we will use the Chrome browser with a GUI. As you can see, the screen size is set to the pretty common 1980x1020p.

Now we will need to define what the browser will be doing. This can be done by using such Browser object methods as navigate – to point to the correct URL of the web page or application and (for example) findElement/findElements to return some element of the web page.

findElement/findElements methods allow us to define strategies to locate an element and selectors to provide what to look for. Strategies and selectors can be of multiple kinds:
strategy – (string, CSS selector/link text/partial link text/tag name/Xpath)
selector – (string) Element selector using the specified location strategy

Let’s take a look at the next snippet:

try {
    browser.navigate("https://www.zabbix.com/");
    browser.collectPerfEntries("open page");

    el = browser.findElement("xpath", "//span[text()='Training']");
    if (el === null) {
     throw Error("cannot find training");
    }
    el.click();

    el = browser.findElement("link text", "Schedule");
    if (el === null) {
        throw Error("cannot find application form");
    }
    el.click();

In this snippet,

  1. I am using a browser to navigate to the Zabbix page.
  2. I collect a range of performance entries related to opening the page (download speed, response time, etc.).
  3. I look for an element with the text “Training” using the XPath strategy, and the selector “Training.”
  4. I click on it, which is a method to interact with elements.
  5. In the next part, I use the strategy “link text” to find a link with the text selector “Schedule.”
  6. I click on it

A visual description would look like this:

Browser interaction with the zabbix.com website

Now, let’s do some more clicking to filter out all other trainings and leave only trainings in Korean and Dutch:

    el = browser.findElement("link text", "English");
    if (el === null) {
        throw Error("cannot find application form");
    }
    el.click();

    el = browser.findElement("xpath", "//span[text()='English']");
    if (el === null) {
        throw Error("cannot find application form");
    }
    el.click();

    el = browser.findElement("xpath", "//span[text()='Korean']");
    if (el === null) {
        throw Error("cannot find application form");
    }
    el.click();

    el = browser.findElement("xpath", "//span[text()='Dutch']");
    if (el === null) {
        throw Error("cannot find password input field");
    }
    el.click();

    Zabbix.sleep(2000);

English is selected by default, so the script “unclicks” it. Then it selects Korean and Dutch and uses the sleep function to have some extra time for the page to load and make a screenshot of the currently opened page:

List of trainings with language filters applied on it

Now let’s get the list of dates so we can monitor which trainings we have left in 2024:

el = browser.findElements("xpath", "//*[contains(text(), ' 20')]");
var dates = [];
for (var n = 0; n < el.length; n++) { 
    dates.push(el[n].getText('2024')); 
}

// Remove entries that do not contain "2024"
dates = dates.filter(function(date) {
    return date.includes('2024');
});

dates = uniq(dates);

In this case we do a bit of a jump, and now search for all elements that contain text 20 (to include all years), but filter them out by year 2024 specifically, which later can be easily replaced with 2025. The end result contains all the upcoming training dates:

Items containing the upcoming training dates

The full host export with the script snippet can be found by following this link.

An additional example

But what if I want to fill in a form? Maybe to make a purchase, create an order, or just test a contact form? Good news – that’s an even simpler operation! Let’s take a look at this snippet:

// enter name
var el = browser.findElement("xpath", "//label[text()='First Name']/following::input");
if (el === null) {throw Error("cannot find name input field");}
el.sendKeys("Aleksandrs");

// enter last name
var el = browser.findElement("xpath", "//label[text()='Last name']/following::input");
if (el === null) {throw Error("cannot find name input field");}
el.sendKeys("Petrovs-Gavrilovs");

// enter cert number
var el = browser.findElement("xpath", "//label[text()='Certificate number']/following::input");
if (el === null) {throw Error("cannot find name input field");}
el.sendKeys("CT-2404-003");

// select version
var el = browser.findElement("css selector", "form#certificate_validation>fieldset>div:nth-of-type(5)>select");
if (el === null) {throw Error("cannot find name input field");}
el.sendKeys("7.0");

// check certificate
var el = browser.findElement("xpath", "//button[text()='Check Certificate']");
if (el === null) {throw Error("cannot find name input field");}
el.click();

This way, I can validate that my certificate is still valid! 

As you can see, there are multiple ways to make a browser emulate user behavior and allow us to validate whether our pages and businesses are performing the way we expect them to! You can find even more examples in Zabbix documentation and Zabbix Certified Training, which I welcome you to attend!

The post An Introduction to Browser Monitoring appeared first on Zabbix Blog.

Zabbix Audit Log: Underlying Design and Considerations

Post Syndicated from Artjoms Rimdjonoks original https://blog.zabbix.com/zabbix-audit-log-underlying-design-and-considerations/28328/

An audit improves the security of a product, specifically the “non-repudiation” aspect in threat-models (risks are reduced when threat-agents cannot deny they did malicious activity). Zabbix 5.0 already had audit functionality, which received a major rewrite in 6.0 and several updates since then. In this blog post, we will go through them and get an overall picture of what has changed (and why).

The server side work on 6.0 was mostly done and further improved in 7.0. Front-end work is still ongoing (due to a larger scope). The main goal of a Zabbix audit is to track all configuration and settings changes – who, when, and what. This is an enterprise-level requirement, but non-enterprise users can also benefit.

The situation before Zabbix 6.0

When a host or template is added, only its name is recorded, without info about items, triggers, tags, etc. The linking of the template on the host is not audited. Everything on the screen is an audit done by the front-end, except the script execution. Zabbix Server itself actually does a lot of configuration changes, including adding and updating hosts and updating items (during LLD or when linking templates during auto-registration or network discovery), but there is no audit for that at all. There are also non-configuration changes (events) we want to audit, including:

  • Script execution (already audited in 5.0):

  • Reloading passive proxy config data (ZBXNEXT-1580), added in 6.2:

  • HA node status change (ZBXNEXT-6923), added in 6.0, history push API requests, and sending data to Zabbix server via API (ZBXNEXT-8541), added in 7.0:

Audit overview

Most Zabbix server audit logic is in:

a) Linking of templates (as a result of auto-registration or network discovery) with updates to:

  • Hosts
  • Items
  • Triggers
  • Graphs
  • Discovery Rules (and prototypes of everything above)
  • Web Scenarios

b) LLD, with the following entities created from prototypes:

  • Hosts
  • Items
  • Triggers
  • Graphs

New audit goals

In addition to the main functional requirement to “track all configuration and settings changes,” there are additional requirements aimed at making all audits faster and easier to manage:

  • All audits are now stored in a single table (Simpler and faster SQL queries)
  • Bulk SQL inserts and efficient ids generation
  • The audit of a particular entity stays longer than this entity. If an entity – (host or user) is deleted – the audit for it stays
  • The audit has an independent housekeeping schedule
  • It is still possible to disable the audit

CUID

Zabbix uses an ids table to generate ids:

When something (items, triggers etc.) needs to be generated, the related row in the ids table gets locked. This represents a problem for generating audit rows, because an audit can be generated independently by the server and front-end:

So, we could end up in a situation where a user cannot create an item because the server is holding a lock on the ids table while generating thousands of new LLD items. That is why a new method for generating ID was used for audits:

Thanks to it, the front-end and server can independently generate ids for audit entries without locks. The chance of collision is astronomically low.

System user

When it is not clear under which user an audit entry needs to be generated, it is recorded under “System user.” Most of the audits done by Server are done under “System user.” One exception is “script execution,”” since it is clear which user clicked on the script execution button. However, under which user should the server record audit entries when new items are generated during LLD? We could track down which user created the LLD rule, but what if the LLD rule was then modified by another user? For such cases, “System user” is used.

RecordSetID

From the spec: “To have the ability to recognize that some set of audit log records was created during the processing of a separate operation, a new column “Recordset ID” for audit log records will be provided. Each audit log record of the separate operation will have the same recordset ID. The recordset ID will be generated using the CUID algorithm.”

We can see that 2 graphs were created in a single operation (e.g. during the linking of one template with 2 graphs).

Audit details

A new audit contains much more information on what was changed with new details:

Upgrade patch

The warning, old auditlog, and auditlog_details tables are removed during the upgrade patch to 6.0. A new auditlog table is created, and the schema is updated.

  • auditid is now CUID
  • userid can be NULL (no more foreign reference on users table)
  • username is added
  • resource_cuid is added(alternative to resource, only for HA)
  • recordsetid is added
  • note and other auditlog_details table data now is in details (JSON)

BulkSQL

It is much more efficient to execute SQL queries in bulk. Zabbix already relies on bulk SQL queries:

Inserting and/or updating thousands of new items in one query is much faster than running thousands of individual queries. There are many reasons why this is the case, but the most basic answer is that DBs are designed this way. Another reason is that a large single query in PostgreSQL needs to start the planner/optimizer once, and then it would be able to properly analyze this large query and create an efficient execution plan.

When running thousands of separate queries, the planner/optimizer needs to be started for each query, and every time it would analyze the small query and decide there is not much it can do. When a server is doing some configuration changes, like LLD or templates linking during auto-registration or network discovery, it will insert/update/delete items/triggers and also auditlog entries in one large query.

Performance impact

Quick performance tests showed that the audit slows the server at most by 4-5%. The larger the setup, the smaller the impact will be.

Storage impact and administration

Zabbix audits can generate a lot of data. If your setup generates a lot of configuration, audits can eventually overrun the storage space. In this case, there are several audit configurations that could be helpful.

First of all, an audit can be disabled for all Zabbix, including the front-end:

Disabling audit is not advised, however – this option exists mostly as a possible workaround. Audit is enabled by default and Zabbix is developed and tested with audit enabled.

Log system actions button:

A disabled audit done by Zabbix server during auto-registration, network discover, and LLD. On some systems, these can generate a lot of configurations and audits, for example when LLD discovers hundreds of new devices every minute.

This could help reduce the storage impact while preserving all other audit functionality.

Housekeeping schedule:

If a host, trigger, or graph is deleted (by housekeeper or manually), the audit generated for it stays (as it exists in a separate table).

A Zabbix audit has its own independent housekeeping schedule, and it can be adjusted to suit your environment.

The post Zabbix Audit Log: Underlying Design and Considerations appeared first on Zabbix Blog.

Zabbix 7.0 – Everything You Need to Know

Post Syndicated from Michael Kammer original https://blog.zabbix.com/zabbix-7-0-everything-you-need-to-know/28210/

After plenty of breathless anticipation, we’re proud to announce the release of the latest major Zabbix version – the new and improved Zabbix 7.0 LTS. This release is the direct result of user feedback and delivers a variety of improvements, including cloud-native Zabbix proxy scalability, website transaction monitoring, improved data collection speed and scalability, new dashboard widgets, major network discovery speed improvements, new templates and integrations, and more!

Without further ado, let’s take a whistle-stop tour of what you need to know:

Synthetic end-user web monitoring

Busy enterprises can now monitor multiple websites and applications by defining flexible multi-step browser-based scenarios. 7.0 LTS also makes it easy to capture screenshots of the current website state, collect and visualize website performance and availability metrics, extract, monitor, and analyze web application data, and get alerts when issues are discovered.

Zabbix proxy high availability and load balancing

When it’s time to expand, Zabbix 7.0 LTS makes it easy to scale a Zabbix environment, guaranteeing 100% availability with automatic proxy load balancing and high availability features, including the ability to assign hosts to load-balanced proxy groups and seamlessly scale a Zabbix environment by deploying additional proxies.

Faster, more efficient Zabbix proxies

Zabbix proxy now fully supports in-memory data storage for collected metrics. Users can choose from Disk, Memory, and Hybrid proxy buffer modes, all of which are ideal for embedded hardware. In addition, memory mode enables the support of edge computing use cases. Users can expect 10-100x better proxy performance by switching to memory or hybrid modes, depending on allocated hardware.

Centralized control of data collection timeouts

Centralizing control of data collection timeouts enables better support for metrics and custom checks, taking longer data collection time intervals. Data collection timeouts can be defined per item-type and overridden per proxy or on an individual item level. In addition, timeouts are now fully configurable in the Zabbix GUI or via Zabbix API.

Faster and more scalable data collection

Synchronous poller processes have been replaced with asynchronous pollers, which improves the speed and scalability of metric polling, particularly for agent, SNMP, and HTTP checks. The next metric can now be polled before waiting for a response from a previously requested metric, and up to 1,000 concurrent checks can now be supported per poller process.

New ways to visualize data

A variety of new dashboard widgets have been introduced, with the goal of giving users detailed information about their monitored metrics and infrastructure at a glance.

Dynamic dashboard widget navigation

Speaking of dashboard widgets, a new communication framework has also been introduced for dashboard widgets, enabling communication between widgets, allowing a widget to serve as a data source for other widgets, and dynamically updating information displayed in a dashboard widget based on the data source.

Faster network discovery

Discovering services and hosts has never been easier, thanks to support of parallelization while performing network discovery. Concurrency support allows for massive improvements in network discovery speed and simplifies host and service discovery while scanning large network segments.

Better security via enterprise-grade multi-factor authentication

Out-of-the box support of multi-factor authentication enables enterprise-grade security and added flexibility for configuring user authentication methods. Support MFA providers include time-based one-time Password (TOTP) and Duo Universal Prompt authentication.

More flexible resource discovery and management

Low-level discovery has received a variety of improvements, which enable enhanced host configuration and management flexibility when discovering hosts in complex environments, such as VMware or Kubernetes.

New templates and integrations

In response to user demand, Zabbix 7.0 LTS comes pre-packaged with a range of new templates for the most popular vendors and cloud providers.

Zabbix 7.0 training updates

All Zabbix training materials have been updated based on the new functionalities that have been added to the product since Zabbix 6.0.

Everyone is welcome to sharpen their skills, but if you’re a Zabbix 6.0 Certified Specialist or Certified Professional you can master Zabbix 7.0 LTS in just one day with our Upgrade Courses. As a 7.0 Specialist, you’ll be able to automate user provisioning with the Just-in-time (JIT) feature, monitor websites with new synthetic end-user monitoring, leverage new visualization features, and enhance the speed and performance of your data collection.

The 7.0 Certified Professional course covers proxy group configuration with high availability and load balancing, improved proxy data collection, new SNMP bulk monitoring, and enhanced host discovery for VMware, Kubernetes, and Cloud infrastructures.

We’re also happy to organize private trainings for organizations of any size, so don’t hesitate to get in touch!

Upcoming 7.0 events

If you’re looking for more information regarding Zabbix 7.0, you’re in luck! You can tune in to the “What’s new in Zabbix 7.0” webinar on June 11 at 12 PM CST or June 12 at 10 AM EEST. If you’d prefer a more hands-on approach, the following workshops are also available:

• “Zabbix Proxy High-availability and Load Balancing” (June 18, 6 PM EEST)
• “New Web Monitoring Features in Zabbix 7.0” (June 20, 6 PM EEST)

While you’re at it, feel free to explore Zabbix 7.0 LTS webinars and workshops in other languages. You can also check out worldwide events related to Zabbix 7.0 LTS, including our free in-person meetup in Riga on June 19 and Zabbix Summit 2024 this fall. 

Ready to upgrade or migrate?

With a brand-new version out, there’s never been a better time to take advantage of our upgrade or migration services. Let our team take the risk out of migrating or upgrading to 7.0, giving you the latest version at a lower cost and with minimal disruption to your organization.

Need a consultation about the latest version?

Not sure about how to get the most out of Zabbix 7.0? Our expert consultants can answer any questions related to the architecture of your infrastructure, the implementation of a back-up strategy, and your capacity planning, while providing strategic advice on which 7.0 services are right for you.

Make your contribution as a translator

The Documentation 7.0 translation project is now live, which means that you can help localize Zabbix 7.0 documentation in multiple languages. Your efforts will help make Zabbix accessible to users around the globe, and you’ll also receive a reward for your contributions. The guidelines, which contain essential information about the project, are available here.

Useful links

To see what else is in store for the future, have a look at the Zabbix roadmap.

You can find the instructions and download the new version on the Download page.

Detailed, step-by-step upgrade instructions are available on our Upgrade procedure page.

Learn about new features and changes introduced in Zabbix 7.0 LTS by visiting the What’s new in Zabbix 7.0 page.

The What’s new documentation section provides a detailed description of the new features.

Take a look at the release notes to see the full list of new features and improvements.

 

The post Zabbix 7.0 – Everything You Need to Know appeared first on Zabbix Blog.