It's 2:14 a.m. and my phone is buzzing because a customer's instance won't get a floating IP. The alert is one line. The truth is somewhere in about forty thousand lines spread across nova-compute
, neutron-server
, the OVS agent, and libvirtd
— each with its own timestamp format, its own idea of what a "request" is, and its own favorite way of burying the actual error under a wall of stack traces. This is the part of the job nobody puts on a slide. You are not solving a hard problem yet. You are finding the problem, and finding it is grep, scroll, swear, repeat.
This is exactly where AI earns its keep — and exactly where most people misuse it. So let me be precise about what I mean by "humanizing AI" for log analysis, because the phrase has been beaten half to death by marketing.
Humanizing AI does not mean an autonomous bot that "handles the incident." It means using a language model for the one thing it is genuinely, freakishly good at: pattern-matching and correlating across huge volumes of text, and translating jargon into plain English. A model can read forty thousand lines faster than you can scroll one screen, notice that the req-
ID in nova-compute
shows up again in neutron-server
1.2 seconds later attached to a binding failure, and tell you that in a sentence.
What it must not do is pull the trigger. The model reads; you decide. It hands you ranked hypotheses and a command to verify them — never a "fix" it wants to apply on its own. You are still the engineer on the hook when the change goes sideways, so you stay the final decision-maker. Every workflow below is built around that rule. I wrote a fuller treatment of this on my site at devopsaitoolkit.com/blog/humanizing-artificial-intelligence-in-log-analysis, but the short version is: the human stays in the loop, and the loop is where the judgment lives.
You are about to paste production logs into a model. Stop. Logs leak. They carry bearer tokens, Keystone auth tokens, DB connection strings, private IPs, customer email addresses, and the occasional password somebody logged "temporarily" in 2021. Treat every log line as hostile until you have stripped it.
I keep a redaction pass that runs before anything leaves the box:
journalctl -u nova-compute --since "10 min ago" --no-pager \
| sed -E \
-e 's/(password|passwd|secret|token|api[_-]?key)["'\'' :=]+[^ ,"]+/\1=REDACTED/gi' \
-e 's/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}/REDACTED_EMAIL/g' \
-e 's/\b([0-9]{1,3}\.){3}[0-9]{1,3}\b/REDACTED_IP/g' \
-e 's/Bearer [A-Za-z0-9._-]+/Bearer REDACTED/g' \
> /tmp/nova-redacted.log
It is not perfect — no regex is — but it catches the obvious offenders, and it forces you to look at what you are about to share. Eyeball the output before you paste it.
Pro Tip: Build the redaction step into the same command that pulls the logs, never as a separate afterthought. The moment "redact later" becomes a step you do by hand, you will skip it at 2 a.m. when it matters most. A pipe that always redacts is a habit; a checklist item is a future incident.
Start where most things start: the host. journalctl
is your front door, and a model is far better at reading its firehose output than you are when you're tired.
journalctl -p err --since "today" --no-pager -o short-iso \
| sed -E 's/Bearer [A-Za-z0-9._-]+/Bearer REDACTED/g' \
> /tmp/host-errors.log
The mistake people make is pasting raw lines and asking "what's wrong?" That gets you a confident, useless summary. Give the model the shape of what you want: timeline, correlation, and a verification step. The prompt matters more than the model. I keep a running set of patterns for this in my journald-with-AI write-up, but the core ask is always the same: "Group these by service and time, tell me which errors are causes versus symptoms, and give me a command to confirm before I touch anything."
That last clause is the whole game. A model will happily tell you "restart the OVS agent." A humanized workflow makes it tell you how to check whether the OVS agent is actually the problem first.
Container logs are where context discipline pays off. A crash-looping pod's current logs are often the least useful thing you can read — the interesting failure happened in the instance that already died. So you reach for the previous container:
kubectl logs deploy/payments -c api --previous --tail=500 \
| sed -E 's/(authorization|cookie):.*/\1: REDACTED/gi' \
> /tmp/payments-prev.log
Then pair it with the events, because the pod logs rarely tell you why Kubernetes killed the thing:
kubectl get events --field-selector involvedObject.name=payments-7d9f-abc \
--sort-by=.lastTimestamp
Now you hand the model both: the previous container logs and the events. The events say "OOMKilled" or "readiness probe failed"; the application logs say what the process was doing in its last breath. The model's job is to connect those two stories. On its own, neither one is conclusive. Together they usually are — and if you only feed one, the model will hallucinate the other half. Garbage context in, confident nonsense out.
Pro Tip: When you share container logs with a model, always say which container and whether it's --previous or current. "Here are the logs" is a trap — the model can't see your kubectl flags, and a restart-loop's current logs versus its previous logs tell completely different stories. Label your evidence.
If your container logs live in Loki rather than kubectl
, the same principle holds — you're just pulling from LogQL instead. I walked through that whole flow, including how to keep the model honest against a Loki backend, in reading Loki logs with AI. The pattern doesn't change with the backend; only the query language does.
Events are the most under-read signal in a cluster. They expire, they're noisy, and they're written in half-jargon that's easy to skim past. That's precisely the kind of text a model parses well. Dump them wide and let it cluster:
kubectl get events -A --sort-by=.lastTimestamp \
| grep -Ev "Normal\s+(Pulled|Created|Started|Scheduled)" \
> /tmp/events.log
Ask the model to bucket these by root cause, not by namespace — "show me which events are likely the same underlying problem reported by different controllers." A human scanning this sees a thousand lines. The model sees three problems wearing a thousand costumes. You still decide which of the three is worth waking someone up for. If you want a deeper dive on the cluster-side patterns, I keep my Kubernetes material at devopsaitoolkit.com/categories/kubernetes-helm.
Here's the 2 a.m. floating-IP problem, and it's the best example of why correlation beats reading. In OpenStack, a single API call fans out across services, and the only thread tying them together is the request ID. Find it, then chase it everywhere:
REQ="req-8f2c1a4e-..." # pulled from the nova-api log for the failed call
grep -h "$REQ" \
/var/log/nova/nova-compute.log \
/var/log/neutron/neutron-server.log \
/var/log/neutron/neutron-openvswitch-agent.log \
| sort \
| sed -E 's/\b([0-9]{1,3}\.){3}[0-9]{1,3}\b/REDACTED_IP/g' \
> /tmp/req-trace.log
For the libvirt side, the request ID won't follow you — libvirtd
and the per-instance QEMU logs key off the instance UUID and domain name instead, so you grab those by time window:
journalctl -u libvirtd --since "02:10" --until "02:16" --no-pager \
> /tmp/libvirt-window.log
Now you've got a stitched-together story across four logs in three formats. A human can read this. It just takes twenty minutes of cross-referencing timestamps while a customer waits. The model does the cross-referencing in seconds and — crucially — tells you which service first reported a real failure versus which ones are just downstream noise reacting to it. That causal ordering is the hard part, and it's exactly what correlation-across-text is built for.
Here's what a genuinely humanized output looks like. Not a fix. Ranked hypotheses, confidence, and the next command to run:
Most likely (high confidence):Thevif-plugged
event from the OVS agent never reachednova-compute
within the timeout.neutron-server
logged the port asBUILD
at 02:11:43 but never transitioned toACTIVE
. nova then timed out waiting for the network and rolled the instance back — so the floating-IP failure is asymptom, not the cause.
Verify before acting:openstack port show <PORT_ID> -f value -c status binding_vif_type
— if status isDOWN
orbinding_failed
, this hypothesis holds.
Less likely (medium confidence):OVS agent lost its connection toneutron-server
(RabbitMQ hiccup). Check withjournalctl -u neutron-openvswitch-agent --since 02:09 | grep -i "agent.*down\|AMQP"
.
Unlikely (low confidence):libvirt failed to attach the tap device. Only pursue if the port showsACTIVE
but the domain XML is missing the interface.
Read that again, because it models the behavior you want. It commits to an ordering. It separates cause from symptom. And every single hypothesis ends in a command you run to confirm or kill it — not an action the model took. You are still the one who runs openstack port show
and reads the result with your own eyes. If you want more OpenStack-specific debugging patterns, that's a whole category on my site at devopsaitoolkit.com/categories/openstack.
Pro Tip: Demand the model rank by confidence AND mark each hypothesis as cause or symptom. The single most expensive mistake in an incident is chasing a loud symptom while the quiet root cause keeps burning. Forcing that label turns the model from a search engine into a triage partner — but you still own the triage.
The difference between a useful AI log workflow and a dangerous one comes down to one demand: show your reasoning and give me a command to verify. A model that says "it's the OVS agent, restart it" is a liability. A model that says "I think it's the OVS agent because these three log lines, and here's the openstack port show
to confirm" is a colleague.
Build that demand into your prompt every time:
That last rule keeps the human firmly in control. The model can suggest you look at something. It does not get to suggest you change something, because the change is your call, with your context, and your name on the change ticket. AI reads; you decide. If you want to see this wired up as an actual assistant rather than a copy-paste loop, I run a free one you can poke at over at devopsaitoolkit.com/dashboard/incident-response.
Strip away the tooling and here's what's left. The model is a phenomenal reader and translator. It collapses forty thousand lines into three hypotheses, turns OpenStack's internal dialect into a sentence a sleep-deprived human can act on, and never gets bored on line thirty-nine thousand. That is real leverage, and refusing to use it out of purism is just making your nights longer.
But the decision is still yours. The model doesn't know that this customer is mid-migration and a "harmless" agent restart will nuke their in-flight transfer. It doesn't know your change-freeze window, your blast radius, or that the "obvious" fix burned you last quarter. That context lives in your head, and that's the irreducibly human part of the job. Humanizing AI means letting it do the reading so you have the energy left to do the deciding.
So redact your logs, feed the right context, demand the reasoning and the verification command — and then you run the command. That's the loop. That's the whole thing.
James Joyner IV runs devopsaitoolkit.com, where he writes about running production OpenStack, Kubernetes, and observability without losing his mind. Try the free AI Incident Response Assistant for ranked, verify-first log triage, and if you write about this stuff too, the Writing Humanizer pack keeps your prose sounding like you.