Appearance
Collect your first application log #
The Logs workspace combines agent and platform events with external ingestion in one organisation-wide stream.
Before you start #
Use a connected test device or another supported source and a user who can configure log ingestion. Decide on a distinctive, non-secret test message before changing the source. If devices are already deployed, configure one representative unit first; a future golden-image change is not a prerequisite for proving collection now.
Open the stream #
Open Logs for the organisation. If no records have arrived, use the onboarding panel to choose the source you actually operate. Follow the generated instructions for the current organisation and source; do not copy credentials, endpoints, or example values from another environment.
For external syslog ingestion, use an organisation API key with the narrow log-ingest scope offered by the API key editor. Include valid device context when the ingestion contract requires it. Disable and rotate the key if it appears in log output.
Send and find the test event #
For example, use dataplicity-log-check-001 as the test message. Send it through the source you configured, then search Logs for that exact text in a recent time window.
If your configured source forwards the Linux system log, and the device has the logger utility, you can generate the event with:
sh
logger -t dataplicity-check 'dataplicity-log-check-001'This writes to the local system log; it does not configure forwarding. It will only reach Dataplicity if your selected collector forwards that log. For an application-file or container source, make the application write the test message to the file or output stream you selected instead.
| Check | Expected result |
|---|---|
| Message | dataplicity-log-check-001 appears in organisation Logs |
| Source | The result identifies the device or producer you configured |
| Time | The timestamp matches when you generated the event |
Use a new message suffix for a repeat test so an earlier event cannot be mistaken for a new success.
- Complete the generated setup for the selected source on one test device or producer.
- Generate the distinctive, non-secret test event through that source.
- Search a short recent window for the exact message.
- Confirm the result carries the device, class, application, origin, level, source type, and timestamp fields that your support workflow needs.
- Confirm a second operator with the intended role can find the same event.
The task is complete when the known event is visible in Dataplicity with the right identity and time context. Local output from the producer is not proof that central ingestion succeeded.
If the event is absent, separate collection from search: first remove optional search filters and keep the short time window. Then check source controls, API key scope where used, device identity, payload format, organisation usage, and the source system's delivery status. Local agent logs can diagnose the agent itself, but do not prove central delivery.
Live and archived data #
The recent stream is optimised for live viewing. Older retained records are queried from archive storage. Archive delivery and query latency can differ from live tail, and a query can cross both paths.
Normal log search covers the retention period shown for your organisation in the UI and service-limit response.
Usage is measured for log ingestion. Review Usage before enabling a noisy source. Filter at the producer where practical and avoid credentials, access tokens, health data, or unnecessary personal data.
Move from an alert to logs #
Use the alert's device or monitor context and first-observed time. Add a resource token, then inspect a narrow window before broadening the query. Preserve relevant context in the incident timeline rather than copying an unbounded log dump.
Permissions #
Control who can view logs through team membership. Support teams typically need log read access; restrict write/configuration to engineering.
Reliable log collection #
- Verify central collection with a distinctive test event
- Use a narrowly scoped API key for ingestion
- Start with the affected resource before broadening a search
- Check retention and delivery when a query returns no result