Search every session, filter by every dimension, and drill into one visit request by request with the beacon overlay beside it.
The result table and the facet sidebar are separate requests, so rows appear as soon as the documents are back rather than waiting on eight facets. Opening a session issues a third into the drill-down panel.
So a search is a bookmarkable URL, and the view degrades to a working table with JavaScript switched off. That is deliberate and it is the exception to the panel needing scripting for its numbers.
Free text goes to Solr as a bound parameter, never spliced into a query — and the rows are the full-text fields the schema builds for exactly this: the path, the User-Agent, the network operator, the netname, the reverse DNS name, the city and the country.
This is the one place in the panel that reaches the large hits index, and it is always bounded to one session and clamped for row count. What you get:
- The request timeline — every log line of the visit in order, with method, path, status, bytes and timing.
- The beacon overlay — the heartbeats and the final flush against that timeline, so you can see the reading time in between requests rather than only the requests.
- The verdict with its reasons, each one named in words, so “why did you call this a bot” is answerable from the document alone.
- The identity strip, flagged with the accent, if your site declared one — because those are the only facts on the page that Loghound did not derive for itself.
It is capped at fifty. The cap is not cosmetic: a crawler walking two hundred thousand URLs would otherwise put two hundred thousand values into one document, which is where a document goes from large to breaking the index merge. The true distinct count is carried separately, so nothing is fabricated — but a free-text path search covers the sample rather than everything that session touched.
Figure 1 — one session, both planes. The drill-down draws exactly this: the request timeline from the log, with the beacon overlay beneath it, so the reading time between requests is visible rather than inferred.
Everything that reaches Solr from this view is validated before it gets there, and it is worth knowing the shape of that because it is what makes a search box over hostile data safe:
- Free text is a bound parameter; the query itself accepts exactly one literal form and nothing else.
- A filter field must be on an allowlist, each value is capped at 256 characters, and each dimension at twenty values.
- Sorting maps an allowlisted key to a literal sort string. A field plus a direction is never assembled from input.
- Row and offset counts are clamped on every request, with a lower per-view ceiling.
- The returned field list is explicit, never a wildcard.
- A session id from the browser is shape-checked before it reaches a query.
Everything shown here came out of a log line written by somebody else, so it is escaped at every output point. The security model is the full account.