S6E12: " I'm a Lumberjack and I'm OK"

Posted
Modified
Comments 0

Navigation
Previous EpisodeNext Episode
Log
Recorded (UTC) Aired (UTC) Editor
2021-07-22 02:22:52 2021-07-31 06:16:48 "Edita"
Verification
Format SHA256 GPG Audio File
MP3 d80d3a8f8a8738db2d659428ffa1918890534a2b87351b27b874de5f37b80f55 click click
OGG 86892e6a98af008dcc0c2803166b2985c28be9ce79a570fc13e4507c2be2af95 click click
Quicklisten:

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.

Notes

Starts at 18m52s.

I was drinking a Rogue Dead Guy (and ALMOST a Dragon’s Milk Stout but I ruined the bottle, sad). Paden was drinking a PBR.

  • 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.

15 Clams

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.

Errata

  • None so far!

Music

Music Credits
Track Title Artist Link Copyright/License
Intro Sunrise Crennwiick click CC-BY-NC-ND 4.0
Outro Slick Rick Jazz One Beats click CC-BY-NC-ND 4.0
(All music is royalty-free, properly licensed for use, used under fair use, or public domain.)

Author
Categories

Comments

There are currently no comments on this article.

Comment...

Enter your comment below. Fields marked * are required. You must preview your comment before submitting it.