Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log messages are mostly for the people operating your software

utcc.utoronto.ca

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Log messages are mostly for the people operating your software

#21

Post by gnoack »

woeirua wrote: post #20

I feel like this is an outdated point of view now. Logs are clearly going to be read primarily by agents very soon, if they're not already now. For example, we're experimenting with having Claude Desktop read log files for remote users. It's often able to troubleshoot and solve issues for our users faster than we can, especially after you give it access to your codebase through GH MCP or something like that. It's wil…

How does this change the point that is being made in the article? Your agent is also only taking one of the existing roles that humans today occupy (e.g. the software operator or developer)

Re: Log messages are mostly for the people operating your software

#22

Post by ragall »

mfuzzey wrote: post #14

Depends a lot on the context and type of software. For server side software where there is a sysadmin in charge of keeping it running I generally agree. But for end user software (desktop, mobile, embedded) no one wil read the logs and there the logs can, and probably should, be aimed at the developers. Of course you can and should still provide usable and informative end user oriented error messages but they're not…

> But for end user software (desktop, mobile, embedded) no one wil [sic] read the logs

Lots of end user software is used in an enterprise context where the helpdesk staff will have to read those logs. And for B2C (or retail, or amateur, whatever you want to call them) users, often they will go through online tutorials to try to self-diagnose because the developers are most of the time unreachable.

Re: Log messages are mostly for the people operating your software

#23

Post by ragall »

Etheryte wrote: post #2

While I see the point the author is trying to make, I'm not really sure I agree. Most users don't even read error messages, never mind logs. At best, logs are something they need for compliance, for most, the concept doesn't exist at all. I do agree that the logs should help you understand what went wrong and why, but in that regard the principle is the same for both sysadmins and developers and I don't really see th…

> but in that regard the principle is the same for both sysadmins and developers and I don't really see the difference?

No, it's very different: developers generally want to know about things they control, so they want detailed debugging info about a program's internal state that could have caused a malfunction. Sysadmins don't care about that (they're fine with coalescing all the errors that developers care about under a general "internal error"), and they care about what in the program environment could have triggered the bug, so that they may entirely avoid it or at least deploy workarounds to sidestep the bug.

Re: Log messages are mostly for the people operating your software

#24

Post by justsomehnguy »

> But if your software is successful (especially if it gets distributed to other people), most of the people running it won't be the developers, they'll only be operating it.

The biggest problem is what when you wrote a code for a 'totally obvious message' you yourself was in the context. Years, year, heck even weeks later you would stare at it and wonder 'why tf I didn't wrote something more verbose?'.

Anecdote: I wrote some supporting scripts to 'integrate' two systems three times - totally oblivious the second and the third times what I already did it. Both times I was somewhere 60% when I though 'wait I totally recognize this code but I just wrote it! What in Deja-vu-nation?!'.

Re: Log messages are mostly for the people operating your software

#25

Post by woeirua »

gnoack wrote: post #21
woeirua wrote: post #20

I feel like this is an outdated point of view now. Logs are clearly going to be read primarily by agents very soon, if they're not already now. For example, we're experimenting with having Claude Desktop read log files for remote users. It's often able to troubleshoot and solve issues for our users faster than we can, especially after you give it access to your codebase through GH MCP or something like that. It's wil…

How does this change the point that is being made in the article? Your agent is also only taking one of the existing roles that humans today occupy (e.g. the software operator or developer)

If the logs are being read by agents then they should be more detailed and verbose to help the agent understand the root cause. We reduce the volume of information for humans. That doesn’t need to be the case any longer.

Re: Log messages are mostly for the people operating your software

#26

Post by jauntywundrkind »

This is a not-so subtle advantage JavaScript has over 90% of everything else: Chrome DevTools Protocol (CDP), which exists/is-great in-large-part thanks to JavaScript being an alive language. Of the Stop Writing Dead Programs variety (https://jackrusher.com/strange-loop-2022/, https://news.ycombinator.com/item?id=33270235). It's just astoundingly capable, so very richly exposes such a featureful runtime, across so many dimensions of tooling. REPL, logging, performance, heap, profile, storage, tracing and others, just for the core, before you get into the browser based things. https://chromedevtools.github.io/devtools-protocol/

This is such a core advantage to javascript: that it is an alive language. The runtime makes it very easy to change and modify systems ongoingly, and as an operator, that is so so so much better than having a statically compiled binary, in terms of what is possible.

One of my favorite techniques is using SIGUSR1 to start the node debugger. Performance impact is not that bad. Pick a random container in prod, and... just debug it. Use logpoints instead of breakpoints, since you don't want to halt the world. Takes some scripting to SSH port forward to docker port forward to the container, but an LLM can crack that script out in no time. https://nodejs.org/en/learn/getting-started/debugging#enable...

My cherry on top is to make sure the services my apps consume are attached to globalThis, so I can just hit my services directly from the running instance, in the repl. Without having to trap them being used here or there.

Re: Log messages are mostly for the people operating your software

#27

Post by superjan »

lucianbr wrote: post #13
EvanAnderson wrote: post #12

Earlier quoted context omitted.

In my sysadmin work I curse every developer who makes me fire up strace, tcpdump, procmon, Wireshark, etc, because they couldn't be bothered to actually say what file couldn't be found, what TCP connection failed to be established. etc.

I get the impression that often it isn't laziness but the concept that error details leak information to an attacker and are therefore a vulnerability. I disagree with this view, but it definitely exists.

Yeah, along those lines we have requirements on never logging PII, and not logging anything that potentially contains PII, such as folder names.

Re: Log messages are mostly for the people operating your software

#28

Post by dexwiz »

dylan604 wrote: post #8
dexwiz wrote: post #4

Earlier quoted context omitted.

That question is more likely how do I install, not what to install.

I think that's being very generous. If you've ever been in tech support, you'll be amazed at how often you'll be asked what to do when it tells me to do X. If they don't know how to do X, then they should be able to look up how to do X. If it's something like install 3rd party library, then that's not the first party's responsibility. Especially OSS for different arch/distros. They are all different. Look up the 3rd…

I've worked in tech support. I get that 25-50% of the cases appear to be "read the docs to me." But the majority of those is because docs are poorly written, are overwhelming for new users, or they don't understand them and won't admit that directly.

Re: Log messages are mostly for the people operating your software

#29

Post by thayne »

LgWoodenBadger wrote: post #7

All software should provide something meaningful for anybody to diagnose, if they’re inclined to. It’s particularly bad in the (Apple) mobile ecosystem, including AppleTV. I have AdGuard Home but one of my spouse’s streaming services wouldn’t work. “There was a problem.” Gee thanks. Eventually figured out that I had to unblock a few hosts so it would work. Only found which ones by googling and finding some other poor…

> It’s particularly bad in the (Apple) mobile ecosystem

It's been years since I've significantly used Apple software, but when I had to use a Mac at work, or helped friends or family troubleshoot some problem on Mac OS, I had a similar experience. When things don't "just work", it was very difficult to figure out why it didn't work.

Re: Log messages are mostly for the people operating your software

#30

Post by bonoboTP »

LgWoodenBadger wrote: post #7

All software should provide something meaningful for anybody to diagnose, if they’re inclined to. It’s particularly bad in the (Apple) mobile ecosystem, including AppleTV. I have AdGuard Home but one of my spouse’s streaming services wouldn’t work. “There was a problem.” Gee thanks. Eventually figured out that I had to unblock a few hosts so it would work. Only found which ones by googling and finding some other poor…

They don't want tinkering or tinkerers.

Apple is all about walled-off, locked-down, black box, just-works (when it does) etc. It's supposed to seem like magic. You're not supposed to tinker with magic, it makes it pedestrian. Apple as a brand is a lifestyle, a feeling. The slick, polished brand. Remember "I'm a Mac, and I'm a PC"? PC is where you tinker, and there is screws and nuts and bolts and jargon and troubleshooting etc. In Apple land, you just take it to a slick genius bar and they do their magic. Or you just buy a new one.

As a European I'm always baffled how Apple got so much market share among the actual techies and power users in the US. You do it to yourself by buying this stuff. It's for people who don't want to spend one second thinking about actual technical issues.

Post reply on HN