If you’ve ever tried to dig a single obscure fact out of a massive technical manual, you’ll know the frustration 😩: you know it’s in there somewhere, you just can’t remember the exact wording, cmdlet name, or property that will get you there.
For me, this pain point came from Office 365 for IT Pros — a constantly updated, encyclopaedic PDF covering Microsoft cloud administration. It’s a superb resource… but not exactly quick to search when you can’t remember the magic keyword.
Often I know exactly what I want to achieve — say, add copies of sent emails to the sender’s mailbox when using a shared mailbox — but I can’t quite recall the right cmdlet or property to Ctrl+F my way to the answer.
That’s when I thought: what if I could take this PDF (and others in my archive), drop them into a centralised app, and use AI as the conductor and translator 🎼🤖 to retrieve the exact piece of information I need — just by asking naturally in plain English.
This project also doubled as a test bed for Claude Code, which I’d been using since recently completing a GenAI Bootcamp 🚀.
I wanted to see how it fared when building something from scratch in an IDE, rather than in a chat window.
👉 In this post, I’ll give a very high level overview of the four iterations (v1–v4) - what worked, what failed, and what I learned along the way.
I gave Claude clear instructions, and to its credit, it produced a functional backend and frontend pretty quickly. I uploaded a PDF into Pinecone, successfully chunked it, and then… nothing.
This first attempt was a non-starter 🚫.
Despite uploading the PDF successfully to Pinecone, the app was unable to retrieve any usable results for whatever reason. I spent a day troubleshooting before calling it a day and moving on.
I had kind of being following a YouTube tutorial for this project, but even though the tutorial was less than a year old, much of the content didn't map to what I was seeing - especially in the Pinecone UI.
Evidence of how quickly the AI landscape and products are changing I guess.😲
💡 Lesson learned: I should've known the steps I was following in the tutorial were likely to have changed.
I do afterall work with Microsoft Cloud on a daily basis, where product interfaces seem to change between browser refreshes!😎
👉 Which led me to v2: if I was going to try again, I wanted a cleaner, containerised architecture from the start.
The first attempt had been a sprawl of Python files, with Claude spinning up new scripts left, right, and centre. So I thought: let’s containerise from the start 🐳.
Features: Modular vector store interface, PDF + Markdown parsing, a React chat UI with source display
On paper, it looked solid. In practice: the containers refused to start, health checks failed — meaning the services never even got to the point of talking to each other — and ports (3030, 8000) were dead 💀.
In short, the project got a bit further in terms of useful results and functionality, but ultimately I parked it and went back to the drawing board.
💡 Lesson learned: Dockerising from day one helps with clean deployments, but only if the containers actually run.
By this point, I genuinely wondered if I was wasting my time and that I might be missing some huge bit of fundamental knowledge that was grounding the project before it had started 🫠.
Still, I knew I wanted to strip things back and simplify.
So, before ordering a copy of "The Big Book of AI: Seniors Edition" off of Amazon, I thought I would try a different tack.
👉 Which led directly to v3: drop the UI, keep it lean, focus on retrieval.
By this point, I realised the frontend was becoming a distraction 🎭. I’d spent too long wrestling with UX issues, which were getting in the way of the real meat and potatoes of the project — so I ditched the UI and went full CLI.
Stack: Python CLI, dual pipelines for PDF + Markdown
Chroma proved more successful than Pinecone, and the CLI gave me a faster dev loop ⚡.
But misaligned environment variables and Azure credential mismatches caused repeated headaches 🤯.
💡 Lesson learned: simplifying the interface let me focus on the retrieval logic — but configuration discipline was just as important. During issue debugging Claude will spin up numerous different python files to fix the issue(s) at hand. I had to remember to get Claude to roll the fixes into the new container builds each time, to ensure the project structure stayed clean and tidy
At this stage, I had a functioning app, but the results of retrival were pretty poor, and the functionality was lacking.
👉 Which led naturally into v4: keep the CLI, tune the retriaval process, and add the features that would make the app useable.
After three rewrites, I finally had something that looked and felt like a useable tool 🎉.
This is the version I still use today 🎉. It wasn’t a quick win: v4 took a long time to fettle into shape with many hours of trying different things to improve the results, testing, re-testing, and testing again 🔄.
The app is in pretty good shape now, with some good features added along the way. Most importantly, the results returned via query are good enough for me to use ✅.
Don’t get me wrong, the “final” version of the app (for now) is pretty usable — but I don’t think I’ll be troubling any AI startup finance backers any time soon 💸🙃.
Here’s what finally tipped the balance from “prototype” to “usable assistant”:
Semantic caching 🧠 – the assistant remembers previous queries and responses, so it doesn’t waste time (or tokens) re-answering the same thing.
ColBERT reranking 🎯 – instead of trusting the first vector search result, ColBERT reorders the results by semantic similarity, surfacing the most relevant chunks.
Analytics 📊 – lightweight stats on query quality and hit rates. Not a dashboard, more like reassurance that the retrieval pipeline is behaving.
Dynamic model control 🔀 – being able to switch between Azure OpenAI (fast, cloud-based) and Ollama (slow, local fallback) directly in the CLI.
💡 Lesson learned: retrieval accuracy isn’t just about the database — caching, reranking, and model flexibility all compound to make the experience better.
There were definitely points where frustration levels were high enough to make me question why I’d even started — four rewrites will do that to you. Pinecone that wouldn’t retrieve, Docker containers that wouldn’t start, environment variables that wouldn’t line up.
Each dead end was frustrating in the moment, but in hindsight, as we all know, the failures are where the learning is. Every wrong turn taught me something that made the next version a little better.
Pinecone: I created two or three different DBs and successfully chunked the data each time. But v1 and v2 couldn’t pull anything useful back out 🪫.
Azure: The only real issue was needing a fairly low chunk size (256) to avoid breaching my usage quota ⚖️.
Iteration habit: If I hit a roadblock with Claude Code that seemed to be taking me further away from the goal, I’d pause ⏸️, step away 🚶, then revisit 🔄. Sometimes it was worth troubleshooting; other times it was better to start fresh.
💡 Start with a CLI before adding a UI — it keeps you focused on retrieval.
💡 Always check embedding/vector dimensions for compatibility.
💡 Dockerising helps with clean deployments, but rebuilds can be brittle.
💡 Small chunk sizes often work better with Azure OpenAI quotas.
💡 RAG accuracy depends on multiple layers — not just the vector DB.
One of the constants across the project was working inside Claude Code, and there were some things I really liked about the experience:
✅ Automatic chat compaction – no endless scrolling or need to copy/paste old snippets
🗂️ Chat history – the ability to pick up where I left off in a previous session
🔢 On-screen token counter – knowing exactly how much context I was burning through
👀 Realtime query view – watching Claude process step-by-step, with expand/collapse options for analysis
Compared to a browser-based UI, these felt like small but meaningful quality-of-life upgrades. For a coding-heavy project, those workflow improvements really mattered.
This project started with the frustration of not being able to remember which cmdlet to search for in a 1,000-page PDF 😤. Four rewrites later, I have a tool that can answer those questions directly.
It’s far from perfect. There are limitations to how well the data can be processed and subsequently how accurately it can be retrieved — at least with the models and resources I used ⚖️. But it’s functional enough that I actually use it — which is more than I could say for versions one through three.
Overall, though, this wasn’t just about the app. It was about getting hands-on with a code editor in the terminal and IDE, instead of being stuck in a chat-based UI 💻. In that regard, the project goal was achieved. Using Claude Code (other CLI-based AI assistants are available 😎) was a much better experience for a coding-heavy project.
I did briefly try OpenAI’s Codex at the very start, just to see which editor I preferred. It didn’t take long to see that Codex didn’t really have the chops ❌. Claude felt sharper, more capable ✨, and it became clear why it has the reputation as the current CLI editor sweetheart 💖 — while Codex has barely made a ripple 🌊.
This project began, as many of mine do, with a career planning conversation. During a discussion with ChatGPT about professional development and emerging skill areas for 2025, one suggestion stuck with me:
"You should become an Infrastructure AI Integration Engineer."
It’s a role that doesn’t really exist yet — but probably should.
What followed was a journey to explore whether such a role could be real. I set out to build an AI-powered infrastructure monitoring solution in Azure, without any formal development background and using nothing but conversations with Claude. This wasn’t just about building something cool — it was about testing whether a seasoned infra engineer could:
Use GenAI to design and deploy a full solution
Embrace the unknown and lean into the chaos of LLM-based workflows
Create something reusable, repeatable, and useful
The first phase of the journey was a local prototype using my Pi5 and n8n for AI workflow automation (see my previous post for that). It worked — but it was local, limited, and not exactly enterprise-ready.
(Stage 1 – Manual AI-Assisted Deployment) The Birth of a Vibe-Coded Project
The project didn’t start with a business requirement — it started with curiosity. One evening, mid-career reflection turned into a late-night conversation with ChatGPT:
"You should become an Infrastructure AI Integration Engineer."
I’d never heard the term, but it sparked something. With 20+ years in IT infrastructure and the growing presence of AI in tooling, it felt like a direction worth exploring.
🤖 Generating all infrastructure and app code using natural language prompts
🧠 Letting Claude decide how to structure everything
🪵 Learning through experimentation and iteration
My starting prompt was something like: "I want to build an AI monitoring solution in Azure that uses Azure OpenAI to analyze infrastructure metrics."
Claude replied:
"Let’s start with a simple architecture: Azure Container Apps for the frontend, Azure Functions for the AI processing, and Azure OpenAI for the intelligence. We'll build it in phases."
That one sentence kicked off a 4–5 week journey involving:
The first build was fully manual — a mix of PowerShell scripts, Azure portal clicks, and Claude-prompting marathons. Claude suggested a phased approach, which turned out to be the only way to keep it manageable.
💬 Claude liked PowerShell. I honestly can’t remember if that was my idea or if I just went along with it. 🤷♂️
This project was built almost entirely through chat with Claude, Anthropic’s conversational AI. I’ve found:
✅ Claude is better at structured technical responses, particularly with IaC and shell scripting.
❌ ChatGPT tends to hallucinate more often in my experience when writing infrastructure code.
But Claude had its own quirks too:
No memory between chats — every session required reloading context.
Occasional focus issues — drifting from task or overcomplicating simple requests.
Tendency to suggest hardcoded values when debugging — needing constant vigilance to maintain DRY principles.
⚠️ Reality check: Claude isn't a Terraform expert. It's a language model that guesses well based on input. The human still needs to guide architecture, validate outputs, and ensure everything actually works.
With the foundation in place, the next step was to add the brainpower — the AI and automation components that turn infrastructure data into actionable insights.
This stage wasn’t about building complex AI logic — it was about using OpenAI to interpret patterns in infrastructure data and return intelligent summaries or recommendations in natural language.
Example prompt fed to OpenAI from within a Function App:
“Based on this log stream, are there any signs of service degradation or performance issues in the last 15 minutes?”
The response would be embedded in a monitoring dashboard or sent via alert workflows, giving human-readable insights without manual interpretation.
Each component in this layer was chosen for a specific reason:
OpenAI for flexible, contextual intelligence
Function Apps for scalable, event-driven execution
Logic Apps for orchestration without writing custom backend code
This approach removed the need for always-on VMs or bespoke integrations — and kept things lean.
📌 By the end of Phase 2, the system had a functioning AI backend that could interpret infrastructure metrics in plain English and respond in near real-time.
With the core infrastructure and AI processing in place, it was time to build the frontend — the visible interface for users to interact with the AI-powered monitoring system.
This phase focused on deploying a set of containerized applications, each responsible for a specific role in the monitoring workflow.
Each container serves a focused purpose, allowing for:
Isolation of concerns — easier debugging and development
Scalable deployment — each component scales independently
Separation of UI and logic — keeping the AI and logic layers decoupled from the frontend
“Claude recommended this separation early on — the decision to use Container Apps instead of AKS or App Services kept costs down and complexity low, while still providing a modern cloud-native experience.”
Here's what the success story doesn’t capture: the relentless battles with Claude’s limitations.
Despite its capabilities, working with GenAI in a complex, multi-phase project revealed real friction points — especially when continuity and context were critical.
Sometimes, working with Claude felt like pair programming with a colleague who had perfect recall — until they completely wiped their memory overnight.
🧵 From an actual troubleshooting session:
“The dashboard is calling the wrong function URL again.
It’s trying to reach func-tf-ai-monitoring-dev-ai,
but the actual function is at func-ai-monitoring-dev-ask6868-ai.”
It was a recurring theme: great memory during a session, zero continuity the next day.
Me: “Right, shall we pick up where we left off yesterday then?” Claude: “I literally have no idea what you're talking about, mate.” Claude: “Wait, who are you again?”
Every failure taught both me and Claude something — but the learning curve was steep, and the iteration cycles could be genuinely exhausting.
Interestingly, Claude dictated the stack more than I did.
Version 1 leaned heavily on PowerShell
Version 2 shifted to Azure CLI and Bash
Despite years of experience with PowerShell, I found Claude was significantly more confident (and accurate) when generating Azure CLI or Bash-based commands. This influenced the eventual choice to move away from PowerShell in the second iteration.
By the end of Part 1, I had a functional AI monitoring solution — but it was fragile, inconsistent, and impossible to redeploy without repeating all the manual steps.
That realisation led directly to Version 2 — a full rebuild using Infrastructure as Code.
After several weeks of manual deployments, the limitations of version 1 became unmissable.
Yes — the system worked — but only just:
Scripts were fragmented and inconsistent
Fixes required custom, ad-hoc scripts created on the fly
Dependencies weren’t tracked, and naming conflicts crept in
Reproducibility? Practically zero
🚨 The deployment process had become unwieldy — a sprawl of folders, partial fixes, and manual interventions. Functional? Sure. Maintainable? Absolutely not.
That’s when the Infrastructure as Code (IaC) mindset kicked in.
“Anything worth building once is worth building repeatably.”
The question was simple:
💡 Could I rebuild everything from scratch — but this time, using AI assistance to create clean, modular, production-ready Terraform code?
Rebuilding in Terraform wasn’t just a choice of tooling — it was a challenge to see how far AI-assisted development could go when held to production-level standards.
Modularity
Break down the monolithic structure into reusable, isolated modules
Portability
Enable consistent deployment across environments and subscriptions
DRY Principles
Absolutely no hardcoded values or duplicate code
Documentation
Ensure the code was clear, self-documenting, and reusable by others
Terraform wasn’t just a tech choice — it became the refinement phase.
A chance to take what I’d learned from the vibe-coded version and bake that insight into clean, structured infrastructure-as-code.
Next: how AI and I tackled that rebuild, and the (sometimes surprising) choices we made.
The prompt engineering approach became absolutely crucial during the Terraform refactoring phase.
Rather than relying on vague questions or “do what I mean” instructions, I adopted a structured briefing style — the kind you might use when assigning work to a consultant:
Define the role
Set the goals
Describe the inputs
Outline the method
Impose constraints
Here’s the actual instruction prompt I used to initiate the Terraform rebuild 👇
This structured approach helped maintain focus and provided clear boundaries for the AI to work within — though, as you'll see, constant reinforcement was still required throughout the process.
The Terraform rebuild became a different kind of AI collaboration.
Where version 1 was about vibing ideas into reality, version 2 was about methodically translating a messy prototype into clean, modular, production-friendly code.
A typical troubleshooting session went something like this:
I’d run the code or attempt a terraform plan or apply.
If there were no errors, I’d verify the outcome and move on.
If there were errors, I’d copy the output into Claude and we’d go back and forth trying to fix the problem.
This is where things often got tricky. Claude would sometimes suggest hardcoded values despite earlier instructions to avoid them, or propose overly complex fixes instead of the simple, obvious one. Even with clear guidance in the prompt, it was a constant effort to keep the AI focused and within scope.
The process wasn’t just code generation — it was troubleshooting, adjusting, and rechecking until things finally worked as expected.
The process revealed both the strengths and limitations of AI-assisted Infrastructure as Code development.
Building two versions of the same project entirely through AI conversations provided unique insights into the practical realities of AI-assisted development.
This wasn’t the utopian "AI will do everything" fantasy — nor was it the cynical "AI can’t do anything useful" view.
It was somewhere in between: messy, human, instructive.
⚡ Rapid prototyping and iteration
Claude could produce working infrastructure code faster than I could even open the Azure documentation.
Need a Container App with specific environment variables? ✅ Done.
Modify the OpenAI integration logic? ✅ Updated in seconds.
🧩 Pattern recognition and consistency
Once Claude grasped the structure of the project, it stuck with it.
Variable names, tagging conventions, module layout — it stayed consistent without me needing to babysit every decision.
🛠️ Boilerplate generation
Claude churned out huge volumes of code across Terraform, PowerShell, React, and Python — all syntactically correct and logically structured, freeing me from repetitive coding.
🧠 Context drift and prompt guardrails
Even with structured, detailed instructions, Claude would sometimes go rogue:
Proposing solutions for problems I hadn’t asked about
Rewriting things that didn’t need fixing
Suggesting complete redesigns for simple tweaks
🎉 Over-enthusiasm
Claude would often blurt out things like:
“CONGRATULATIONS!! 🎉 You now have a production-ready AI Monitoring platform!”
To which I’d reply: “Er, no bro. We're nowhere near done here. Still Cuz.”
(Okay, I don’t really talk to Claude like a GenZ wannabe Roadman — but you get the idea 😂)
🐛 Runtime debugging limitations
Claude could write the code. But fixing things like:
Azure authentication issues
Misconfigured private endpoints
Resource naming collisions
…was always on me. These weren’t things AI could reliably troubleshoot on its own.
🔁 Project continuity fail
There’s no persistent memory.
Every new session meant reloading context from scratch — usually by copy-pasting yesterday’s chat into a new one.
Tedious, error-prone, and inefficient.
⚠️ Fundamental challenge: No memory
Claude has no memory beyond the current chat. Even structured prompts didn’t prevent “chat drift” unless I constantly reinforced boundaries.
This is where ChatGPT has an edge in my opiion.
If I ask about previous chats, ChatGPT can give me examples and context about chats we had previously if prompted.
🎯 The specificity requirement
Vague:
"Fix the container deployment"
Resulted in:
"Let’s rebuild the entire architecture from scratch" 😬
Precise:
"Update the environment variable REACT_APP_API_URL in container-apps module"
Got the job done.
🚫 The hardcoded value trap
Claude loved quick fixes — often hardcoding values just to “make it work”.
I had to go back and de-hardcode everything to stay true to the DRY principles I set from day one.
**⏳ Time impact for non-devs
Both stages of the project took longer than they probably should have — not because of any one flaw, but because of the nature of working with AI-generated infrastructure code.
A seasoned DevOps engineer might have moved faster by spotting bugs earlier and validating logic more confidently. But a pure developer? Probably not. They’d likely struggle with the Azure-specific infrastructure decisions, access policies, and platform configuration that were second nature to me.
This kind of work sits in a grey area — it needs both engineering fluency and platform experience. The real takeaway? GenAI can bridge that gap in either direction, but whichever way you’re coming from, there’s a learning curve.
The cost: higher validation effort.
The reward: greater independence and accelerated learning.
The final Terraform solution creates a fully integrated AI monitoring ecosystem in Azure — one that’s modular, intelligent, and almost production-ready.
Here’s what was actually built — and why.
🧠 Azure OpenAI Integration
At the heart of the system is GPT-4o-mini, providing infrastructure analysis and recommendations at a significantly lower cost than GPT-4 — without compromising on quality for this use case.
📦 Container Apps Environment
Four lightweight, purpose-driven containers manage the monitoring workflow:
⚙️ FastAPI backend – Data ingestion and processing
📊 React dashboard – Front-end UI and live telemetry
🔄 Background processor – Continuously monitors resource health
🚀 Load generator – Simulates traffic for stress testing and metrics
⚡ Azure Function Apps for AI Processing
Serverless compute bridges raw telemetry with OpenAI for analysis.
Functions scale on demand, keeping costs low and architecture lean.
⚠️ The only part of the project not handled in Terraform was the custom dashboard container build.
That's by design — Terraform isn’t meant for image building or pushing.
Instead, I handled that manually (or via CI pipeline), which aligns with Hashicorps .
🆚 Why Container Apps instead of AKS?
Honestly? Claude made the call.
When I described what I needed (multi-container orchestration without complex ops), Claude recommended Container Apps over AKS, citing:
Lower cost
Simpler deployment
Sufficient capability for this workload
And… Claude was right. AKS would have been overkill.
💸 Why GPT-4o-mini over GPT-4?
This was a no-brainer. GPT-4o-mini gave near-identical results for our monitoring analysis — at a fraction of the cost.
Perfect balance of performance and budget.
📦 Why modular Terraform over monolithic deployment?
Because chaos is not a deployment strategy.
Modular code = clean boundaries, reusable components, and simple environment customization.
It’s easier to debug, update, and scale.
The final Terraform deployment delivers a complete, modular, and production-friendly AI monitoring solution — fully reproducible across environments. More importantly, it demonstrates that AI-assisted infrastructure creation is not just viable, but effective when paired with good practices and human oversight.
The final deployment provisions a complete, AI-driven monitoring stack — built entirely with Infrastructure as Code and connected through modular Terraform components.
This solution costs ~£15 per month for a dev/test deployment (even cheaper if you remember to turn the container apps off!😲) — vastly cheaper than typical enterprise-grade monitoring tools (which can range £50–£200+ per month).
Key savings come from:
⚡ Serverless Functions instead of always-on compute
📦 Container Apps that scale to zero during idle time
🤖 GPT-4o-mini instead of GPT-4 (with negligible accuracy trade-off)
Building the same solution twice — once manually, once using Infrastructure as Code — offered a unique lens through which to view both AI-assisted development and modern infrastructure practices.
🔎 The reality check
AI-assisted development is powerful but not autonomous. It still relies on:
Human oversight
Strategic decisions
Recognizing when the AI is confidently wrong
⚡ Speed vs. Quality
AI can produce working code fast — sometimes scarily fast — but:
The validation/debugging can take longer than traditional coding
The real power lies in architectural iteration, not production-readiness
📚 The learning curve
Truthfully, both v1 and v2 took much longer than they should have.
A seasoned developer with better validation skills could likely complete either project in half the time — by catching subtle issues earlier.
This project started as a career thought experiment — “What if there was a role focused on AI-integrated infrastructure?” — and ended with a fully functional AI monitoring solution deployed in Azure.
What began as a prototype on a local Pi5 evolved into a robust, modular Terraform deployment. Over 4–5 weeks, it generated thousands of lines of infrastructure code, countless iterations, and a treasure trove of insights into AI-assisted development.
The result is a portable, cost-effective, AI-powered monitoring system that doesn’t just work — it proves a point. It's not quite enterprise-ready, but it’s a solid proof-of-concept and a foundation for learning, experimentation, and future iteration.
AI-assisted development is powerful — but not autonomous.
It requires constant direction, critical oversight, and the ability to spot when the AI is confidently wrong.
Infrastructure as Code changes how you architect.
Writing Terraform forces discipline: clean structure, explicit dependencies, and reproducible builds.
Vibe coding has a learning curve.
Both versions took longer than expected. A seasoned developer could likely move faster — but for infra pros, this is how we learn.
Context management is still a major limitation.
The inability to persist AI session memory made long-term projects harder than they should have been.
The role of “Infrastructure AI Integration Engineer” is real — and emerging.
This project sketches out what that future job might involve: blending IaC, AI, automation, and architecture.
If you're an infrastructure engineer looking to explore AI integration, here’s the reality:
The tools are ready.
The method works.
But it’s not magic — it takes effort, patience, and curiosity.
The future of infrastructure might be conversational — but it’s not (yet) automatic.
If you’ve read this far — thanks. 🙏
I’d love feedback from anyone experimenting with AI-assisted IaC or Terraform refactors.
Find me on [LinkedIn] or leave a comment.
After successfully diving into AI automation with n8n (and surviving the OAuth battles), I decided to tackle a more ambitious learning project: exploring how to integrate AI into infrastructure monitoring systems. The goal was to understand how AI can transform traditional monitoring from simple threshold alerts into intelligent analysis that provides actionable insights—all while experimenting in a safe home lab environment before applying these concepts to production cloud infrastructure.
What you'll discover in this post:
Complete monitoring stack deployment using Docker Compose
Prometheus and Grafana setup for metrics collection
n8n workflow automation for data processing and AI analysis
Azure OpenAI integration for intelligent infrastructure insights
Professional email reporting with HTML templates
Lessons learned for transitioning to production cloud environments
Practical skills for integrating AI into traditional monitoring workflows
Here's how I built a home lab monitoring system to explore AI integration patterns that can be applied to production cloud infrastructure.
Full disclosure: I'm using a Visual Studio Enterprise subscription which provides £120 monthly Azure credits. This makes Azure OpenAI experimentation cost-effective for learning purposes. I found direct OpenAI API connections too expensive for extensive experimentation.
Building any intelligent monitoring system starts with having something intelligent to monitor. Enter the classic Prometheus + Grafana combo, containerized for easy deployment and scalability.
The foundation phase establishes reliable metric collection before adding intelligence layers. This approach ensures we have clean, consistent data to feed into AI analysis rather than trying to retrofit intelligence into poorly designed monitoring systems.
[ ] Deploy a multi-container application with Docker Compose
[ ] Debug why a container can't reach another container
[ ] Make API calls with authentication headers using curl
[ ] Read and understand JSON data structures
[ ] Explain what CPU and memory metrics actually mean for system health
Quick Test: Can you deploy a simple web application stack (nginx + database) using Docker Compose and troubleshoot networking issues? If not, spend time with Docker fundamentals first.
Common Issue at This Stage: Container networking problems are the most frequent stumbling block. If containers can't communicate, review Docker Compose networking documentation and practice with simple multi-container applications before proceeding.
The entire monitoring stack deploys through a single Docker Compose file. This approach ensures consistent environments from home lab development through cloud production.
Within minutes, you'll have comprehensive system metrics flowing through Prometheus and visualized in Grafana. But pretty graphs are just the beginning—the real transformation happens when we add AI analysis.
[ ] Understand what the metrics represent in business terms
[ ] Create a custom Grafana panel showing memory usage as a percentage
Quick Test: Create a dashboard panel that shows "Memory utilization is healthy/concerning" based on percentage thresholds. If you can't do this easily, spend more time with Prometheus queries and Grafana visualization.
Common Issues at This Stage:
Prometheus targets showing as "DOWN" - Usually container networking or firewall issues
Grafana showing "No data" - Often datasource URL configuration problems
PromQL query errors - Syntax issues with metric names or functions
Traditional monitoring tells you what happened (CPU is at 85%) but not why it matters or what you should do about it. Most alerts are just noise without context about whether that 85% CPU usage is normal for your workload or a sign of impending system failure.
This is where workflow automation and AI analysis bridge the gap between raw metrics and actionable insights.
What n8n brings to the solution:
Orchestrates data collection from multiple sources beyond just Prometheus
Transforms raw metrics into structured data suitable for AI analysis
Handles error scenarios and fallbacks gracefully without custom application development
Enables complex logic through visual workflows rather than scripting
Provides integration capabilities with email, chat systems, and other tools
Why AI analysis matters:
Adds context: "85% CPU usage is normal for this workload during business hours"
n8n transforms our basic monitoring stack into an intelligent analysis system. Through visual workflow design, we can create complex logic without writing extensive custom code.
The magic happens in the data processing node, which transforms Prometheus's JSON responses into clean, AI-friendly data structures. This step is crucial—AI analysis is only as good as the data you feed it.
// Process Metrics Node - JavaScript Codeconstinput=$input.first();try{// Extract metric values from Prometheus responseconstmemoryData=input.json.data.result[0];constmemoryPercent=parseFloat(memoryData.value[1]).toFixed(2);// Determine system health statusletalertLevel,alertStatus,systemHealth;if(memoryPercent<60){alertLevel='LOW';alertStatus='HEALTHY';systemHealth='optimal';}elseif(memoryPercent<80){alertLevel='MEDIUM';alertStatus='WATCH';systemHealth='elevated but manageable';}else{alertLevel='HIGH';alertStatus='CRITICAL';systemHealth='requires immediate attention';}// Structure data for AI analysisconstprocessedData={timestamp:newDate().toISOString(),memory_percent:parseFloat(memoryPercent),alert_level:alertLevel,alert_status:alertStatus,system_health:systemHealth,collection_source:'prometheus',analysis_ready:true};return{json:processedData};}catch(error){console.error('Metrics processing failed:',error);return{json:{error:true,message:'Unable to process metrics data',timestamp:newDate().toISOString()}};}
[ ] Understand the data flow from Prometheus → n8n → Email
Quick Test: Build a simple workflow that emails you the current memory percentage every hour. If this seems challenging, spend more time understanding n8n's HTTP request and JavaScript processing nodes.
Common Issues at This Stage:
n8n workflow execution failures - Usually authentication or API endpoint problems
JavaScript node errors - Often due to missing error handling or incorrect data parsing
Email delivery failures - SMTP configuration or authentication issues
Debugging Tip: Use console.log() extensively in JavaScript nodes and check the execution logs for detailed error information.
This is where the system evolves from "automated alerting" to "intelligent analysis." Azure OpenAI takes our clean metrics and transforms them into actionable insights that even non-technical stakeholders can understand and act upon.
The transition from raw monitoring data to business intelligence happens here—transforming "Memory usage is 76%" into "The system is operating efficiently with healthy resource utilization, indicating well-balanced workloads with adequate capacity for current business requirements."
Why this transformation matters:
Technical teams get context about whether metrics indicate real problems
Business stakeholders understand impact without needing to interpret technical details
Decision makers receive actionable recommendations rather than just status updates
The AI analysis node sends structured data to Azure OpenAI with carefully crafted prompts:
// Azure OpenAI Analysis Node - HTTP Request Configuration{"url":"https://YOUR_RESOURCE.openai.azure.com/openai/deployments/gpt-4o-mini/chat/completions?api-version=2024-02-15-preview","method":"POST","headers":{"Content-Type":"application/json","api-key":"YOUR_AZURE_OPENAI_API_KEY"},"body":{"messages":[{"role":"system","content":"You are an infrastructure monitoring AI assistant. Analyze system metrics and provide clear, actionable insights for both technical teams and business stakeholders. Focus on business impact, recommendations, and next steps."},{"role":"user","content":"Analyze this system data: Memory usage: {{$json.memory_percent}}%, Status: {{$json.alert_status}}, Health: {{$json.system_health}}. Provide business context, technical assessment, and specific recommendations."}],"max_tokens":500,"temperature":0.3}}
The AI response gets structured into professional reports suitable for email distribution:
// Create Report Node - JavaScript Codeconstinput=$input.first();try{// Handle potential API errorsif(!input.json.choices||input.json.choices.length===0){thrownewError('No AI response received');}// Extract AI analysis from Azure OpenAI responseconstaiAnalysis=input.json.choices[0].message.content;constmetricsData=$('Process Metrics').item.json;// Calculate token usage for monitoringconsttokenUsage=input.json.usage?input.json.usage.total_tokens:0;constreport={report_id:`AI-MONITOR-${newDate().toISOString().slice(0,10)}-${Date.now()}`,generated_at:newDate().toISOString(),ai_insights:aiAnalysis,system_metrics:{memory_usage:`${metricsData.memory_percent}%`,cpu_usage:`${metricsData.cpu_percent}%`,alert_status:metricsData.alert_status,system_health:metricsData.system_health},usage_tracking:{tokens_used:tokenUsage,model_used:input.json.model||'gpt-4o-mini'},metadata:{next_check:newDate(Date.now()+5*60*1000).toISOString(),report_type:metricsData.alert_level==='LOW'?'routine':'alert',confidence_score:0.95// Based on data quality}};return{json:report};}catch(error){// Fallback report without AI analysisconstmetricsData=$('Process Metrics').item.json;return{json:{report_id:`AI-MONITOR-ERROR-${Date.now()}`,generated_at:newDate().toISOString(),ai_insights:`System analysis unavailable due to AI service error. Raw metrics: Memory ${metricsData.memory_percent}%, CPU ${metricsData.cpu_percent}%. Status: ${metricsData.alert_status}`,error:true,error_message:error.message}};}
This transforms the AI response into a structured report with tracking information, token usage monitoring, and timestamps—everything needed for understanding resource utilization and system performance.
Before moving to production thinking, verify you can:
[ ] Successfully call Azure OpenAI API with authentication
[ ] Create prompts that generate useful infrastructure analysis
[ ] Handle API errors and implement fallback behavior
[ ] Monitor token usage to understand resource consumption
[ ] Generate reports that are readable by non-technical stakeholders
Quick Test: Can you send sample metrics to Azure OpenAI and get back analysis that your manager could understand and act upon? If the analysis feels generic or unhelpful, focus on prompt engineering improvement.
Common Issues at This Stage:
Azure OpenAI authentication failures - API key or endpoint URL problems
Rate limiting errors (HTTP 429) - Too frequent API calls or quota exceeded
Generic AI responses - Prompts lack specificity or context
Token usage escalation - Inefficient prompts or too frequent analysis
The difference between this and traditional monitoring emails is remarkable—instead of "CPU is at 85%," stakeholders get "The system is operating within optimal parameters with excellent resource efficiency, suggesting current workloads are well-balanced and no immediate action is required."
Understanding the real progression of this project helps set realistic expectations for your own learning experience.
Week 1: Foundation Building
I started by getting the basic monitoring stack working. The Docker Compose approach made deployment straightforward, but understanding why each component was needed took time. I spent several days just exploring Prometheus queries and Grafana dashboards—this foundational understanding proved essential for later AI integration.
Week 2: Workflow Automation Discovery
Adding n8n was where things got interesting. The visual workflow builder made complex logic manageable, but I quickly learned that proper error handling isn't optional—it's essential. Using Anthropic Claude to debug JavaScript issues in workflows saved hours of frustration and accelerated my learning significantly.
Week 3: AI Integration Breakthrough
This is where the real magic happened. Seeing raw metrics transformed into business-relevant insights was genuinely exciting. The key insight: prompt engineering for infrastructure is fundamentally different from general AI use—specificity about your environment and context matters enormously.
Week 4: Production Thinking
The final week focused on understanding how these patterns would apply to real cloud infrastructure. This home lab approach meant I could experiment safely and make mistakes without impact, while building knowledge directly applicable to production environments.
After running the system continuously in my home lab environment:
System Reliability:
Uptime: 99.2% (brief restarts for updates and one power outage)
Data collection reliability: 99.8% (missed 3 collection cycles due to network issues)
AI analysis success rate: 97.1% (some Azure throttling during peak hours)
Email delivery: 100% (SMTP proved reliable for testing purposes)
Resource Utilization on Pi 5:
Memory usage: 68% peak, 45% average (acceptable for home lab testing)
CPU usage: 15% peak, 8% average (monitoring has minimal impact)
Storage growth: 120MB/week (Prometheus data with 7-day retention and compression)
Response Times in Home Lab:
Metric collection: 2.3 seconds average
AI analysis response: 8.7 seconds average (Azure OpenAI)
End-to-end report generation: 12.4 seconds
Email delivery: 3.1 seconds average
Token Usage Observations:
Average tokens per analysis: ~507 tokens
Analysis frequency: Hourly during active testing
Model efficiency: GPT-4o-mini provided excellent analysis quality for infrastructure metrics
Optimization: Prompt refinement reduced token usage by ~20% over time
Note: These are home lab observations for learning purposes. Production cloud deployments would have different performance characteristics and scaling requirements.
Prometheus query optimization is critical: Inefficient queries can overwhelm the Pi 5, especially during high-cardinality metric collection. Always validate queries against realistic datasets and implement appropriate rate limiting. Complex aggregation queries should be pre-computed where possible.
n8n workflow complexity escalates quickly: What starts as simple data collection becomes complex orchestration with error handling, retries, and fallbacks. Start simple and add features incrementally. I found that using Anthropic Claude to help debug workflow issues significantly accelerated problem resolution.
AI prompt engineering requires iteration: Generic prompts produce generic insights that add little value over traditional alerting. Tailoring prompts for specific infrastructure contexts, stakeholder audiences, and business objectives dramatically improves output quality and relevance.
Network reliability affects everything: Since the system depends on multiple external APIs (Azure OpenAI, SMTP), network connectivity issues cascade through the entire workflow. Implementing proper timeout handling and offline modes is essential for production reliability.
Token usage visibility drives optimization: Monitoring token consumption in real-time helped optimize prompt design and understand the resource implications of different analysis frequencies. This transparency enabled informed decisions about monitoring granularity versus AI resource usage.
// Implement exponential backoff for API callsasyncfunctionretryWithBackoff(apiCall,maxRetries=3){for(letattempt=1;attempt<=maxRetries;attempt++){try{returnawaitapiCall();}catch(error){if(error.status===429||error.status>=500){constbackoffDelay=Math.min(1000*Math.pow(2,attempt),30000);awaitnewPromise(resolve=>setTimeout(resolve,backoffDelay));}else{throwerror;}}}thrownewError(`API call failed after ${maxRetries} attempts`);}
This home lab project successfully demonstrates how AI can transform traditional infrastructure monitoring from simple threshold alerts into intelligent, actionable insights. The structured approach—from Docker fundamentals through AI integration—provides a practical learning path for developing production-ready skills in a cost-effective environment.
Key Achievements:
Technical Integration: Successfully combined Prometheus, Grafana, n8n, and Azure OpenAI into a cohesive monitoring system
AI Prompt Engineering: Developed context-specific prompts that transform raw metrics into business-relevant insights
Professional Communication: Created stakeholder-ready reports that bridge technical data and business impact
Cost-Conscious Development: Leveraged subscription benefits for extensive AI experimentation
Most Valuable Insights:
AI analysis quality depends on data structure and prompt engineering - generic prompts produce generic insights
Visual workflow tools dramatically reduce development complexity while maintaining flexibility
Home lab experimentation provides a safe environment for expensive AI service optimization
Business context and stakeholder communication are as important as technical implementation
Professional Development Impact:
The patterns learned in this project—intelligent data collection, contextual analysis, and automated communication—scale directly to enterprise monitoring requirements. For infrastructure professionals exploring AI integration, this home lab approach provides hands-on experience with real tools and challenges that translate to immediate career value.
The investment in learning these integration patterns delivers improved monitoring effectiveness, reduced alert noise, and enhanced stakeholder communication—essential skills for modern infrastructure teams working with AI-augmented systems.
