Blog

Gartner’s Magic Quadrant: A Crystal Ball for IT or an Illusion?

Gartner’s Magic Quadrant: A Crystal Ball for IT or an Illusion?

Good morning, everyone! Dimitri Bellini here, and welcome back to Quadrata. I know I’ve been away for a few weeks—I managed to get a bit of a vacation in—and I’ve come back with a ton of ideas for new open-source software to share with you.

But today, I want to take a step back and have a more general chat. This is for anyone who works in a company that has to deal with much larger enterprise clients, or for anyone involved in the high-stakes decision of choosing which software to invest in. In the world of IT, there’s a powerful and often mysterious force that guides these decisions: the Gartner Magic Quadrant.

It’s often treated like a crystal ball, a tool that can predict the future of your tech empire and tell you exactly where to step next. While it’s certainly a useful instrument, it’s crucial to understand what it is, how it works, and most importantly, its limitations.

What Exactly Is the Gartner Magic Quadrant?

Simply put, the Magic Quadrant is a series of market research reports that provide a visual snapshot of a specific tech market. Whether it’s cloud computing, observability, or storage, Gartner maps out the main competitors, helping you understand the landscape at a glance. For a top manager who doesn’t have time to research hundreds of solutions, it simplifies the immense complexity of the IT world into a single, digestible chart.

Decoding the Four Squares

The “magic” happens within a four-square grid, where vendors are placed based on their “Ability to Execute” and “Completeness of Vision.” Here’s what each quadrant means:

  • Leaders (Top Right): These are the champions. They have a strong vision that aligns with Gartner’s view of the future and the resources to execute it. They are well-established, reliable, and considered the top players in their field.
  • Challengers (Top Left): These vendors dominate the market today and have a strong ability to execute, but their vision for the future might not be as clear or innovative. They are strong performers but may be less prepared for tomorrow’s shifts.
  • Visionaries (Bottom Right): These are the innovators. They understand where the market is going and have a compelling vision, but they may not have the resources or market presence to execute on that vision at scale just yet.
  • Niche Players (Bottom Left): These vendors focus successfully on a small segment of the market. They might be very good at what they do, but they lack either a broad vision or the ability to outperform others across the board.

Why the Magic Quadrant Is So Influential

If you’ve ever tried to sell a product to a large enterprise, you’ve likely been asked, “Are you in the Gartner Magic Quadrant?” If the answer is yes, the doors magically open. Why? Because it represents a safe choice.

There’s an old saying in IT: “No one ever got fired for buying IBM.” The Magic Quadrant works on a similar principle. A manager can point to it and say, “I chose a Leader. It was the best on the market according to the experts. If it doesn’t work out, what more could I have done?” It provides a shield of justification.

For vendors, being placed in the quadrant—especially as a Leader—is a powerful marketing tool. It validates their position in the market and instantly gives them credibility. It works for both the buyer and the seller.

The Hamlet-like Doubt: Is the Leader Always the Best Choice?

And here is where the critical thinking comes in. Just because a product is in the “Leaders” quadrant, does that automatically make it the right choice for your company? This is the fundamental question every manager should ask.

The process to get into the quadrant is incredibly complex and resource-intensive. It requires detailed reports on financials, sales strategy, customer feedback, marketing, and innovation. This creates a few potential issues:

1. It Favors the Already Favored

Large, multinational corporations have the money, specialized staff, and massive structures needed to provide Gartner with the exhaustive data required. This creates a high barrier to entry for small-to-medium-sized companies or innovative startups that might have a superior product but lack the corporate machinery to prove it according to Gartner’s specific methodology.

2. The Open Source Blind Spot

Open source solutions often don’t fit neatly into these corporate boxes. A powerful open-source tool might require more initial customization and “handiwork,” but in return, it offers unparalleled flexibility. The Magic Quadrant’s model can struggle to properly evaluate this trade-off, often overlooking solutions that could be a perfect fit for a company willing to invest in configuration over out-of-the-box features.

3. It’s Based on the Past, Not the Future

The analysis relies heavily on past performance and existing data. A truly disruptive, game-changing technology that doesn’t fit the standard parameters might not even make it onto the chart. By the time it does, it might be too late.

Conclusion: Use It as a Map, Not a Destination

So, what’s the takeaway? The Gartner Magic Quadrant is an excellent starting point. If you know nothing about a particular market, it gives you a fantastic overview of the key players. But your work doesn’t end there. The most critical step is due diligence.

You must dive deeper to understand your company’s unique, real-world needs. No two businesses are exactly alike, even if they’re in the same industry. To stay on the crest of the wave, you need a tool that is molded to your specific workflows, not a one-size-fits-all solution that’s beautiful and feature-packed but of which you’ll only use a fifth of its capabilities. Think about it: if you want the ultimate performance car, do you buy the best-selling Volkswagen, or do you seek out a niche masterpiece like a Ferrari or a Bugatti?

Choosing the Leader is the easy path. But putting in the passion and the effort to analyze, think, and then decide on the truly *right* tool—that’s what makes a great manager. Don’t just follow the chart; understand your needs, explore all options (even the niche ones!), and make an informed decision that will genuinely drive your business forward.


That’s all for today! I hope this discussion was useful. What are your thoughts on the Gartner Magic Quadrant? Have you used it to make decisions? Let me know in the comments below!

If you liked this post and the accompanying video, please give it a like and subscribe to the channel if you haven’t already. I’ll be back next week with a very interesting—and yes, niche—tool that I think you’ll love.

Bye everyone!

– Dimitri

Connect with me and the community:

Read More
Finally! OpenAI Enters the Open-Source Arena with Two New Models

Finally! OpenAI Enters the Open-Source Arena with Two New Models

Good morning, everyone! Dimitri Bellini here, and welcome back to Quadrata. For a while now, I’ve been waiting for something genuinely new to discuss in the world of artificial intelligence. The on-premise, open-source scene has been buzzing, but largely dominated by excellent models from the East. I was waiting for a major American player to make a move, and finally, the moment has arrived. OpenAI, the minds behind ChatGPT, have released not one, but two completely open-source models. This is a big deal, and in this post, I’m going to break down what they are, what they can do, and put them to the test myself.

What’s New from OpenAI? A Revolution in the Making

OpenAI has released two “open-weight” models, which means we have access to the model’s core infrastructure and the data it was trained on. This is fantastic news for developers, researchers, and hobbyists like us, as it allows for deep customization. The two new models are:

  • GPT-OSS-120B: A massive 120-billion parameter model.
  • GPT-OSS-20B: A more accessible 20-billion parameter model.

This move is a significant step, especially with a permissive Apache 2.0 license, which allows for commercial use. You can build on top of these models, fine-tune them with your own data, and deploy them in your applications without the heavy licensing restrictions we often see.

Key Features That Matter

So, what makes these models stand out? Here are the highlights:

  • Truly Open License: The Apache 2.0 license gives you immense freedom to innovate and even commercialize your work.
  • Designed for Agentic Tasks: These models are built to be “agents” that can interact with tools and perform complex, multi-step tasks. While the term “agentic” is a bit of a buzzword lately, the potential is there.
  • Deeply Customizable: With open weights, you can perform post-training to tailor the model to your specific needs, creating a specialized LLM for your unique use case.
  • Full Chain of Thought: A major point of contention with closed models is their “black box” nature. You get an answer but can’t see the reasoning. These models expose their entire thought process, allowing you to understand why they reached a certain conclusion. This transparency is crucial for debugging and trust.

Choosing Your Model: Hardware and Performance

The two models cater to very different hardware capabilities.

The Powerhouse: GPT-OSS-120B

This is the star of the show, with performance comparable to the closed GPT-3.5-Turbo model. However, running it is no small feat. You’ll need some serious hardware, like an NVIDIA H100 GPU with at least 80GB of VRAM. This is not something most of us have at home, but it’s a game-changer for businesses and researchers with the right infrastructure.

The People’s Model: GPT-OSS-20B

This is the model most of us can experiment with. It’s designed to be more “human-scale” and offers performance roughly equivalent to the `o3-mini` model. The hardware requirements are much more reasonable:

  • At least 16GB of VRAM on a dedicated NVIDIA GPU.
  • A tool like Ollama or vLLM to run it (at the time of writing, Ollama already has full support!).

This is the model I’ll be focusing my tests on today.

My Hands-On Test: Putting GPT-OSS-20B to Work with Zabbix

Benchmarks are one thing, but real-world performance is what truly counts. I decided to throw a few complex, Zabbix-related challenges at the 20B model to see how it would handle them. I used LM Arena to compare its output side-by-side with another strong model of a similar size, Qwen2.

Test 1: Zabbix JavaScript Preprocessing

My first test was a niche one: I asked the model to write a Zabbix JavaScript preprocessing script to modify the output of a low-level discovery rule by adding a custom user macro. This isn’t a simple “hello world” prompt; it requires an understanding of Zabbix’s specific architecture, LLD, and JavaScript context.

The Result: I have to say, both models did an impressive job. They understood the context of Zabbix, preprocessing, and discovery macros. The JavaScript they generated was coherent and almost perfect. The GPT-OSS model’s code needed a slight tweak—it wrapped the code in a function, which isn’t necessary in Zabbix, and made a small assumption about input parameters. However, with a minor correction, the code worked. Not bad at all for a model running locally!

Test 2: Root Cause Analysis of IT Events

Next, I gave the model a set of correlated IT events with timestamps and asked it to identify the root cause. The events were:

  1. Filesystem full on a host
  2. Database instance down
  3. CRM application down
  4. Host unreachable

The Result: This is where the model’s reasoning really shone. It correctly identified that the “Filesystem full” event was the most likely root cause. It reasoned that a full disk could cause the database to crash, which in turn would bring down the CRM application that depends on it. It correctly identified the chain of dependencies. Both GPT-OSS and Qwen2 passed this test with flying colors, demonstrating strong logical reasoning.

Test 3: The Agentic Challenge

For my final test, I tried to push the “agentic” capabilities. I provided the model with a tool to interact with the Zabbix API and asked it to fetch a list of active problems. Unfortunately, this is where it stumbled. While it understood the request and even defined the tool it needed to use, it failed to actually execute the API call, instead getting stuck or hallucinating functions. This shows that while the potential for tool use is there, the implementation isn’t quite seamless yet, at least in my initial tests.

Conclusion: A Welcome and Necessary Step Forward

So, what’s my final verdict? The release of these open-source models by OpenAI is a fantastic and much-needed development. It provides a powerful, transparent, and highly customizable alternative from a Western company in a space that was becoming increasingly dominated by others. The 20B model is a solid performer, capable of impressive reasoning and coding, even if it has some rough edges with more advanced agentic tasks.

For now, it stands as another great option alongside models from Mistral and others. The true power here lies in the community. With open weights and an open license, I’m excited to see how developers will improve, fine-tune, and build upon this foundation. This is a very interesting time for local and on-premise AI.

What do you think? Have you tried the new models? What are your impressions? Let me know your thoughts in the comments below!


Stay Connected with Me:

Read More
Copyparty: The Lightweight, Powerful File Server You Didn’t Know You Needed

Copyparty: The Lightweight, Powerful File Server You Didn’t Know You Needed

Good morning, everyone, and welcome back to Quadrata! This is my corner of the internet dedicated to the open-source world and the IT solutions that I—and hopefully you—find exciting. If you enjoy this kind of content, don’t forget to leave a like on the video and subscribe to the channel!

This week, we’re diving back into the world of open-source solutions. I stumbled upon a truly stunning tool in the file-sharing space that has a wonderful nostalgic feel, reminiscent of the BBS days of the 90s. It’s called Copyparty, and its charm lies not just in its retro vibe but in its incredible versatility. You can install it almost anywhere, making it a fantastic utility to have in your toolkit.

So, let’s take a closer look together.

What Exactly is Copyparty?

At its core, Copyparty is a web file server that allows you to share and exchange files. What makes it special is that it’s all contained within a single Python file. This makes it incredibly lightweight and portable. While you can run it directly, I prefer using it inside a Docker container for easier management and deployment.

But why use it? The answer is simplicity and performance. If you’ve ever needed to quickly move files between your PC and your NAS, or share a large file with a friend without jumping through hoops, Copyparty could be the perfect, high-performing solution for you.

A Surprising Number of Features in a Tiny Package

I was genuinely impressed by the sheer number of features packed into this tool. It’s highly customizable and offers much more than simple file transfers. Here’s a condensed list of its most interesting capabilities:

  • Smart Uploads & Downloads: When you upload a large file, Copyparty can intelligently split it into smaller chunks. This maximizes your bandwidth and, more importantly, allows for resumable transfers. If your connection drops halfway through, you can pick up right where you left off.
  • File Deduplication: To save precious disk space, Copyparty uses file hashes to identify and avoid storing duplicate files.
  • On-the-fly Compression: You can have files automatically zipped and compressed on the fly, which is another great space-saving feature.
  • Batch Renaming & Tagging: If you have a large collection of photos or, like in the old days, a folder full of MP3s, you can quickly rename them based on a specific pattern.
  • Extensive Protocol Support: It’s not just limited to HTTP. Copyparty supports a whole suite of protocols, including WebDAV, FTPS, TFTP, and Samba, making it a complete hub for file communication.
  • Truly Cross-Platform: It runs virtually everywhere: Linux, macOS, Windows, Android, and even on a Raspberry Pi, thanks to its optimized nature. Yes, you can install it directly on your phone!
  • Built-in Media Tools: Copyparty includes a surprisingly nice music player that can read metadata from your audio files (like BPM and duration) and a compact image browser for viewing your photos.
  • Powerful Command Line (CLI): For those who need to automate or optimize file transfers, there’s a full-featured command-line interface.

Tailor It to Your Needs: Configuration and Security

One of Copyparty’s greatest strengths is its customizability via a single configuration file, copyparty.conf. Here, you can enable or disable features, block connections from specific IP ranges, set upload limits based on disk space, and even change the UI theme.

For user management, you have a couple of options. You can use a simple user/password file or integrate with an external Identity Provider (IDP). The permission system is also very granular. Using a system of flags (like RW for read/write, MDA, etc.), you can define exactly what each user can do on specific paths. It might seem a bit “primordial” compared to modern web GUIs, but for a compact solution, it’s incredibly fast and effective to manage.

How to Install Copyparty with Docker

As I mentioned, my preferred method is using Docker. Copyparty’s developers provide a straightforward Docker Compose file that makes getting started a breeze. I use a GUI tool like Portainer to manage my containers, which simplifies the process even further.

Here’s a look at a basic docker-compose.yml structure:


services:
copyparty:
image: 9001/copyparty
ports:
- "3923:3923"
volumes:
# Volume for configuration file (copyparty.conf)
- /path/to/your/config:/cfg
# Volume for the files you want to share
- /path/to/your/data:/mnt
# ... other docker-specific configurations

In this setup, I’ve defined two key volumes:

  1. A volume for the configuration, where the copyparty.conf file lives.
  2. A mount point for the actual data I want to share or upload to.

Once you run docker-compose up -d, your service will be up and running!

A Walkthrough of the Web Interface

The official GitHub page has a wealth of information and even a live demo, but let me show you my installation. The interface has a fantastic vintage feel, but it’s packed with functionality.

Uploading and Sharing

Uploading a file is as simple as dragging and dropping. First, Copyparty hashes the file to check for duplicates. Then, it begins streaming the upload in a highly optimized way. Once uploaded, you’ll see details like the IP address it was uploaded from and the timestamp.

Sharing is just as easy. You can select a file, create a share link with a custom name, set a password, and even define an expiration date. It generates both a URL and a QR code, making it incredibly convenient to share with others.

Management and Media

The UI includes several helpful tools:

  • Control Center: See active clients, current uploads/downloads, and active shares.
  • Recent Uploads (Extinguisher Icon): Quickly view the latest files added to your share, which is useful for moderation in a multi-user environment.
  • Advanced Search (Lens Icon): A powerful search tool with a wide array of filters to find exactly what you’re looking for.
  • Settings (Gear Icon): Customize the UI, change the language, and tweak how files are displayed.

And don’t forget the built-in media player and image gallery, which turn your file share into a simple media server.

Monitoring

For advanced users, Copyparty can even export its metrics, allowing you to monitor its performance and status with tools like Zabbix. This is a testament to its professional-grade design.

Final Thoughts: Is Copyparty Right for You?

I think Copyparty is a fantastic and interesting product. It’s a very nice solution to try, especially because it’s so lightweight and can be installed almost anywhere. There are many situations where a fast, simple, and self-hosted file-sharing tool is exactly what you need.

Its blend of retro simplicity and modern, powerful features makes it a unique and valuable tool in the open-source world.

That’s all for this week! I’m always eager to hear your thoughts. Have you used Copyparty before? Or do you use another solution that you find more interesting? Let me know in the comments below—perhaps we can discuss it in a future video!

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


Follow my work and join the community:

Read More
My Deep Dive into NetLockRMM: The Open-Source RMM You’ve Been Waiting For

My Deep Dive into NetLockRMM: The Open-Source RMM You’ve Been Waiting For

Good morning everyone, I’m Dimitri Bellini, and welcome back to Quadrata, my channel dedicated to the fantastic world of open source and IT. If you’re managing multiple systems, you know the challenge: finding a reliable, centralized way to monitor and control everything without breaking the bank. Proprietary solutions can be costly, and the open-source landscape for this has been somewhat limited.

That’s why this week, I’m excited to show you a new product that tackles this problem head-on. It’s an open-source tool called NetLockRMM, and it’s designed to solve the exact problem of remote device management.

What is NetLockRMM?

NetLockRMM stands for Remote Monitoring and Management. It’s a self-hosted solution that gives you a single web portal to manage and control your remote hosts. Whether you’re dealing with servers or desktops running Windows, Linux, or macOS, this tool aims to bring them all under one roof. For those of us who use tools like Zabbix to manage numerous proxies or server installations, the idea of a single point of control is incredibly appealing.

Here are some of the key features it offers:

  • Cross-Platform Support: Agents are available for Windows, Linux, and macOS, covering most use cases.
  • System Monitoring: Keep an eye on vital parameters like CPU, RAM, and disk usage. While it’s not a full-fledged monitoring system like Zabbix, it provides a great overview for standard requirements.
  • Remote Control: Access a remote shell, execute commands, and even get full remote desktop access to your Windows machines directly from your browser.
  • File Transfer: Easily upload or download files to and from your managed hosts.
  • Automation: Schedule tasks and run scripts across your fleet of devices to automate maintenance and checks.
  • Multi-Tenancy: Manage different clients or departments from within the same instance.

Getting Started: The Installation and Setup Guide

One of the best parts about NetLockRMM is how simple it is to get up and running. Here’s a step-by-step guide to get you started.

Prerequisites

All you really need is a system with Docker installed. The entire application stack runs in containers, making deployment clean and isolated. If you plan to access the portal from the internet, you’ll also need a domain name (FQDN).

Step 1: The Initial Installation

The development team has made this incredibly easy. The official documentation points to a single Bash script that automates the setup.

  1. Download the installation script from their repository (https://docs.netlockrmm.com/en/server-installation-docker).
  2. Make it executable (e.g., chmod +x /home/docker-compose-quick-setup.sh).
  3. Run the script. It will ask you a few questions to configure your environment, such as the FQDN you want to use and the ports for the services.
  4. The script will then generate the necessary docker-compose.yml file and, if you choose, deploy the containers for you.

While you can easily manage the deployment from the command line, I’m getting quite fond of using a handy container management tool to deploy my stacks, which makes the process even more convenient.

Step 2: Activating Your Instance

Here’s an important point. While NetLockRMM is open-source, the developers have a fair model to support their work. To fully unlock its features, you need to get a free API key.

  1. Go to the official NetLockRMM website and sign up for an account.
  2. Choose the On-Premise Open Source plan. It’s free and allows you to manage up to 25 devices, which is very generous for home labs or small businesses.
  3. In your portal dashboard, navigate to “My Product” to find your API key.
  4. In your self-hosted NetLockRMM instance, go to Settings > System and paste the Member Portal API Key.

Without this step, the GUI will work, but you won’t be able to add any new hosts. So, make sure you do this first!

Step 3: Deploying Your First Agent

With the server running and activated, it’s time to add your first machine.

  1. In the NetLockRMM dashboard, click the deployment icon in the top navigation bar.
  2. Create a new agent configuration or use the default. This is where you’ll tell the agent how to connect back to your server.
  3. This is critical: For the API, App, and other URLs, make sure you enter the full FQDN, including the port number (e.g., https://rmm.yourdomain.com:443). The agent won’t assume the default port, and it won’t work without it.
  4. Select the target operating system (Windows, Linux, etc.) and download the customized installer.
  5. Run the installer on your target machine.
  6. Back in the NetLockRMM dashboard, the new machine will appear in the Unauthorized Hosts list. Simply authorize it to add it to your park of managed devices.

Exploring the Key Features in Action

Once an agent is authorized, you can click on it to see a wealth of information and tools. You get a summary of the OS, hardware specs, firewall status, and uptime. You can also browse running processes in the task manager and see a list of services.

Powerful Remote Control

The remote control features are where NetLockRMM truly shines. For Windows, the remote desktop access is fantastic. It launches a session right in your browser, giving you full GUI control without needing any other software. It’s fast, responsive, and incredibly useful.

For Linux, the remote terminal is currently more of a command-execution tool than a fully interactive shell, but it’s perfect for running scripts or a series of commands. You can also browse the file system and transfer files on all supported platforms.

Automation and Scripting

The automation section allows you to create policies and jobs that run on a schedule. You can define checks for disk space, running services, or even script your own checks. There’s also a growing library of community scripts you can use for common tasks, like running system updates on Ubuntu.

My Final Thoughts: A Promising Future

NetLockRMM is a young but incredibly promising project. It’s under very active development—when I checked their GitHub, the last release was just a few days ago! This shows a dedicated team working to improve the product.

It fills a significant gap in the open-source ecosystem, providing a powerful, modern, and easy-to-use RMM solution that can compete with paid alternatives. While there are a few cosmetic bugs and rough edges, the core functionality is solid and works well.

I believe that with community support—through feedback, bug reports, and contributions—this tool could become something truly special. I’ve already given them a star on GitHub, and I encourage you to check them out too.


I hope I’ve shown you something new and interesting today. This is exactly the kind of project we love to see in the open-source world.

But what do you think? Have you tried NetLockRMM, or do you use another open-source alternative for remote management? I’d love to hear your thoughts and recommendations in the comments below. Every comment helps me and the rest of the community learn.

And as always, if you enjoyed this deep dive, please subscribe to the channel for more content like this. See you next week with another episode!

Bye everyone, from Dimitri.

Stay in touch with Quadrata:

Read More
Taming Your Containers: A Deep Dive into Komodo, the Ultimate Open-Source Management GUI

Taming Your Containers: A Deep Dive into Komodo, the Ultimate Open-Source Management GUI

Hello everyone, Dimitri Bellini here, and welcome back to Quadrata, my corner of the internet dedicated to the world of open-source and IT. If you’re like me, you love the power and flexibility of containers. But let’s be honest, managing numerous containers and multiple hosts purely through the command line can quickly become overwhelming. It’s easy to lose track of what’s running, which services need attention, and how your host resources are holding up.

This week, I stumbled upon a solution that genuinely changed my mood and simplified my workflow: Komodo. It’s an open-source container management platform that is so well-made, I just had to share it with you.

What is Komodo?

At its core, Komodo is an open-source graphical user interface (GUI) designed for the management of containers like Docker, Podman, and others. It provides a centralized dashboard to deploy, monitor, and manage all your containerized applications, whether they are running locally or on remote hosts. The goal is to give you back control and visibility, turning a complex mess of shell commands into a streamlined, intuitive experience.

Key Features That Make Komodo Shine

  • Unified Dashboard: Get a bird’s-eye view of all your hosts and the containers running on them. Komodo elegantly displays resource usage (CPU, RAM, Disk Space), operating system details, and more, all in one place.
  • Multi-Host Management: Komodo uses a core-periphery architecture. You install the main Komodo instance on one server and a lightweight agent on any other hosts you want to manage. This allows you to control a “cluster” of machines from a single, clean web interface.
  • Effortless Deployments: You can deploy applications (which Komodo calls “stacks”) directly from Docker Compose files. Whether you paste the code into the UI, point to files on the server, or link a Git repository, Komodo handles the rest.
  • Automation and CI/CD: Komodo includes features for building images directly from your source code repositories and creating automated deployment procedures that can be triggered by webhooks.
  • Advanced User Management: You can create multiple users and groups, and even integrate with external authentication providers like GitHub, Google, or any OIDC provider.

How Does Komodo Compare to the Competition?

Many of you are probably familiar with Portainer. It has been a fantastic solution for years, but its focus has shifted towards Kubernetes, and the free Community Edition has become somewhat limited compared to its commercial offerings. Portainer pioneered the agent-based multi-host model, which Komodo has adopted and refined.

On the other end of the spectrum is Dockge, a much simpler tool focused on managing Docker Compose files on a single host. It’s a great, lightweight option, but Komodo offers a far more comprehensive suite of features for those managing a more complex environment.

Getting Started with Komodo: A Step-by-Step Guide

One of the best things about Komodo is how easy it is to set up. All you need is a machine with Docker installed.

1. Installation

The official documentation makes this incredibly simple (https://komo.do/docs/setup/mongo). The installation is, fittingly, container-based.

  1. Create a dedicated directory for your Komodo installation.
  2. Download the docker-compose.yml and .env files provided on the official Komodo website. Komodo uses a database to store its configuration, giving you the choice between MongoDB (the long-standing default) or Ferretdb (a Postgres-based alternative). For a simple start, the default files work perfectly.
  3. Run the following command in your terminal:
    docker-compose --env-file ./.env up -d

And that’s it! Komodo, its agent (periphery), and its database will start up as containers on your machine.

2. First-Time Setup

Once the containers are running, navigate to your server’s IP address on port 9120 (e.g., http://YOUR_SERVER_IP:9120). The first time you access the UI, it will prompt you to create an administrator account. Simply enter your desired username and password, and you’ll be logged into the main dashboard.

Exploring the Komodo Dashboard and Deploying an App

The dashboard is clean and intuitive. You’ll see your server(s) listed. The host where you installed Komodo is automatically added. You can easily add more remote hosts by installing the Komodo agent on them using a simple command provided in the UI.

Deploying Your First Stack (Draw.io)

Let’s deploy a simple application to see Komodo in action. A stack is essentially a project defined by a Docker Compose file.

  1. From the main dashboard, navigate to Stacks and click New Stack.
  2. Give your stack a name, for example, drawio-app.
  3. Click Configure. Select the server you want to deploy to.
  4. For the source, choose UI Defined. This allows you to paste your compose file directly.
  5. In the Compose file editor, paste the configuration for a Draw.io container. Here’s a simple example:
    services:
    drawio:
    image: jgraph/drawio
    ports:
    - "8080:8080"
    - "8443:8443"
    restart: unless-stopped

  6. Click Save and then Update.
  7. The stack is now defined, but not yet running. Click the Deploy button and confirm. Komodo will pull the image and start your container.

You can now see your running service, view its logs, and access the application by clicking the port link—all from within the Komodo UI. It’s incredibly slick!

Modifying a Stack

Need to change a port or an environment variable? It’s just as easy. Simply edit the compose file in the UI, save it, and hit Redeploy. Komodo will gracefully stop the old container and start the new one with the updated configuration.

Final Thoughts

I have to say, I’m thoroughly impressed with Komodo. It strikes a perfect balance between simplicity and power. It provides the deep visibility and control that power users need without a steep learning curve. The interface is polished, the feature set is rich, and the fact that it’s a thriving open-source project makes it even better.

I’ll definitely be adopting Komodo to manage the entropy on my own servers. It’s a fantastic piece of software that I can wholeheartedly recommend to anyone working with containers.

But that’s my take. What do you think? Have you tried Komodo, or do you use another tool for managing your containers? I’d love to hear your thoughts and suggestions in the comments below. Your ideas might even inspire a future video!

That’s all for today. A big salute from me, Dimitri, and I’ll see you next week!


Don’t forget to subscribe to my YouTube channel for more open-source content:

Quadrata on YouTube

Join our community on Telegram:

ZabbixItalia Telegram Channel

Read More
Unlock Your Servers from Anywhere: A Deep Dive into Apache Guacamole

Unlock Your Servers from Anywhere: A Deep Dive into Apache Guacamole

Good morning everyone, Dimitri Bellini here! Welcome back to Quadrata, my channel dedicated to the open-source world and the IT that I love—and that you, my viewers, clearly enjoy too.

In this post, we’re diving into a tool that’s a bit esoteric but incredibly powerful, something I first used years ago and have recently had the chance to rediscover: Apache Guacamole. No, it’s not a recipe for your next party; it’s a fantastic open-source tool that allows you to connect to your applications, shells, and servers using nothing more than a web browser.

What is Apache Guacamole?

At its core, Guacamole is a clientless remote desktop gateway. This means you can access your remote machines—whether they use RDP, SSH, VNC, or even Telnet—directly from Chrome, Firefox, or any modern HTML5 browser. Imagine needing to access a server while you’re away from your primary workstation. Instead of fumbling with VPNs and installing specific client software, you can just open a browser on your laptop, tablet, or even your phone and get full access. It’s a game-changer for convenience and accessibility.

The architecture is straightforward but robust. Your browser communicates with a web application (running on Tomcat), which in turn talks to the Guacamole daemon (`guacd`). This daemon acts as a translator, establishing the connection to your target machine using its native protocol (like RDP or SSH) and streaming the display back to your browser as simple HTML5.

Key Features That Make Guacamole Stand Out

Guacamole isn’t just a simple proxy; it’s packed with enterprise-grade features that make it suitable for a wide range of use cases:

  • Broad Protocol Support: It natively supports VNC, RDP, SSH, and Telnet, covering most of your remote access needs.
  • Advanced Authentication: You can integrate it with various authentication systems, including Active Directory, LDAP, and even Two-Factor Authentication (2FA), to secure access.
  • Granular Permissions: As an administrator, you can define exactly which users or groups can access which connections.
  • Centralized Logging & Screen Recording: This is a huge feature for security and compliance. Guacamole can log all activity and even record entire user sessions as videos, providing a complete audit trail of who did what and when.
  • Screen Sharing: Need to collaborate on a problem? You can share your active session with a colleague by simply sending them a link. You can both work in the same shell or desktop environment simultaneously.

Surprising Powerhouse: Where You’ve Already Seen Guacamole

While it might not be a household name, you’ve likely used Guacamole without even realizing it. It’s the powerful engine behind several major commercial products, including:

  • Microsoft Azure Bastion
  • FortiGate SSL Web VPN
  • CyberArk PSM Gateway

The fact that these major security and cloud companies build their products on top of Guacamole is a massive testament to its stability and power.

Getting Started: Installation with Docker

The easiest and most recommended way to get Guacamole up and running is with Docker. In the past, this meant compiling various components, but today, it’s a much simpler process. You’ll need three containers:

  1. guacamole/guacd: The native daemon that handles the protocol translations.
  2. guacamole/guacamole: The web application front-end.
  3. A Database: PostgreSQL or MySQL to store user and connection configurations.

Important Note: I found that the official docker-compose.yml file in the documentation can be problematic. The following method is based on a community-provided configuration that works flawlessly with the latest versions.

Step 1: Create a Directory and Initialize the Database

First, create a directory for your Guacamole configuration and data. Then, run the following command to have Guacamole’s container initialize the database schema for you. This script will pull the necessary SQL files and set up the initial database structure.


mkdir guacamole-data
docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --postgres > guacamole-data/initdb.sql

Step 2: Create Your Docker Compose File

Inside your main directory, create a file named docker-compose.yml. This file will define the three services we need to run.


services:
guacd:
container_name: guacd
image: guacamole/guacd
volumes:
- /opt/guacamole/drive:/drive:rw
- /opt/guacamole/record:/record:rw
networks:
- guacamole
restart: always

guacdb:
container_name: guacdb
image: postgres:15.2-alpine
environment:
PGDATA: /var/lib/postgresql/data/guacamole
POSTGRES_DB: guacamole_db
POSTGRES_USER: guacamole_user
POSTGRES_PASSWORD: guacpass
volumes:
- /opt/guacamole/db-init:/docker-entrypoint-initdb.d:z
- /opt/guacamole/data:/var/lib/postgresql/data:Z
networks:
- guacamole
restart: always

guacamole:
container_name: guac-guacamole
image: guacamole/guacamole
depends_on:
- guacd
- guacdb
environment:
GUACD_HOSTNAME: guacd
POSTGRESQL_HOSTNAME: guacdb
POSTGRESQL_DATABASE: guacamole_db
POSTGRESQL_USER: guacamole_user
POSTGRESQL_PASSWORD: guacpass
RECORDING_SEARCH_PATH: /record
# uncomment if you're behind a reverse proxy
# REMOTE_IP_VALVE_ENABLED: true
# uncomment to disable brute-force protection entirely
# BAN_ENABLED: false
# https://guacamole.apache.org/doc/gug/guacamole-docker.html#running-guacamole-behind-a-proxy
volumes:
- /opt/guacamole/record:/record:rw
networks:
- guacamole
ports:
- 8080:8080/tcp
restart: always

networks:
guacamole:
name: guacamole

Be sure to change YourStrongPasswordHere to a secure password!

Step 3: Launch Guacamole

Now, from your terminal in the same directory, simply run:


docker-compose up -d

Docker will pull the images and start the three containers. In a minute or two, your Guacamole instance will be ready!

Your First Connection: A Quick Walkthrough

Once it’s running, open your browser and navigate to http://YOUR_SERVER_IP:8080/guacamole/.

The default login credentials are:

  • Username: guacadmin
  • Password: guacadmin

After logging in, head to Settings > Connections to add your first remote machine. Click “New Connection” and fill out the details. For an SSH connection, you’ll set the protocol to SSH and enter the hostname/IP, username, and password. For Windows RDP, you’ll do the same but may also need to check the “Ignore Server Certificate” box under the Parameters section if you’re using a self-signed certificate.

Once saved, your new connection will appear on your home screen. Just click it, and you’ll be dropped right into your remote session, all within your browser tab. You can have multiple sessions open at once and switch between them like browser tabs. To access features like the clipboard or file transfers, use the Ctrl+Alt+Shift key combination to open the Guacamole side menu.

A True Game-Changer for Remote Access

As you can see, Apache Guacamole is an incredibly versatile and powerful tool. Whether you’re a system administrator who needs a centralized access point, a developer working remotely, or a company looking to enhance security with a bastion host and session recording, it’s a solution that is both elegant and effective.

I highly recommend giving it a try. It’s one of those open-source gems that can fundamentally improve your workflow.

What are your thoughts? Have you used Guacamole or a similar tool before? Let me know in the comments below! And if you found this guide helpful, don’t forget to share it.


Thank you for reading! For more content on open-source and IT, make sure to subscribe to the channel.

YouTube Channel: Quadrata

Join our community on Telegram: ZabbixItalia Telegram Channel

See you in the next one!

Read More
Zabbix 7.4 is Here! A Deep Dive into the Game-Changing New Features

Zabbix 7.4 is Here! A Deep Dive into the Game-Changing New Features

Good morning, everyone! It’s Dimitri Bellini, and welcome back to Quadrata, my channel dedicated to the world of open-source IT. It’s an exciting week because our good friend, Zabbix, has just rolled out a major new version: Zabbix 7.4! After months of hard work from the Zabbix team, this release is packed with features that will change the way we monitor our infrastructure. So, let’s dive in together and explore what’s new.

The “Escapological” Feature: Nested Low-Level Discovery

Let’s start with what I consider the most mind-bending, “centrifugal” new feature: nested low-level discovery (LLD). Until now, LLD was fantastic for discovering objects like file systems or network interfaces on a host. But we couldn’t go deeper. If you discovered a database, you couldn’t then run another discovery *within* that database to find all its tablespaces dynamically.

With Zabbix 7.4, that limitation is gone! I’ve set up a demo to show you this in action. I created a discovery rule that finds all the databases on a host. From the output of that first discovery, a new “discovery prototype” of type “Nested” can now be created. This second-level discovery can then parse the data from the first one to find all the tablespaces specific to each discovered database.

The result? Zabbix first discovers DB1 and DB2, and then it automatically runs another discovery for each of them, creating items for every single tablespace (like TS1 for DB1, TS2 for DB1, etc.). This allows for an incredible level of granularity and automation, especially in complex environments like database clusters or containerized applications. This is a true game-changer.

And it doesn’t stop there. We can now also have host prototypes within host prototypes. Previously, if you discovered a VMware host and it created new hosts for each virtual machine, those new VM hosts couldn’t run their own discovery to create *more* hosts. Now they can, opening the door for multi-layered infrastructure discovery.

A Smarter Way to Onboard: The New Host Wizard

How many times have new users felt a bit lost when adding their first host to Zabbix? What hostname do I use? How do I configure the agent? The new Host Wizard solves this beautifully.

Found under Data Collection -> Host Wizard, this feature provides a step-by-step guide to get your monitoring up and running. Here’s a quick walkthrough:

  1. Select a Template: You start by searching for the type of monitoring you need (e.g., “Linux”). The wizard will show you compatible templates. Note that not all templates are updated for the wizard yet, but the main ones for Linux, Windows, AWS, Azure, databases, and more are already there.
  2. Define the Host: You provide a hostname and assign it to a host group, just like before, but in a much more guided way.
  3. Configure the Agent: This is where the magic happens. For an active agent, for example, you input your Zabbix server/proxy IP and configure security (like a pre-shared key). The wizard then generates a complete installation script for you to copy and paste directly into your Linux or Windows shell! This script handles everything—installing the agent, configuring the server address, and setting up the keys. It’s incredibly convenient.
  4. Fine-Tune and Deploy: The final step shows you the configurable macros for the template in a clean, human-readable format, making it easy to adjust thresholds before you create the host.

A quick heads-up: I did notice a small bug where the wizard’s script currently installs Zabbix Agent 7.2 instead of 7.4. I’ve already opened a ticket, and I’m sure the Zabbix team will have it fixed in a patch release like 7.4.1 very soon.

Dashboard and Visualization Upgrades

Real-Time Editing and a Fresh Look

Dashboards have received a major usability boost. You no longer have to click “Edit,” make a change to a widget, save it, and then see the result. Now, all changes are applied in real-time as you configure the widget. If you thicken a line in a graph, you see it thicken instantly. This makes dashboard creation so much faster and more intuitive.

Furthermore, Zabbix has introduced color palettes for graphs. Gone are the days of having multiple metrics on a graph with nearly identical shades of the same color. You can now choose a palette that assigns distinct, pleasant, and easily recognizable colors to each item, making your graphs far more readable.

The New Item Card Widget

There’s a new widget in town called the Item Card. When used with something like the Host Navigator widget, you can select a host, then select a specific item (like CPU Utilization), and the Item Card will populate with detailed information about that item: its configuration, recent values, a mini-graph, and any associated triggers. It’s a fantastic way to get a quick, focused overview of a specific metric.

Powerful Enhancements for Maps and Monitoring

Maps Get a Major Overhaul

Maps are now more powerful and visually appealing than ever. Here are the key improvements:

  • Element Ordering: Finally, we can control the Z-index of map elements! You can bring elements to the front or send them to the back. This means you can create a background image of a server rack and place your server icons perfectly on top of it, which was impossible to do reliably before.
  • Auto-Hiding Labels: To clean up busy maps, labels can now be set to appear only when you hover your mouse over an element.
  • Dynamic Link Indicators: The lines connecting elements on a map are no longer just tied to trigger status. You can now have their color or style change based on an item’s value, allowing you to visualize things like link bandwidth utilization directly on your map.

More Control with New Functions and Security

Zabbix 7.4 also brings more power under the hood:

  • OAuth 2.0 Support: You can now easily configure email notifications using Gmail and Office 365, as Zabbix provides a wizard to handle the OAuth 2.0 authentication.
  • Frontend-to-Server Encryption: For security-conscious environments, you can now enable encryption for the communication between the Zabbix web frontend and the Zabbix server.
  • New Time-Based Functions: Functions like first.clock and last.clock have been added, giving us more power to correlate events based on their timestamps, especially when working with logs.

Small Changes, Big Impact: Quality of Life Improvements

Sometimes it’s the little things that make the biggest difference in our day-to-day work. Zabbix 7.4 is full of them:

  • Inline Form Validation: When creating an item or host, Zabbix now instantly highlights any required fields you’ve missed, preventing errors before you even try to save.
  • Copy Button for Test Output: When you test a preprocessing step and get a large JSON output, there’s now a simple “Copy” button. No more struggling to select all the text in the small window!
  • New Templates: The library of official templates continues to grow, with notable additions for enterprise hardware like Pure Storage.

Final Thoughts

Zabbix 7.4 is a massive step forward. From the revolutionary nested discovery to the user-friendly Host Wizard and the countless usability improvements, this release offers something for everyone. It makes Zabbix both more powerful for seasoned experts and more accessible for newcomers.

What do you think of this new release? Is there a feature you’re particularly excited about, or something you’d like me to cover in more detail? The nested discovery part can be complex, so I’m happy to discuss it further. Let me know your thoughts in the comments below!

And with that, that’s all for today. See you next week!


Don’t forget to engage with the community:

  • Subscribe to my YouTube Channel: Quadrata
  • Join the discussion on the Zabbix Italia Telegram Channel: ZabbixItalia

Read More
Chat with Your Zabbix: A Practical Guide to Integrating AI with Zabbix AI MCP Server

Unlocking Zabbix with AI: A Look at the Zabbix AI MCP Server

Good morning everyone, Dimitri Bellini here, back on my channel Quadrata! Today, we’re diving into something truly interesting, a bit experimental, and as always, involving our good friend Zabbix. This exploration comes thanks to a member of the Italian Zabbix community, Matteo Peirone, who reached out on LinkedIn to share a fascinating project he developed. I was immediately intrigued and knew I had to show it to you.

So, what are we talking about? It’s called the Zabbix AI MCP Server, and it allows us to instrument operations within Zabbix using artificial intelligence. Let’s break down what this means and how it works.

What is the Zabbix AI MCP Server?

At its core, the Zabbix AI MCP Server acts as an intermediary, bridging the gap between artificial intelligence and the Zabbix server’s APIs. Many of you might already be familiar with Zabbix APIs, which allow us to consult data or perform actions within our Zabbix environment. This project aims to simplify these interactions significantly, especially for those not deeply versed in API scripting.

To get started, we need a few key components:

  • An inference engine: This can be cloud-based or local (via Ollama or VLLM). I’ve been experimenting with a few.
  • An adequate AI model compatible with the engine.
  • The Zabbix AI MCP Server itself.
  • A small, yet crucial, project called mcp-to-openapi-proxy.
  • In my setup, I’m using Open Web UI as a chat interface, similar to ChatGPT, to interact with the AI.

Understanding MCP: Model Context Protocol

Before we go further, it’s important to understand what “MCP” stands for. It means Model Context Protocol. This protocol, invented by Anthropic (the creators of Claude), is designed to allow AI models to interact with external “tools.” These tools can be anything from platform functionalities to specific software features.

Essentially, MCP provides a standardized way for an AI to:

  1. Discover available tools and their capabilities (e.g., functions, resources).
  2. Understand how to use these tools, including descriptions and invocation methods.

This is particularly relevant for AI agents, which are sophisticated prompts instructed to perform tasks that might require external interactions, like research or system operations. MCP helps standardize these tool interactions, which can be a challenge as not all LLM models handle function calls equally well.

How the Zabbix AI MCP Server Works

The Zabbix AI MCP Server, developed by Matteo Peirone, leverages this MCP framework. It exposes Zabbix’s API functionalities as “tools” that an AI can understand and use. This means you can:

  • Consult data: Ask for the latest problems, analyze triggers, or get details about a host.
  • Perform actions: Create or update objects within Zabbix (if not in read-only mode).

All of this can be done without needing to write complex API scripts yourself!

The Architecture in My Setup:

Here’s how the pieces connect in my demonstration:

  1. Open Web UI: This is my chat interface where I type my requests in natural language.
  2. mcp-to-openapi-proxy: This acts as a bridge. Open Web UI is instructed to look for tools here. This proxy converts MCP functions into REST API endpoints (normalized in the OpenAPI standard) that Open Web UI can consume. It essentially acts as an MCP client.
  3. Zabbix AI MCP Server: This is the star of the show. The mcp-to-openapi-proxy communicates with this server. The Zabbix AI MCP Server is configured with the details of my Zabbix instance (URL, authentication token or credentials).
  4. Zabbix Server: The Zabbix AI MCP Server then interacts with the actual Zabbix server APIs to fetch data or perform actions based on the AI’s request.

Getting Started: Installation and Setup Guide

Here’s a brief rundown of how I got this up and running. It might seem a bit involved, but following these steps should make it manageable:

  1. Clone the Zabbix AI MCP Server Repository:

    git clone https://github.com/mpeirone/zabbix-mcp-server.git

    (You’ll find the repository on Matteo Peirone’s GitHub)

  2. Navigate into the directory and install dependencies:

    cd zabbix-mcp-server
    uv sync

    (I’m using uv here, which is a fast Python package installer and resolver).

  3. Configure the Zabbix AI MCP Server:
    Copy the example configuration file:

    cp config/.env.example .env

    Then, edit the .env file to include your Zabbix server URL, authentication method (token or user/password), and set READ_ONLY=false if you want to test creation/update functionalities (use with caution!).

    ZABBIX_URL="http://your-zabbix-server/api_jsonrpc.php"
    ZABBIX_TOKEN="your_zabbix_api_token"
    # or
    # ZABBIX_USER="your_user"
    # ZABBIX_PASSWORD="your_password"
    READ_ONLY=false

  4. Install and Run the mcp-to-openapi-proxy:
    This component exposes the MCP server over HTTP.

    pipx install uv
    uvx mcpo --port 8000 --api-key "top-secret" -- uv run python3.11 src/zabbix_mcp_server.py

    This command will typically start the proxy on port 8000, and it will, in turn, launch your Zabbix MCP server application. It will also generate an API token (e.g., “topsecret”) that you’ll need for Open Web UI.

  5. Set up Open Web UI:
    Deploy Open Web UI (e.g., via Docker). I’ve configured mine to connect to a local Ollama instance, but you can also point it to other LLM providers.
  6. Configure Tools in Open Web UI:

    • In Open Web UI, navigate to the Admin Panel -> Settings -> Connections to set up your LLM connection (e.g., Ollama, OpenAI, OpenRouter).
    • Then, go to Tools and add a new tool server:

      • URL: Point it to where your `mcp-to-openapi-proxy` is running (e.g., `http://my_server_ip:8000/`).
      • Authentication: Use “Bearer Token” and provide the token generated by `mcp-to-openapi-proxy` (e.g., “topsecret”).
      • Give it a name (e.g., “Zabbix MCP Proxy”) and ensure it’s enabled.

Putting It to the Test: Demo Highlights

In my video, I demonstrated a few queries:

  • “Give me the latest five Zabbix problems in a nice table.”
    Using a local Mistral model via VLLM, the system successfully called the Zabbix MCP Server and retrieved the problem data, formatting it into a table. The accuracy was good, matching the problems shown in my Zabbix dashboard.
  • Fetching Host Details:
    I asked, “Give me the details of the host called Zabbix server.” Initially, with the local model, the phrasing needed to be precise. Switching to a more powerful model like Gemini Pro (via OpenRouter) and specifying “hostname equal to Zabbix server” yielded the correct host ID and details. This highlights how the LLM’s capability plays a role in interpreting requests and using the tools.

One challenge observed is that sometimes, for more complex information (like correlating event IDs with host names not directly in the initial problem get API call), the AI might need more sophisticated tool definitions or better prompting to make multiple, related API calls. However, the beauty of MCP is that you could potentially create a custom “tool” within the Zabbix MCP Server that performs these multiple queries internally and presents a consolidated result.

The Potential and Why This is Exciting

This approach is incredibly versatile. For those not comfortable with APIs, it’s a game-changer. But even for seasoned users, it opens up possibilities for quick queries and potentially for building more complex AI-driven automation around Zabbix.

The Zabbix AI MCP Server is an experiment, something new and fresh. It’s a fantastic starting point that can be refined and improved, perhaps with your help and ideas! The fact that it’s built on an open standard like MCP means it could integrate with a growing ecosystem of AI tools and agents.

Join the Conversation!

This is just the beginning. It’s fascinating to think about how we can use methodologies like the MCP server not just within Zabbix, but across many other applications. The ability to automate and interact with complex systems using natural language is a powerful concept.

What do you think about this? Can you see yourself using something like this? What other use cases come to mind? Let me know in the comments below – I’m really keen to hear your thoughts and start a discussion on this topic.

If you found this interesting, please give the video a big thumbs up, and if you haven’t already, subscribe to Quadrata for more explorations into the world of open source and IT!

That’s all for today. See you next week!

A big thank you again to Matteo Peirone for this innovative project!


Connect with me and the community:

Read More
Chat with Your Zabbix: A Practical Guide to Integrating AI with Zabbix AI MCP Server

Unlocking Zabbix with AI: A Look at the Zabbix AI MCP Server

Good morning everyone, Dimitri Bellini here, back on my channel Quadrata! Today, we’re diving into something truly interesting, a bit experimental, and as always, involving our good friend Zabbix. This exploration comes thanks to a member of the Italian Zabbix community, Matteo Peirone, who reached out on LinkedIn to share a fascinating project he developed. I was immediately intrigued and knew I had to show it to you.

So, what are we talking about? It’s called the Zabbix AI MCP Server, and it allows us to instrument operations within Zabbix using artificial intelligence. Let’s break down what this means and how it works.

What is the Zabbix AI MCP Server?

At its core, the Zabbix AI MCP Server acts as an intermediary, bridging the gap between artificial intelligence and the Zabbix server’s APIs. Many of you might already be familiar with Zabbix APIs, which allow us to consult data or perform actions within our Zabbix environment. This project aims to simplify these interactions significantly, especially for those not deeply versed in API scripting.

To get started, we need a few key components:

  • An inference engine: This can be cloud-based or local (via Ollama or VLLM). I’ve been experimenting with a few.
  • An adequate AI model compatible with the engine.
  • The Zabbix AI MCP Server itself.
  • A small, yet crucial, project called mcp-to-openapi-proxy.
  • In my setup, I’m using Open Web UI as a chat interface, similar to ChatGPT, to interact with the AI.

Understanding MCP: Model Context Protocol

Before we go further, it’s important to understand what “MCP” stands for. It means Model Context Protocol. This protocol, invented by Anthropic (the creators of Claude), is designed to allow AI models to interact with external “tools.” These tools can be anything from platform functionalities to specific software features.

Essentially, MCP provides a standardized way for an AI to:

  1. Discover available tools and their capabilities (e.g., functions, resources).
  2. Understand how to use these tools, including descriptions and invocation methods.

This is particularly relevant for AI agents, which are sophisticated prompts instructed to perform tasks that might require external interactions, like research or system operations. MCP helps standardize these tool interactions, which can be a challenge as not all LLM models handle function calls equally well.

How the Zabbix AI MCP Server Works

The Zabbix AI MCP Server, developed by Matteo Peirone, leverages this MCP framework. It exposes Zabbix’s API functionalities as “tools” that an AI can understand and use. This means you can:

  • Consult data: Ask for the latest problems, analyze triggers, or get details about a host.
  • Perform actions: Create or update objects within Zabbix (if not in read-only mode).

All of this can be done without needing to write complex API scripts yourself!

The Architecture in My Setup:

Here’s how the pieces connect in my demonstration:

  1. Open Web UI: This is my chat interface where I type my requests in natural language.
  2. mcp-to-openapi-proxy: This acts as a bridge. Open Web UI is instructed to look for tools here. This proxy converts MCP functions into REST API endpoints (normalized in the OpenAPI standard) that Open Web UI can consume. It essentially acts as an MCP client.
  3. Zabbix AI MCP Server: This is the star of the show. The mcp-to-openapi-proxy communicates with this server. The Zabbix AI MCP Server is configured with the details of my Zabbix instance (URL, authentication token or credentials).
  4. Zabbix Server: The Zabbix AI MCP Server then interacts with the actual Zabbix server APIs to fetch data or perform actions based on the AI’s request.

Getting Started: Installation and Setup Guide

Here’s a brief rundown of how I got this up and running. It might seem a bit involved, but following these steps should make it manageable:

  1. Clone the Zabbix AI MCP Server Repository:

    git clone https://github.com/mpeirone/zabbix-mcp-server.git

    (You’ll find the repository on Matteo Peirone’s GitHub)

  2. Navigate into the directory and install dependencies:

    cd zabbix-mcp-server
    uv sync

    (I’m using uv here, which is a fast Python package installer and resolver).

  3. Configure the Zabbix AI MCP Server:
    Copy the example configuration file:

    cp config/.env.example .env

    Then, edit the .env file to include your Zabbix server URL, authentication method (token or user/password), and set READ_ONLY=false if you want to test creation/update functionalities (use with caution!).

    ZABBIX_URL="http://your-zabbix-server/api_jsonrpc.php"
    ZABBIX_TOKEN="your_zabbix_api_token"
    # or
    # ZABBIX_USER="your_user"
    # ZABBIX_PASSWORD="your_password"
    READ_ONLY=false

  4. Install and Run the mcp-to-openapi-proxy:
    This component exposes the MCP server over HTTP.

    pipx install uv
    uvx mcpo --port 8000 --api-key "top-secret" -- uv run python3.11 src/zabbix_mcp_server.py

    This command will typically start the proxy on port 8000, and it will, in turn, launch your Zabbix MCP server application. It will also generate an API token (e.g., “topsecret”) that you’ll need for Open Web UI.

  5. Set up Open Web UI:
    Deploy Open Web UI (e.g., via Docker). I’ve configured mine to connect to a local Ollama instance, but you can also point it to other LLM providers.
  6. Configure Tools in Open Web UI:

    • In Open Web UI, navigate to the Admin Panel -> Settings -> Connections to set up your LLM connection (e.g., Ollama, OpenAI, OpenRouter).
    • Then, go to Tools and add a new tool server:

      • URL: Point it to where your `mcp-to-openapi-proxy` is running (e.g., `http://my_server_ip:8000/`).
      • Authentication: Use “Bearer Token” and provide the token generated by `mcp-to-openapi-proxy` (e.g., “topsecret”).
      • Give it a name (e.g., “Zabbix MCP Proxy”) and ensure it’s enabled.

Putting It to the Test: Demo Highlights

In my video, I demonstrated a few queries:

  • “Give me the latest five Zabbix problems in a nice table.”
    Using a local Mistral model via VLLM, the system successfully called the Zabbix MCP Server and retrieved the problem data, formatting it into a table. The accuracy was good, matching the problems shown in my Zabbix dashboard.
  • Fetching Host Details:
    I asked, “Give me the details of the host called Zabbix server.” Initially, with the local model, the phrasing needed to be precise. Switching to a more powerful model like Gemini Pro (via OpenRouter) and specifying “hostname equal to Zabbix server” yielded the correct host ID and details. This highlights how the LLM’s capability plays a role in interpreting requests and using the tools.

One challenge observed is that sometimes, for more complex information (like correlating event IDs with host names not directly in the initial problem get API call), the AI might need more sophisticated tool definitions or better prompting to make multiple, related API calls. However, the beauty of MCP is that you could potentially create a custom “tool” within the Zabbix MCP Server that performs these multiple queries internally and presents a consolidated result.

The Potential and Why This is Exciting

This approach is incredibly versatile. For those not comfortable with APIs, it’s a game-changer. But even for seasoned users, it opens up possibilities for quick queries and potentially for building more complex AI-driven automation around Zabbix.

The Zabbix AI MCP Server is an experiment, something new and fresh. It’s a fantastic starting point that can be refined and improved, perhaps with your help and ideas! The fact that it’s built on an open standard like MCP means it could integrate with a growing ecosystem of AI tools and agents.

Join the Conversation!

This is just the beginning. It’s fascinating to think about how we can use methodologies like the MCP server not just within Zabbix, but across many other applications. The ability to automate and interact with complex systems using natural language is a powerful concept.

What do you think about this? Can you see yourself using something like this? What other use cases come to mind? Let me know in the comments below – I’m really keen to hear your thoughts and start a discussion on this topic.

If you found this interesting, please give the video a big thumbs up, and if you haven’t already, subscribe to Quadrata for more explorations into the world of open source and IT!

That’s all for today. See you next week!

A big thank you again to Matteo Peirone for this innovative project!


Connect with me and the community:

Read More
The Ultimate Guide to Open Source Backups: Kopia vs. Minarca

The Ultimate Guide to Open Source Backups: Kopia vs. Minarca

Good morning, everyone! It’s Dimitri Bellini, and welcome back to Quadrata, my channel dedicated to the world of open source. A few weeks ago, I had one of those heart-stopping moments we all dread: a chunk of my data suddenly became inaccessible. While I had some backup systems in place, they weren’t as reliable as I thought. That scare sent me on a mission to find the best, most robust open-source backup solution out there.

We often don’t think about backups until it’s too late. Whether it’s a broken hard drive, corrupted files, or the dreaded ransomware attack, having a solid backup strategy is the only thing that stands between you and disaster. But remember, as the saying goes, “The backup is guaranteed, but the restore is another story.” A good tool needs to handle both flawlessly.

My Hunt for the Perfect Backup Tool: The Checklist

Before diving into the options, I set some clear requirements for my ideal solution. It needed to be more than just a simple file-copying utility. Here’s what I was looking for:

  • Truly Open Source: The solution had to be freely available and transparent.
  • Cross-Platform: It must work seamlessly across Windows, Linux, and macOS.
  • Powerful Features: I was looking for advanced capabilities like:

    • Deduplication: A smart feature that saves significant space by not storing the same file or block of data more than once. This is different from compression, which just shrinks individual files.
    • Encryption: End-to-end encryption is a must, especially if I’m sending my data to a cloud provider. My data should be for my eyes only.

  • Flexible & Versatile: It needed a Command Line Interface (CLI) for automation and a Graphical User Interface (GUI) for ease of use. It also had to support a wide range of storage backends, from a local NAS (using protocols like SSH, NFS, SFTP) to cloud storage like Amazon S3 and Backblaze B2.
  • Simplicity: Finally, it couldn’t be a convoluted mess of scripts. The setup and daily management had to be straightforward.

The Contenders: Kopia vs. Minarca

My research led me to several interesting projects like Restic, Borg, and UrBackup, but two stood out for meeting almost all my criteria: Kopia and Minarca. They represent two fundamentally different philosophies in the backup world, and I put both to the test.

Deep Dive #1: Kopia – The Power User’s Choice

Kopia is a modern, feature-rich, agent-based backup tool. This means all the intelligence—deduplication, encryption, scheduling—resides in the agent you install on your computer. It directly manages the data in your chosen storage repository without needing a server component on the other end.

What I Love About Kopia (Pros):

  • Advanced Features: It offers fantastic cross-device deduplication, strong end-to-end encryption, compression, and error correction to ensure your data is always valid.
  • Snapshot-Based: Kopia creates point-in-time “snapshots” of your directories. This is great for versioning and ensures a consistent state for each backup.
  • Incredibly Versatile: It supports virtually every storage backend you can think of.
  • Resilient by Design: All your configuration policies are stored within the remote repository itself. If your computer dies, you can install Kopia on a new machine, connect to your repository, and all your settings and backup history are immediately available for a restore.

Potential Hurdles (Cons):

  • Learning Curve: While the GUI simplifies things, the underlying policy system for managing snapshot retention, scheduling, and exclusions is incredibly detailed and can be a bit overwhelming for beginners.
  • No Simultaneous Multi-Repository: It doesn’t natively support backing up to multiple repositories at the exact same time in a single job.

A Quick Kopia Walkthrough

Using Kopia involves three main steps:

  1. Connect to a Repository: You start by pointing the Kopia UI to your storage location, whether it’s a local folder, an SFTP server, or a cloud bucket like Backblaze B2. You’ll set a password that encrypts everything.
  2. Create a Snapshot: You then select a folder you want to back up and Kopia will create a snapshot. The first run will upload everything, but subsequent snapshots are incredibly fast, as it only processes and uploads the changes, thanks to deduplication.
  3. Restore: To restore, you browse your snapshots by date and time, find the files or folders you need, and either download them or “mount” the entire snapshot as a local drive to browse through it.

Deep Dive #2: Minarca – Simplicity and Centralized Control

Minarca takes a more traditional client-server approach. You install a lightweight agent on your machines and a server component on a central server (which can be a simple Linux box in your home or office). This architecture is fantastic for managing multiple devices.

Where Minarca Shines (Pros):

  • Incredibly User-Friendly: Both the agent and the server have beautiful, simple interfaces. It’s very intuitive to set up and manage.
  • Centralized Management: The web-based server dashboard is the star of the show. It gives you a complete overview of all your users and devices, with stats on backup duration, space used, and new or modified files. You can even restore files for any user directly from the web interface!
  • Multi-User/Multi-Device: It’s built from the ground up to support multiple users, each with multiple devices, all backing up to one central location.
  • Easy Installation: Setting up the Minarca server on an Ubuntu or Debian machine takes just a few simple commands.

What’s Missing (Cons):

  • No Built-in Advanced Features: Minarca currently leaves features like deduplication and encryption to the underlying storage system (for example, using a ZFS filesystem on your server).
  • File-Based, Not Snapshot-Based: It works by copying files (incrementally) rather than creating atomic snapshots like Kopia.

A Quick Minarca Walkthrough

Getting started with Minarca is a breeze:

  1. Set Up the Server: Install the Minarca server package on a Linux machine.
  2. Configure the Agent: On your client PC, install the Minarca agent and point it to your server’s address with the credentials you created.
  3. Create a Backup Job: In the agent, you can easily select which folders to include or exclude and set a simple backup schedule.
  4. Restore: The agent’s restore interface presents a calendar. You just click a date to see the available backup and browse the files you want to recover. Or, as an admin, you can do this from the central web dashboard.

Kopia vs. Minarca: Which One Is for You?

After testing both extensively, it’s clear they serve different needs.

Choose Kopia if: You are a power user who wants the most advanced features like end-to-end encryption and high-efficiency deduplication built right in. You are comfortable with a more technical setup and prefer a decentralized, agent-only approach.

Choose Minarca if: You value simplicity, ease of use, and centralized control. It’s the perfect solution if you need to manage backups for your family or a small office, and you want a clean dashboard to monitor everything at a glance.

My Final Thoughts and Your Turn

Both Kopia and Minarca are fantastic, robust open-source solutions that put you in control of your data. They are both miles ahead of just hoping for the best. The most important takeaway is this: don’t be like me and wait for a scare. Set up your backups today!

I’d love to hear from you. Which of these tools sounds more appealing to you? Are you using another open-source solution that you love? Let me know in the comments below. Your feedback is always welcome!


Thank you for reading, and don’t forget to subscribe to my YouTube channel for more deep dives into the world of open source.

Until next time, this is Dimitri. Ciao!

Read More
SigNoz: A Powerful Open Source APM and Observability Tool

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
Red Hat Enterprise Linux 10 and Its Clones: What’s New and Which to Choose?

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
Mastering SNMP in Zabbix: A Deep Dive into Modern Monitoring Techniques

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
Deep Dive into Zabbix Low-Level Discovery & the Game-Changing 7.4 Update

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
My Journey into Vibe Coding: Building a Zabbix Service Visualizer with AI

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