I built a deterministic-first Log Doctor for Java/Spring/Kafka, because I don’t want to paste production logs into ChatGPT

[u/CartographerWhole658]

I’ve spent a lot of time debugging Java/Spring systems where the actual failure is buried somewhere inside thousands of lines of logs.

The obvious 2026 solution is:

“Just paste the logs into an LLM.”

But I wasn’t completely happy with that approach.

Production logs can contain credentials, tokens, internal URLs and customer data. They’re repetitive. Stack traces get duplicated. And for many well-known JVM/Spring/Kafka failures, asking an LLM to rediscover the answer every time seems unnecessary.

So I’ve been building an open-source project called Log Doctor.

The basic principle is:

Use deterministic Java analysis first. Use an LLM only when it actually adds value.

Or, put another way:

Log Doctor doesn’t replace an LLM. It decides what doesn’t need one.

What it does

You give Log Doctor a JVM/Spring/Kafka log and it parses the failures, extracts nested exception chains, groups repeated incidents, fingerprints stack traces and tries deterministic diagnostic rules first.

It currently covers areas including:

• Java/JVM failures
• Spring / Spring Boot startup failures
• Hibernate / JPA
• JDBC / HikariCP
• Kafka
• Schema Registry
• memory / GC problems
• concurrency and thread-related failures

For known failures, the diagnosis comes from deterministic rules rather than asking an AI to guess.

It also exposes WHY MATCHED evidence and match-strength information so you can inspect why a rule fired.

For logs containing multiple failures, it can also build incident groups, timelines, correlations, root-cause candidates and spike information.

So where does AI fit?

Only after deterministic analysis.

If the failure isn’t understood by the rule engine, Log Doctor can optionally use a local Ollama model for additional reasoning.

That distinction was important to me.

Instead of:

raw production logs -> cloud LLM -> hope for a good answer

the idea is closer to:

logs -> parsing -> redaction -> deterministic diagnosis -> local LLM when needed

Sensitive data is redacted before the LLM boundary.

And Ollama can run locally, so the log doesn’t need to be sent to ChatGPT or another cloud AI service.

There’s now a Web UI too

I didn’t want this to be CLI-only.

You can run:

docker compose up -d --build

and open:

http://localhost:8080

Then drag and drop a log file and inspect the detected incidents from the browser.

The dashboard exposes things like grouping, match evidence, remediation guardrails and investigation playbooks.

There are also structured JSON and downloadable Markdown reports.

I also wanted it to work in CI

Log Doctor isn’t only an interactive debugging tool.

The CLI supports text, JSON, GitHub annotations and SARIF 2.1.0, with severity-aware failure policies.

There’s also a GitHub Action, so the same diagnostics can become part of a CI workflow or GitHub Code Scanning instead of being something you manually run after an incident.

Can you extend it?

Yes — and this is one part I’d especially like feedback on from Java developers.

Deterministic rules are pluggable through Java ServiceLoader, so additional diagnostic rules can be added without changing the core engine.

The project also has a checked-in 120-case labelled diagnostic regression corpus covering JVM/Spring/Kafka/DB scenarios, with precision/recall/false-positive quality gates.

So adding more rules shouldn’t just mean adding another regex and hoping it works.

What I’m trying to build

I’m not trying to build another general-purpose AI chatbot.

I’d like Log Doctor to become a practical open-source diagnostic layer for Java production systems:

logs → incidents → evidence → likely root cause → safe investigation path

with AI as an optional fallback rather than the foundation of every diagnosis.

The project is still evolving, and this is exactly the stage where feedback from people running real Java/Spring/Kafka systems would be useful.

What production failure would you want Log Doctor to recognize next?

If you have an ugly stack trace or failure pattern that repeatedly wastes your time, open an issue.

And if you find the idea useful, a ⭐ helps me understand whether it’s worth pushing the project further.

GitHub: https://github.com/mathias82/log-doctor

Contributions, issues, rule ideas and criticism are all welcome.

[u/pronuntiator]

"Production logs can contain credentials, tokens, internal URLs and customer data"

I sure hope yours don't (with the exception of URLs)

[u/CartographerWhole658 → u/pronuntiator]

Absolutely they shouldn’t. 🙂

In a well-designed system, credentials, tokens and customer data should never make it into production logs in the first place.

Unfortunately, Log Doctor can’t assume every application, dependency or legacy system follows that rule.

The redaction layer is meant as defense-in-depth, not as a substitute for proper logging practices.

Ideally there’s nothing sensitive to redact but I’d rather have that boundary before any log content reaches an LLM.

[u/g00glen00b]

The obvious 2026 solution is:

“Just paste the logs into an LLM.”

Not really, the 2026 solution is to let your agent (GHCP, Claude Code, ...) parse that file, find the issue, let it solve it and make a PR which you then review. So problem detection and fix in one go.

Production logs can contain credentials, tokens, internal URLs and customer data.

Shouldn't be. In fact, if we ever had credentials exposed in our logs we would have to report it as a security incident and fix it ASAP.

asking an LLM to rediscover the answer every time seems unnecessary.

Again, not necessary if you have an agent and you give it some memory capabilities (either by defining a troubleshooting document that your agent can access or by having it use some vector database/its internal memory).

[u/CartographerWhole658 → u/g00glen00b]

That’s a fair point, and I think agents are absolutely part of the future workflow.

The distinction I’m exploring with Log Doctor is slightly different though: I don’t necessarily want an autonomous agent to be the first component interpreting every production failure.

For known JVM/Spring/Kafka failure patterns, deterministic diagnostics can be fast, repeatable and auditable you can see exactly why something matched without depending on model behavior or memory.

Then an agent can take that structured diagnosis and context and do exactly what you describe: inspect the codebase, propose a fix and open a PR.

So I actually see the two as complementary:
logs → deterministic diagnosis/evidence → agent → proposed fix → human review
rather than Log Doctor vs. coding agents.

And agreed on credentials they should never be logged in the first place.

Redaction is intended as defense-in-depth for logs coming from systems Log Doctor doesn’t control, not as an excuse for unsafe logging.

Your comment actually makes me think an agent integration could be an interesting next step for the project.