Analyse Loki logs with an agent that can read your code.
Finding the log line is half the job. The other half is working out what emitted it and why.
LogQL, generated
LogQL's stream selectors and parser expressions are more awkward to write from memory than PromQL, particularly when you need to extract a field from a JSON line and filter on it. Describing what you are looking for and getting the query is a real saving during an incident, which is precisely when nobody wants to read documentation.
The jump to code
A log line is a string emitted from a specific place. With the repository open the agent can find that place, which turns an unfamiliar error message into a location and a surrounding context. That step is normally a manual grep against a message that has been reformatted since it was written.
Patterns across many lines
The useful question is often not what one line says but whether a class of them correlates with something: a deploy, one tenant, one endpoint. That is analysis over the result set rather than a lookup, and it is the kind of thing that is tedious by hand and quick to ask for.
Local matters here most
Of everything in this category, logs are the data most likely to contain something sensitive, frequently by accident. Running against a local model means the lines stay on your machine while you analyse them.
Ask for it
Questions
Related
- Local-First AI Coding AgentSame agent core in a native desktop app and a 6 MB Rust binary, running whichever model you choose, including one on your own laptop.
- Local LLM Coding AgentFor when the constraint is not cost but that the code cannot leave the building.
- Diagram-Driven DevelopmentThe diagram stops being documentation produced after the fact and becomes the instruction the code is written from.
- Terminal Coding AgentOne binary, no runtime, no browser. Free and open source.