New Post: Embedded Linux Logging Article - #644
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new draft Interrupt post describing logging strategies for resource-constrained embedded Linux devices, focusing on flash wear, RAM pressure, and practical daemon/configuration tradeoffs.
Changes:
- Introduces a new draft article covering kernel logging, syslog vs journald, and storage/rate-limiting considerations.
- Adds example configurations (journald.conf options and a Fluent Bit pipeline) plus references.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # This is a template for Interrupt posts. Use previous, more recent posts from the _posts/ | ||
| # directory for more inspiration and patterns. | ||
| # | ||
| # When submitting a post for publishing, submit a PR with the post in the _drafts/ directory | ||
| # and it will be moved to _posts/ on the date of publish. | ||
| # | ||
| # e.g. | ||
| # $ cp _drafts/_template.md _drafts/my_post.md | ||
| # | ||
| # It will now show up in the front page when running Jekyll locally. | ||
|
|
||
| title: Embedded Linux Logging |
Deploying interrupt with
|
| Latest commit: |
7afdbd3
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://295ef8d5.interrupt.pages.dev |
| Branch Preview URL: | https://grace-linux-log.interrupt.pages.dev |
|
|
||
| **How much should you actually log?** Severity levels let you dial verbosity up for active debugging and down for production, but the real lever for device longevity isn't the volume of logs you generate, it is how much of that volume actually gets written to flash, how often, and in what size chunks. Concretely, that means filtering relevant logs, rate-limiting logs as early as possible, and moving anything you only need to *count* out of the log stream and into a metric. | ||
|
|
||
| None of these are settings you get right once and forget. Rather, they are tradeoffs worth revisiting as a device's fleet, firmware, and failure modes evolve. Getting them right is what separates a logging architecture that helps you debug a fleet in the field from one that quietly wears out the flash underneath it. |
There was a problem hiding this comment.
I really like this closing, nice!
|
Good topic, and good axes (tools and tradeoffs) to look at it with - excited to get this one added to the library! |
|
I know you can technically hit merge with my approval, but would appreciate one last pass from our benevolent interrupt leaders (@bahildebrand / @gminn others?) before I start giving full "ship it" approval, in case there's any best practices/preferences I missed :) |
gminn
left a comment
There was a problem hiding this comment.
This is an awesome article @grace-nordic :star-struck: have a few comments + recommendations!
Adds a new draft article covering Embedded Linux logging strategies for resource-constrained devices. It walks through various different logging daemons available and ideas to help reduce overall log volume while still preserving critical information for debugging devices.