Appearance
Logs and diagnostics
Logs are the first line of diagnosis when a device misbehaves in the field. Configure them before devices ship, not after the first support call.
Why device-tied logs matter
Generic log platforms collect streams of data but often lack device identity. When support gets a ticket about "the gateway at site 7," they need logs tied to that specific device - not a search across unrelated streams.
Setup approach
- Identify the log sources that matter for your application (application logs, systemd journals, custom output).
- Configure log collection on the device during image build.
- Verify logs appear in the Dataplicity dashboard for a test device.
- Include log configuration in your golden image.
- Teach responders the dashboard configuration and search path before the first incident.
Device workspace evidence
After devices ship, operators usually need more than the log stream:
| Surface | Use it for |
|---|---|
| Logging | Organisation-retained application and system lines |
| Device Diagnostics | Host and system facts on the device record |
| Device timeline | Recent lifecycle and operational events |
| Agent Log | Dataplicity agent output for that unit |
If Diagnostics is available to your organisation, use it to inspect device hardware and system information before opening a shell.
When to use this
- Application errors need investigation without SSH
- Support wants context before opening a remote shell
- Engineering needs visibility into field behaviour