Auditoria

Monitoramento e auditoria

Rastreabilidade

Todo upload e download realizado pelo Riversoft® STCP DirectLink é registrado com o usuário, a data e a hora de cada evento. Os filtros de arquivos e de horário e o roteamento são aplicados conforme a configuração da instância. Os logs podem ser gravados no banco de log (logDbEnable) e exportados por telemetria.

Relatório de transferências

O endpoint GET /report retorna as transferências concluídas com sucesso pelo usuário autenticado:

Parâmetro	Descrição
`filterdirection`	Obrigatório. `5` = downloads concluídos; `7` = uploads concluídos.
`days`	Período, em dias, até o momento da consulta. Padrão: `1`.
`page`	Página, a partir de `0`. Cada página tem até 100 registros (configurável em `reportMaxLines`, até 1000).
`filterfile`	Filtro por trecho do nome do arquivo.

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

Os códigos de evento estão em Eventos de sessão e transferência.

Supervisão pelo Riversoft Console Portal

O Riversoft STCP DirectLink mantém um serviço de supervisão, usado pelo Riversoft Console Portal para acompanhar a instância, os usuários, as sessões e os serviços. O serviço é cadastrado na instância como o serviço de rede Supervisão (directlink) (porta padrão 33060), e a Riversoft STCP Gemini API conecta a ele em nome do Portal, com a credencial de supervisão. As conexões de supervisão são registradas no log. Veja Serviços de supervisão.

Telemetria

O Riversoft STCP DirectLink exporta traces, logs e métricas no padrão OpenTelemetry para um collector, incluindo os fluxos de autenticação, JWT e SSO. A exportação é configurada na seção Telemetry. Veja Configuração › Telemetria.

Ao investigar uma falha, consulte o log e a telemetria pelo horário, rota, usuário e status HTTP. Não inclua tokens, cookies ou o header Authorization nas buscas e nos chamados.

Recursos do processo

O serviço Supervisor do Riversoft STCP DirectLink fornece estatísticas de memória e CPU do processo pelo comando 19. O comando é destinado aos administradores e usa a autenticação e o transporte TCP/TLS do Supervisor; ele não é um endpoint HTTP.

Requisição

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

A mensagem é precedida por um header de 4 bytes (big-endian): o primeiro byte contém o valor de Net1.TCPRfc2204 e os outros três, o tamanho total da mensagem, incluindo o header. Cada conexão atende uma requisição. Em produção, use TLS com validação do certificado e do hostname.

Resposta

Situação	Retorno
Coleta concluída	`ErrorCode=0`, amostra em `Data`.
Falha na coleta de memória ou CPU, ou prazo de 5 segundos expirado	`ErrorCode=99`, motivo em `ErrorMsg`, sem `Data`.
Falha parcial (threads ou memória do sistema)	`ErrorCode=0`; o campo afetado é omitido e o motivo aparece em `Data.collection_errors`.

Principais campos de Data

Campo	Unidade	Descrição
`pid`	—	Identificador do processo.
`sampled_at`	RFC 3339 UTC	Instante da coleta.
`cpu_total_seconds`	segundos	CPU acumulada (usuário + sistema). Não é percentual.
`logical_cpus`	—	CPUs lógicas visíveis ao processo.
`goroutines`, `threads`	—	Goroutines e threads do sistema operacional em uso.
`rss_bytes`	bytes	Memória física residente do processo.
`heap_alloc_bytes`	bytes	Objetos alocados, incluindo os que aguardam coleta.
`heap_live_bytes`	bytes	Objetos vivos após o último ciclo de coleta de lixo (GC).
`total_alloc_bytes`	bytes	Total acumulado alocado; crescimento é esperado.
`gc_count`	—	Ciclos de GC concluídos desde o início do processo.
`gc_pause_total_nano`	nanossegundos	Soma das pausas de GC.
`system_memory.total_bytes`, `available_bytes`, `used_bytes`, `free_bytes`	bytes	Memória física do sistema.

Interpretação

CPU no intervalo: 100 × Δcpu_total_seconds ÷ Δtempo. 100% equivale a um núcleo ocupado.
Compare amostras do mesmo processo (mesmo pid); reinicie a série quando o processo reiniciar ou um contador diminuir.
Avalie a retenção de memória pelo piso de heap_live_bytes após vários ciclos de GC (gc_count crescente) sob carga semelhante. O crescimento de total_alloc_bytes sozinho não indica problema.
RSS alto depois da queda do heap vivo pode indicar reserva de memória ou fragmentação.
Na capacidade do servidor, priorize available_bytes em vez de free_bytes.
Colete a cada 30 a 60 segundos, incluindo períodos de carga e de repouso. Consultas em alta frequência afetam o processo.

Nota

A coleta não inclui swap, discos, descritores de arquivo nem eventos de falta de memória, e a memória do sistema pode não refletir as quotas de um container. Os indicadores apontam tendências; não comprovam, sozinhos, um vazamento de memória.

Checklist de monitoramento

Logs gravados em banco ou exportados por telemetria, sem segredos.
Relatório de transferências consultado periodicamente para os usuários críticos.
Acesso ao Supervisor protegido por TLS e credenciais próprias.
Coleta de recursos a cada 30 a 60 segundos, com retenção e rotação definidas.
Falhas de coleta registradas sem substituí-las por valores zero.

Uso do Riversoft STCP DirectLink Portal Solução de problemas