Appearance
Collect your first application log #
Finish with a known message from one test Linux device visible in your organisation's Logs, with the correct source and timestamp. This path uses a Linux syslog source and the setup wizard's generated rsyslog configuration.
Before you start #
Use one test Linux host with rsyslog and the logger utility, permission to change its logging configuration, and Dataplicity access to configure ingestion. Keep local access to the host while testing. For a container or application-file source, use the matching collector instructions in Logs instead of the syslog path below.
1. Configure the source #
- Open Logs in the intended organisation.
- Open the Syslog setup guide from the collector setup panel.
- Under Credential, choose Create logs forwarder key, or select a dedicated existing key.
- Under Source, choose the relay pattern for a host forwarding ordinary local syslog.
- Under Install, copy the generated rsyslog configuration for this organisation and device context.
- Install that configuration on the test host and restart rsyslog as directed by the wizard.
Use the generated endpoint and credential format. Syslog uses the key digest in structured data, rather than the raw API key. Keep credentials out of log messages and rotate the key if it is exposed.
Expected result: rsyslog runs with the selected forwarding configuration. The test below confirms whether records actually reach Dataplicity.
2. Send and find the test event #
On the configured host, run:
sh
logger -t dataplicity-check 'dataplicity-log-check-001'This writes to the local system log. It reaches Dataplicity only when the forwarder configured in step 1 sends that log.
Return to Logs, choose a recent time window, and search for dataplicity-log-check-001. Open the matching event.
Check it worked #
| Check | Expected result |
|---|---|
| Message | The exact test text appears in organisation Logs |
| Source | The event identifies the device or producer you configured |
| Time | The timestamp matches when you generated the event |
You are finished when all three match. Use a new suffix for each repeat test so an older event cannot be mistaken for a new success.
If the event is missing #
First remove optional search filters while keeping a short recent time window. Then check the source configuration, forwarder delivery errors, key scope, device context and payload format. Check organisation usage and ingestion limits if the source is sending but records are absent. Local output alone does not prove central delivery.
Next task #
Search logs to narrow an investigation to a device and time window. Ask a second operator with the intended support role to confirm they can find the event; grant read access through team roles.
Retention, usage and investigating alerts
Recent records support live viewing; older retained records are queried from archive storage and may have different query latency. Use the retention period shown for your organisation in the UI and service-limit response.
Review Usage before enabling a noisy source. Filter at the producer where practical and exclude credentials and unnecessary personal data.
When investigating an alert, start with its resource and first-observed time. Search a narrow window before broadening it, and preserve relevant context in the incident timeline. See From signal to verified recovery.