Using the audit trail
The audit trail records every data change made in SC//Reliant™ Platform Manager (RPM), whether or not that change affects servers (in the cloud or on eVDI devices) or nodes (at the edge). It is not a traditional event log: each record shows who changed what, when, and the value before and after.
Two ways to consume the audit trail
Both methods read the same records, so what you see in RPM is what your security tooling receives.
| Method | How it works | Best for |
|---|---|---|
| RPM | Browse and filter the records under Site administration → Audit Trail. | Interactive review, spot checks, and answering a specific "who changed this, and when" question. |
| Your own SIEM or observability platform | Scale Computing provisions your organization with a dedicated read-only Elasticsearch index. You poll it on a schedule and ingest the records into the platform of your choice. | Continuous monitoring, alerting on high-risk changes, dashboards, and retaining audit history alongside your other security telemetry. |
For the procedures, see Viewing the audit trail in Platform Manager and Integrating the audit trail with a SIEM.
What gets audited
The audit trail captures data changes across the SC//Reliant platform: users and roles, node groups and their properties, shell info records, and platform configuration values such as the RVC version assigned to a node group.
Each record covers a change to one object, such as a Node, a NodeGroup, or a Server, and lists every field that changed on it with that field's previous and current value. A single user action can change several fields at once, and the record lists all of them. Capturing both values makes the trail well suited to tracking sensitive or high-impact changes, such as a user's role or a node group's hardening controls.
Index and endpoint
Scale Computing hosts your audit records in a dedicated index on Elastic Cloud, Elastic's managed Elasticsearch service. The index supports every standard Elasticsearch search API in read-only form, so any tool that can issue an authenticated HTTPS request can consume the data.
| Item | Value |
|---|---|
| Endpoint | https://rel-prod.es.us-east-1.aws.found.io (HTTPS, port 443) |
| Index | prod_<tenant_code>_audits, where <tenant_code> is your organization's client code |
| Credential | Read-only API key. Scale Computing delivers it separately through a secure channel. |
| Access scope | Read-only and limited to your index. The index rejects writes and any request for another index. |
| Data freshness | New audit records appear within approximately 2 to 3 minutes of the change |
Throughout this documentation, replace the <tenant_code> placeholder and the API key with the values Scale Computing provides.
Authentication
Your API key arrives as a single encoded string. Use it directly in an HTTP Authorization header.
Authorization: ApiKey <encoded_api_key>Some tools, Logstash among them, require the unencoded id:api_key pair instead. The encoded string is that pair in Base64, so you can decode it locally.
echo '<encoded_api_key>' | base64 -d
# output: <id>:<api_key>Treat the key as a secret: store it in your secrets manager, never in source control.
Handle audit data as sensitive. Audit records capture previous and current field values, which can include configuration details your organization treats as confidential. Apply the same access controls to the ingested data as you would to RPM itself.
Record schema
Each audit record has the following fields.
| Field | Type | Description |
|---|---|---|
id | number | Unique, monotonically increasing audit record identifier. |
es_scope | keyword/text | Your client code, always your own because the index contains only your data. |
item_type | text | Type of object changed, for example Node, NodeGroup, or Server. |
item_id | number | Internal identifier of the changed object. |
item_name | text | Human-readable name of the changed object. |
created_at | date | Timestamp of the change, ISO 8601, Coordinated Universal Time (UTC). |
event | text | Change type, for example create, update, or destroy. |
author | text | User or system actor that made the change. |
fields | text | JSON-encoded array of the field names that changed. |
previous | text | JSON-encoded array of the prior values, positionally aligned with fields. |
current | text | JSON-encoded array of the new values, positionally aligned with fields. |
metadata | object | Additional context. May be null. |
fields, previous, and current hold JSON strings, not native arrays. Most platforms parse them at ingest. For parsing examples, see Integrating the audit trail with a SIEM.
An example record:
{
"id": 18231013,
"es_scope": "<tenant_code>",
"item_type": "NodeGroup",
"item_id": 2965,
"item_name": "Node Group: Edge Platform HA - HQ Labs",
"created_at": "2026-07-30T15:12:26.000Z",
"event": "update",
"author": "jane.doe",
"fields": "[\"description\"]",
"previous": "[\"old value\"]",
"current": "[\"new value\"]",
"metadata": null
}Key management and support
Contact your Scale Computing account team to rotate a key, to report an exposed key for revocation and reissue, or for help with the index, the API key, or an integration. Rotate the key at least annually, or on whatever schedule your credential policy defines.
Related documentation
- Viewing the audit trail in Platform Manager: reviewing audit records in RPM.
- Integrating the audit trail with a SIEM: ingesting audit records into a third-party platform.
- Monitoring your environment: overview of the SC//Reliant monitoring solution.
- Anatomy of Sensu event data: structure of the monitoring event stream.