Logging and Observability
Introduction
As you tighten remote login and local console access for production, it becomes more important to keep the device observable. Torizon OS already ships device monitoring, which sends metrics to Torizon Cloud through Fluent Bit. A separate question is whether you also ship logs off the device.
This article is part of the Production Hardening Checklist, which also explains how to persist these changes across a fleet.
This article complies with the Typographic Conventions for the Toradex Documentation.
Device Monitoring
Fluent Bit is enabled on stock images whenever /etc/fluent-bit/enabled exists. The default configuration sends metrics to Torizon Cloud, including CPU, memory, temperature, Docker daemon state, and eMMC health.
Keep it enabled for production fleets unless you have a specific reason not to. Metrics help you understand device health when interactive access is rare, alongside Torizon Remote Access.
For the configuration details, see Device Monitoring in Torizon OS. Capture any Fluent Bit configuration changes with TorizonCore Builder when you customize its inputs or outputs, as described in Applying and Persisting Changes.
Off-Box Log Forwarding
By default, Torizon OS stores journald logs in volatile storage (RAM), not on eMMC or NAND. That choice protects flash lifespan: continuous logging to eMMC increases wear and can shorten the life of the storage medium. See Persistent Journald Logging if you need logs to survive reboot, and weigh that against the flash-wear warning on that page.
Because local logs are volatile by default, they are lost on reboot, power loss, or storage failure, and they can be cleared after an incident if someone gains high privileges on the device. Forwarding copies to a remote system improves both incident response and routine fleet debugging.
Torizon Cloud metrics are not full log aggregation. Where you need that, Fluent Bit, or a similar agent, can send journal and container logs to a sink you operate yourself.
The trade-offs are:
| Benefits | Costs and risks |
|---|---|
| Preserves evidence when a device is replaced or needs forensic review | Consumes bandwidth and power on constrained or metered links |
| Gives central search and alerting across the fleet | Logs frequently contain secrets, personal data, or customer data, which makes the sink itself sensitive |
| Makes support easier when interactive access is rare | Adds an always-on network dependency and another configuration surface to maintain |
| Supports forensics after an incident, rather than only during one | Misconfigured forwarding can flood the sink, or block the device under backpressure |
Treat off-box logging as an option for products that need centralized forensics or support workflows, rather than as a universal hardening requirement. If you skip it, rely on metrics and Remote Access for observability, and only enable persistent journald when you accept the eMMC wear trade-off.
Where you do choose to forward logs, the outline is:
- Add the Fluent Bit inputs you need, such as the systemd journal, or Docker and Fluentd forward inputs. See Device Monitoring in Torizon OS.
- Add an output for your aggregator, using TLS and least-privilege credentials.
- Filter aggressively before shipping, using unit allow-lists and dropping noisy debug output.
- Deploy the configuration with TorizonCore Builder.
Sink-specific setup is beyond the scope of this article.