Auditing

Monitoring and auditing

Traceability

Every upload and download performed by Riversoft® STCP DirectLink is logged with the user, date and time of each event. File and time filters and routing are applied according to the instance configuration. Logs can be written to the log database (logDbEnable) and exported through telemetry.

Transfer report

The GET /report endpoint returns the transfers completed successfully by the authenticated user:

Parameter	Description
`filterdirection`	Required. `5` = completed downloads; `7` = completed uploads.
`days`	Period, in days, up to the time of the request. Default: `1`.
`page`	Page, starting at `0`. Each page has up to 100 records (configurable in `reportMaxLines`, up to 1000).
`filterfile`	Filter by part of the file name.

curl -G "https://<domain>/directlink/v2/report" \
  -H "Authorization: Bearer <access_token>" \
  --data-urlencode "filterdirection=7" \
  --data-urlencode "days=7" \
  --data-urlencode "page=0"

The event codes are in Session and transfer events.

Supervision through the Riversoft Console Portal

Riversoft STCP DirectLink runs a supervision service, used by the Riversoft Console Portal to track the instance, users, sessions and services. The service is registered in the instance as the Supervision (directlink) network service (default port 33060), and the Riversoft STCP Gemini API connects to it on behalf of the Portal, with the supervision credential. Supervision connections are recorded in the log. See Supervision services.

Telemetry

Riversoft STCP DirectLink exports traces, logs and metrics in the OpenTelemetry standard to a collector, including the authentication, JWT and SSO flows. Export is configured in the Telemetry section. See Configuration › Telemetry.

When investigating a failure, search the log and telemetry by time, route, user and HTTP status. Do not include tokens, cookies or the Authorization header in searches or tickets.

Process resources

The Riversoft STCP DirectLink Supervisor service provides process memory and CPU statistics through command 19. The command is intended for administrators and uses the Supervisor authentication and TCP/TLS transport; it is not an HTTP endpoint.

Request

{
  "cmd": 19,
  "id": "sample-1",
  "timestamp": 0,
  "monuser": "<supervisor-user>",
  "monpasswd": "<password>",
  "agent": "resource-monitor",
  "cmdargs": {}
}

The message is preceded by a 4-byte header (big-endian): the first byte holds the value of Net1.TCPRfc2204 and the other three hold the total message length, including the header. Each connection serves one request. In production, use TLS with certificate and hostname validation.

Response

Situation	Result
Collection completed	`ErrorCode=0`, sample in `Data`.
Memory or CPU collection failure, or 5-second deadline expired	`ErrorCode=99`, reason in `ErrorMsg`, no `Data`.
Partial failure (threads or system memory)	`ErrorCode=0`; the affected field is omitted and the reason appears in `Data.collection_errors`.

Main Data fields

Field	Unit	Description
`pid`	—	Process identifier.
`sampled_at`	RFC 3339 UTC	Collection time.
`cpu_total_seconds`	seconds	Accumulated CPU (user + system). Not a percentage.
`logical_cpus`	—	Logical CPUs visible to the process.
`goroutines`, `threads`	—	Goroutines and operating system threads in use.
`rss_bytes`	bytes	Process resident physical memory.
`heap_alloc_bytes`	bytes	Allocated objects, including those awaiting collection.
`heap_live_bytes`	bytes	Live objects after the last garbage collection (GC) cycle.
`total_alloc_bytes`	bytes	Accumulated total allocated; growth is expected.
`gc_count`	—	GC cycles completed since the process started.
`gc_pause_total_nano`	nanoseconds	Sum of GC pauses.
`system_memory.total_bytes`, `available_bytes`, `used_bytes`, `free_bytes`	bytes	System physical memory.

Interpretation

CPU over the interval: 100 × Δcpu_total_seconds ÷ Δtime. 100% equals one busy core.
Compare samples from the same process (same pid); restart the series when the process restarts or a counter decreases.
Assess memory retention by the floor of heap_live_bytes after several GC cycles (increasing gc_count) under similar load. Growth of total_alloc_bytes alone does not indicate a problem.
High RSS after the live heap drops can indicate memory reservation or fragmentation.
For server capacity, prefer available_bytes over free_bytes.
Collect every 30 to 60 seconds, including load and idle periods. High-frequency queries affect the process.

Note

The collection does not include swap, disks, file descriptors or out-of-memory events, and system memory may not reflect container quotas. The indicators show trends; on their own, they do not prove a memory leak.

Monitoring checklist

Logs written to a database or exported through telemetry, without secrets.
Transfer report checked periodically for critical users.
Supervisor access protected by TLS and dedicated credentials.
Resource collection every 30 to 60 seconds, with retention and rotation defined.
Collection failures recorded without replacing them with zero values.

Using Riversoft STCP DirectLink Portal Troubleshooting