Auditoría

Monitoreo y auditoría

Trazabilidad

Cada carga y descarga realizada por Riversoft® STCP DirectLink se registra con el usuario, la fecha y la hora de cada evento. Los filtros de archivos y de horario y el enrutamiento se aplican según la configuración de la instancia. Los logs pueden grabarse en la base de log (logDbEnable) y exportarse por telemetría.

Informe de transferencias

El endpoint GET /report devuelve las transferencias concluidas con éxito por el usuario autenticado:

Parámetro	Descripción
`filterdirection`	Obligatorio. `5` = descargas concluidas; `7` = cargas concluidas.
`days`	Período, en días, hasta el momento de la consulta. Predeterminado: `1`.
`page`	Página, a partir de `0`. Cada página tiene hasta 100 registros (configurable en `reportMaxLines`, hasta 1000).
`filterfile`	Filtro por parte del nombre del archivo.

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

Los códigos de evento están en Eventos de sesión y transferencia.

Supervisión mediante el Riversoft Console Portal

Riversoft STCP DirectLink mantiene un servicio de supervisión, que el Riversoft Console Portal usa para seguir la instancia, los usuarios, las sesiones y los servicios. El servicio se registra en la instancia como el servicio de red Supervisión (directlink) (puerto predeterminado 33060), y la Riversoft STCP Gemini API se conecta a él en nombre del Portal, con la credencial de supervisión. Las conexiones de supervisión se registran en el log. Vea Servicios de supervisión.

Telemetría

Riversoft STCP DirectLink exporta trazas, logs y métricas en el estándar OpenTelemetry a un collector, incluidos los flujos de autenticación, JWT y SSO. La exportación se configura en la sección Telemetry. Vea Configuración › Telemetría.

Al investigar una falla, consulte el log y la telemetría por hora, ruta, usuario y estado HTTP. No incluya tokens, cookies ni el header Authorization en las búsquedas ni en los tickets.

Recursos del proceso

El servicio Supervisor de Riversoft STCP DirectLink proporciona estadísticas de memoria y CPU del proceso mediante el comando 19. El comando está dirigido a los administradores y usa la autenticación y el transporte TCP/TLS del Supervisor; no es un endpoint HTTP.

Solicitud

{
  "cmd": 19,
  "id": "muestra-1",
  "timestamp": 0,
  "monuser": "<usuario-supervisor>",
  "monpasswd": "<contrasena>",
  "agent": "resource-monitor",
  "cmdargs": {}
}

El mensaje va precedido de un header de 4 bytes (big-endian): el primer byte contiene el valor de Net1.TCPRfc2204 y los otros tres, el tamaño total del mensaje, incluido el header. Cada conexión atiende una solicitud. En producción, use TLS con validación del certificado y del hostname.

Respuesta

Situación	Resultado
Recolección concluida	`ErrorCode=0`, muestra en `Data`.
Falla en la recolección de memoria o CPU, o plazo de 5 segundos vencido	`ErrorCode=99`, motivo en `ErrorMsg`, sin `Data`.
Falla parcial (threads o memoria del sistema)	`ErrorCode=0`; el campo afectado se omite y el motivo aparece en `Data.collection_errors`.

Principales campos de Data

Campo	Unidad	Descripción
`pid`	—	Identificador del proceso.
`sampled_at`	RFC 3339 UTC	Momento de la recolección.
`cpu_total_seconds`	segundos	CPU acumulada (usuario + sistema). No es un porcentaje.
`logical_cpus`	—	CPU lógicas visibles para el proceso.
`goroutines`, `threads`	—	Goroutines y threads del sistema operativo en uso.
`rss_bytes`	bytes	Memoria física residente del proceso.
`heap_alloc_bytes`	bytes	Objetos asignados, incluidos los que esperan recolección.
`heap_live_bytes`	bytes	Objetos vivos después del último ciclo de recolección de basura (GC).
`total_alloc_bytes`	bytes	Total acumulado asignado; su crecimiento es esperado.
`gc_count`	—	Ciclos de GC concluidos desde el inicio del proceso.
`gc_pause_total_nano`	nanosegundos	Suma de las pausas de GC.
`system_memory.total_bytes`, `available_bytes`, `used_bytes`, `free_bytes`	bytes	Memoria física del sistema.

Interpretación

CPU en el intervalo: 100 × Δcpu_total_seconds ÷ Δtiempo. 100% equivale a un núcleo ocupado.
Compare muestras del mismo proceso (mismo pid); reinicie la serie cuando el proceso se reinicie o un contador disminuya.
Evalúe la retención de memoria por el piso de heap_live_bytes después de varios ciclos de GC (gc_count creciente) con una carga similar. El crecimiento de total_alloc_bytes por sí solo no indica un problema.
Un RSS alto después de la caída del heap vivo puede indicar reserva de memoria o fragmentación.
Para la capacidad del servidor, priorice available_bytes sobre free_bytes.
Recolecte cada 30 a 60 segundos, incluidos los períodos de carga y de reposo. Las consultas de alta frecuencia afectan al proceso.

Nota

La recolección no incluye swap, discos, descriptores de archivo ni eventos de falta de memoria, y la memoria del sistema puede no reflejar las cuotas de un container. Los indicadores muestran tendencias; por sí solos, no comprueban una fuga de memoria.

Checklist de monitoreo

Logs grabados en base de datos o exportados por telemetría, sin secretos.
Informe de transferencias consultado periódicamente para los usuarios críticos.
Acceso al Supervisor protegido con TLS y credenciales propias.
Recolección de recursos cada 30 a 60 segundos, con retención y rotación definidas.
Fallas de recolección registradas sin reemplazarlas por valores cero.

Uso de Riversoft STCP DirectLink Portal Solución de problemas