Hacktoberfest Open-Source AI Challenge: Ghost in the Machine Submission
A system error rarely explains itself. You get a timestamp, an error message, maybe a warning that appeared five minutes earlier, and the familiar task of figuring out what went wrong.
What if a local AI assistant could help you investigate those clues without sending your logs to a hosted AI service?
That idea led me to build GhostTrace, a local AI-powered system-log investigator using Python, Flask, Ollama, and Gemma 3 4B.
🔗 GitHub repository: https://github.com/Yadnu14/GhostTrace
👻 What is GhostTrace?
GhostTrace is a small web application that takes system log text and uses AI to produce a structured investigation report.
Instead of returning an unstructured paragraph, it aims to help developers separate what the logs actually show from what might have caused the problem and what to investigate next.
The current prototype includes:
Local AI inference: Gemma 3 4B runs through Ollama on the user's machine.
Log analysis: Users can supply log text for investigation.
Structured reports: Findings, possible causes, and recommended investigation steps are organized into a readable report.
Fallback analysis: Basic keyword-based analysis can provide a fallback when AI inference is unavailable.
Evidence-focused prompting: The model is instructed to avoid presenting unsupported assumptions as facts.
Browser-based interface: Flask serves the application, with HTML, CSS, and JavaScript providing the interface.
Safer report rendering: The frontend escapes HTML before applying Markdown-style formatting to generated reports.
GhostTrace is not a replacement for a monitoring platform or a professional incident-response workflow. It is an experiment in making log investigation more accessible with local AI.
🧠 Why Gemma 3 4B and Ollama?
I wanted the AI component to run locally instead of building another application that depends on a remote model API.
The architecture is intentionally simple:
User-supplied log text
|
v
Flask web application
|
v
Local Ollama API
|
v
Gemma 3 4B
|
v
Structured investigation report
|
v
Browser interface
The application sends the supplied logs to the locally running Ollama service, which uses Gemma 3 4B to generate the report.
If AI inference is unavailable, GhostTrace can fall back to simpler keyword-based analysis.
This approach keeps the application small enough to understand and modify without introducing a complicated cloud architecture.
🔐 Why local AI matters
Logs can contain more than technical errors. Depending on the application, they may include internal hostnames, file paths, account identifiers, tokens, or other sensitive information.
Sending logs to an external service may be inappropriate in some environments.
With GhostTrace's default local setup, inference runs through Ollama on the user's machine rather than a hosted AI API. After the model has been downloaded, the inference workflow does not need to send prompts to a remote model provider.
That distinction matters.
Local inference provides more control over where data goes, but it does not automatically make every application secure. Logs still need to be handled carefully, and the application must be configured and deployed responsibly.
Running an open-weight model also gives developers more flexibility. They can experiment with prompts, inspect the surrounding application code, and explore alternative models without rebuilding the entire project around a proprietary API.
For me, that flexibility is one of the most useful parts of open innovation: the ability to learn by building, changing, testing, and improving the system yourself.
🛠️ The practical engineering behind it
Getting a model to generate text is only one part of building a useful tool.
The surrounding application still needs to handle input, communicate with the model, present results clearly, and behave sensibly when something fails.
GhostTrace addresses a few of those concerns:
- Evidence before conclusions
The model is prompted to distinguish observations from hypotheses. A missing heartbeat, for example, may indicate a service problem, but it does not prove the precise root cause or that the issue has been resolved.
- A fallback path
If local AI inference is unavailable, basic keyword-based analysis can still offer limited assistance. This fallback is deliberately simple and should not be confused with a full diagnostic engine.
- Safer output handling
AI-generated content should not automatically be trusted as HTML. GhostTrace escapes HTML before rendering report formatting, reducing the risk of generated text being interpreted as executable markup.
- Keeping the scope controlled
GhostTrace analyzes supplied log text. It does not automatically execute system commands or modify system files. This keeps the prototype focused on investigation rather than giving an AI unrestricted control over a machine.
These are modest design choices, but they matter when building tools that interpret technical information.
🚀 Try GhostTrace locally
The project uses Python, Flask, Ollama, and Gemma 3 4B.
First, install Python and Ollama from their official websites:
Python: https://www.python.org/
Ollama: https://ollama.com/
Then clone the repository:
git clone https://github.com/Yadnu14/GhostTrace.git
cd GhostTrace
Create and activate a virtual environment in Windows PowerShell:
python -m venv .venv
..venv\Scripts\Activate.ps1
Install the dependencies:
python -m pip install -r requirements.txt
Download the model:
ollama pull gemma3:4b
With Ollama running, start the application:
python app.py
Open http://127.0.0.1:5000 in your browser and supply log text for investigation.
The initial model download requires an internet connection. Once downloaded, the model can perform inference locally.
⚠️ What GhostTrace cannot do yet
This project is a prototype, and its limitations are important.
AI-generated reports can be incorrect or incomplete.
Keyword-based fallback analysis is limited and may miss relevant context.
The current workflow depends on users supplying log text; it is not an automated monitoring agent.
It does not replace established observability tools, alerting systems, or forensic investigation.
It has not been presented as a production-ready or security-audited application.
A plausible explanation is not the same as a verified root cause. Any findings should be checked against the original logs.
🌍 The bigger idea: open innovation
The most interesting part of GhostTrace is not simply that an AI model can summarize logs.
It is that the complete workflow can be explored locally: the interface, the Python application, the prompts, the model integration, and the fallback logic.
Open-weight AI makes experimentation more accessible. Local inference can reduce dependence on external APIs, while open-source application code gives developers room to inspect and change how the system behaves.
That does not mean local models are always more capable than hosted models, or that open systems have no trade-offs. Model quality, hardware requirements, maintenance, and reliability still matter.
But for a project like GhostTrace, local inference is a practical fit for exploring AI-assisted troubleshooting while keeping the architecture understandable and the data flow under the developer's control.
🎃 Final thoughts
GhostTrace started with a simple question: can a small local AI model help make sense of system logs without sending them to a remote AI service?
The result is a working prototype built around Gemma 3 4B, Ollama, and Flask. There is plenty left to improve, but the project demonstrates how open-weight AI can be integrated into a practical developer tool without requiring a large cloud stack.
For the Ghost in the Machine challenge, GhostTrace is my take on finding something useful hiding inside the noise.
Sometimes the ghost is just an error message waiting for a closer look.
Explore the code: https://github.com/Yadnu14/GhostTrace
Built for the Hacktoberfest Open-Source AI Challenge, Week 4.
Top comments (0)