What I Built

LogTriage is an automated, privacy-first log analysis and triage engine designed to prevent developers and SREs from drowning in log noise[cite: 1].

When applications throw errors, standard log management tools flood on-call engineers with repetitive stack traces and raw dumps[cite: 1]. LogTriage solves this by ingesting live streams or log files, stripping noise and duplicates via fingerprinting, redacting sensitive data (like API tokens or PII), and using local LLMs to generate instant root-cause analysis, severity scores, and actionable fix recommendations[cite: 1].

Who would pay for it?

Managed Service Providers (MSPs) & SOCs: Needing scalable, automated first-responder triage without sending sensitive client data over third-party APIs.

DevOps & Engineering Teams: Looking to reduce Mean Time to Resolution (MTTR) and cut out-of-hours alert fatigue by receiving high-context summaries instead of raw error dumps.

Code

yashr5120 / LogTriage

An offline-first log triage engine that uses local Gemma AI via Ollama to detect critical errors, deduplicate log events, and generate concise diagnostic alerts while preserving privacy and reducing log noise.

Smart Local Log & Error Triage Engine

GitHub repository

An offline-first Python service that turns noisy application logs into grouped redacted, structured diagnostic alerts. Rules work without Ollama; an installed local Gemma model is optional and never receives a cloud request.

Features

Streaming stdin, regular-file, and tail -f-style file ingestion.
Case-insensitive severity rules with JSON and timestamped-text parsing.
Bounded traceback/context assembly and stable fingerprint deduplication.
Cooldown and severity escalation handling.
Ollama /api/generate integration with strict validation and rules fallback.
JSONL or human-readable output and optional SQLite history.
Deterministic demo scenarios and machine-readable benchmark metrics.

flowchart TD
 A[stdin/file/follow] --> B[Parser and severity rules]
 B --> C[Traceback context]
 C --> D[Sliding-window fingerprint groups]
 D --> E[Rules or local Ollama]
 E --> F[Validated Alert]
 F --> G[JSONL/console]
 F --> H[Optional SQLite]

Install and run

py -m venv .venv
.venv\Scripts\Activate.ps1
pip install -e ".[dev]"
logtriage demo --scenario

…

View on GitHub

How I Built It

LogTriage is built natively around local, open-weights AI models using Ollama:

Ingestion & Processing Engine (src/logtriage/ingestion/, processing/): Reads logs via standard input (stdin), static log files, or live continuous tailing (follow)[cite: 1]. It parses log formats, extracts multi-line stack traces, and groups identical errors into fingerprint clusters using local hashing[cite: 1].

Local Privacy & Redaction (src/logtriage/redaction.py): Before any log content touches an inference model, sensitive credentials, API keys, and personal data are scrubbed locally[cite: 1].

Open-Source AI Inference (src/logtriage/inference/): Connects to Ollama running open models (e.g., Llama 3 or Mistral)[cite: 1]. A structured prompt template extracts root causes and proposed fixes while enforcing strict output JSON validation[cite: 1].

Alerting & Metrics (src/logtriage/alerts/, metrics.py): Dispatches structured alerts to designated endpoints (like webhooks or Slack) while tracking token usage and processing latency[cite: 1].

Why Does Open Innovation Matter?

Log management is inherently fraught with strict compliance and data sovereignty constraints (GDPR, HIPAA, SOC 2). Sending raw, unredacted application logs or stack traces to closed cloud APIs poses significant data privacy risks.

Open-source AI and open-weights models make local, on-premise log triage possible. By running inference via Ollama directly on the local machine or internal server, LogTriage guarantees that raw enterprise logs never leave the internal infrastructure[cite: 1]. Closed APIs simply cannot offer this level of privacy, zero-latency local execution, and total control over data flow.

DEV Community

LogTriage