S6E12: " I'm a Lumberjack and I'm OK"
|Previous Episode||Next Episode|
|S6E11: "Ransom? Where?"||S6E13: "EOL"|
|Recorded (UTC)||Aired (UTC)||Editor|
|2021-07-22 02:22:52||2021-07-31 06:16:48||"Edita"|
We talk about the importance of logging, and a standardized logging interface (and how important it is to use it). This one is just Paden and I.
Just the Tip
- Paden talks about AFPD, the Apple Filetalk Protocol Daemon.
- It’s basically Apple’s alternative to NFS.
Starts at 18m52s.
- Logging is important, and logging a certain way is important.
- Someone mentioned the 12-Factor App philosophy/methodology, specifically its logging philosophy.
- Essentially, it argues against syslog and instead claims that log entries should only be sent to stdout.
- This loses so much fidelity and filtering, especially if your syslogger is backed by journald.
- It operates under the assumption that a log analyzer is both available and appropriate for all scalable applications. It is not, because this then requires additional infrastructure.
- Not highly stressed in the episode, but what the philosophy highly neglects is that syslog/journald entries themselves can be sent to almost every log analyzer out there, AND in the process it keeps the meta information (such as severity level, which are immensely useful filtering to both the development process AND production deployment).
- JSON logs were suggested in the discussion in our Discord. This is an issue because it then requires additional parsing to read. It’s dumb to need to have jq installed on a production server just to read logs. JSON is not a human-friendly data format, and I will die on this hill.
- Log analyzers are a dumb dependency. They add an additional point of failure, additional cost (in both time and money), and hinder helpful real-time stream viewing of events.
- I am not saying log analyzers are bad. They can be a very useful value-adder. But their existence should not be presupposed as part of a software’s design, as that is orthogonal to actual deployment debugging.
- If stdout logging only is desired, it should be done in addition to the system’s logger mechanism.
- Logs tell you what happened or was supposed to happen – events, essentially. They are not intended to provide overview insight or analysis. Alerts describe inconsistencies in expected/desired behavior, and should be reported based on an actual behavior test (such as a ping attempt, an HTTP request to your web application, etc.). Reports are a summary of status/states and/or metrics. DO NOT CONFLATE THESE THREE, and STOP USING YOUR LOGS FOR ALERTS OR REPORTS. This is not what logs are for.
- Your company is not Amazon, Google, Twitter, Facebook, etc. You do not need to mimic the Phoenix Project.
In this segment, Jthan shares with you a little slice of life. The title is a reference to this video. (2m16s in)
Starts at 50m38s.
Paden mentions SOMEONE buying a house, and doing work on that house before the purchase has gone through, and the potential legal ramifications.
- None so far!
|Intro||Sunrise||Crennwiick||click||CC-BY-NC-ND 4.0||Outro||Slick Rick||Jazz One Beats||click||CC-BY-NC-ND 4.0|