One installation covers every site on the machine, and one pair of indexes can cover several machines. This is where they are compared, and where you scope everything else to one of them.
Every hit and every session carries the virtual host it came from, so nothing here needs a second installation or a second index. On a machine serving one site this view has nothing to say; on one serving six it is the difference between a dashboard and a blur.
One row per host, sorted by evasive-bot share, capped at fifty hosts — and it is one faceted request with the five population queries nested inside it, so the cost does not grow with the number of sites.
Sorting by evasive share rather than by volume is the deliberate choice: the site you need to look at is rarely the busiest one, it is the one whose traffic is least human.
A host whose access log this installation reads and a host measured by the beacon alone sit in the same table, each row saying which it is. They are not comparable on everything — a beacon-only host has no status codes, no bytes and no server timing at all — so the table says so rather than letting a blank column read as a zero.
The second request on this view fills a host selector that is page furniture rather than a control on one card: it is reachable from every view, and picking a host adds a filter that every query on every view already applies. So scoping the entire dashboard to one site is one mechanism rather than seven.
- With one host or none, the selector is never inserted into the page at all. A control whose only option is the one you already have is noise.
- The selector’s own request removes the host filter from its own filters before it runs. Without that, picking a host would reduce the selector to the host you picked and there would be no way back.
If you run Loghound on more than one machine, joining a pair you already have is usually what you want: two indexes and six hostnames, rather than twelve indexes. They stay separable here, and there are three things that make it safe — session ids that cannot collide, hit ids that carry the installation id so two machines tailing identically named files cannot overwrite each other, and a writer field so a destructive operation can be scoped to its own documents.
Fingerprint clustering counts distinct addresses per fingerprint across every site in the index, on purpose: a rotating proxy fleet working through your sites in turn is exactly the pattern that is invisible from inside any one of them.