QuietOps: Local Gemma Turns 240 Docker Log Lines Into Five Signals 🦥

infraopsx — Tue, 20 Oct 2026 02:49:34 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge, Week 3: Slow and Steady.

What I Built

The least glamorous part of debugging a container incident is often the first five minutes: staring at a log stream and reading the same error dozens of times. I wanted the next operator to receive a small, readable handoff instead.

QuietOps is a local-first Python CLI that turns a bounded Docker/Linux log file into grouped symptoms and a cautious briefing generated by Gemma 3 1B running locally through Ollama.

The workflow is intentionally simple:

Scan the file for errors and warnings, with explicit limits on input size and line count.
Remove common secrets, IP addresses and email addresses on a best-effort basis; group repetitive messages and assign evidence IDs such as E01–E05.
Send only a small set of redacted examples to a loopback-only Ollama endpoint.
Ask the local model for potential explanations and read-only checks, while keeping the visible factual overview separate from model prose.
Validate JSON, reject non-existent IDs and some obviously unrelated event-to-claim citations. These conservative checks do not prove a suggestion correct.
Create Markdown, JSON and a standalone HTML handoff that distinguishes observations from hypotheses.

This is not an auto-remediation agent. It cannot connect to a production server, execute shell commands, edit configuration or restart containers. The human operator remains in control.

Demo

Open the live QuietOps report · Source code · Real-Gemma CI and deployment runs

The browser demo is a static HTML report produced by real Gemma 3 1B inference in GitHub Actions, not a mockup or a public model API. The Actions runner starts local Ollama, downloads Gemma's actual weights, analyzes the repository's synthetic fixture and publishes the resulting handoff. Visitors can inspect the generated JSON and Markdown without creating an account. The app does not accept log uploads on this public page.

I also kept a separate deterministic, no-model preview, explicitly labeled AI not run. It is not the live Gemma demonstration.

The synthetic fixture contains 240 Docker-style lines. QuietOps finds 110 warning/error lines and groups them into these five signatures:

Event	What the excerpt actually shows	Occurrences
E01	API logs a PostgreSQL connection URL (not proof that the URL is wrong)	32
E02	Worker retries queue delivery after a timeout (WARNING)	27
E03	API database query timeout	19
E04	Nginx upstream connection refused	17
E05	PostgreSQL password authentication failure for the app user	15

Five initial review items instead of 240 log lines is a 97.9% reduction in items to scan, not a measured 97.9% saving of an operator's time. Nor does it establish an accurate root-cause diagnosis.

To run the deterministic grouping without any model:

python3 examples/make_demo.py
python3 -m quietops preview examples/docker-incident.log --output-dir out/

To reproduce actual AI-assisted output locally after installing Ollama:

ollama pull gemma3:1b
# Make sure the local Ollama service is running.
python3 -m quietops scan examples/docker-incident.log --model gemma3:1b --output-dir out/

Code

The project uses only Python's standard library, and keeps Ollama as a separately installed local inference server. The core is broken into small inspectable stages:

input log
  → byte/line limits
  → best-effort secret redaction
  → error/warning filtering
  → repeated-signature grouping
  → E01–E05 evidence IDs
  → Ollama API on 127.0.0.1
  → Gemma 3 1B JSON response
  → schema + conservative event-reference checks
  → deterministic factual overview + unverified Gemma suggestions
  → self-contained HTML + Markdown + JSON

There is no signup, managed cloud database, background collector, hosted model or remote log upload. The network request is restricted to localhost, with HTTP proxies disabled for it. The parser checks the size before reading the entire file and does not process unbounded streams.

The project includes automated regression tests: a simulated local Ollama server, secret redaction, explicit WARNING handling, invented evidence IDs, and claims that cite unrelated log events. A separate GitHub Actions workflow downloads the actual Gemma weights and verifies a real model-generated artifact. These are deliberately separate levels of evidence; green tests do not prove a diagnosis is correct.

How I Built It

I started with a mundane handoff problem: the same few errors flood an incident log, but the next shift still has to scroll through every repetition.

I used the Python standard library for bounded parsing, normalization, grouping, redaction and report generation. The model gets a small set of redacted event excerpts over Ollama on 127.0.0.1, not the unfiltered log stream. The default first pass examines up to 8,000 lines or 2 MB and sends at most 12 event groups with two excerpts each; 8,000 is an engineering limit, not a measured Gemma quality threshold.

My first tests used a fake Ollama HTTP server. They passed, but the first actual Gemma run failed because the response wasn't valid JSON. Requiring Ollama JSON Schema structured output fixed the integration, as confirmed by this real-model CI run.

A subtler failure showed up once the browser demo was public. Gemma sometimes attached a real evidence ID to a statement the underlying log did not support. For example, a worker queue retry was treated as evidence of a database outage. I also discovered that keyword detection was labeling a WARNING about a timeout as ERROR.

That led to three concrete changes:

Explicit log levels take precedence over severity keywords such as "timeout".
The visible observed-log overview comes from deterministic counts and service labels, not unchecked model prose.
Model-generated hypotheses and read-only checks must cite existing events and pass conservative, event-by-event topical checks. Unrelated-service suggestions can be dropped.

These checks are intentionally modest. They do not verify causal reasoning. A note citing E05 for a suspected credential mismatch is a hypothesis worth checking, not a proven diagnosis. A model can still be wrong, even if every event ID exists.

One rare-but-critical failure test changed the selection logic. In a reproducible synthetic fixture containing 15 distinct, frequently repeated WARNING signatures and one single FATAL database corruption detected event, a pure top-12-by-frequency baseline omitted the FATAL. QuietOps now reserves one of the 12 slots for an observed FATAL/CRITICAL/PANIC/OOM/corruption signature when none would otherwise appear. The same test retains the FATAL. See the benchmark regression test and passing CI.

Synthetic case (16 distinct signatures)	Rare FATAL included in 12 shown?
Frequency-only baseline	No
QuietOps with critical-signal reservation	Yes

This comparison measures deterministic event selection only, not Gemma diagnosis accuracy, precision/recall over production incidents, or human time saved. One slot is reserved, not every rare failure; the tool remains a first-pass handoff rather than full incident analysis.

Why Does Open Innovation Matter?

Operational logs may contain internal hostnames, usernames, network details and credentials. Running inference on-device means the analysis does not require shipping those logs to a third-party API. This was my primary reason for using a locally runnable open-weight model.

The other benefit is control. I can inspect the preprocessing rules, change the prompt, replace the model and reproduce the test environment without paying per-token API fees. Once the model weights are downloaded, local inference can run without an external model service.

QuietOps's own code is MIT-licensed. Gemma model weights have their own Google Gemma terms and are not redistributed with the project. Secret redaction is best-effort, so users must still inspect logs before processing or sharing them.

The Lazy Payoff

Instead of requiring a tired operator to scroll 240 synthetic lines to find five recurring patterns, QuietOps turns the first pass into five reviewable groups, with optional local-Gemma suggestions clearly separated from observations.

It is a small, reproducible convenience, not an AI that claims to fix outages. The best possible result is that the next person can start asking better questions sooner—and can see exactly where the model might be wrong.

Prize Categories

Best Use of Gemma — actual Gemma 3 1B inference is demonstrated in the successful GitHub Actions run linked above.

Development disclosure: AI-assisted coding and English drafting were used in this project. The synthetic examples, CI outcomes and limitations are described as they actually occurred. No paid customers, real production diagnoses, measured human time savings or contest winnings are claimed.

DEV Community: infraopsx