Jarroba Tools · Logs

Understand a log without reading it: detected format, number of EVENTS (a 40-line stack trace counts as one), breakdown by level, time range, the errors with their ROOT CAUSE resolved, and the most frequent patterns. Accepts a file PATH — that is how you look at a log that does not fit in your context, such as a CI log of hundreds of MB.

What ELSE happened around a moment in time. Given an instant — the spike log_trends returned, or the time of an alert — find the patterns that cluster there and do not appear the same way in the rest of the log. Correlation is NOT causation, and what settles it is order: what started BEFORE comes first and is a candidate explanation; what came after is usually a consequence. Background noise is filtered out even when a narrow window lands on one of its bursts.

Convert a log from one format to another through OpenTelemetry's Logs Data Model: JSON, logfmt, syslog RFC 5424, CSV, OpenTelemetry or Elastic Common Schema. Tells you UP FRONT what the conversion loses — syslog only has eight severities and a text body, so coming down to it from JSON drops fields.

Check whether the log is WELL WRITTEN — not what happened in the system: secrets or personal data printed, one line flooding the file, timestamps with no time zone (which make two machines impossible to correlate), the clock going backwards, everything at the same level, no request id, payload dumps, and orphan stack traces with no error line. Every finding comes with its count and a sample; secrets are masked.

Group log lines into TEMPLATES (Drain algorithm): "connected to 10.0.0.1" and "connected to 10.0.0.7" are the same message. Turns a million lines into a few hundred readable things, each with its count, worst level and time range. Also returns the RARE ones (seen once or twice), which in a production log are usually what you were looking for.

Validate a Jarroba Tools LOG PROFILE (the `logprofile: 1` JSON that configures the log tools: format, server time zone, own-code prefixes, rules and AI budget). Returns ALL errors at once, each with the exact field (`rules[2].pattern`) and what was expected, so you can fix them in one pass instead of one at a time. Format documented in `public/logprofile.md`.

Propose a LOG PROFILE from a real log: infers the format, the own-code prefix (read from the stack traces, which is where it is demonstrated) and a starting set of rules covering the most frequent errors and whatever floods the file. What it does NOT propose is the server time zone: that is not in the log, and inventing it shifts the entire timeline without anyone noticing. Accepts a file path.

Cut a log down to a CHARACTER budget while keeping what matters: errors with their full stack trace, the window of what happened just before, and anything that appears only once or twice. Repeats are collapsed with their count ([xN]) and gaps are marked ([...N]). Use it to hand a big log to a model without spending the context on the same line repeated.

Put a folder or a list of rotated logs into TIME ORDER, split into series. Rotation numbering runs BACKWARDS against time: `app.log.3.gz` is older than `app.log.1.gz`, and plain `app.log` is the newest; alphabetically `app.log.10` sorts before `app.log.9` while in time it comes after. Use this BEFORE reading several logs of one service, or you will read them backwards. Returns the paths already ordered, ready to feed to log_analyze one by one.

Read an exception stack trace (Java/JVM, Python, Node, Go, .NET, Rust, Ruby or PHP) and answer the only question anyone asks it: WHERE TO LOOK. Follows the "Caused by" chain to the root cause, separates your code from the framework, and points at your first frame. Infers which package is yours from the trace itself if you do not say.

Answer WHEN IT STARTED, which is what a log is really asked. Compares each pattern against ITSELF rather than against total volume — in a busy service everything rises at 9am and nothing has happened — and returns three different things: what SPIKED relative to its own normal and at what time; what is NEW, which did not exist before and is usually what a deploy left behind; and what STOPPED APPEARING, which raises no counter and is often the worse news.