Appearance
Logs and diagnostics #
Logs are the first line of diagnosis when a device misbehaves in the field. If devices are already deployed, start with one representative connected unit and prove a test event now. Add the same configuration to the product image before the next shipment or reimage.
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).
- Use the current Logs onboarding panel to select the supported source and obtain its organisation-specific instructions.
- Configure one representative test device or producer.
- Send and find a distinctive test event.
- Include the proven configuration in your golden image or existing deployment process.
- Teach responders the 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