Vibe Coding with AI: Building an Automatic Zabbix Service Map
Vibe Coding with AI: Building an Automatic Zabbix Service Map
Good morning everyone! Dimitri Bellini here, back on the Quadrata channel, your spot for diving into the open-source world and IT topics I love – and hopefully, you do too!
If you enjoy these explorations, please give this video a thumbs up and subscribe if you haven’t already. Today, we’re venturing into the exciting intersection of coding, Artificial Intelligence, and Zabbix. I wanted to tackle a real-world challenge I faced: using AI to enhance Zabbix monitoring, specifically for event correlation.
Enter “Vibe Coding”: A Different Approach
Lately, there’s been a lot of buzz around “Vibe Coding.” What is it exactly? Honestly, it feels like a rather abstract concept! The general idea is to write code, perhaps in any language, by taking a more fluid, iterative approach. Instead of meticulous planning, designing flowcharts, and defining every function upfront, you start by explaining your goal to an AI and then, through a process of trial, error, and refinement (“kicks and punches,” as I jokingly put it), you arrive at a solution.
It’s an alternative path, potentially useful for those less familiar with specific languages, although I believe some foundational knowledge is still crucial to avoid ending up with a complete mess. It’s the method I embraced for the project I’m sharing today.
What You’ll Need for Vibe Coding:
- Time and Patience: It’s an iterative process, sometimes frustrating!
- Money: Accessing powerful AI models often involves API costs.
- Tools: I used VS Code along with an AI coding assistant plugin. The transcript mentions “Cline” and “Roocode”; a popular and evolving option in this space is Continue.dev (which might be what was referred to, as tool names evolve). These tools integrate AI directly into the IDE.
The Zabbix Challenge: Understanding Service Dependencies
My initial goal was ambitious: leverage AI within Zabbix for better event correlation to pinpoint the root cause of problems faster. However, Zabbix presents some inherent challenges:
- Standard Zabbix configurations (hosts, groups, tags) don’t automatically define the intricate dependencies *between* services running on different hosts.
- Knowledge about these dependencies is often siloed within different teams in an organization, making manual mapping difficult and often incomplete.
- Zabbix, by default, doesn’t auto-discover applications and their communication pathways across hosts.
- Existing correlation methods (time-based, host groups, manually added tags) are often insufficient for complex scenarios.
Creating and maintaining a service map manually is incredibly time-consuming and struggles to keep up with dynamic environments. My objective became clear: find a way to automate service discovery and map the communications between them automatically.
My Goal: Smarter Event Correlation Through Auto-Discovery
Imagine a scenario with multiple Zabbix alerts. My ideal outcome was to automatically enrich these events with tags that reveal their relationships. For example, an alert on a CRM application could be automatically tagged as dependent on a specific database instance (DB Instance) because the system detected a database connection, or perhaps linked via an NFS share. This context is invaluable for root cause analysis.
My Vibe Coding Journey: Tools and Process
To build this, I leaned heavily on VS Code and the AI assistant plugin (let’s refer to it as Continue.dev for clarity, acknowledging the transcript’s terms “Cline/Clean”). The real power came from the Large Language Model (LLM) behind it.
AI Model Choice: Claude 3 Sonnet
While local, open-source models like Llama variants exist, I found they often lack the scale or require prohibitive resources for complex coding tasks. The most effective solution for me was using Claude 3 Sonnet via its API (provided by Anthropic). It performed exceptionally well, especially with the “tool use” features supported by Continue.dev, which seemed more effective than with other models I considered.
I accessed the API via OpenRouter, a handy service that acts as a broker for various AI models. This provides flexibility, allowing you to switch models without managing separate accounts and billing with each provider (like Anthropic, Google, OpenAI).
Lessons Learned: Checkpoints and Context Windows
- Use Checkpoints! Continue.dev offers a “Checkpoint” feature. Vibe coding can lead you down wrong paths. Checkpoints let you revert your codebase. I learned the hard way that this feature relies on Git. I didn’t have it set up initially and had to restart significant portions of work. My advice: Enable Git and use checkpoints!
- Mind the Context Window: When interacting with the AI, the entire conversation history (the context) is crucial. If the context window of the model is too small, it “forgets” earlier parts of the code or requirements, leading to errors and inconsistencies. Claude 3 Sonnet has a reasonably large context window, which was essential for this project’s success.
The Result: A Dynamic Service Map Application
After about three hours of work and roughly $10-20 in API costs (it might have been more due to some restarts!), I had a working proof-of-concept application. Here’s what it does:
- Connects to Zabbix: It fetches the list of hosts monitored by my Zabbix server.
- Discovers Services & Connections: For selected hosts, it retrieves information about running services and their network connections.
- Visualizes Dependencies: It generates a dynamic, interactive map showing the hosts and the communication links between them.
The “Magic Trick”: Using Netstat
How did I achieve the automatic discovery? The core mechanism is surprisingly simple, albeit a bit brute-force. I configured a Zabbix item on all relevant hosts to run the command:
netstat -ltunpa
This command provides a wealth of information about listening ports (services) and established network connections, including the programs associated with them. I added some preprocessing steps (initially aiming for CSV, though the core data comes from netstat) to make the data easier for the application to parse.
Live Demo Insights
In the video, I demonstrated the application live. It correctly identified:
- My Zabbix server host.
- Another monitored host (Graph Host).
- My own machine connecting via SSH to the Zabbix host (shown as an external IP since it’s not monitored by Zabbix).
- Connections between the hosts, such as the Zabbix agent communication (port 10050) and web server access (port 80).
- Clicking on hosts or connections reveals more details, like specific ports involved.
While the visual map is impressive (despite some minor graphical glitches that are typical of the rapid Vibe Coding process!), the truly valuable output is the underlying relationship data. This data is the key to achieving the original goal: enriching Zabbix events.
Next Steps and Your Thoughts?
This application is a proof-of-concept, demonstrating the feasibility of automatic service discovery using readily available data (like netstat output) collected by Zabbix. The “wow effect” of the map is nice, but the real potential lies in feeding this discovered dependency information back into Zabbix.
My next step, time permitting, is to tackle the event correlation phase – using these discovered relationships to automatically tag Zabbix problems, making root cause analysis much faster and more intuitive.
What do you think? I’d love to hear your thoughts, ideas, and suggestions in the comments below!
- Have you tried Vibe Coding or similar AI-assisted development approaches?
- Do you face similar challenges with service dependency mapping in Zabbix or other monitoring tools?
- Are there specific use cases you’d like me to explore further?
Don’t forget to like this post if you found it interesting, share it with others who might benefit, and subscribe to the Quadrata YouTube channel for more content like this!
You can also join the discussion on the ZabbixItalia Telegram Channel.
Thanks for reading, have a great week, and I’ll see you in the next video!
Bye from Dimitri.