Blog

Home
SigNoz: A Powerful Open Source APM and Observability Tool
By Dimitri Bellini12 June, 2025Blog

Diving Deep into SigNoz: A Powerful Open Source APM and Observability Tool

Good morning everyone, I’m Dimitri Bellini, and welcome back to Quadrata, the channel where we explore the fascinating world of open source and IT. As I always say, I hope you enjoy these videos, and if you haven’t already, please consider subscribing and hitting that like button if you find the content valuable!

While Zabbix always holds a special place in our hearts for monitoring, today I want to introduce something different. I’ve been getting requests from customers about how to monitor their applications, and for that, you typically need an Application Performance Monitor (APM), or as it’s sometimes fancily called, an “Observability Tool.”

Introducing SigNoz: Your Open Source Observability Hub

The tool I’m excited to share with you today is called SigNoz. It’s an open-source solution designed for comprehensive observability, which means it helps you monitor metrics, traces (the calls made within your application), and even logs. This last part is a key feature of SigNoz, as it aims to incorporate everything you might need to keep a close eye on your applications.

One of its core strengths is that it’s built natively on OpenTelemetry. OpenTelemetry is becoming an industry standard for collecting telemetry data (metrics, traces, logs) from your applications and transmitting it to a backend like SigNoz. We’ll touch on the advantages of this later.

Why Consider SigNoz?

SigNoz positions itself as an open-source alternative to paid, proprietary solutions like Datadog or New Relic, which can be quite expensive. Of course, choosing open source isn’t just about avoiding costs; it’s also about flexibility and community. For home labs, small projects, or even just for learning, SigNoz can be incredibly useful.

Key Features of SigNoz

  • Application Performance Monitoring (APM): Out-of-the-box, you get crucial metrics like P99 latency, error rates, requests per second, all neatly presented in dashboards.

  • Distributed Tracing: This allows you to follow the path of a request as it travels through your application, helping you pinpoint bottlenecks and errors.

  • Log Management: A relatively recent but powerful addition, SigNoz can ingest logs, allowing you to search and analyze them, similar to tools like Greylog (though perhaps with fewer advanced log-specific features for now).

  • Metrics and Dashboards: SigNoz provides a user-friendly interface with customizable dashboards and widgets.

  • Alerting: You can set up alerts, much like triggers in Zabbix, to get notified via various channels when something goes wrong.

Under the Hood: The Architecture of SigNoz

Understanding how SigNoz is built is fundamental to appreciating its capabilities:

  • OpenTelemetry: As mentioned, this is the core component for collecting and transmitting data from your applications.

  • ClickHouse: This is the database SigNoz uses. ClickHouse is an open-source, column-oriented database management system that’s incredibly efficient for handling and querying millions of data points very quickly. It also supports high availability and horizontal scaling even in its open-source version, which isn’t always the case with other databases.

  • SigNoz UI: The web interface that allows you to visualize and interact with the data collected by OpenTelemetry and stored in ClickHouse.

For those wanting to try it out at home, you can easily get this all running with Docker.

The Power of OpenTelemetry

OpenTelemetry is a game-changer. It’s becoming a de facto standard, with even tools like Dynatrace now able to use OpenTelemetry as a data source. The community around it is very active, making it a solid foundation for a product like SigNoz.

Key advantages of OpenTelemetry include:

  • Standardization: It provides a consistent way to instrument applications.

  • Libraries and Agents: It offers out-of-the-box libraries and agents for most major programming languages, simplifying instrumentation.

  • Auto-Instrumentation (Monkey Patching): Theoretically, OpenTelemetry can automatically inject the necessary code into your application to capture telemetry data without you needing to modify your application’s source code significantly. You just invoke your application with certain environment parameters. I say “theoretically” because while I tried it with one of my Python applications, I couldn’t get it to trace anything. Let me know in the comments if you’d like a dedicated video on this; I’m curious to dig deeper into why it didn’t work for me straight away!

Getting Started: Installing SigNoz with Docker and a Demo App

For my initial tests, I used a demo application suggested by the SigNoz team. Here’s a rundown of how you can get started with a standalone Docker setup:

1. Install SigNoz

It’s straightforward:

  1. Clone the SigNoz repository: git clone https://github.com/SigNoz/signoz.git (or the relevant path from their docs).

  2. Navigate into the directory and run Docker Compose. This will pull up four containers:

    • SigNoz Hotel Collector (OpenTelemetry Collector): Gathers data from OpenTelemetry agents.

    • SigNoz Query Service/Frontend: The graphical interface.

    • ClickHouse Server: The database.

    • Zookeeper: Manages ClickHouse instances (similar to etcd).

You can usually find the exact commands in the official SigNoz documentation under the Docker deployment section.

2. Set Up the Sample FastAPI Application

To see SigNoz in action, I used their “Sample FastAPI App”:

  1. Clone the demo app repository: (You’ll find this on the SigNoz GitHub or documentation).

  2. Create a Python 3 virtual environment: It’s always good practice to isolate dependencies. 
    python3 -m venv .venv
    
source .venv/bin/activate

  3. Install dependencies: 
    pip install -r requirements.txt

  4. Install OpenTelemetry components for auto-instrumentation: 
    pip install opentelemetry-distro opentelemetry-exporter-otlp

  5. Bootstrap OpenTelemetry (optional, for auto-instrumentation): 
    opentelemetry-bootstrap --action=install

    This attempts to find requirements for your specific application.

  6. Launch the application with OpenTelemetry instrumentation:

    You’ll need to set a few environment variables:

    • OTEL_RESOURCE_ATTRIBUTES: e.g., service.name=MyFastAPIApp (This name will appear in SigNoz).

    • OTEL_EXPORTER_OTLP_ENDPOINT: The address of your SigNoz collector (e.g., http://localhost:4317 if running locally).

    • OTEL_EXPORTER_OTLP_TRACES_EXPORTER: Set to otlp.

    • OTEL_EXPORTER_OTLP_PROTOCOL: Can be grpc or http/protobuf.

    Then, run your application using the opentelemetry-instrument command:

    OTEL_RESOURCE_ATTRIBUTES=service.name=FastApp OTEL_EXPORTER_OTLP_ENDPOINT="http://:4317" OTEL_EXPORTER_OTLP_TRACES_EXPORTER=otlp OTEL_EXPORTER_OTLP_PROTOCOL=grpc opentelemetry-instrument uvicorn main:app --host 0.0.0.0 --port 8000

    (Replace with the actual IP where SigNoz is running).
    The opentelemetry-instrument part is what attempts the “monkey patching” or auto-instrumentation. The application itself (uvicorn main:app...) starts as it normally would.

A Quick Look at SigNoz in Action

Once the demo app was running and sending data, I could see traces appearing in my terminal (thanks to console exporter settings). To generate some load, I used Locust with a simple configuration to hit the app’s HTTP endpoint. This simulated about 10 users.

Navigating to the SigNoz UI (typically on port 3301, or as configured, if you’re using the Docker setup that forwards to 8080 or another port for the frontend, but the collector often listens on 4317/4318), the dashboard immediately showed my “FastApp” service. Clicking on it revealed:

  • Latency, request rate, and error rate graphs.

  • A list of endpoints called.

Drilling down into the traces, I could see individual requests. For this simple “Hello World” app, the trace was trivial, just showing the HTTP request. However, if the application were more complex, accessing a database, for example, OpenTelemetry could trace those interactions too, showing you the queries and time taken. This is where it gets really interesting for debugging and performance analysis.

The SigNoz interface felt responsive and well-designed. I was quite impressed with how smoothly it all worked.

Final Thoughts and What’s Next

I have to say, SigNoz seems like a very capable and well-put-together tool. It’s definitely worth trying out, especially if you’re looking for an open-source observability solution.

I plan to test it further with a more complex application, perhaps one involving a database, to see how it handles more intricate call graphs and to really gauge if it can be a strong contender against established players for more demanding scenarios.

It’s also interesting to note that Zabbix has APM features on its roadmap, potentially for version 8. So, the landscape is always evolving! But for now, SigNoz is a noteworthy project, especially for those interested in comprehensive observability that includes metrics, traces, AND logs in one package. This log management capability could make it a simpler alternative to setting up a separate, more complex logging stack for many use cases, particularly in home labs or smaller environments.

So, what do you think? Have you tried SigNoz or other APM tools? Let me know in the comments below! If there’s interest, I can certainly make more videos exploring its features or trying out more complex scenarios.

Thanks for watching, and I’ll see you next week. A greeting from me, Dimitri!

—

Stay Connected with Quadrata:

📺 Subscribe to Quadrata on YouTube

💬 Join the Zabbix Italia Telegram Channel (Also great for general monitoring discussions!)

Read More

0

Red Hat Enterprise Linux 10 and Its Clones: What’s New and Which to Choose?
By Dimitri Bellini04 June, 2025Blog

Red Hat Enterprise Linux 10 is Here: A Look at the New Release and Its Impact on Clones

Good morning everyone, I’m Dimitri Bellini, and welcome back to Quadrata, my channel dedicated to the world of open source and IT. This week, we’re shifting focus from our usual Zabbix discussions to something that’s recently made waves in the Linux world: the release of Red Hat Enterprise Linux 10 (RHEL 10)!

The arrival of a new RHEL version is always significant, especially for the enterprise sector. So, let’s dive into what RHEL 10 brings to the table and, crucially, how its popular clones – AlmaLinux, Rocky Linux, and Oracle Linux – are adapting to this new landscape. If you find this content useful, don’t forget to put a like and subscribe to the channel if you haven’t already!

What’s New in Red Hat Enterprise Linux 10?

Red Hat Enterprise Linux is renowned as the most important distribution in the enterprise world, where companies pay for official support and long-term stability. RHEL versions are designed to be stable over time, offer excellent hardware and software support, and typically come with at least 10 years of support. This makes it ideal for server and enterprise environments, rather than your everyday desktop.

With RHEL 10, Red Hat continues to build on this foundation while embracing new IT trends. Here are some of the key highlights:

Key Highlights of RHEL 10:

  • Kernel 6.12 (as mentioned): While the video mentions kernel 6.12, Red Hat typically focuses on stability for its enterprise releases. This means they select a mature kernel and then backport necessary bug fixes and feature advancements from newer kernels to their chosen stable version.

  • Image Mode with BootC: This is an interesting development that transforms the standard operating system concept towards an immutable distro model. Instead of traditional package management like RPM for updates, you create an OS image with everything needed. Updates involve deploying a new image, allowing for easy rollback to a previous version upon reboot. This simplifies OS updates significantly in certain contexts.

  • Wayland by Default: RHEL 10 moves decisively towards Wayland, with support for Xorg being removed, at least as the main desktop environment.

  • RDP for Remote Access: For remote access to RHEL 10 workstations, the system has transitioned from VNC to RDP (Remote Desktop Protocol), the well-known protocol from the Windows world, aiming for a more standard and efficient solution.

  • Architecture Upgrade to x86-64-v3: RHEL 10 has moved its baseline architecture level from x86-64-v2 to v3 during compilation. This means it embraces newer instruction sets in modern AMD and Intel processors but, importantly, drops support for older CPUs that don’t meet the v3 specification. If you’re running older hardware, this is a critical change.

The RHEL Clones: Navigating the Landscape After CentOS

As many of you know, Red Hat’s decision to shift CentOS from a direct RHEL rebuild to CentOS Stream (a rolling-release version that’s upstream of RHEL) led to the rise of several community-driven distributions aiming to fill the gap. The most prominent among these are AlmaLinux, Rocky Linux, and Oracle Linux, each striving to provide an enterprise-grade, RHEL-compatible experience.

With RHEL 10 out, these clones are now releasing their own version 10s. Let’s see how they’re approaching it.

AlmaLinux 10 “PurpleLion” – The Swift Innovator

AlmaLinux was quick to respond, releasing its version 10 (codename PurpleLion) just about a week after RHEL 10’s announcement. AlmaLinux is community-driven and has made some distinct choices:

  • Shift in Philosophy: While previously focused on “bug-for-bug” compatibility, AlmaLinux 10 aims for “Application Binary Interface (ABI)” compatibility with RHEL. This means it ensures applications compiled for RHEL will run on AlmaLinux, but it allows AlmaLinux to introduce its own improvements and not be 100% identical to RHEL.

  • Key Differentiators:

    • Kernel with Frame Pointers: AlmaLinux 10 tunes its kernel by enabling Frame Pointers. This can simplify debugging and profiling of the OS and applications, though it might introduce a slight performance overhead (around 1-2%).

    • Broader Hardware Support (x86-64-v2 and v3): Unlike RHEL 10’s default, AlmaLinux 10 provides options for both x86-64-v2 and x86-64-v3 architectures, offering kernels for older CPUs.

    • Continued SPICE Support: They continue to support the SPICE protocol for remote access to virtual machines, which was dropped in RHEL 9 and 10.

    • Additional Device Drivers: AlmaLinux 10 includes over 150 device drivers that Red Hat has dropped in its current version.

    • EPEL for v2: AlmaLinux is taking on the task of compiling EPEL (Extra Packages for Enterprise Linux) packages for the x86-64-v2 architecture, given their continued support for it.

  • Release Strategy: Aims to release major and minor versions as quickly as possible, gathering sources from various places.

Rocky Linux 10 – The Staunch Loyalist

Rocky Linux is known for its purist approach, aiming for 100% bug-for-bug compatibility with RHEL.

  • The Purist’s Choice: If you want a distribution that is as close to RHEL as possible, Rocky Linux is your go-to. The packages are intended to be bit-for-bit identical.

  • Release Strategy: More conservative. Rocky Linux typically waits for the general availability (GA) of the RHEL version before releasing its corresponding version to ensure full compatibility. As of this writing, Rocky Linux 10 has nightly builds available but is not yet officially released.

  • Kernel: The kernel is not altered and remains the same as in RHEL 10.

  • Architecture Support: Following RHEL’s lead, Rocky Linux 10 will focus on the x86-64-v3 architecture, meaning no default support for older v2 CPUs unless they decide to provide an alternative kernel.

Oracle Linux 10 – The Enterprise Powerhouse

Oracle Linux also maintains bug-for-bug compatibility with RHEL and is a strong contender, especially in enterprise environments.

  • Enterprise Focus: Offers 100% RHEL compatibility and the backing of a major vendor, Oracle, which also provides official support options.

  • Unbreakable Enterprise Kernel (UEK): A key differentiator is the option to use Oracle’s UEK. This is an Oracle-tuned kernel designed for better performance and efficiency, particularly for enterprise workloads and, naturally, Oracle’s own database products. Users can choose between the RHEL-compatible kernel or the UEK.

  • Release Timing: Oracle Linux releases typically follow RHEL’s official upstream release, as they need the sources to compile and verify. Version 10 is not yet available.

OpenELA: A Collaborative Effort for Enterprise Linux

After Red Hat changed how it provided sources, a new initiative called OpenELA (Open Enterprise Linux Association) was formed. This non-profit collaboration involves CIQ (the company behind Rocky Linux), Oracle, and SUSE. Their primary goal is to work together to obtain RHEL sources and continue to provide free and open enterprise Linux versions based on RHEL. Notably, AlmaLinux has chosen its own path and is not part of OpenELA.

Choosing Your Champion: AlmaLinux vs. Rocky Linux vs. Oracle Linux

So, with these options, which one should you choose?

  • AlmaLinux 10: Might be your pick if you appreciate faster release cycles, need support for older hardware (x86-64-v2), value features like enabled Frame Pointers, or require specific drivers/software (like SPICE) that RHEL has dropped. You’re okay with a distribution that’s binary compatible but not strictly bug-for-bug identical to RHEL.

  • Rocky Linux 10: If your priority is unwavering stability and 100% bug-for-bug compatibility with Red Hat Enterprise Linux, and you prefer a purely community-driven approach, Rocky Linux is likely the best fit.

  • Oracle Linux 10: If you’re operating in a large enterprise, might need commercial support, or could benefit from the potentially optimized performance of the Unbreakable Enterprise Kernel (UEK) for specific workloads, Oracle Linux is a strong contender.

The speed of release is also a factor for some. AlmaLinux tends to be the fastest, while Rocky Linux and Oracle Linux are a bit more measured. However, whether a release comes out a few weeks sooner or later might not be critical for many, as long as it’s timely.

My Perspective: Why Standardization Matters in the Enterprise

Personally, I’ve decided to stabilize on Red Hat and its derivatives for enterprise environments because standardization is fundamental. When you’re working in complex systems, introducing too many variables can lead to unpredictable problems.

I encountered a situation a while ago that illustrates this. We were setting up synthetic monitoring using a Selenium Docker container. It worked perfectly in our environment. However, for our client, who was using Podman (common in RHEL environments) instead of Docker as the container engine, the same setup was incredibly slow after just a few concurrent connections – the CPU would max out, and it was a complete mess. Understanding that subtle difference was key to resolving the issue.

This is why, for certain enterprise scenarios, I lean towards RHEL-based systems. They are often more rigorously tested and standardized for such environments, which can save a lot of headaches down the line.

Conclusion

The Linux distribution landscape is ever-evolving, and the release of RHEL 10 alongside new versions from its clones is a testament to this dynamism. Each distribution we’ve discussed offers a solid RHEL-compatible experience but caters to slightly different needs and philosophies.

I hope this overview has been interesting and helps you understand the current state of play. The choice ultimately depends on your specific requirements, whether it’s cutting-edge innovation, purist compatibility, or enterprise-grade support.

What are your thoughts on RHEL 10 and its clones? Which distribution are you leaning towards, or currently using, and why? Let me know in the comments below! The battle of distributions is always a hot topic!

Thanks for reading, and if you enjoyed this, please share it and make sure you’re subscribed to Quadrata on YouTube for more content like this. You can also join the conversation on our ZabbixItalia Telegram Channel.

A big greeting from me, Dimitri Bellini. Bye everyone, and I’ll see you next week!

Follow Quadrata:

Read More

0

Mastering SNMP in Zabbix: A Deep Dive into Modern Monitoring Techniques
By Dimitri Bellini29 May, 2025Blog

Mastering SNMP in Zabbix: A Deep Dive into Modern Monitoring Techniques

Good morning, everyone! It’s Dimitri Bellini, and welcome back to my channel, Quadrata, where we explore the fascinating world of open source and IT. This week, I’m revisiting a topic that frequently comes up in my work: SNMP monitoring with Zabbix. There have been some significant updates in recent Zabbix versions, especially regarding how SNMP is handled, so I wanted to share a recap and dive into these new features.

If you enjoy this content, don’t forget to subscribe to the channel or give this video a thumbs up. Your support means a lot!

What Exactly is SNMP? A Quick Refresher

SNMP stands for Simple Network Management Protocol. It’s an internet standard protocol designed for collecting and organizing information about managed devices on IP networks. Think printers, switches, routers, servers, and even more specialized hardware. Essentially, it allows us to query these devices for valuable operational data.

Why Bother with SNMP?

You might wonder why we still rely on such an “old” protocol. The answer is simple:

  • Ubiquity: Almost every network-enabled device supports SNMP out of the box.

  • Simplicity (in concept): It provides a standardized way to access a wealth of internal device information without needing custom agents for every device type.

SNMP Fundamentals You Need to Know

Before diving into Zabbix specifics, let’s cover some SNMP basics:

  • Protocol Type: SNMP primarily uses UDP. This means it’s connectionless, which can sometimes make testing connectivity (like with Telnet for TCP) a bit tricky.

  • Components:

    • Manager: This is the entity that requests information. In our case, it’s the Zabbix Server or Zabbix Proxy.

    • Agent: This is the software running on the managed device that listens for requests from the manager and sends back the requested data.

  • Versions:

    • SNMPv1: The original, very basic.

    • SNMPv2c: The most commonly used version. It introduced improvements like the “GetBulk” operation and enhanced error handling. “c” stands for community-based.

    • SNMPv3: Offers significant security enhancements, including encryption and authentication. It’s more complex to configure but essential for secure environments.

  • Key Operations:

    • GET: Retrieves the value of a specific OID (Object Identifier).

    • GETNEXT: Retrieves the value of the OID following the one specified – useful for “walking” a MIB tree.

    • SET: (Rarely used in Zabbix for monitoring) Allows modification of a device’s configuration parameter via SNMP.

    • GETBULK: (Available in SNMPv2c and v3) Allows the manager to request a large block of data with a single request, making it much more efficient than multiple GET or GETNEXT requests. This is key for modern Zabbix performance!

The `GETBULK` operation is particularly important. Imagine querying a switch with 100 interfaces, and for each interface, you want 10 metrics. Without bulk requests, Zabbix would make 1000 individual requests. This can flood the device and cause its SNMP process to consume excessive CPU, especially on devices with less powerful processors. `GETBULK` significantly reduces this overhead.

Understanding OIDs and MIBs

You’ll constantly hear about OIDs and MIBs when working with SNMP.

  • OID (Object Identifier): This is a unique, numeric address that identifies a specific piece of information on a managed device. It’s like a path in a hierarchical tree structure. For example, an OID might point to a specific network interface’s operational status or its traffic counter.

  • MIB (Management Information Base): A MIB is essentially a database or a “dictionary” that describes the OIDs available on a device. It maps human-readable names (like `ifDescr` for interface description) to their numeric OID counterparts and provides information about the data type, access rights (read-only, read-write), and meaning of the data. MIBs can be standard (e.g., IF-MIB for network interfaces, common across vendors) or vendor-specific.

To navigate and understand MIBs and OIDs, I highly recommend using a MIB browser. A great free tool is the iReasoning MIB Browser. It’s a Java application that you can download and run without extensive installation. You can load MIB files (often downloadable from vendor websites or found via Google) into it, visually explore the OID tree, see the numeric OID for a human-readable name, and get descriptions of what each OID represents.

For example, in a MIB browser, you might find that `ifOperStatus` (interface operational status) returns an integer. The MIB will tell you that `1` means “up,” `2` means “down,” `3` means “testing,” etc. This information is crucial for creating value mappings in Zabbix to display human-friendly statuses.

SNMP Monitoring in Zabbix: The Evolution

Zabbix has supported SNMP for a long time, but the way we implement it has evolved, especially with recent versions.

The “Classic” Approach (Pre-Zabbix 6.4)

Traditionally, SNMP monitoring in Zabbix involved:

  • SNMP Agent Items: You’d create an item of type “SNMP agent” and provide the specific numeric OID (or its textual representation if the MIB was installed on the Zabbix server/proxy) in the “SNMP OID” field.

  • Discovery Rules: For discovering multiple instances (like network interfaces), you’d use a discovery rule, again specifying OIDs. The key would often look like `discovery[{#SNMPVALUE},oid1,{#IFDESCR},oid2,…]`. Each OID would populate a Low-Level Discovery (LLD) macro.

Limitations of the Classic Approach:

  • No True Bulk Requests: Even if “Use bulk requests” was checked in the host interface settings, it was more of an optimization for multiple *items* rather than fetching multiple OID values for a *single* item or discovery rule efficiently. Each OID in a discovery rule often meant a separate query.

  • Synchronous Polling: Each SNMP check would typically occupy a poller process until it completed.

  • Potential Device Overload: As mentioned earlier, many individual requests could strain the monitored device.

The Modern Approach with Zabbix 6.4+

Zabbix 6.4 brought a significant game-changer with new SNMP item types:

  • `snmp.get[OID]`: For fetching a single OID value.

  • `snmp.walk[OID1,OID2,…]`: This is the star of the show! It allows you to “walk” one or more OID branches and retrieve all underlying data in a single operation. The output is a large text block containing all the fetched OID-value pairs.

Key Benefits of the snmp ‘walk’ Approach:

  • True Bulk SNMP Requests: The snmp ‘walk’ item inherently uses bulk SNMP operations (for SNMPv2c and v3), making data collection much more efficient.

  • Asynchronous Polling Support: These new item types work with Zabbix’s asynchronous polling capabilities, meaning a poller can initiate many requests without waiting for each one to complete, freeing up pollers for other tasks.

  • Reduced Load on Monitored Devices: Fewer, more efficient requests mean less stress on your network devices.

  • Master/Dependent Item Architecture: The snmp ‘walk’ item is typically used as a “master item.” It collects a large chunk of data once. Then, multiple “dependent items” (including discovery rules and item prototypes) parse the required information from this master item’s output without making additional SNMP requests.

Implementing the Modern SNMP Approach in Zabbix

Let’s break down how to set this up:

1. Configure the SNMP Interface on the Host

In Zabbix, when configuring a host for SNMP monitoring:

  • Add an SNMP interface.

  • Specify the IP address or DNS name.

  • Choose the SNMP version (v1, v2, or v3). For v2c, you’ll need the Community string (e.g., “public” or whatever your devices are configured with). For v3, you’ll configure security name, levels, protocols, and passphrases.

  • Max repetitions: This setting (default is often 10) applies to snmp ‘walk’ items and controls how many “repeats” are requested in a single SNMP GETBULK PDU. It influences how much data is retrieved per underlying bulk request.

  • Use combined requests: This is the *old* “Use bulk requests” checkbox. When using the new snmp ‘walk’ items, this is generally not needed and can sometimes interfere. I usually recommend unchecking it if you’re fully embracing the snmp ‘walk’ methodology. The snmp ‘walk’ item itself handles the efficient bulk retrieval.

2. Create the Master snmp ‘walk’ Item

This item will fetch all the data you need for a set of related metrics or a discovery process.

  • Type: SNMP agent

  • Key: `snmp.walk[oid.branch.1, oid.branch.2, …]`

    Example: `snmp.walk[IF-MIB::ifDescr, IF-MIB::ifOperStatus, IF-MIB::ifAdminStatus]` or using numeric OIDs.

  • Type of information: Text (as it returns a large block of text).

  • Set an appropriate update interval.

This item will collect data like:



IF-MIB::ifDescr.1 = STRING: lo

IF-MIB::ifDescr.2 = STRING: eth0

IF-MIB::ifOperStatus.1 = INTEGER: up(1)

IF-MIB::ifOperStatus.2 = INTEGER: down(2)

...and so on for all OIDs specified in the key.

3. Create a Discovery Rule (Dependent on the Master Item)

If you need to discover multiple instances (e.g., network interfaces, storage volumes):

  • Type: Dependent item

  • Master item: Select the snmp ‘walk’ master item created above.

  • Preprocessing Steps: This is where the magic happens!

    • Add a preprocessing step: SNMP walk to JSON.

      • Parameters: This is where you define your LLD macros and map them to the OIDs from the snmp ‘walk’ output.


        
{#IFDESCR} => IF-MIB::ifDescr
        
{#IFOPERSTATUS} => IF-MIB::ifOperStatus
        
{#IFADMINSTATUS} => IF-MIB::ifAdminStatus
        
// or using numeric OIDs:
        
{#IFDESCR} => .1.3.6.1.2.1.2.2.1.2
        
{#IFOPERSTATUS} => .1.3.6.1.2.1.2.2.1.8

      • This step transforms the flat text output of snmp ‘walk’ into a JSON structure that Zabbix LLD can understand. It uses the SNMP index (the number after the last dot in the OID, e.g., `.1`, `.2`) to group related values for each discovered instance. Zabbix automatically makes `{#SNMPINDEX}` available.

The `SNMP walk to JSON` preprocessor will generate JSON like this, which LLD uses to create items based on your prototypes:



[

    { "{#SNMPINDEX}":"1", "{#IFDESCR}":"lo", "{#IFOPERSTATUS}":"1", ... },

    { "{#SNMPINDEX}":"2", "{#IFDESCR}":"eth0", "{#IFOPERSTATUS}":"2", ... }

]

4. Create Item Prototypes (Dependent on the Master Item)

Within your discovery rule, you’ll create item prototypes:

  • Type: Dependent item

  • Master item: Select the same snmp ‘walk’ master item.

  • Key: Give it a unique key, often incorporating LLD macros, e.g., `if.operstatus.[{#IFDESCR}]`

  • Preprocessing Steps:

    • Add a preprocessing step: SNMP walk value.

      • Parameters: Specify the OID whose value you want to extract for this specific item prototype, using `{#SNMPINDEX}` to get the value for the correct discovered instance.


        
IF-MIB::ifOperStatus.{#SNMPINDEX}
        
// or numeric:
        
.1.3.6.1.2.1.2.2.1.8.{#SNMPINDEX}

    • Add other necessary preprocessing steps (e.g., “Change per second,” “Multiply by 8” for bits to Bytes/sec, custom scripts, value mapping).

For static items (not discovered) that should also use the data from the snmp ‘walk’ master item, you’d create them as dependent items directly under the host, also using the “SNMP walk value” preprocessor, but you’d specify the full OID including the static index (e.g., `IF-MIB::ifOperStatus.1` if you always want the status of the interface with SNMP index 1).

Practical Tips & Troubleshooting

  • Use `snmpwalk` Command-Line Tool: Before configuring in Zabbix, test your OIDs and community strings from your Zabbix server or proxy using the `snmpwalk` command (part of `net-snmp-utils` or similar packages on Linux).

    Example: `snmpwalk -v2c -c public your_device_ip IF-MIB::interfaces`

    Use the `-On` option (`snmpwalk -v2c -c public -On your_device_ip .1.3.6.1.2.1.2`) to see numeric OIDs, which can be very helpful.

  • Check Zabbix Server/Proxy Logs: If things aren’t working, the logs are your best friend. Increase debug levels if necessary.

  • Consult Zabbix Documentation: The official documentation is a valuable resource for item key syntax and preprocessing options.

  • Test Preprocessing Steps: Zabbix allows you to test your preprocessing steps. For dependent items, you can copy the output of the master item and paste it as input for testing the dependent item’s preprocessing. This is invaluable for debugging `SNMP walk to JSON` and `SNMP walk value`.

Wrapping Up

The introduction of snmp ‘walk’ and the refined approach to SNMP in Zabbix 6.4+ is a massive improvement. It leads to more efficient polling, less load on your monitored devices, and a more streamlined configuration once you grasp the master/dependent item concept with preprocessing.

While it might seem a bit complex initially, especially the preprocessing steps, the benefits in performance and scalability are well worth the learning curve. Many of the newer official Zabbix templates are already being converted to use this snmp ‘walk’ method, but always check, as some older ones might still use the classic approach.

That’s all for today! I hope this deep dive into modern SNMP monitoring with Zabbix has been helpful. I got a bit long, but there was a lot to cover!

What are your experiences with SNMP in Zabbix? Have you tried the new snmp ‘walk’ items? Let me know in the comments below!

Don’t forget to check out my YouTube channel for more content:

Quadrata on YouTube

And join the Zabbix Italia community on Telegram:

ZabbixItalia Telegram Channel

See you next week, perhaps talking about something other than Zabbix for a change! Bye everyone, from Dimitri Bellini.

Read More

0

Deep Dive into Zabbix Low-Level Discovery & the Game-Changing 7.4 Update
By Dimitri Bellini26 May, 2025Blog

Deep Dive into Zabbix Low-Level Discovery & the Game-Changing 7.4 Update

Good morning, everyone, and welcome back to Quadrata! This is Dimitri Bellini, and on this channel, we explore the fascinating world of open source and IT. I’m thrilled you’re here, and if you enjoy my content, please give this video a like and subscribe if you haven’t already!

I apologize for missing last week; work had me on the move. But I’m back, and with the recent release of Zabbix 7.4, I thought it was the perfect time to revisit a powerful feature: Low-Level Discovery (LLD). There’s an interesting new function in 7.4 that I want to discuss, but first, let’s get a solid understanding of what LLD is all about.

What Exactly is Zabbix Low-Level Discovery?

Low-Level Discovery is a fantastic Zabbix feature that automates the creation of items, triggers, and graphs. Think back to the “old days” – or perhaps your current reality if you’re not using LLD yet. Manually creating monitoring items for every CPU core, every file system, every network interface on every host… it’s a painstaking and error-prone process, especially in dynamic environments.

Imagine:

  • A new mount point is added to a server. If you forget to add it to Zabbix, you won’t get alerts if it fills up. Disaster!

  • A network switch with 100 ports. Manually configuring monitoring for each one? A recipe for headaches.

LLD, introduced way back in Zabbix 2.0, came to rescue us from this. It allows Zabbix to automatically discover resources on a host or device and create the necessary monitoring entities based on predefined prototypes.

Why Do We Need LLD?

  • Eliminate Manual Toil: Say goodbye to the tedious task of manually creating items, triggers, and graphs.

  • Dynamic Environments: Automatically adapt to changes like new virtual machines, extended filesystems, or added network ports.

  • Consistency: Ensures that all similar resources are monitored in the same way.

  • Accuracy: Reduces the risk of human error and forgotten resources.

How Does Low-Level Discovery Work?

The core principle is quite straightforward:

  1. Discovery Rule: You define a discovery rule on a host or template. This rule specifies how Zabbix should find the resources.

  2. Data Retrieval: Zabbix (or a Zabbix proxy) queries the target (e.g., a Zabbix agent, an SNMP device, an HTTP API) for a list of discoverable resources.

  3. JSON Formatted Data: The target returns the data in a specific JSON format. This JSON typically contains an array of objects, where each object represents a discovered resource and includes key-value pairs. A common format uses macros like {#FSNAME} for a filesystem name or {#IFNAME} for an interface name.


    
{
    
  "data": [
    
    { "{#FSNAME}": "/", "{#FSTYPE}": "ext4" },
    
    { "{#FSNAME}": "/boot", "{#FSTYPE}": "ext4" },
    
    { "{#FSNAME}": "/var/log", "{#FSTYPE}": "xfs" }
    
  ]
    
}

  4. Prototype Creation: Based on the received JSON data, Zabbix uses prototypes (item prototypes, trigger prototypes, graph prototypes, and even host prototypes) to automatically create actual items, triggers, etc., for each discovered resource. For example, if an item prototype uses {#FSNAME} in its key, Zabbix will create a unique item for each filesystem name returned by the discovery rule.

The beauty of this is its continuous nature. Zabbix periodically re-runs the discovery rule, automatically creating entities for new resources and, importantly, managing resources that are no longer found.

Out-of-the-Box vs. Custom Discoveries

Zabbix comes with several built-in LLD rules, often found in default templates:

  • File systems: Automatically discovers mounted file systems (e.g., on Linux and Windows).

  • Network interfaces: Discovers network interfaces.

  • SNMP OIDs: Discovers resources via SNMP.

  • Others like JMX, ODBC, Windows services, and host interfaces.

But what if you need to discover something specific to your custom application or a unique device? That’s where custom LLD shines. Zabbix is incredibly flexible, allowing almost any item type to become a source for discovery:

  • Zabbix agent (system.run[]): Execute a script on the agent that outputs the required JSON.

  • External checks: Similar to agent scripts but executed on the Zabbix server/proxy.

  • HTTP agent: Perfect for querying REST APIs that return lists of resources.

  • JavaScript items: Allows for complex logic, multiple API calls, and data manipulation before outputting the JSON.

  • SNMP agent: For custom SNMP OID discovery.

The key is that your custom script or check must output data in the LLD JSON format Zabbix expects.

Configuring a Discovery Rule: Key Components

When you set up a discovery rule, you’ll encounter several important configuration tabs:

  • Discovery rule (main tab): Define the item type (e.g., Zabbix agent, HTTP agent), key, update interval, etc. This is where you also configure how Zabbix handles “lost” resources.

  • Preprocessing: Crucial for custom discoveries! You can take the raw output from your discovery item and transform it. For example, convert CSV to JSON, use regular expressions, or apply JSONPath to extract specific parts of a complex JSON.

  • LLD macros: Here, you map the keys from your discovery JSON (e.g., {#FSNAME}) to JSONPath expressions that tell Zabbix where to find the corresponding values in the JSON output from the preprocessing step.

  • Filters: Include or exclude discovered resources based on regular expressions matching LLD macro values.

  • Overrides: A more advanced feature allowing you to change specific attributes (like item status, severity of triggers, tags) for discovered objects that match certain criteria.

Managing Lost Resources: A Welcome Improvement

A critical aspect of LLD is how it handles resources that were previously discovered but are no longer present. For a long time, we had the “Keep lost resources period” setting. If a resource disappeared, Zabbix would keep its associated items, triggers, etc., for a specified duration (e.g., 7 days) before deleting them. During this period, the items would often go into an unsupported state as Zabbix tried to query non-existent resources, creating noise.

Starting with Zabbix 7.0, a much smarter option was introduced: “Disable lost resources.” Now, you can configure Zabbix to immediately (or after a period) disable items for lost resources. This is fantastic because:

  • It stops Zabbix from trying to poll non-existent resources, reducing load and unsupported item noise.

  • The historical data for these items is preserved until they are eventually deleted (if configured to do so via “Keep lost resources period”).

  • If the resource reappears, the items can be automatically re-enabled.

You can use these two settings in combination: for example, disable immediately but delete after 7 days. This offers great flexibility and a cleaner monitoring environment.

Prototypes: The Blueprints for Monitoring

Once LLD discovers resources, it needs templates to create the actual monitoring entities. These are called prototypes:

  • Item prototypes: Define how items should be created for each discovered resource. You use LLD macros (e.g., {#FSNAME}) in the item name, key, etc.

  • Trigger prototypes: Define how triggers should be created.

  • Graph prototypes: Define how graphs should be created.

  • Host prototypes: This is a particularly powerful one, allowing LLD to create *new hosts* in Zabbix based on discovered entities (e.g., discovering VMs from a hypervisor).

The Big News in Zabbix 7.4: Nested Host Prototypes!

Host prototypes have been around for a while, evolving significantly from Zabbix 6.0 to 7.0, gaining features like customizable interfaces, tags, and macro assignments for the discovered hosts. However, there was a significant limitation: a template assigned to a host created by a host prototype could not, itself, contain another host prototype to discover further hosts. In essence, nested host discovery wasn’t supported.

Imagine trying to monitor a virtualized environment:

  1. You discover your vCenter.

  2. You want the vCenter discovery to create host objects for each ESXi hypervisor. (Possible with host prototypes).

  3. Then, you want each discovered ESXi hypervisor host (using its assigned template) to discover all the VMs running on it and create host objects for those VMs. (This was the roadblock!).

With Zabbix 7.4, this limitation is GONE! Zabbix now supports nested host prototypes. This means a template applied to a discovered host *can* indeed contain its own host prototype rules, enabling multi-level, chained discoveries. This is a game-changer for complex environments like Kubernetes, container platforms, or any scenario with layered applications.

A Quick Look at How It Works (Conceptual Demo)

In the video, I demonstrated this with a custom LLD setup:

  1. Initial Discovery: I used a simple system.run item that read a CSV file. This CSV contained information about “parent” entities (simulating, say, hypervisors).

  2. Preprocessing: A “CSV to JSON” preprocessing step converted this data into the LLD JSON format.

  3. LLD Macros: I defined LLD macros like {#HOST} and {#HOSTGROUP}.

  4. Host Prototype (Level 1): A host prototype used these macros to create new hosts in Zabbix and assign them a specific template (let’s call it “Template A”).

  5. The Change in 7.4:

    • In Zabbix 7.0 (and earlier): If “Template A” itself contained a host prototype (e.g., to discover “child” entities like VMs), that nested host prototype would simply not appear or function on the hosts created by the Level 1 discovery. The Zabbix documentation even explicitly stated this limitation.

    • In Zabbix 7.4: “Template A” *can* now have its own discovery rules and host prototypes. So, when the Level 1 discovery creates a host and assigns “Template A”, “Template A” can then kick off its *own* LLD process to discover and create further hosts (Level 2).

This allows for a much more dynamic and hierarchical approach to discovering and monitoring complex infrastructures automatically.

Conclusion: Embrace the Automation!

Low-Level Discovery is an indispensable Zabbix feature for anyone serious about efficient and comprehensive monitoring. It saves incredible amounts of time, reduces errors, and keeps your monitoring setup in sync with your ever-changing IT landscape.

The introduction of “Disable lost resources” in Zabbix 7.0 was a great step forward, and now, with nested host prototypes in Zabbix 7.4, the power and flexibility of LLD have reached new heights. This opens up possibilities for automating the discovery of deeply layered applications and infrastructure in a way that wasn’t easily achievable before.

I encourage you to explore LLD in your Zabbix environment. Start with the out-of-the-box discoveries, and then don’t be afraid to dive into custom LLDs to tailor Zabbix perfectly to your needs.

What are your thoughts on Low-Level Discovery or this new Zabbix 7.4 feature? Are there any specific LLD scenarios you’d like me to cover in a future video? Let me know in the comments below! Your feedback is always appreciated.

Thanks for watching, and I’ll see you next week!

All the best,
Dimitri Bellini

Connect with me and the community:

Read More

0

My Journey into Vibe Coding: Building a Zabbix Service Visualizer with AI
By Dimitri Bellini08 May, 2025Blog

My Journey into Vibe Coding: Building a Zabbix Service Visualizer with AI

Good morning, everyone, and welcome back to Quadrata! This is Dimitri Bellini, and on this channel, we dive into the fascinating world of open source and IT – the stuff I love, and hopefully, you do too. If you enjoy this content, please give it a thumbs up and consider subscribing for more insights and stories from this field.

This week, we’re returning to a topic I’m really excited about: Vibe Coding. That’s my term for using artificial intelligence to help us write code, sometimes with what feels like “punches and kicks” to get the AI to cooperate!

What is Vibe Coding and Why Bother?

Simply put, Vibe Coding is about leveraging AI, specifically Large Language Models (LLMs), to assist in software development. Why is this useful? Well, if you’re like me and have ambitious project ideas, or if you’re venturing into areas of coding where you’re not an expert, AI can be an incredible partner. It can help bridge knowledge gaps and accelerate development, especially for complex tasks.

The Project: Automating Zabbix Service Discovery and Correlation

Inspired by our good friend Zabbix, which always provides a wealth of project ideas, I embarked on a new challenge. My goal was to:

  • Automate the discovery of services running on hosts (both Windows and Linux).

  • Understand the relationships between these services – who is consuming what, and who is providing it.

  • Visualize these relationships through a user-friendly graphical interface.

  • And crucially, enable automatic correlation of problems to quickly identify root causes during outages.

A quick word of caution: always be skeptical of “automagic” solutions. Effective monitoring and problem correlation require solid data and context. As I often say, doubt who tells you that a monitoring system can make aggregation or magic around a problem if there is no information at the base.

For correlation, I decided to start with a combination of temporary correlation (events happening close in time) and severity/tag patterns, keeping things manageable for this initial phase.

Tools of the Trade for AI-Assisted Development

Embarking on this Vibe Coding journey required a specific toolkit:

  • Time and Patience: AI isn’t perfect. Sometimes it hallucinates or breaks code, so patience is key!

  • Visual Studio Code (VS Code): My preferred editor, especially with its Remote Node function, allowing me to develop on a dedicated VM and keep my main PC clean.

  • AI Coding Assistants: I explored both Roo Code and Cline. I leaned towards Roo Code due to its superior customization options.

  • OpenRouter Account: This is an API aggregator for various LLMs (GPT, Claude, Google, etc.). It’s fantastic because, with a small investment (say, €30 to start), you can experiment with multiple AI engines without committing to each platform individually.

Why Roo Code?

Roo Code stood out for a few reasons:

  • Customization: It offers more fine-tuning capabilities.

  • Checkpoint Feature: This is a lifesaver! It allows you to restore your code to a previous state (essentially a Git commit). When the AI goes off the rails and messes things up, this feature is invaluable. I had to activate this immediately.

  • The “Memory Bank” Concept: A game-changer for maintaining context, which we’ll dive into next.

A quick note on versions: I encountered some regressions with Roo Code version 3.16 that hindered my development, so I had to stick with version 3.15.5, which worked reliably for my setup.

The Power of “Memory Bank” in Vibe Coding

One of the most significant discoveries during this project was the “Memory Bank” feature within Roo Code. This isn’t science fiction; it’s a methodology for structuring the content of your code and interactions with the AI in an organized way. Essentially, it involves prompting the AI to save all useful information generated during your coding iterations into specific files within your project.

The benefits are huge:

  • Maintains Project Context: Even across different development sessions. If I work on the code today and come back tomorrow, the AI (and I!) can pick up right where we left off, with full awareness of previous decisions, implemented functions, and architectural choices.

  • Living Documentation: It helps document the project, including what functions were implemented and what the future goals are.

If you’re planning to do any Vibe Coding, I highly recommend exploring this Memory Bank approach. It makes a massive difference.

Navigating the LLM Landscape: My Experiments

Choosing the right LLM engine was an adventure in itself:

  • I started with OpenRouter and quickly burned through my initial $30 credit using Anthropic’s Claude 3 Opus (which I referred to as LLM Cloud 3.7 in the video). It’s incredibly powerful but can be expensive for extensive use.

  • This led me to explore running models locally on my “beast” of a machine (equipped with 3x RTX 8000 GPUs).

    • Qwen3 32B: This model showed great promise for coding, especially with its reasoning capabilities. However, even at FP16 precision (requiring about 60GB of VRAM), its 32,000-token context length was a bottleneck for my project, which had already exceeded 200,000 tokens of context with all the code and information. It did handle agentic features (tools) quite well, though.

    • GLM-4 32B: Another high-quality model for coding, capable of function calling and “thinking.” While impressive, the results weren’t quite what I needed for this specific project.

  • The Breakthrough: Google’s Gemini 2.5 Pro Experimental 0325 (as named in my video, likely referring to a specific version of Gemini 1.5 Pro available at the time). This model has been exceptional!

    • It performs on par with top-tier models like Claude 3 Opus.

    • Crucially, I could access it for free via OpenRouter (with some rate limits, but perfectly usable for development).

    • It supports thinking, tool use, and even image input, which means I can show the AI screenshots of the UI and explain desired changes visually. This multi-modal capability, combined with the Memory Bank, leads to much more interesting and accurate results.

If you’re looking to experiment without breaking the bank, I highly recommend trying the Gemini 2.5 Pro Experimental 0325 (or its current equivalent free tier) through OpenRouter. Google has done a fantastic job with this model.

Bringing it All Together: A Peek at the Zabbix Project POC

So, what did all this Vibe Coding produce? I’ve developed a Proof of Concept (POC) that I’m quite excited about. Here’s a glimpse of what it can do:

  • Visualizing Host Relationships: Using Vis.js for the graphical interface, I can select a host (e.g., a Zabbix server or a DB backend) and see its connections. For instance, it can show SSH connections, Zabbix agent communications, and which hosts are consuming its MySQL service.
    Zabbix Service Visualization Example

  • Service Discovery: I can query for all hosts exposing a particular service (e.g., all hosts with port 22 open) and see who is consuming those services.

  • Problem Correlation in Action: This is the core of the project. When problems arise in Zabbix:

    • The tool ingests active problems.

    • If I stop a critical service (like MySQL on a database server), the system correctly identifies this as the potential root cause.

    • It then flags dependent issues (like the Zabbix server application going down because its database is unavailable) as symptoms.

This correlation effectively pinpoints the source of the problem, which is incredibly valuable in complex infrastructures.

The Journey So Far and What’s Next

This project is very much a starting point, not the final destination. There’s so much more that can be done, especially around refining the correlation logic. My journey has been fueled by a passion for IT and learning – a passion I believe is essential in our field. (And yes, sometimes accompanied by the energetic beats of Tomorrowland, which I discovered is a fantastic coding soundtrack for me!)

If you work in IT, nurturing your curiosity and desire to learn is paramount. If you don’t find pleasure in understanding the tools and technologies you work with daily, it might be a sign to re-evaluate. Passion drives progress!

Join the Conversation!

This is where you come in! I’d love to hear your thoughts on this project. What do you think of the approach? Do you have suggestions for features or improvements? Could I tackle a different aspect of this? Your feedback is precious and will help shape the future direction of this development.

Please leave your comments below. Let me know what you think!

That’s all for today. Thanks again for watching and reading. I hope you found this dive into Vibe Coding and my Zabbix project interesting. Stay tuned for more adventures in the world of open source and IT!

Thanks to everyone, and see you next week.

Bye from Dimitri.

Connect with me:

Read More

0

Spice Up Your Zabbix Dashboards: Exploring the E-Chart Widget Module
By Dimitri Bellini02 May, 2025Blog

Spice Up Your Zabbix Dashboards: Exploring the E-Chart Widget Module

Good morning everyone, and welcome back! It’s Dimitri Bellini here from Quadrata, your go-to channel for the open-source and IT world that I love – and hopefully, you do too!

This week, we’re diving back into our good friend, Zabbix. Why? Because a contact from the vibrant Brazilian Zabbix community reached out to me. He shared a fascinating project he’s been working on, aimed at enhancing the visual appeal of Zabbix dashboards. I was intrigued, and after taking a look, I knew I had to share it with you.

The project is called E-Chart Zabbix, and as the name suggests, it leverages the powerful Apache ECharts library to bring fresh, dynamic visualizations into our Zabbix frontend.

Discovering Apache ECharts: A Hidden Gem for Data Visualization

Before we jump into the Zabbix module itself, let’s talk about the foundation: Apache ECharts. Honestly, I was blown away. I wasn’t aware of such a rich, well-crafted open-source ecosystem for graphic libraries. We’ve often searched for good charting solutions for client projects, and I wish we’d found these sooner!

ECharts offers a fantastic array of chart types, far beyond the standard Zabbix offerings. Just look at some of the demos:

  • Interactive charts with smooth animations when filtering data series.

  • Easy export to PNG format – a simple but often crucial feature.

  • A vast selection including various pie charts, heatmaps, geomaps, and even radar charts (great for visualizing multi-dimensional performance metrics).

It’s a treasure trove of inspiration for anyone needing to present data effectively. I definitely plan to explore these libraries more myself.

Introducing the E-Chart Zabbix Module by Monzphere

The E-Chart Zabbix module, developed by the folks at Monzphere (a Brazilian company creating both paid and open-source Zabbix extensions), takes a selection of these ECharts visualizations and integrates them as widgets directly into the Zabbix dashboard.

Here are some of the widgets included:

  • Low Level Discovery (LLD) Table: This is a standout feature! It addresses a common request: displaying LLD items (like network interface stats) in a structured table format. It cleverly uses item name patterns (e.g., *:bits received and *:bits sent) to automatically create columns for related metrics. This is incredibly useful for seeing RX/TX, errors, or other stats side-by-side for multiple interfaces.

  • Interface Load Visualization: A graph where the line width dynamically represents the load or traffic volume.

  • Treemap: Excellent for quickly identifying the most significant metrics in a dataset by representing values as proportionally sized rectangles.

  • Horizontal Bar Chart: A familiar format, but enhanced with the ability to use wildcards (*) in item patterns to easily include all metrics from an LLD rule.

  • Funnel Chart: Another great way to visually compare the magnitude of different metrics.

  • Water Effect Chart: A visually appealing gauge-like chart.

  • Sunburst/Donut Chart: A hierarchical visualization, useful for nested data.

Important Note: While testing (on Zabbix 7.0), I noticed a couple of things that seem to be works in progress. For instance, the LLD table didn’t automatically convert BPS values to KBPS/MBPS, and some charts like the Pie and Water Effect seemed to only display one metric even when configured with multiple. It’s a new project, so some rough edges are expected, but the potential is definitely there!

Installation Guide (Zabbix 7.0)

Ready to try it out? Here’s how to install the module (I tested this on Zabbix 7.0, compatibility with older versions isn’t specified):

  1. Download the Module:
    Go to the E-Chart Zabbix GitHub repository. Click the ‘Code’ button and copy the repository URL or download the ZIP file.

  2. Access Your Zabbix Server Console:
    SSH into your Zabbix server.

  3. Clone or Extract Files:
    Navigate to a temporary directory. If you copied the URL, use git clone:
    git clone https://github.com/monzphere/echart-zabbix.git
    Or, if you downloaded the ZIP, upload and unzip it:
    unzip echart-zabbix-main.zip (The exact filename might vary).

  4. Move Module Files:
    Copy the contents of the downloaded/cloned directory (it should contain files like `Module.php`, directories like `Widget`, etc.) into your Zabbix frontend modules directory. The target directory is typically:
    /usr/share/zabbix/modules/echart-zabbix
    You might need to create the `echart-zabbix` directory first. Use a command like:
    sudo mkdir /usr/share/zabbix/modules/echart-zabbix
    sudo cp -r echart-zabbix-main/* /usr/share/zabbix/modules/echart-zabbix/
    (Adjust paths and use `sudo` if necessary).

  5. Activate in Zabbix Frontend:
    Log in to your Zabbix web interface.
    Navigate to: Administration -> General -> Modules.

  6. Scan and Enable:
    Click the “Scan directory” button. You should see the “ECharts” module listed, likely authored by Monzphere. By default, it will be disabled. Click on the “Disabled” status to enable it.

Using the New Widgets

Once enabled, you can add these new widgets to any dashboard:

  1. Edit your desired dashboard.

  2. Click “Add widget”.

  3. For the “Type”, select “ECharts”.

  4. A new dropdown will appear allowing you to choose the specific ECharts widget type (Treemap, LLD Table, Funnel, etc.).

  5. Configure the widget, primarily by defining the “Item pattern” to select the data you want to display. You can use wildcards (*) here.

  6. Save the widget and the dashboard.

While the configuration options are currently quite basic, the results can already add a nice visual touch and, in the case of the LLD table, significant functional value.

Context and Final Thoughts

It’s true that Zabbix itself has made strides in visualization, especially with recent improvements to maps (as I covered in a previous video – check it out!), honeycomb views, and gauges. Playing with map backgrounds, icons, and color themes can drastically improve the user experience.

However, the E-Chart Zabbix module offers *different* kinds of visualizations that aren’t natively available. It complements the existing Zabbix features, providing more tools for specific data presentation needs. The LLD table alone is a compelling reason to check it out.

This project is a great example of the community extending Zabbix’s capabilities. While it needs refinement, I believe it’s worth supporting. Trying it out and providing constructive feedback to the developers via GitHub issues is the best way to help it mature.

A big thank you to the Monzphere team for this contribution!

What do you think? Have you tried the E-Chart Zabbix module or Apache ECharts? Do you have other favorite ways to enhance your Zabbix dashboards? Let me know in the comments below!

Don’t forget to join the conversation in the Zabbix Italia Telegram channel – it’s a great community (if you didn’t know it existed, now you do!).

And of course, if you found this useful, please give the video a thumbs up and subscribe to Quadrata for more open-source and IT content.

Thanks for watching/reading, and I’ll see you next week!

– Dimitri Bellini

Read More

0

Vibe Coding with AI: Building an Automatic Zabbix Service Map
By Dimitri Bellini24 April, 2025Blog

Vibe Coding with AI: Building an Automatic Zabbix Service Map

Good morning everyone! Dimitri Bellini here, back on the Quadrata channel, your spot for diving into the open-source world and IT topics I love – and hopefully, you do too!

If you enjoy these explorations, please give this video a thumbs up and subscribe if you haven’t already. Today, we’re venturing into the exciting intersection of coding, Artificial Intelligence, and Zabbix. I wanted to tackle a real-world challenge I faced: using AI to enhance Zabbix monitoring, specifically for event correlation.

Enter “Vibe Coding”: A Different Approach

Lately, there’s been a lot of buzz around “Vibe Coding.” What is it exactly? Honestly, it feels like a rather abstract concept! The general idea is to write code, perhaps in any language, by taking a more fluid, iterative approach. Instead of meticulous planning, designing flowcharts, and defining every function upfront, you start by explaining your goal to an AI and then, through a process of trial, error, and refinement (“kicks and punches,” as I jokingly put it), you arrive at a solution.

It’s an alternative path, potentially useful for those less familiar with specific languages, although I believe some foundational knowledge is still crucial to avoid ending up with a complete mess. It’s the method I embraced for the project I’m sharing today.

What You’ll Need for Vibe Coding:

  • Time and Patience: It’s an iterative process, sometimes frustrating!

  • Money: Accessing powerful AI models often involves API costs.

  • Tools: I used VS Code along with an AI coding assistant plugin. The transcript mentions “Cline” and “Roocode”; a popular and evolving option in this space is Continue.dev (which might be what was referred to, as tool names evolve). These tools integrate AI directly into the IDE.

The Zabbix Challenge: Understanding Service Dependencies

My initial goal was ambitious: leverage AI within Zabbix for better event correlation to pinpoint the root cause of problems faster. However, Zabbix presents some inherent challenges:

  • Standard Zabbix configurations (hosts, groups, tags) don’t automatically define the intricate dependencies *between* services running on different hosts.

  • Knowledge about these dependencies is often siloed within different teams in an organization, making manual mapping difficult and often incomplete.

  • Zabbix, by default, doesn’t auto-discover applications and their communication pathways across hosts.

  • Existing correlation methods (time-based, host groups, manually added tags) are often insufficient for complex scenarios.

Creating and maintaining a service map manually is incredibly time-consuming and struggles to keep up with dynamic environments. My objective became clear: find a way to automate service discovery and map the communications between them automatically.

My Goal: Smarter Event Correlation Through Auto-Discovery

Imagine a scenario with multiple Zabbix alerts. My ideal outcome was to automatically enrich these events with tags that reveal their relationships. For example, an alert on a CRM application could be automatically tagged as dependent on a specific database instance (DB Instance) because the system detected a database connection, or perhaps linked via an NFS share. This context is invaluable for root cause analysis.

My Vibe Coding Journey: Tools and Process

To build this, I leaned heavily on VS Code and the AI assistant plugin (let’s refer to it as Continue.dev for clarity, acknowledging the transcript’s terms “Cline/Clean”). The real power came from the Large Language Model (LLM) behind it.

AI Model Choice: Claude 3 Sonnet

While local, open-source models like Llama variants exist, I found they often lack the scale or require prohibitive resources for complex coding tasks. The most effective solution for me was using Claude 3 Sonnet via its API (provided by Anthropic). It performed exceptionally well, especially with the “tool use” features supported by Continue.dev, which seemed more effective than with other models I considered.

I accessed the API via OpenRouter, a handy service that acts as a broker for various AI models. This provides flexibility, allowing you to switch models without managing separate accounts and billing with each provider (like Anthropic, Google, OpenAI).

Lessons Learned: Checkpoints and Context Windows

  • Use Checkpoints! Continue.dev offers a “Checkpoint” feature. Vibe coding can lead you down wrong paths. Checkpoints let you revert your codebase. I learned the hard way that this feature relies on Git. I didn’t have it set up initially and had to restart significant portions of work. My advice: Enable Git and use checkpoints!

  • Mind the Context Window: When interacting with the AI, the entire conversation history (the context) is crucial. If the context window of the model is too small, it “forgets” earlier parts of the code or requirements, leading to errors and inconsistencies. Claude 3 Sonnet has a reasonably large context window, which was essential for this project’s success.

The Result: A Dynamic Service Map Application

After about three hours of work and roughly $10-20 in API costs (it might have been more due to some restarts!), I had a working proof-of-concept application. Here’s what it does:

  1. Connects to Zabbix: It fetches the list of hosts monitored by my Zabbix server.

  2. Discovers Services & Connections: For selected hosts, it retrieves information about running services and their network connections.

  3. Visualizes Dependencies: It generates a dynamic, interactive map showing the hosts and the communication links between them.

The “Magic Trick”: Using Netstat

How did I achieve the automatic discovery? The core mechanism is surprisingly simple, albeit a bit brute-force. I configured a Zabbix item on all relevant hosts to run the command:

netstat -ltunpa

This command provides a wealth of information about listening ports (services) and established network connections, including the programs associated with them. I added some preprocessing steps (initially aiming for CSV, though the core data comes from netstat) to make the data easier for the application to parse.

Live Demo Insights

In the video, I demonstrated the application live. It correctly identified:

  • My Zabbix server host.

  • Another monitored host (Graph Host).

  • My own machine connecting via SSH to the Zabbix host (shown as an external IP since it’s not monitored by Zabbix).

  • Connections between the hosts, such as the Zabbix agent communication (port 10050) and web server access (port 80).

  • Clicking on hosts or connections reveals more details, like specific ports involved.

While the visual map is impressive (despite some minor graphical glitches that are typical of the rapid Vibe Coding process!), the truly valuable output is the underlying relationship data. This data is the key to achieving the original goal: enriching Zabbix events.

Next Steps and Your Thoughts?

This application is a proof-of-concept, demonstrating the feasibility of automatic service discovery using readily available data (like netstat output) collected by Zabbix. The “wow effect” of the map is nice, but the real potential lies in feeding this discovered dependency information back into Zabbix.

My next step, time permitting, is to tackle the event correlation phase – using these discovered relationships to automatically tag Zabbix problems, making root cause analysis much faster and more intuitive.

What do you think? I’d love to hear your thoughts, ideas, and suggestions in the comments below!

  • Have you tried Vibe Coding or similar AI-assisted development approaches?

  • Do you face similar challenges with service dependency mapping in Zabbix or other monitoring tools?

  • Are there specific use cases you’d like me to explore further?

Don’t forget to like this post if you found it interesting, share it with others who might benefit, and subscribe to the Quadrata YouTube channel for more content like this!

You can also join the discussion on the ZabbixItalia Telegram Channel.

Thanks for reading, have a great week, and I’ll see you in the next video!

Bye from Dimitri.

Read More

0

Exploring Zabbix 7.4 Beta 1: What’s New and What I’m Hoping For
By Dimitri Bellini18 April, 2025Blog

Exploring Zabbix 7.4 Beta 1: What’s New and What I’m Hoping For

Good morning everyone! Dimitri Bellini here, back on the Quadrata channel – your spot for everything Open Source and the IT topics I find fascinating (and hopefully, you do too!). Thanks for tuning in each week. If you haven’t already, please consider subscribing and hitting that like button; it really helps the channel!

This week, we’re diving into something exciting: the latest Zabbix 7.4 Beta 1 release. This is a short-term support (STS) version, meaning it’s packed with new features that pave the way for the next Long-Term Support (LTS) release, expected later this year. With Beta 1 out and release candidates already tagged in the repositories, the official 7.4 release feels very close – likely within Q2 2024. So, let’s break down what’s new based on this first beta.

Key Features Introduced in Zabbix 7.4 Beta 1

While we don’t have that dream dashboard I keep showing (maybe one day, Zabbix team!), Beta 1 brings several practical and technical improvements.

Performance and Internals: History Cache Management

A significant technical improvement is the enhanced management of the history cache. Sometimes, items become disabled (manually or via discovery) but still occupy space in the cache, potentially causing issues. Zabbix 7.4 introduces:

  • Automatic Aging: Zabbix will now automatically clean up these inactive items from the cache.

  • Manual Aging Command: For environments with many frequently disabled objects, you can now manually trigger this cleanup at runtime using a command. This helps free up resources and maintain stability.

  • Cache Content Analysis: For troubleshooting, there are now better tools to analyze cache content and adjust log verbosity in real-time, which is invaluable in critical production environments.

UI and Widget Enhancements

  • Item History Widget Sorting: The Item History widget (introduced in 7.0) gets a much-needed update. When displaying logs, you can now choose to show the newest entries first, making log analysis much more intuitive than the old default (oldest first).

  • Test Item Value Copy Button: A small but incredibly useful UI tweak! When testing items, especially those returning large JSON payloads, you no longer need to manually select the text. There’s now a dedicated copy icon. Simple, but effective!

  • User Notification Management: Finally! Users can now manage their own notification media types (like email addresses) directly from their user settings via a dedicated menu. Previously, this required administrator intervention.

New Monitoring Capabilities

  • New ICMP Ping Item (`icmpping`): A new item key for ICMP checks includes a crucial `retry` option. This helps reduce noise and potential engine load caused by transient network issues. Instead of immediately flagging an object as unreachable/reachable and potentially triggering unnecessary actions or internal retries, you can configure it to try, say, 3 times before marking the item state as unreachable. This should lead to more stable availability monitoring.

  • New Timestamp Functions & Macros: We have new functions (like `item.history.first_clock`) that return timestamps of the oldest/newest values within an evaluation period. While the exact use case isn’t immediately obvious to me (perhaps related to upcoming event correlation or specific Windows monitoring scenarios?), having more tools for time-based analysis is interesting. Additionally, new built-in timestamp macros are available for use in notifications.

Major Map Enhancements

Maps receive some fantastic updates in 7.4, making them much more powerful and visually appealing:

  • Item Value Link Indicators: This is huge! Previously, link status (color/style) could only be tied to triggers. Now, you can base link appearance on:

    • Static: Just a simple visual link.

    • Trigger Status: The classic method.

    • Item Value: Define thresholds for numeric item values (e.g., bandwidth usage) or specific strings for text items (e.g., “on”/”off”) to change the link’s color and line style. This opens up possibilities for visualizing performance directly on the map without relying solely on triggers.

  • Auto-Hiding Labels: Tired of cluttered maps with overlapping labels? You can now set labels to hide by default and only appear when you hover over the element. This drastically improves readability for complex maps.

  • Scalable Background Images: Map background images will now scale proportionally to fit the map widget size, preventing awkward cropping or stretching.

One thing I’d still love to see, maybe before the final 7.4 release, is the ability to have multiple links between two map objects (e.g., representing aggregated network trunks).

New Templates and Integrations

Zabbix continues to expand its out-of-the-box monitoring:

  • Pure Storage FlashArray Template: Monitoring for this popular enterprise storage solution is now included.

  • Microsoft SQL for Azure Template: Enhanced cloud monitoring capabilities.

  • MySQL/Oracle Agent 2 Improvements: Simplifications for running custom queries directly via the Zabbix Agent 2 plugins.

What I’m Hoping For (Maybe 7.4, Maybe Later?)

Looking at the roadmap and based on some code movements I’ve seen, here are a couple of features I’m particularly excited about and hope to see soon, possibly even in 7.4:

  • Nested Low-Level Discovery (LLD): This would be a game-changer for dynamic environments. Imagine discovering databases, and then, as a sub-task, discovering the tables within each database using discovery prototypes derived from the parent discovery. This structured approach would simplify complex auto-discovery scenarios (databases, Kubernetes, cloud resources). I have a strong feeling this might make it into 7.4.

  • Event Correlation: My big dream feature! The ability to intelligently link related events, identifying the root cause (e.g., a failed switch) and suppressing the symptoms (all the hosts behind it becoming unreachable). This would significantly reduce alert noise and help focus on the real problem. It’s listed on the roadmap, but whether it lands in 7.4 remains to be seen.

  • Alternative Backend Storage: Also on the roadmap is exploring alternative backend solutions beyond traditional SQL databases (like potentially TimescaleDB alternatives, though not explicitly named). This is crucial groundwork for Zabbix 8.0 and beyond, especially for handling the massive data volumes associated with full observability (metrics, logs, traces).

  • New Host Wizard: A guided wizard for adding new hosts is also in development, which should improve the user experience.

Wrapping Up

Zabbix 7.4 is shaping up to be another solid release, bringing valuable improvements to maps, performance, usability, and monitoring capabilities. The map enhancements based on item values and the history cache improvements are particularly noteworthy from this Beta 1.

I’ll definitely keep you updated as we get closer to the final release and if features like Nested LLD or Event Correlation make the cut!

What do you think? Are these features useful for you? What are you hoping to see in Zabbix 7.4 or the upcoming Zabbix 8.0? Let me know in the comments below – I’m always curious to hear your thoughts and often pass feedback along (yes, I’m known for being persistent with the Zabbix team, like Alexey Vladyshev!).

Don’t forget to check out the Quadrata YouTube channel for more content like this.

And if you’re not already there, join the conversation in the ZabbixItalia Telegram Channel – it’s a great place to connect with other Italian Zabbix users.

That’s all for today. Thanks for reading, and I’ll catch you in the next one!

– Dimitri Bellini

Read More

0

I switched from Linux to MacOs: My First Month Experience
By Dimitri Bellini11 April, 2025Blog

I switched from Linux to MacOs: My First Month Experience

Good morning everyone, Dimitri Bellini here! Welcome back to my channel, Quadrata, where we dive into the world of open source and IT. If you’ve been following along, you’ll know I recently discussed my decision to potentially move from my trusty Linux setup to the world of Apple laptops.

Well, the temptation won. I bought it. After over 20 years deeply rooted in the Linux ecosystem, primarily using Fedora on various ThinkPads for the last decade, I took the plunge and acquired a MacBook Pro M4. It was a step I took with some apprehension, mainly driven by a quest for increased productivity and hardware that felt truly integrated and powerful, especially after my ThinkPad T14S started showing its age with battery life and overheating issues during video calls and rendering.

The Machine: Why the MacBook Pro M4?

I didn’t go for the Air as initially considered. I found a fantastic deal on a MacBook Pro M4 (around €1650), which made the decision easier. Here’s what I got:

  • CPU/GPU: 12 cores (4 performance, 8 efficiency) + GPU cores + Neural Engine

  • RAM: 24GB Unified Memory (great for VMs and local AI models)

  • Storage: 512GB SSD (the compromise for the price – 1TB was significantly more expensive)

  • Display: A stunning high-resolution display with excellent brightness.

Coming from years of using used ThinkPads – which were workhorses, true Swiss Army knives – this felt like a significant hardware upgrade, especially considering the price point I managed to secure.

Hardware Impressions: The Good, The Bad, and The Workarounds

Hardware: The Good Stuff

  • Battery Life: This is a game-changer. I’m easily getting 10-12 hours of normal use (coding, web browsing, conferences, shell usage). Standby time is phenomenal; I barely turn it off anymore. This was simply unattainable on my previous x86 Linux laptops.

  • Display: Truly gorgeous. It’s hard to compare with most laptops in the same price range I found this Mac in.

  • Touchpad: Exceptional. The haptic feedback and precision are on another level. It genuinely enhances the daily user experience.

  • Speakers: Finally! Decent built-in audio. I can actually listen to music with bass and clarity. This also translates to much better web call experiences – the microphone and speaker combination works so well I often don’t need a headset.

  • Performance (CPU/GPU/Neural Engine): It handles my workload smoothly. The real surprise was running local AI models. I tested Gemma 3 (around 10GB, 12 billion parameters) and got around 23 tokens/second. This opens up possibilities for local AI experimentation without needing a dedicated GPU rig.

  • USB-C Flexibility: Having three USB-C/Thunderbolt ports is adequate, and the ability to charge via any of them using a Power Delivery hub (which also connects my peripherals) is incredibly convenient. One cable does it all.

Hardware: The Not-So-Good

  • Keyboard: This is my biggest hardware gripe. The key travel is very shallow. While better than some cheap laptops, it feels like typing on plastic compared to the ThinkPad keyboards I’m used to.

  • Weight: At 1.6kg, the MacBook Pro is noticeably heavier than my old T14S. Quality materials add weight, I suppose.

  • Non-Upgradeable Storage: 512GB isn’t huge, and knowing I can’t upgrade it later means careful storage management is essential. You *must* choose your storage size wisely at purchase.

Hardware Workarounds

To address the storage limitation for non-critical files, I found a neat gadget: the BaseQi MicroSD Card Adapter. It sits flush in the SD card slot, allowing me to add a high-capacity MicroSD card (I used a SanDisk Extreme Pro) for documents and media. It’s not fast enough for active work or applications due to latency, but perfect for expanding storage for less performance-sensitive data. I sync these documents to the cloud as a backup.

For the keyboard, since I mostly work docked, I bought an external mechanical keyboard: the Epomaker EK68 (or possibly a similar model like the AJAZZ K820 Pro mentioned). It’s a 75% layout keyboard with great tactile feedback that I got for around €50 – a worthwhile investment for comfortable typing.

Diving into macOS: A Linux User’s Perspective

Okay, let’s talk software. Coming from the freedom and structure of Linux, macOS feels… different. Sometimes simple, sometimes restrictive.

The Frustrations

  • No Native Package Manager: This was jarring. Hunting for software online, downloading DMG files – it felt archaic compared to `apt` or `dnf`. The App Store exists, but often has weird pricing discrepancies compared to direct downloads, and doesn’t have everything.

  • The Dock: I used to admire it from afar on Linux. Now that I have it? I find it mostly useless. It takes up space and doesn’t offer the workflow benefits I expected.

  • Finder (File Manager): Oh, Finder. It feels incredibly basic. Simple tasks like moving files often default to copy-paste. Customizing it to show path bars or folder info requires digging into options. Searching defaults to the entire Mac instead of the current folder, which is maddening. It feels permeated throughout the OS and hard to escape.

  • Application Closing: Clicking the ‘X’ often just minimizes the app instead of closing it. You need to explicitly Quit (Cmd+Q) or Force Quit. It’s a different paradigm I’m still adjusting to.

  • Monotasking Feel: The OS seems optimized for focusing on one application at a time. While this might benefit single-app workflows (video editing, music production), it feels less efficient for my typical multi-tasking sysadmin/developer style. The strong single-core performance seems to reflect this philosophy.

  • System Settings/Control Center: There are *so many* options, and finding the specific setting you need can feel like a maze.

The Silver Linings & Essential Tools

It’s not all bad, of course. The UI, while sometimes frustrating, is generally coherent. And thankfully, the community has provided solutions:

  • Homebrew: This is **ESSENTIAL**. It brings a proper package manager experience to macOS (`brew install `). It makes installing and updating software (especially open-source tools) sane. Install this first!

  • iTerm2: A vastly superior terminal emulator compared to the default Terminal. Highly customizable and brings back a familiar Linux-like terminal experience.

  • Oh My Zsh (or Oh My Bash): Customizes the shell environment for a better look, feel, and useful shortcuts/plugins. Works great with iTerm2.

  • Forklift: A paid, dual-pane file manager. It’s my current replacement for Finder, offering features like tabs, sync capabilities (Google Drive, etc.), and a more productive interface. Still evaluating, but much better than Finder for my needs.

  • Zed: A fast, modern code and text editor. It starts quickly and handles my text editing needs well.

  • LibreOffice: My go-to office suite. Works perfectly via Homebrew (`brew install libreoffice`).

  • Inkscape & GIMP: Open-source staples for vector and raster graphics. Both easily installable via Homebrew (`brew install inkscape gimp`) and cover my needs perfectly.

  • Latest: A handy utility (installable via Brew) that scans your applications (even those not installed via Brew or the App Store) and notifies you of available updates. Helps manage the entropy of different installation methods.

  • WireGuard & Tunnelblick: Essential VPN clients. WireGuard has an official client, and Tunnelblick is my preferred choice for OpenVPN connections on macOS.

Key System Setting Tweaks

After watching countless videos, here are a few settings I changed immediately:

  • Window Tiling (Sequoia+): Enabled tiling but *removed the margins* between windows to maximize screen real estate.

  • Touchpad: Enabled “Secondary Click” (two-finger tap) for right-click functionality.

  • Dock: Enabled “Show battery percentage”. Set the Dock to “Automatically hide and show”. Removed unused default app icons and recent application suggestions to minimize clutter.

The Verdict After One Month

So, am I happy? It’s complicated.

The hardware is undeniably premium. The performance, display, battery life, and touchpad are fantastic. For the price I paid, it feels like great value in that regard.

However, productivity isn’t magically perfect. macOS has its own quirks, bugs, and limitations. Using third-party (especially open-source) applications doesn’t always feel as seamless as on Linux. The “it just works” mantra isn’t universally true.

The software experience requires adaptation and, frankly, installing several third-party tools to replicate the workflow I was comfortable with on Linux. Homebrew is the saving grace here.

Overall, it’s a high-quality machine with some frustrating software paradigms for a long-time Linux user. The experience is *coherent*, which is better than the sometimes fragmented feel of Windows, but coherence doesn’t always mean *better* for my specific needs.

Will I stick with it? Time will tell. Maybe in another month, I’ll be fully converted. Or maybe I’ll be cheering even louder for the Asahi Linux project to bring full Linux support to the M4 chips!

What Are Your Thoughts?

This is just my experience after one month. I’m still learning! What are your tips for a Linux user transitioning to macOS? What essential apps or settings have I missed? Let me know in the comments below!

If you found this useful, please give the video a thumbs up, share it, and subscribe to the Quadrata YouTube channel if you haven’t already!

Also, feel free to join the discussion on the ZabbixItalia Telegram Channel.

Thanks for reading, and see you next week!

– Dimitri Bellini

Read More

0

Automating My Video Workflow with N8N and AI: A Real-World Test
By Dimitri Bellini03 April, 2025Blog

Automating My Video Workflow with N8N and AI: A Real-World Test

Good morning everyone, Dimitri Bellini here! Welcome back to Quadrata, my channel dedicated to the open-source world and the IT topics I find fascinating – and hopefully, you do too.

This week, I want to dive back into artificial intelligence, specifically focusing on a tool we’ve touched upon before: N8N. But instead of just playing around, I wanted to tackle a real problem I face every week: automating the content creation that follows my video production.

The Challenge: Bridging the Gap Between Video and Text

Making videos weekly for Quadrata is something I enjoy, but the work doesn’t stop when the recording ends. There’s the process of creating YouTube chapters, writing blog posts, crafting LinkedIn announcements, and more. These tasks, while important, can be time-consuming. My goal was to see if AI, combined with a powerful workflow tool, could genuinely simplify these daily (or weekly!) activities.

Could I automatically generate useful text content directly from my video’s subtitles? Let’s find out.

The Toolkit: My Automation Stack

To tackle this, I assembled a few key components:

  • N8N: An open-source workflow automation tool that uses a visual, node-based interface. It’s incredibly versatile and integrates with countless services. We’ll run this using Docker/Docker Compose.

  • AI Models: I experimented with two approaches:

    • Local AI with Ollama: Using Ollama to run models locally, specifically testing Gemma 3 (27B parameters). The latest Ollama release (0.1.60 at the time of recording, though versions update) offers better support for models like Gemma.

    • Cloud AI with Google AI Studio: Leveraging the power of Google’s models via their free API tier, primarily focusing on Gemini 2.5 Pro due to its large context window and reasoning capabilities.

  • Video Transcripts: The raw material – the subtitles generated for my YouTube videos.

Putting it to the Test: Automating Video Tasks with N8N

I set up an N8N workflow designed to take my video transcript and process it through AI to generate different outputs. Here’s how it went:

1. Getting the Transcript

The first step was easy thanks to the N8N community. I used a community node called “YouTube Transcript” which, given a video URL, automatically fetches the subtitles. You can find and install community nodes easily via the N8N settings.

2. Generating YouTube Chapters

This was my first major test. I needed the AI to analyze the transcript and identify logical sections, outputting them in the standard YouTube chapter format (00:00:00 - Chapter Title).

  • Local Attempt (Ollama + Gemma 3): I configured an N8N “Basic LLM Chain” node to use my local Ollama instance running Gemma 3. I set the context length to 8000 tokens and the temperature very low (0.1) to prevent creativity and stick to the facts. The prompt was carefully crafted to explain the desired format, including examples.

    Result: Disappointing. While it generated *some* chapters, it stopped very early in the video (around 6 minutes for a 25+ minute video), missing the vast majority of the content. Despite the model’s theoretical capabilities, it failed this task with the given transcript length and my hardware (RTX 8000 GPUs – good, but maybe not enough or Ollama/model limitations).

  • Cloud Attempt (Google AI Studio + Gemini 2.5 Pro): I switched the LLM node to use the Google Gemini connection, specifically targeting Gemini 2.5 Pro with a temperature of 0.2.

    Result: Much better! Gemini 2.5 Pro processed the entire transcript and generated accurate, well-spaced chapters covering the full length of the video. Its larger context window and potentially more advanced reasoning capabilities handled the task effectively.

For chapter generation, the cloud-based Gemini 2.5 Pro was the clear winner in my tests.

3. Crafting the Perfect LinkedIn Post

Next, I wanted to automate the announcement post for LinkedIn. Here, the prompt engineering became even more crucial. I didn’t just want a generic summary; I wanted it to sound like *me*.

  • Technique: I fed the AI (Gemini 2.5 Pro again, given the success with chapters) a detailed prompt that included:

    • The task description (create a LinkedIn post).

    • The video transcript as context.

    • Crucially: Examples of my previous LinkedIn posts. This helps the AI learn and mimic my writing style and tone.

    • Instructions on formatting and including relevant hashtags.

    • Using N8N variables to insert the specific video link dynamically.

  • Result: Excellent! The generated post was remarkably similar to my usual style, captured the video’s essence, included relevant tags, and was ready to be published (with minor review).

4. Automating Blog Post Creation

The final piece was generating a draft blog post directly from the transcript.

  • Technique: Similar to the LinkedIn post, but with different requirements. The prompt instructed Gemini 2.5 Pro to:

    • Generate content in HTML format for easy pasting into my blog.

    • Avoid certain elements (like quotation marks unless necessary).

    • Recognize and correctly format specific terms (like “Quadrata”, my name “Dimitri Bellini”, or the “ZabbixItalia Telegram Channel” – https://t.me/zabbixitalia).

    • Structure the text logically with headings and paragraphs.

    • Include basic SEO considerations.

  • Result: Success again! While it took a little longer to generate (likely due to the complexity and length), the AI produced a well-structured HTML blog post draft based on the video content. It correctly identified and linked the channels mentioned and formatted the text as requested. This provides a fantastic starting point, saving significant time.

Key Takeaways and Challenges

This experiment highlighted several important points:

  • Prompt Engineering is King: The quality of the AI’s output is directly proportional to the quality and detail of your prompt. Providing examples, clear formatting instructions, and context is essential. Using AI itself (via web interfaces) to help refine prompts is a valid strategy!

  • Cloud vs. Local AI Trade-offs:

    • Cloud (Gemini 2.5 Pro): Generally more powerful, handled long contexts better in my tests, easier setup (API key). However, subject to API limits (even free tiers have them, especially for frequent/heavy use) and potential costs.

    • Local (Ollama/Gemma 3): Full control, no API limits/costs (beyond hardware/electricity). However, requires capable hardware (especially GPU RAM for large contexts/models), and smaller models might struggle with complex reasoning or very long inputs. Performance was insufficient for my chapter generation task in this test.

  • Model Capabilities Matter: Gemini 2.5 Pro’s large context window and reasoning seemed better suited for processing my lengthy video transcripts compared to the 27B parameter Gemma 3 model run locally (though further testing with different local models or configurations might yield different results).

  • Temperature Setting: Keeping the temperature low (e.g., 0.1-0.2) is vital for tasks requiring factual accuracy and adherence to instructions, minimizing AI “creativity” or hallucination.

  • N8N is Powerful: It provides the perfect framework to chain these steps together, handle variables, connect to different services (local or cloud), and parse outputs (like the Structured Output Parser node for forcing JSON).

Conclusion and Next Steps

Overall, I’m thrilled with the results! Using N8N combined with a capable AI like Google’s Gemini 2.5 Pro allowed me to successfully automate the generation of YouTube chapters, LinkedIn posts, and blog post drafts directly from my video transcripts. While the local AI approach didn’t quite meet my needs for this specific task *yet*, the cloud solution provided a significant time-saving and genuinely useful outcome.

The next logical step is to integrate the final publishing actions directly into N8N using its dedicated nodes for YouTube (updating descriptions with chapters) and LinkedIn (posting the generated content). This would make the process almost entirely hands-off after the initial video upload.

This is a real-world example of how AI can move beyond novelty and become a practical tool for automating tedious tasks. It’s not perfect, and requires setup and refinement, but the potential to streamline workflows is undeniable.

What do you think? Have you tried using N8N or similar tools for AI-powered automation? What are your favourite use cases? Let me know in the comments below! And if you found this interesting, give the video a thumbs up and consider subscribing to Quadrata for more content on open source and IT.

Thanks for reading, and see you next week!

Bye everyone,
Dimitri

Read More

0

Unlock Powerful Visualizations: Exploring Zabbix 7.0 Dashboards
By Dimitri Bellini31 March, 2025Blog

Unlock Powerful Visualizations: Exploring Zabbix 7.0 Dashboards

Good morning everyone! Dimitri Bellini here, back with another episode on Quadrata, my channel dedicated to the world of open source and IT. Today, we’re diving back into our favorite monitoring tool, Zabbix, but focusing on an area we haven’t explored much recently: **data visualization and dashboarding**, especially with the exciting improvements in Zabbix 7.0.

For a long time, many of us (myself included!) might have leaned towards Grafana for sophisticated dashboards, and rightly so – it set a high standard. However, Zabbix has been working hard, taking inspiration from the best, and Zabbix 7.0 introduces some fantastic new widgets and capabilities that significantly boost its native dashboarding power, pushing towards better observability of our collected metrics.

Why Zabbix Dashboards Now Deserve Your Attention

Zabbix 7.0 marks a significant step forward in visualization. The web interface’s dashboard section has received substantial upgrades, introducing new widgets that make creating informative and visually appealing dashboards easier than ever. Forget needing a separate tool for basic visualization; Zabbix now offers compelling options right out of the box.

Some of the key additions in 7.0 include:

  • Gauge Widgets: For clear, immediate visualization of single metrics against thresholds.

  • Pie Chart / Donut Widgets: Classic ways to represent proportions.

  • On-Icon Widget: Excellent for compactly displaying the status of many items (like host availability).

  • Host Navigator & Item Navigator: Powerful tools for creating dynamic, interactive dashboards where you can drill down into specific hosts and their metrics.

  • Item Value Widget: Displays a single metric’s value with trend indication.

Building a Dynamic Dashboard in Zabbix 7.0: A Walkthrough

In the video, I demonstrated how to leverage some of these new features. Let’s recap the steps to build a more dynamic and insightful dashboard:

Step 1: Creating Your Dashboard

It all starts in the Zabbix interface under Dashboards -> All dashboards. Click “Create dashboard”, give it a meaningful name (I used “test per video”), and you’ll be presented with an empty canvas, ready for your first widget.

Step 2: Adding the Powerful Graph Widget

The standard graph widget, while not brand new, has become incredibly flexible.

  • Host/Item Selection: You can use wildcards (*) for both hosts (e.g., Linux server*) and items (e.g., Bits received*) to aggregate data from multiple sources onto a single graph.

  • Aggregation: Easily aggregate data over time intervals (e.g., show the sum or average traffic every 3 minutes).

  • Stacking: Use the “Stacked” option combined with aggregation to visualize total resource usage (like total bandwidth across multiple servers).

  • Multiple Datasets: Add multiple datasets (like ‘Bits received’ and ‘Bits sent’) to the same graph for comprehensive views.

  • Customization: Control line thickness, fill transparency, handling of missing data, axis limits (e.g., setting a max bandwidth), legend display, and even overlay trigger information or working hours.

This allows for creating dense, informative graphs showing trends across groups of systems or interfaces.

Step 3: Introducing Interactivity with Navigators

This is where Zabbix 7.0 dashboards get really dynamic!

Host Navigator Setup

Add the “Host Navigator” widget. Configure it to target a specific host group (e.g., Linux Servers). You can further filter by host status (enabled/disabled), maintenance status, or tags. This widget provides a clickable list of hosts.

Item Navigator Setup

Next, add the “Item Navigator” widget. The key here is to link it to the Host Navigator:

  • In the “Host” selection, choose “From widget” and select your Host Navigator widget.

  • Specify the host group again.

  • Use “Item tags” to filter the list of items shown (e.g., show only items with the tag component having the value network).

  • Use “Group by” (e.g., group by the component tag) to organize the items logically within the navigator. (Note: In the video, I noticed a slight confusion where the UI might label tag value filtering as tag name, something to keep an eye on).

Now, clicking a host in the Host Navigator filters the items shown in the Item Navigator – the first step towards interactive drill-down!

Step 4: Visualizing Single Metrics (Gauge & Item Value)

With the navigators set up, we can add widgets that react to our selections:

Gauge Widget

Add a “Gauge” widget. Configure its “Item” setting to inherit “From widget” -> “Item Navigator”. Now, when you select an item in the Item Navigator (after selecting a host), this gauge will automatically display that metric’s latest value. Customize it with:

  • Min/Max values and units (e.g., %, BPS).

  • Thresholds (defining ranges for Green, Yellow, Red) for instant visual feedback.

  • Appearance options (angles, decimals).

Item Value Widget

Similarly, add an “Item Value” widget, also inheriting its item from the “Item Navigator”. This provides a simple text display of the value, often with a trend indicator (up/down arrow). You can customize:

  • Font size and units.

  • Whether to show the timestamp.

  • Thresholds that can change the background color of the widget for high visibility.

Step 5: Monitoring Multiple Hosts with On-Icon

The “On-Icon” widget is fantastic for a compact overview of many similar items across multiple hosts.

  • Configure it to target a host group (e.g., Linux Servers).

  • Select a specific item pattern relevant to status (e.g., agent.ping).

  • Set thresholds (e.g., Red if value is 0, Green if value is 1) to color-code each host’s icon based on the item value.

This gives you an immediate “at-a-glance” view of the health or status of all hosts in the group regarding that specific metric. The icons automatically resize to fit the widget space.

Putting It All Together

By combining these widgets – graphs for trends, navigators for interactivity, and gauges/item values/on-icons for specific states – you can build truly powerful and informative dashboards directly within Zabbix 7.0. The ability to dynamically filter and drill down without leaving the dashboard is a massive improvement.

Join the Conversation!

So, that’s a first look at the enhanced dashboarding capabilities in Zabbix 7.0. There’s definitely a lot to explore, and these new tools significantly improve how we can visualize our monitoring data.

What do you think? Have you tried the new Zabbix 7.0 dashboards? Are there specific widgets or features you’d like me to cover in more detail? Let me know in the comments below!

If you found this useful, please give the video a thumbs up and consider subscribing to the Quadrata YouTube channel for more content on open source and IT.

And don’t forget to join the conversation in the ZabbixItalia Telegram Channel – it’s a great place to ask questions and share knowledge with fellow Zabbix users.

Thanks for reading, and I’ll see you in the next one!

– Dimitri Bellini

Read More

0

Zabbix 7.0 Synthetic Monitoring: A Game Changer for Web Performance Testing
By Dimitri Bellini31 March, 2025Blog

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!

I hope this overview gives you a solid start with Zabbix 7’s synthetic monitoring. It’s a feature with immense potential.

What do you think? Have you tried it yet, or do you have specific use cases in mind? Let me know in the comments below!

If you found this video helpful, please give it a thumbs up and consider subscribing to the Quadrata channel for more open-source and IT content.

Don’t forget to join our Italian Zabbix community on Telegram: ZabbixItalia!

Thanks for watching, and see you next week. Bye everyone!

Read More

0

Zabbix 7.0 LTS is Almost Here: A Deep Dive into the Next Generation of Monitoring
By Dimitri Bellini31 March, 2025Blog

Zabbix 7.0 LTS is Almost Here: A Deep Dive into the Next Generation of Monitoring

Good morning everyone, Dimitri Bellini here from the Quadrata channel! It’s fantastic to have you back on my corner of the internet dedicated to the world of open source and IT. First off, a huge thank you – we’ve recently crossed the 800 subscriber mark, which is amazing! My goal is to hit 1000 this year, so if you haven’t already, please consider subscribing!

This week, we’re diving into something truly exciting: the upcoming release of Zabbix 7.0. It’s just around the corner, and while we wait for the final release, the Release Candidate 1 already packs all the features we expect to see. So, let’s explore what makes this version so special.

Why Zabbix 7.0 LTS is a Game Changer

Zabbix 7.0 isn’t just another update; it’s an LTS (Long Term Support) version. This is crucial because LTS releases are designed for stability and longevity, typically receiving support for three years (extendable to five for security). This makes them the ideal choice for production environments where reliability and long-term planning are paramount. Updating complex systems isn’t always easy, so an LTS version provides that much-needed stability.

The previous LTS, version 6.0, was released back in February 2022. While the usual cycle is about 1.5 years between LTS versions, 7.0 took a bit longer. This extended development time was necessary to incorporate significant changes, both under the hood and in terms of user-facing features. Trust me, the wait seems worth it!

Don’t panic if you’re on 6.0 – full support continues until February 28, 2025. You have ample time to plan your migration. In fact, I often suggest waiting for a few minor point releases (like 7.0.3 or 7.0.5) to let the dust settle before deploying in critical environments.

Bridging the Gap: Key Enhancements Since Zabbix 6.0

Since many users stick with LTS versions in production and might have skipped the intermediate 6.2 and 6.4 releases, I want to cover the major improvements introduced between 6.0 and 7.0. There’s a lot to unpack!

Performance, Scalability, and Architecture Boosts

  • Automatic Configuration Sync (Server-Proxy-Agent): This is huge! Previously, configuration changes on the GUI could take time (often a minute or more by default) to propagate through the server, proxies, and agents due to database polling cycles. Now, changes trigger near-instantaneous updates across the chain using a differential sync mechanism. This means faster deployments of new hosts and checks, and less load as only the *changes* are pushed.

  • SNMP Bulk Monitoring: Instead of multiple individual `get` requests, Zabbix can now group SNMP requests, reducing load on both the Zabbix server and the monitored devices.

  • Asynchronous Polling: Passive checks (SNMP, HTTP, Zabbix agent passive) are now asynchronous. The server sends the request and moves on, processing the data as it arrives. This significantly improves scalability, especially for large environments.

  • Proxy High Availability (HA) and Load Balancing: Finally! You can group proxies together for automatic failover and load balancing. If a proxy in the group fails, its assigned hosts are automatically redistributed to other available proxies in the group. We’ll look at a demo of this shortly!

  • Customizable Item Timeouts: The previous global 30-second timeout limit is gone. Now you can set timeouts per item (up to 10 minutes), providing flexibility for checks that naturally take longer.

  • Proxy Backward Compatibility: Upgrading is now less stressful. A Zabbix 7.0 server can work with 6.0 proxies in an “outdated” state. They’ll continue sending data and executing remote commands, giving you time to upgrade the proxies without a complete “big bang” cutover. Configuration updates for hosts on outdated proxies won’t work, however.

Enhanced Integrations and User Management

  • LDAP/AD Just-in-Time (JIT) User Provisioning: A highly requested feature for enterprise environments. Zabbix can now automatically create and update user accounts based on your Active Directory or LDAP server upon their first login. You can map attributes like email and phone numbers, and even assign Zabbix roles based on AD/LDAP groups. Plus, support for multiple LDAP servers is included.

  • Expanded Vault Support: Alongside HashiCorp Vault, Zabbix 7.0 now integrates with CyberArk for external secret management.

  • Real-time Data Streaming: Push metrics and events efficiently to external systems like Kafka or Splunk. Crucially, you can filter what gets sent based on tags (e.g., send only high-priority events, or only network-related metrics), allowing for sophisticated data routing to different data lakes or analysis tools.

Improved Monitoring & User Experience

  • Advanced Web Monitoring with Selenium: This is potentially revolutionary for Zabbix. The web monitoring capabilities have been rebuilt using Selenium, allowing you to simulate real user interactions (clicking buttons, filling forms) and monitor user experience, page performance, and functionality directly within Zabbix.

  • Manual Problem Suppression: Acknowledge known issues or problems occurring during maintenance windows by suppressing them temporarily (indefinitely or for a defined period). They’ll reappear if the issue persists after the suppression window.

  • Clearer Agent Availability: The agent availability status is now more intuitive, incorporating a heartbeat mechanism to clearly show if an agent (active or passive) is truly up and running. The corresponding dashboard widget has also been revamped.

  • UI and Template Upgrades: Continuous improvements to the graphical interface, new widgets (like improved pie charts/gauges), and significantly enhanced templates, especially for VMware, AWS, Azure, and Google Cloud monitoring.

  • OS Prototype Functionality Extension: More flexibility in managing discovered hosts, including adding templates and tags more easily.

Hands-On: Exploring Proxy High Availability (Demo Recap)

I set up a quick Docker environment with a Zabbix 7.0 RC1 server and three proxies to test the new Proxy HA feature. Here’s a summary of how it works:

  1. Create a Proxy Group: Under `Administration -> Proxy groups`, define a group (e.g., “MyHAProxies”). Set the `Failover period` (how quickly hosts move after a proxy failure – I used 1 minute for the demo) and the `Minimum available proxies` (the minimum number needed for the group to be considered operational).

  2. Assign Proxies to the Group: Edit each proxy you want in the group (`Administration -> Proxies`) and assign it to the created Proxy Group. You also need to specify the proxy address for active agents, as agent configuration changes with this feature.

  3. Assign Hosts to the Proxy Group: When configuring a host, instead of selecting a specific proxy, select the Proxy Group. Zabbix automatically assigns the host to the least loaded proxy within that group initially.

  4. Simulate Failure: I stopped one of the proxy containers.

  5. Observe Failover: After the configured failover period (1 minute), Zabbix detected the proxy was down. The hosts monitored by that proxy were automatically redistributed among the remaining two active proxies in the group. Crucially, checking the `Latest data` for a moved host showed minimal interruption in data collection.

  6. Recovery: When I restarted the stopped proxy, Zabbix detected it coming back online. After a stabilisation period (to avoid flapping), it automatically started rebalancing the hosts back across all three proxies.

  7. Monitoring the Group: A new internal item `zabbix[proxy_group,,state]` allows you to monitor the health of the proxy group itself (e.g., online, degraded). This is essential for alerting! (Note: I’ve asked the Zabbix team to add this to the default server health template).

This feature significantly enhances the resilience of your Zabbix monitoring infrastructure, especially in distributed environments.

Planning Your Upgrade to Zabbix 7.0

Upgrading requires careful planning. Here’s a checklist:

  • Read the Release Notes: Understand all the new features and changes.

  • Check Requirements: Ensure your OS, database, and library versions meet the new requirements for Zabbix 7.0. You might need to upgrade your underlying infrastructure (e.g., moving from RHEL 7 to RHEL 8 or 9).

  • Review Breaking Changes & Known Issues: The official Zabbix documentation has sections dedicated to these. Pay close attention to avoid surprises.

  • CRITICAL: Primary Keys: Zabbix 6.0 introduced optional primary keys for history tables. If you upgraded from 5.x to 6.x and didn’t manually add them (it could be a slow process), **now is the time**. While Zabbix 7.0 *might* run without them, future versions *will require* them. Adding primary keys also provides a significant performance boost (often 20%+). Factor this database maintenance into your upgrade plan if needed.

  • Follow the Official Upgrade Procedure: Stick to the step-by-step guide in the Zabbix documentation for your specific environment.

  • Backup Everything: Before you start, ensure you have reliable backups of your Zabbix database and configuration files.

Conclusion: Get Ready for Zabbix 7.0!

Zabbix 7.0 LTS is shaping up to be a monumental release. The focus on scalability, high availability, usability, and deeper integration makes it incredibly compelling for both existing users and those considering Zabbix for their monitoring needs. Features like Proxy HA, LDAP JIT provisioning, and the new Selenium-based web monitoring are truly exciting developments.

I’ll definitely be exploring the new web monitoring capabilities in more detail once the documentation is fully available, so stay tuned for that!

What feature in Zabbix 7.0 are you most excited about? Let me know in the comments below!

If you found this overview helpful, please give the video a thumbs up, share it, and subscribe to Quadrata to help us reach that 1000 subscriber goal!

Also, feel free to join the discussion on the ZabbixItalia Telegram Channel.

Thanks for watching/reading, have a great week, and see you next time!

– Dimitri Bellini

Read More

0

Visualizing Your Infrastructure: A Deep Dive into Zabbix Maps
By Dimitri Bellini31 March, 2025Blog

Visualizing Your Infrastructure: A Deep Dive into Zabbix Maps

Good morning everyone, Dimitri Bellini here, and welcome back to Quadrata – your go-to channel for open source and IT solutions! Today, I want to dive into a feature of our good friend Zabbix that we haven’t explored much yet: Zabbix Maps.

Honestly, I was recently working on some maps, and while it might not always be the most glamorous part of Zabbix, it sparked an idea: why not share what these maps are truly capable of, and perhaps more importantly, what they aren’t?

What Zabbix Maps REALLY Are: Your Digital Synoptic Panel

Think of Zabbix Maps as the modern, digital equivalent of those old-school synoptic panels with blinking lights. They provide a powerful graphical way to represent your infrastructure and its status directly within Zabbix. Here’s what you can achieve:

  • Real-time Host Status: Instantly see the overall health of your hosts based on whether they have active problems.

  • Real-time Event Representation: Visualize specific problems (triggers) directly on the map. Imagine a specific light turning red only when a critical service fails.

  • Real-time Item Metrics: Display actual data values (like temperature, traffic throughput, user counts) directly on your map, making data much more intuitive and visually appealing.

The core idea is to create a custom graphical overview tailored to your specific infrastructure, giving you an immediate understanding of what’s happening at a glance.

Clearing Up Misconceptions: What Zabbix Maps Are NOT

It’s crucial to understand the limitations to use maps effectively. Often, people hope Zabbix Maps will automatically generate network topology diagrams.

  • They are NOT Automatic Network Topology Maps: While you *could* manually build something resembling a network diagram, Zabbix doesn’t automatically discover devices and map their connections (who’s plugged into which switch port, etc.). Tools that attempt this often rely on protocols like Cisco’s CDP or the standard LLDP (both usually SNMP-based), which aren’t universally available across all devices. Furthermore, in large environments (think thousands of hosts and hundreds of switches), automatically generated topology maps quickly become an unreadable mess of tiny icons and overlapping lines. They might look cool initially but offer little practical value day-to-day.

  • They are NOT Application Performance Monitoring (APM) Relationship Maps (Yet!): Zabbix Maps don’t currently visualize the intricate relationships and data flows between different application components in the way dedicated APM tools do. While Zabbix is heading towards APM capabilities, the current map function isn’t designed for that specific purpose.

For the nitty-gritty details, I always recommend checking the official Zabbix documentation – it’s an invaluable resource.

Building Blocks of a Zabbix Map

When constructing your map, you have several element types at your disposal:

  • Host: Represents a monitored device. Its appearance can change based on problem severity.

  • Trigger: Represents a specific problem condition. You can link an icon’s appearance directly to a trigger’s state.

  • Map: Allows you to create nested maps. The icon for a sub-map can reflect the most severe status of the elements within it – great for drilling down!

  • Image: Use custom background images or icons to make your map visually informative and appealing.

  • Host Group: Automatically display all hosts belonging to a specific group within a defined area on the map.

  • Shape: Geometric shapes (rectangles, ellipses) that can be used for layout, grouping, or, importantly, displaying text and real-time data.

  • Link: Lines connecting elements. These can change color or style based on a trigger’s status, often used to represent connectivity or dependencies.

Zabbix also provides visual cues like highlighting elements with problems or showing small triangles to indicate a recent status change, helping you focus on what needs attention.

Bringing Maps to Life with Real-Time Data

One of the most powerful features is embedding live data directly onto your map. Instead of just seeing if a server is “up” or “down,” you can see its current CPU load, network traffic, or application-specific metrics.

This is typically done using Shapes and a specific syntax within the shape’s label. In Zabbix 6.x and later, the syntax looks something like this:

{?last(/Your Host Name/your.item.key)}

This tells Zabbix to display the last received value for the item your.item.key on the host named Your Host Name. You can add descriptive text around it, like:

CPU Load: {?last(/MyWebServer/system.cpu.load[,avg1])}

Zabbix is smart enough to often apply the correct unit (like Bps, %, °C) automatically if it’s defined in the item configuration.

Let’s Build a Simple Map (Quick Guide)

Here’s a condensed walkthrough based on what I demonstrated in the video (using Zabbix 6.4):

  1. Navigate to Maps: Go to Monitoring -> Maps.

  2. Create New Map: Click “Create map”. Give it a name (e.g., “YouTube Test”), set dimensions, and optionally choose a background image.

    • Tip: You can upload custom icons and background images under Administration -> General -> Images. I uploaded custom red/green icons and a background for the demo.

  3. Configure Map Properties: Decide on options like “Icon highlighting” (the colored border around problematic hosts) and “Mark elements on trigger status change” (the triangles for recent changes). You can also filter problems by severity or hide labels if needed. Click “Add”.

  4. Enter Constructor Mode: Open your newly created map and click “Constructor”.

  5. Add a Trigger-Based Icon:

    • Click “Add element” (defaults to a server icon).

    • Click the new element. Change “Type” to “Trigger”.

    • Under “Icons”, select your custom “green” icon for the “Default” state and your “red” icon for the “Problem” state.

    • Click “Add” next to “Triggers” and select the specific trigger you want this icon to react to.

    • Click “Apply”. Position the icon on your map.

  6. Add Real-Time Data Display:

    • Click “Add element” and select “Shape” (e.g., Rectangle).

    • Click the new shape. In the “Label” field, enter your data syntax, e.g., Temp: {?last(/quadrata-test-host/test.item)} (replace with your actual host and item key).

    • Customize font size, remove the border (set Border width to 0), etc.

    • Click “Apply”. Position the shape.

    • Important: In the constructor toolbar, toggle “Expand macros” ON to see the live data instead of the syntax string.

  7. Refine and Save: Adjust element positions (you might want to turn off “Snap to grid” for finer control). Remove default labels if they clutter the view (Map Properties -> Map element label type -> Nothing). Click “Update” to save your changes.

Testing with `zabbix_sender`

A fantastic tool for testing maps (especially with trapper items) is the zabbix_sender command-line utility. It lets you manually push data to Zabbix items.

Install the `zabbix-sender` package if you don’t have it. The basic syntax is:

zabbix_sender -z -s -k -o

For example:

zabbix_sender -z 192.168.1.100 -s quadrata-test-host -k test.item -o 25

Sending a value that crosses a trigger threshold will change your trigger-linked icon on the map. Sending a different value will update the real-time data display.

Wrapping Up

So, there you have it – a look into Zabbix Maps. They aren’t magic topology generators, but they are incredibly flexible and powerful tools for creating meaningful, real-time visual dashboards of your infrastructure’s health and performance. By combining different elements, custom icons, backgrounds, and live data, you can build truly informative synoptic views.

Don’t be afraid to experiment! Start simple and gradually add complexity as you get comfortable.

What are your thoughts on Zabbix Maps? Have you created any cool visualizations? Share your experiences or ask questions in the comments below!

If you found this helpful, please give the video a thumbs up, share it, and subscribe to Quadrata for more content on Zabbix and open source solutions.

Also, feel free to join the conversation in the Zabbix Italia Telegram channel – it’s a great community!

Thanks for reading, and I’ll see you in the next post!

– Dimitri Bellini

Read More

0

Unlock Your Documents Potential with Ragflow: An Open-Source RAG Powerhouse
By Dimitri Bellini31 March, 2025Blog

Unlock Your Documents Potential with Ragflow: An Open-Source RAG Powerhouse

Good morning, everyone! Dimitri Bellini here, back on the Quadrata channel – your spot for diving into the exciting world of open source and IT tech. Today, we’re tackling a topic some of you have asked about: advanced solutions for interacting with your own documents using AI.

I sometimes wait to showcase software until it’s a bit more polished, and today, I’m excited to introduce a particularly interesting one: Ragflow.

What is RAG and Why Should You Care?

We’re diving back into the world of RAG solutions – Retrieval-Augmented Generation. It sounds complex, but the core idea is simple and incredibly useful: using your *own* documents (manuals, reports, notes, anything on your disk) as a private knowledge base for an AI.

Instead of relying solely on the general knowledge (and potential inaccuracies) of large language models (LLMs), RAG lets you get highly relevant, context-specific answers based on *your* information. This is a practical, powerful use case for AI, moving beyond generic queries to solve specific problems using local data.

Introducing Ragflow: A Powerful Open-Source RAG Solution

Ragflow (find it on GitHub!) stands out from other RAG tools I’ve explored. It’s not just a basic framework; it’s shaping up to be a comprehensive, business-oriented platform. Here’s why it caught my eye:

  • Open Source: Freely available and community-driven.

  • Complete Solution: Offers a wide range of features out-of-the-box.

  • Collaboration Ready: Designed for teams to work on shared knowledge bases.

  • Easy Installation: Uses Docker Compose for a smooth setup.

  • Local First: Integrates seamlessly with local LLM providers like Ollama (which I use).

  • Rapid Development: The team is actively adding features and improvements.

  • Advanced Techniques: Incorporates methods like Self-RAG and Raptor for better accuracy.

  • API Access: Allows integration with other applications.

Diving Deeper: How Ragflow Enhances RAG

Ragflow isn’t just about basic document splitting and embedding. It employs sophisticated techniques:

  • Intelligent Document Analysis: It doesn’t just grab text. Ragflow performs OCR and analyzes document structure (understanding tables in Excel, layouts in presentations, etc.) based on predefined templates. This leads to much better comprehension and more accurate answers.

  • Self-RAG: A framework designed to improve the quality and factuality of the LLM’s responses, reducing the chances of the AI “inventing” answers (hallucinations) when it doesn’t know something.

  • Raptor: This technique focuses on the document processing phase. For long, complex documents, Raptor builds a hierarchical summary or tree of concepts *before* chunking and embedding. This helps the AI maintain context and understand the overall topic better.

These aren’t trivial features; they represent significant steps towards making RAG systems more reliable and useful.

Getting Started: Installing Ragflow (Step-by-Step)

Installation is straightforward thanks to Docker Compose. Here’s how I got it running:

  1. Clone the Repository (Important Tip!): Use the `–branch` flag to specify a stable release version. This saved me some trouble during testing. Replace `release-branch-name` with the desired version (e.g., `0.7.0`).

    git clone --branch release-branch-name https://github.com/infiniflow/ragflow.git

  2. Navigate to the Docker Directory:

    cd ragflow/docker

  3. Make the Entrypoint Script Executable:

    chmod +x entrypoint.sh

  4. Start the Services: This will pull the necessary images (including Ragflow, MySQL, Redis, MinIO, Elasticsearch) and start the containers.

    docker-compose up -d

    Note: Be patient! The Docker images, especially the main Ragflow one, can be quite large (around 9GB in my tests), so ensure you have enough disk space.

Once everything is up, you can access the web interface (usually at `http://localhost:80` or check the Docker Compose file/logs for the exact port).

A Look Inside: Configuring and Using Ragflow

The web interface is clean and divided into key sections: Knowledge Base, Chat, File Manager, and Settings.

Setting Up Your AI Models (Ollama Example)

First, you need to tell Ragflow which AI models to use. Go to your profile settings -> Model Providers.

  • Click “Add Model”.

  • Select “Ollama”.

  • Choose the model type: “Chat” (for generating responses) or “Embedding” (for analyzing documents). You’ll likely need one of each.

  • Enter the **exact** model name as it appears in your Ollama list (e.g., `mistral:latest`, `nomic-embed-text:latest`).

  • Provide the Base URL for your Ollama instance (e.g., `http://your-ollama-ip:11434`).

  • Save the model. Repeat for your embedding model if it’s different. I used `nomic-embed-text` for embeddings and `weasel-lm-7b-v1-q5_k_m` (a fine-tuned model) for chat in my tests.

Creating and Populating a Knowledge Base (Crucial Settings)

This is where your documents live.

  • Create a new Knowledge Base and give it a name.

  • Before Uploading: Go into the KB settings. This is critical! Define:

    • Language: The primary language of your documents.

    • Chunking Method: How documents are split. Ragflow offers templates like “General”, “Presentation”, “Manual”, “Q&A”, “Excel”, “Resume”. Choose the one that best fits your content. I used “Presentation” for my Zabbix slides.

    • Embedding Model: Select the Ollama embedding model you configured earlier.

    • Raptor: Enable this for potentially better context handling on complex docs.

  • Upload Documents: Now you can upload files or entire directories.

  • Parse Documents: Click the “Parse” button next to each uploaded document. Ragflow will process it using the settings you defined (OCR, chunking, embedding, Raptor analysis). You can monitor the progress.

Building Your Chat Assistant

This connects your chat model to your knowledge base.

  • Create a new Assistant.

  • Give it a name and optionally an avatar.

  • Important: Set an “Empty Response” message (e.g., “I couldn’t find information on that in the provided documents.”). This prevents the AI from making things up.

  • Add a welcome message.

  • Enable “Show Citation”.

  • Link Knowledge Base: Select the KB you created.

  • Prompt Engine: Review the system prompt. The default is usually quite good, instructing the AI to answer based *only* on the documents.

  • Model Setting: Select the Ollama chat model you configured. Choose a “Work Mode” like “Precise” to encourage focused answers.

  • (Optional) Re-ranking Model: I skipped this in version 0.7 due to some issues, but it’s a feature to watch.

  • Confirm and save.

Putting Ragflow to the Test (Zabbix Example)

I loaded my Zabbix presentation slides and asked the assistant some questions:

  • Explaining Zabbix log file fields.

  • Identifying programming languages used in Zabbix components.

  • Differentiating between Zabbix Agent Passive and Active modes.

  • Describing the Zabbix data collection flow.

The results were genuinely impressive! Ragflow provided accurate, detailed answers, citing the specific slides it drew information from. There was only one minor point where I wasn’t entirely sure if the answer was fully grounded in the text or slightly inferred, but overall, the accuracy and relevance were excellent, especially considering it was analyzing presentation slides.

Integrating Ragflow with Other Tools via API

A standout feature is the built-in API. For each assistant you create, you can generate an API key. This allows external applications to query that specific assistant and its associated knowledge base programmatically – fantastic for building custom integrations.

Final Thoughts and Why Ragflow Stands Out

Ragflow is a compelling RAG solution. Its focus on accurate document analysis, integration of advanced techniques like Self-RAG and Raptor, ease of use via Docker and Ollama, and the inclusion of collaboration and API features make it feel like a mature, well-thought-out product, despite being relatively new.

While it’s still evolving (as seen with the re-ranking feature I encountered), it’s already incredibly capable and provides a robust platform for anyone serious about leveraging their own documents with AI.

What do you think? Have you tried Ragflow or other RAG solutions? What are your favourite use cases for chatting with your own documents?

Let me know in the comments below! I’m always keen to hear your experiences and suggestions for tools to explore.

Don’t forget to give this video a thumbs up if you found it helpful, and subscribe to the Quadrata channel for more open-source tech deep dives.

Also, if you’re interested in Zabbix, join our friendly community on Telegram: Zabbix Italia.

Thanks for watching, and see you next week!

– Dimitri Bellini

Read More

0