Writing "/etc/hosts" breaks the Substack editor

Why would someone "sanitize" OutOfMemoryException out of their logs? That is a silly point to make.

An OutOfMemoryException log should not be the same as a search log

  Error: OutOfMemoryException

And

  Search: OutOfMemoryException

Should not be related in any way

The point is not to sanitize known strings like "OutOfMemoryException". The point is to sanitize or (preferably) escape any untrusted data that gets logged, so that it won't be confused for something else.

i think GP's point is how would you even sanitize the string "OutOfMemoryException" which presumably comes from a trusted system

i guess demanding "Structured logs for everything or bust" is the answer? (i'm not a big o11y guy so pardon me if this is obvious)

Until someone searches for "Error: OutOfMemoryException"

If structured logging is too much, unique prefixes solve this issue. Basically you need some token that user provided data is unable to output to the log. If you rigorously escape all newlines, you can then use start-of-line and end-of-line as unforgeable tokens. The possibilities are endless and it all comes down to understanding whether the intersection of two grammars is empty.

Low tech example: escape all newlines in user supplied strings, then add a known prefix to all user supplied data (let's say a double hashtag ##, but anything else works too). When you want to search logs for strings coming from your system, remove/ignore everything after the marker.

It all comes down to understanding whether the intersection of two grammars is empty.

"o11y" stands for "observability".

Numeronyms are evil and we should stop using them.

The difficulty here is that in the example above, it's unlikely, given any amount of scale, that the two people were on the same team. They were doing different things with the same data and probably didn't know what the other was doing.

Sure you could add a convention to your 'how to log' doc that specifies that all user input should be tagged with double '#' but who reads docs until things break? convention is a shitty way to make things work.

There's 100 ways that you could make this work correctly. Only restarting on a much more specific string, i.e. including the app name in the log line etc . . . but that's all just reducing the likely hood that you get burned.

I've also written a OOM-Killer.sh myself, I'm not above that, but it's one of those edge cases that's impossible to do correctly, which is why parsing and acting on log data generally considered and anti-pattern.

Thanks. My mind started running the random string generator given those restrictions, like a puzzle game. But had no idea of what it meant until you wrote it. Who invented that stupid idea and thought it would be a good one?

because its easily googlable.

counter point - people are going to use them, better to expose newbies early and often and then everyone is better off

shorthands will always be in demand. we used to say “horseless carriage”, then “automobile”, then “car”. would you rather use Light amplification by stimulated emission of radiation or just “laser”s? etc

in the new york times? sure, spell out observability. but on HN? come on. the term is 7 years old and is used all over the site. it’s earned it

You're right, avoiding them gives better a11y

I've never seen it before.

t4s, couldn't agree more.

no we drive to work in our h16e to set up the l47n

I read the gp to mean that error.log (being parsed to look for OOM) would have no associations with userSearches.log, in which an end-user searched for OOM

Or we could use words that don't require people to use Google just to be able to read. A dependence on a search engine for reading text is unnecessary.

If you find typing tedious just use autocomplete or other tools instead of making it the readers' problem.

Absolutely incredible how dense HN can be and that no one has explained. Obviously that isn’t what they are saying, they are saying it’s profoundly stupid to have the server be controlled by a simple string search at all.