[drop_cap]B[/drop_cap]ackground radiation in space is a crazy thing. At any given moment cosmic rays, mostly protons and heavier nuclei flung out by exploding stars, punch straight through the hull of a spacecraft and through an astronaut’s eyeball. Can’t do much about it.

Apollo 11’s crew reported seeing flashes of light on the way to the Moon, eyes open or closed, roughly one every two or three minutes once they’d been in the dark long enough. Nothing was there. A particle had just crossed the retina, either ionizing it directly or throwing off a faint blue flicker of Cherenkov radiation as it outran the speed of light through the eye’s own fluid.

There is a similar kind of background radiation on the internet. And you also can’t do that much about it either. As anyone who has ever run a server knows, the moment an IP can be reached, it will be reached. Thousands of requests hitting your SSH port, trying to brute-force into your shiny new box before you’ve even logged in yourself. This type of radiation is less “cosmic” in origin but more mechanical: automated bot farms, compromised clients, just hammering every possible domain and IP and moving on. Like an army of invisible insects crawling to find a crack.

To most users it’s completely invisible. But if you maintain any kind of online service, congratulations, you are now at the receiving end of a bazillion automated requests: vulnerability scanning, credential stuffing, the works.

You can (and should) lock everything down as best you can, keep your stack updated and make sure nothing malicious gets through. Basic security hygiene will prevent most of this from doing real harm. But even with basic pattern-blocking and mitigation in place, it’s still staggering how much of an average server log is just “insect noise”.

While you’re busy optimizing your conversion funnels for X actual customers in your shiny “analytics” dashboard, there’s probably ten or twenty times that amount of trash hitting your box and eating up resources for no reason at all.

Again, it’s mostly harmless, but still annoying, because it clutters the logs. I’ve spent the last few days tuning out some of that noise: aiming to drop more requests at the edge (with some creative ASN filtering) before they ever reach the origin server.

I did the log-reading part with a basic tail -f for years. It works, but it’s not exactly easily parsable. So for this latest round I pivoted to lnav, and it’s been a game changer.

Color-coding out of the box. Keyboard binds for everything. Chain multiple log files. Mix and match raw access logs with syslog or a many other formats, all in one interactive TUI.

For someone like me who prefers debuggability over abstraction, lnav has become an invaluable tool for wading through the noise. It’s like htop, but for logs: the raw and unvarnished truth, presented in a way that lets me act on it fast.

It lets you toggle filters live, hide and show fields, and run actual SQL queries against your logs.

Thanks to lnav I spotted a bunch of new bad actor patterns and cut the background radiation on some of my live services by a whopping 80%. My raw logs are readable again, to the point where they’ve become more transparent than any analytics dashboard I’ve ever used.

And the best part: no consent banners, no tracking cookies. It’s all just sitting there, running on every server, waiting to be inspected. Worried customers aren’t hitting endpoints in the desired order, or that something’s misconfigured? Don’t bother with a tracking pixel. Just watch the logs.

That’s the part that actually got me. Not the tool, the fact that the machine is legible again. Every dashboard I’ve ever installed was someone else deciding what counted as signal before I got to see it. lnav doesn’t decide anything. It just shows me the log, helps me filter out any remaining noise and makes reading raw logs fun again.

It almost feels like a cheat code.