Logs¶
Core and every installed connector module each have their own “Logs” tab within their configuration view, providing access to operation log files and to the audit log. Core’s “Logs” tab additionally lists the log files of the Core Proxy, the component that handles sign-in and routes browser traffic to Core and every connector module.
Go to the “Configuration” node in the navigation panel and select the “Logs” tab to view Core’s log files. The same “Logs” tab is available for each installed connector module, from that connector’s own configuration view. The tab lists log file names; click on a file name to open its raw log text in a separate browser tab.
Operation Logs¶
Operation logs record diagnostic messages useful for troubleshooting, such as task status changes and connector errors.
Each line starts with a timestamp and a severity level (for example, INF for informational messages or WRN for
warnings), followed by the message text. Many of these same events are also what you may already have seen live in the
message panel at the bottom of the main application window (see Main Application); the operation log
file keeps a persistent, browsable record of them.
Example operation log lines from Core, showing a task starting and then a connected output failing:
2026-09-06 13:03:07.627 +12:00 [INF] Task [Task1] Running
2026-09-06 13:03:16.640 +12:00 [WRN] Task [Task1] Task status changed at 2026-09-06 13:03:16+12:00. Output connector "MQTT" has failed to process a sample. The connector log may contain additional information.
The Core Proxy’s own operational log, named “Proxy Api”, is listed here alongside Core’s, recording routing and connectivity diagnostics.
Audit Log¶
Important
Only users in the Administrator role can view the audit log.
In addition to operation logs, the audit log is a structured, machine-readable record of user actions performed within Dataristix, listed alongside the operation log files and opened the same way. Each audit log entry is a line ending in a JSON object appended to the log, containing fields including:
Timestamp— the UTC date and time the action occurred.UserName— the signed-in user’s user name (not their display name).UserDisplayName— the signed-in user’s display name.UserUuid— a unique identifier for the user account.UserSessionId— a unique identifier for the user’s current sign-in session.UserAction— a human-readable description of the action performed, for example “Duplicate task”.RemoteIpAddress— the IP address the request originated from.Method— the underlying API method and endpoint that was invoked.Success— whether the action completed successfully.
Note
The example below shows additional fields, such as UserActionId and TraceId. These are reserved for future
use and not documented here.
Example audit log entry:
2026-09-08 14:36:54.359 +12:00 [INF] Operation succeeded. {"UserName":"admin","UserDisplayName":"admin","UserUuid":"dd5db556-1c36-4575-8bc9-d5925cbb1b07","UserSessionId":"49e2e678-c7c1-469e-bd12-67d02de5e7a2","UserAction":"Duplicate task","UserActionId":"a825ac1c-9094-4a67-b0d1-08df0d51f71d","RemoteIpAddress":"127.0.0.1","TraceId":"0HNOD4TKF44BS:0000000B","Method":"POST /api/v3/tasks/4998","Success":true,"Timestamp":"2026-09-08T02:36:54.2014085Z","$type":"IpcAuditContext"}
Note
Audit log entries are also recorded for actions that did not succeed ("Success":false), for example a task
change rejected because the signed-in user’s role does not permit it.
Most actions listed in the audit log also have a corresponding entry in History. Use the audit log
entry’s Timestamp and UserAction to identify the matching history entry.
Sign-In Events¶
Important
Only users in the Administrator role can view sign-in events.
The Core Proxy keeps a separate, restricted log of sign-in, sign-out, and session events, named “Proxy Api Audit”. It is kept apart from the Proxy’s operational log because these entries can include a signed-in user’s name, and apart from the audit log above because its entries are plain text, not JSON.
A successful sign-in or sign-out records the user’s name. A failed sign-in does not: the attempted user name has not been authenticated and could be anything typed into the sign-in form, potentially even a mistyped password, so only a short, non-reversible hash of it is recorded. This still lets you spot the same target being attempted repeatedly, without exposing what was actually typed.
Example sign-in event log lines:
2026-09-08 09:12:03.512 +12:00 [INF] User admin signed in
2026-09-08 09:15:22.104 +12:00 [WRN] Sign-in failed for user-hash a1b2c3d4e5f6a7b8 from 127.0.0.1
2026-09-08 09:16:47.318 +12:00 [WRN] OAuth sign-in failed for request from 127.0.0.1
2026-09-08 10:02:15.001 +12:00 [INF] User admin signed out
Forwarding Logs¶
To also forward operation logs and audit log entries to an external OpenTelemetry collector, in addition to viewing them here, see Telemetry. This applies to Core, every connector module, and the Core Proxy: each module’s operational log follows the “General Telemetry Settings”, and each module’s audit log follows the “Audit Log Telemetry Settings” - including the Core Proxy’s own logs, its operational log (“Proxy Api”) and its sign-in events log (“Proxy Api Audit”).