Most kernel panics I've chased have been ghosts: they happen once, take the box down with them, and leave nothing useful behind because the disk the logs were meant to land on was the thing that froze. So when this one turned out to be reproducible, I was almost pleased.
The host would panic under heavy network load, roughly daily, always with the screen too garbled to read and nothing in the journal because it never got the chance to flush. The trick was getting the panic out of the dying machine before it died. netconsole does exactly that: it fires kernel log messages straight out over UDP to another box, no working disk required.
modprobe netconsole \
[email protected]/eth0,[email protected]/00:11:22:33:44:55
With a nc -u -l 6666 catching the stream on the other end, the next panic arrived complete. The trace pointed squarely at the NIC driver, in the receive path, under load. That was enough to find a known issue against that driver and confirm I was hitting it. Reproducing it on demand with an iperf3 blast meant I could test the fix instead of waiting a day to find out it hadn't worked.
A panic you can summon is a panic you can fix. The annoying ones are the polite ones that only show up when you're not looking.