This _almost_ touches on the useful part of this:
If you search in less and then put it in follow mode, it continues to highlight the search terms. This is very useful for trapping an exception or webcall in the wild.
The downside:
less buffers and tail -f prints directly. On a slow printing log this can cause events to show up slowly, and can cause performance issues on a fast moving log.
If you're piping through a script for processing, tail -f is still the best bet. If you need multiple files, multitail is probably better.
less +F hits a quick+easy operational niche and is available almost everywhere (whereas multitail is not).
The other useful thing is filtering - on sufficiently modern versions of less [1], you can use & to filter the lines, in the same way you use / to search them - only lines matching the filter are shown, and the display continues to update. Use &! for a negative filter. This has replaced grep | tail for me, with the advantage that it's non-destructive, so you can undo the filter, reapply a different one, etc.
[1] Everything i've used on Linux in the last few years, not the vanilla one on the Mac, but the one in Homebrew
But how do you combine the two on the command line, so less is tailing the file AND highlighting a pattern when launched?
I typically read logfiles with less +F, but it would be nice to create an alias for patterns in specific types of logs, so I don't have to remember them or rely on command history.
From creating vi (nvi, on NetBSD) macros, I'm used to thinking in terms of competely replicating the keystrokes that one would do interactively... so I tried it both ways (with and without ^M). The way I published is the one that works. Why the ^M ? Because if you're working interactively the search-pattern isn't submitted until you press Enter. nvi(1) (what NetBSD (and Free and OpenBSD) uses) will accept "-c" "command" arguments which are similar to the less(1) "+"... so, you can:
$ vi -c 123 ./myfile
and start editing "./myfile" at line 123. Nice for edit/compile/edit/compile dance that might happen if you're developing software. Play with that (and try your imagination with other ideas).
I was going to mention multitail as well, which is a fantastic utility. That and rsstail, both by Folkert Van Heusden, are quite slick. The mark it leaves (a red line across the screen) is even more visible than those given by less.
I've commented a bit more on them (in the context of other RSS tools) here:
Though not quite applicable to logfiles, I've written a script to tail my Newsbeuter feed URLs with Multitail support, for a console / terminal-based RSS feed.
The downside: less buffers and tail -f prints directly. On a slow printing log this can cause events to show up slowly, and can cause performance issues on a fast moving log. If you're piping through a script for processing, tail -f is still the best bet. If you need multiple files, multitail is probably better. less +F hits a quick+easy operational niche and is available almost everywhere (whereas multitail is not).