Lol, no. Unified log was designed first and foremost for Apple engineers and through some convoluted series of events that I am evidently not privy to ended up becoming exposed to developers as well. Except it was pretty much useless to developers because they couldn’t figure out how to use it. And not because the tools to use it effectively weren’t there, no, not at all; Apple engineers rely on them heavily (there are private, easy to use frameworks to work with log archives; the new, public OSLog framework that came out last year has an admittedly useful subset). No, the problem was that nothing was documented, most of the stuff that Apple was using to parse the logs and reassemble them remained private, and without these it’s hard enough to slog through the log stream let alone when you compound it with the many idiosyncrasies like private logging or trying to figure out which subsystem things are coming from. Really, Console is just the cherry on top because it gets even less love that logging guts itself because nobody has to use it internally.
Quite frequently, logs show up things like missing files and directories, incorrect permissions, unexpected configurations etc. which can be fixed by a sufficiently technical end user, without needing to go through support.
There's a similar problem with error dialogs. Product people always push to keep technical details out of those dialogs, even if technical users would find the details useful for accomplishing their goals, figuring out what went wrong and working around it. It's more forgiveable for dialogs, as long as there are logs.
When the logs are similarly indigestible, the software is simply less usable by technical users. Quality better be damn high, because if it breaks, and there's no way to look into the hard shiny shell, it can generate an amazing amount of frustration to people who are used to making stuff work.
(Of course the % of users who are sufficiently technical is decreasing all the time.)
Lol, yes; the number of times I've seen a message to the effect of "Something broke. Contact your system administrator.", and I stare at it, and I mutter "I am the sysadmin, you stupid machine!" is excessive.
I always thought: "Something Happened" might be the worst, ever, but I recently came upon this when setting up a Dell Desktop running Windows 10, trying to use a wireless keyboard. (I learned to always keep a USB keyboard around for bootstrapping purposes):
- "No keyboard detected, press any key to continue…."
I think there is a deep-seated bias at Apple against TUI's, and this is well and truly expressed in the flaming pile of junk that is Console.apps' GUI.
For me, tail and grep are always the better option when it comes time to look for messages, or try to observe what's going on with a system.
That said, it is also very shocking to sit and watch an idle MacOS machines' logfiles. Either most MacOS software is barely held together with bubble gum and duct tape, or there are a lot of messages being spewed by folks who forgot to turn their terrible debug logging off ..
One decent programmer could make Console a useful app.
One of them is "Log Reports", which lists every log file in /private/var/log/.
Console.app also makes plenty of use of structured data: right-click on a log entry (in the live-scrolling main view), and it offers you a dozen different facets to filter the view: hide/show by Thread/Application/Subsystem/User/Category/etc,
I've actually thought about using Console for development. It's far better at least compared to my current go-to "tail -f"
(By the way, I have yet to see anyone use the other logs in the sidecar because it’s easier to just open that folder in Finder.)
I suppose it might be ripe for wrapping with a TUI that can help with predicates and options...
Now I’m wondering if this console “rewrite” happened around the same time, perhaps in response to it. Maybe after seeing one difficult-to-wrangle log message, they concluded that gaining complete control over all logging was the only solution?
In any case, they went way too far. Console is effectively useless now; I got so tired of opening it up and finding nothing of value that I stopped even looking, and just apply every other possible debugging method first.
Their push for multi-process solutions like XPC have made logging even more useless because by default the new log system refuses to show output from sub-processes AT ALL. So imagine an app that previously had a nice sequential log for in-process actions A, B, and C; after migrating to sub-processes, now you see only the output of action B because the A and C actions are in different sub-processes! While there is a way to enable the output from all of them, it’s not the default and it’s not obvious and it’s just another stupid debugging hurdle.
$ log stream --level debug --process MyProcess > mylog.txt
For lighter-weight logging, replace "debug" with "info" or "default". If your program has debug symbols, you can also toss in the --source flag to add the filename and line number for each logging statement, if available.
The new logging is a significant improvement once you get used to it, IMO.
They used to "point at" the Console, which provided a handy, non-platform specific way to get debug output from a GUI app. But oh no, we can't have that. Got to use whatever the logging API flavor of the month is to get anything into the Console (that correct logging API (i.e. one that actuallyworks) has also changed over the last 4-5 releases).
Oh well, dup2 (2) to the rescue.
Anyone has recommendations for an app to tail log files over http?
Last 100 bytes of a website:
$ curl -sr -100 https://example.com
$ watch -n10 curl -sr -100 https://example.com