7 ms·
> I don't get why people get so theological about logging.
Because the reason to log is about people, not about technology.
There's no technical reason to ma
> I don't get why people get so theological about logging.
Because the reason to log is about people, not about technology.
There's no technical reason to make logs: Just don't make bugs, and you won't need the logs to find out what went wrong because nothing will have gone wrong. Go to the beach!
This is hard though, and bugs happen for all sorts of reason that have nothing to do with the programmer making a mistake-- the customer can be unsatisfied because they didn't know what they wanted. Programmers learn very early in their career to distrust the requirements, because they know that saying but that's what the ticket says gets them nowhere besides an argument: They have to do what the business/customer meant.
Put another way, the user doesn't want logs: The user wants to know if everything is okay or not, and presumably they have some way to figure that out, but if it isn't working correctly (or they merely think it isn't), the programmer will probably want those logs to help them.
In many environments, the loop is larger than just those two people, there's QA support people, and internal experts/operators, and triage, and all of those people are going to have different needs from those logfiles. People might also have a second use for those logs involving anticipation of failures and tracking capacity.
So there are a lot of non-technical, non-functional needs for logs, and once you understand this, it may be a little easier to understand why people would have almost rabid opinions about what those logs should look like (or if they can get the cure they need another way, what they might prefer instead of logs)
> [standard out] will work in an OOM situation
If you use write() which doesn't allocate memory, that's almost true, but if you use printf() it might allocate memory, and it might not work in an OOM anyway depending on what "standard out" actually is.
> will work if your network switch is on fire, when the DNS records are wrong and your technicians can't even enter the building
And yes you can write logs that nobody will ever be able to read, but what's the point of that? When your manufacturing plant is a smoldering rubble, someone is going to want to launch an expedition for those hard drives and try and figure out what caused millions (or potentially billions) of dollars in damages, so if you just wrote everything to standard output and washed your hands of the rest, you might have to find another job anyway.
I've been programming for over three decades at this point, and I'm convinced there is no "easy one-size-fits-all answer" to whether to log or not, or if to log, how to log, so I find it useful to learn about this bit of theology so that I'm better equipped to talk to others about this, and maybe convince them of my opinions.
> And yes you can write logs that nobody will ever be able to read, but what's the point of that? When your manufacturing plant is a smoldering rubble, someone is going to want to launch an expedition for those hard drives and try and figure out what caused millions (or potentially billions) of dollars in damages, so if you just wrote everything to standard output and washed your hands of the rest, you might have to find another job anyway.
Reducing the number of points of failure is almost always a good idea. The network being down is one problem, not being able to ever know what your applications did when the network was down is another problem added to the first problem.
> Reducing the number of points of failure is almost always a good idea.
I think it is good to think about what happens when things fail: Things fail all the time and most of those failures are benign -- and even those that aren't can often be remedied by turning it off and on, but some of them aren't, so what happens then?
If you run out of disk space, writing a log line to the disk complaining that you're out of disk space is no help, but what else can you do? You could send a network alert, or print something to hardcopy (if there's a printer nearby), or ring a bell if you have one attached -- all of these things are also potential points of failure, but they can also help prevent a meltdown.
And if that sounds surprising, you might also be shocked the number of problems that can be solved with:
<img src="cdn1/img.jpg" onerror="(function(t){t.onerror=function(){};t.src='cdn2/img.jpg'})(this)">
It's for this reason (I think) that people usually qualify your statement as reducing the number of "single" points of failure, instead of the way you put it, because having two single-points of failure isn't exactly like having two weak links in a chain, and in many cases, it's nothing like it at all.
In any event, there's another advantage to thinking about the failure-process instead of trying to merely avoid failures:
The biggest reason reducing points of failure is a bad idea is when it is more expensive to do so than to simply tolerate the failure: One thing that dominates the attention of startups looking to improve their availability beyond 99.999% uptime, is "removing the failure points" to get higher uptime, but if Amazon is down, what are Amazon's customers going to do? Are they going to buy from someplace else? Sometimes it is simply that more-established brands have the benefit of ignoring some problems, but you can be sure a large company like Amazon has someone who knows exactly how much more they can spend per second of uptime they may desire, and I think it is worth it for a small company to get good at that exercise as well, because sometimes the juice just isn't worth the squeeze.
As a specific example: My ad servers (HTTP event collectors) are critical, and I want 100% uptime for them because missing a click means missing money, but the reporting dashboard (so the publishers know how much money they made, and the advertiser knows how much they owe me) doesn't need that, so as long as the user got redirected to the landing page correctly, and I can generate line charts and excel spreadsheets once a day, nobody cares that the reporting UI might be down for a few minutes a day-- they will simply press refresh, not knowing if it is their internet or mine, and combined with aggressive javascript-side caching and automatic retries, I am not quite sure any of my customers even notice my downtime.
If instead, I focused on reducing the things that could go wrong (because as you say, it is almost always a good idea), I might spend time trying to improve the availability of my database simply because that's the thing that fails instead of whacking a setTimeout into the JavaScript since the impact is that the user would just retry on failure. That setTimeout saved me the cost of a whole server (and power and heat and electricity) and in the early days of my ad server, that would've been a lot of beer.
> "When your manufacturing plant is a smoldering rubble, someone is going to want to launch an expedition for those hard drives and try and figure out what caused millions (or potentially billions) of dollars in damages, so if you just wrote everything to standard output and washed your hands of the rest, you might have to find another job anyway."
That's the normal state of life; when a building burns down, forensic investigators pick over the evidence trying to work out what started a fire. They don't ask everyone to record every time two bits of metal touch, every switch switched, every use of electricity, every flammable material entering the building, just in case there's a fire one day. Use a teaspoon in a metal cup? Log it. Post-it note? Flammable, log it. Don't know if your shoes are flammable? Log them anyway just in case.
And yet the cause of the fire is not likely to be any of those things, it's likely to be the normalization-of-deviance fireworks next kept next to the open gas tank where the employees take smoke breaks which people were reporting for ages until they were told to shut up about it.
Beverley Hills Supper Club was known to be overcrowded, badly designed and ignoring fire department reports for years before it burned down. Cocoanut Grove nightclub had flammable decorations and an employee using flames for light. Rana Plaza had big cracks appear in the building before it collapsed, employees were told to go back to work or be sacked. The World Trade Center collapsed because a plane hit it. Titanic sank because it was going too fast and ignoring reports of icebergs and chose nice looking corridors over high bulkheads. Grenfell Tower burned while "everyone" knew the building was coated in flammable coating and nobody in power wanted to pay to do anything about it. Station Nightclub burned because someone accidentally brought outdoor fireworks indoors, and the sound damping foam was flammable not fireproof and it killed people because the emergency exit doors were locked.
We have a culture of log every order the captain makes, every response from the crew, every movement of the rudder, every radio signal sent and received, and at the same time "why did the front fall off?" "a wave hit it" "is that unusual?" "Yeah, at sea? Chance in a million."
> "you can write logs that nobody will ever be able to read, but what's the point of that?"
Cover your ass, cargo culting, habit, defaults are powerful, the cognitive bias effect like psychic powers where
the one time people predict a bad thing happening and it happens is very memorable but the all the times people predict a bad happening and nothing happens are very forgettable, it's easy to remember one time logs helped and ignore all the times they didn't and the costs associated with them. For some possibilities.
> They don't ask everyone to record every time two bits of metal touch, every switch switched, every use of electricity, every flammable material entering the building, just in case there's a fire one day.
It's industry specific. In my line of work, yes, they do ask you to make extensive records like that and it is why we log nearly everything. Though I've mostly been in safety-critical and aerospace work (space now, previously just aero). I imagine medical, pharmaceutical manufacturing, and others have similar requirements. If you're making systems that don't matter (in the sense of, if they fail no one cares except a few possibly angry users), then don't bother logging anything.