An LLM reads four hours of event logs in seconds and hands you anomaly candidates and a reconstructed timeline. The word doing the heavy lifting is "candidates": every finding gets confirmed against the raw logs before it enters your diagnosis — and logs with real names in them go to a local model, not the cloud.
Tier: Core · Workflow area: Troubleshooting & diagnosis · ~30 minutes
Log analysis is the AI use case with the best effort-to-value ratio in troubleshooting and the highest hallucination surface: models invent event IDs, shift timestamps, and manufacture tidy narratives from noisy data. The recipe below gets the speed while the verify-in-the-raw step keeps the honesty.
Select-String away; save the model for questions about patterns, not lookups.Extract a focused window. Time-bound, level-filtered, from the sources that matter. Windows:
Get-WinEvent -FilterHashtable @{
LogName = 'System','Application'
Level = 1,2,3 # critical, error, warning
StartTime = (Get-Date).AddHours(-4)
} | Select-Object TimeCreated, LogName, Id, ProviderName, LevelDisplayName, Message |
Export-Csv .\events-4h.csv -NoTypeInformation
Linux:
journalctl --since "-4 hours" -p warning -o short-iso --no-pager > syslog-4h.txt
Aim for hundreds to low thousands of lines. If the incident time is known, cut a ±30-minute window around it and a second, wider warning-level window for context.
Decide the privacy route before anything is pasted. Scan the extract: usernames, hostnames, IPs, email addresses, file paths with names in them? If yes — and for endpoint logs the answer is almost always yes — either sanitize with substitution (keep it consistent: the same user must map to the same placeholder or correlation dies) or run the analysis locally:
ollama pull llama3.1:8b
ollama run llama3.1:8b "$(cat analysis-prompt.txt events-4h.csv)"
Local models are noticeably weaker at this than frontier models — compensate with tighter extracts and expect an extra verification pass, not by giving up and pasting raw PII to the cloud.
Prompt for candidates and a timeline — with citation of line evidence.
You are helping analyze Windows event logs from a machine that froze and
rebooted around 11:20 local time. The CSV below covers 08:00–12:00.
Produce:
1. TIMELINE: reconstructed sequence of notable events with timestamps —
each entry must quote the source line's event ID and provider verbatim.
2. ANOMALY CANDIDATES: up to 5 patterns that deviate from the log's own
baseline (new error types, frequency spikes, silent gaps, ordering
oddities). For each: the evidence lines, and what would confirm or
refute it as relevant to the freeze.
3. WHAT'S MISSING: logs or time ranges you would want next.
Rules: cite only lines present in the data — never invent an event ID or
timestamp. Mark inferences as inferences. A gap in logging is a finding,
not a place to interpolate.
Log data:
[paste events-4h.csv]
Verify every finding in the raw. For each timeline entry and anomaly candidate, find the actual lines:
# Confirm the claimed disk warnings actually exist, with the claimed timing
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='disk'; StartTime=(Get-Date).AddHours(-4)} |
Format-Table TimeCreated, Id, Message -Wrap
grep -n "I/O error" syslog-4h.txt | head -20
You are checking three failure modes: invented entries (an event ID that appears nowhere), shifted times (real events, wrong order — fatal for causal reasoning), and overfitted stories (a clean narrative stitched over unrelated noise). A verified good output looks like:
TIMELINE (verified):
10:41 disk / Event 153 — "IO operation retried" (first occurrence in window) ✔ raw line 2211
10:52–11:14 Event 153 repeats 14x, escalating frequency ✔ count matches: 14
11:17 Application hangs: Event 1002, OfficeC2RClient ✔
11:20 Kernel-Power 41 — unclean reboot ✔
CANDIDATE CONFIRMED: storage degradation preceding freeze.
Next check: SMART status — not in event logs (correctly flagged as missing).
Let the confirmed picture drive the next extraction. Storage story confirmed? Pull SMART data and the storage controller logs. Auth anomalies? Pull the Security log for the same window. Iterating extract → analyze → verify beats one giant paste every time, and each loop's verified findings go into the ticket as you go.
log show --last 4h --predicate 'messageType >= 16' --style syslog > out.txt; the unified log is verbose, so halve the window before pasting.Endpoint and auth logs are personal-data-dense — real names, sign-in times, sometimes URLs that reveal behavior; default to the local-model route for anything user-attributable, and sanitize consistently when you must use a hosted model.
AI turns hours of log reading into minutes of log checking — the speed is real, but only the findings you have re-located in the raw logs are yours to act on; the rest is a well-told story.