Como ler logs de um robô de trading na Deriv

Por Equipe Codexium · Publicado em 2026-11-08 · Atualizado em 2026-11-10 · 7 min de leitura · Robôs de trading

O log é a única testemunha confiável do que o robô fez. A tela mostra um resumo; a memória de quem acompanhou mistura impressão com fato. Quando uma sessão termina com um resultado estranho — uma ordem a mais, um stop que não parou, um intervalo sem operações — é no log que está a resposta. Este guia mostra o que um bom log de robô deve conter, como ler as linhas na ordem certa e quais padrões indicam problema técnico, e não só "dia ruim".

Ler log não melhora a estratégia. Se a regra tem expectativa negativa, o log só documenta isso com precisão. O objetivo é separar erro de execução de resultado da regra, para que você não troque parâmetros por causa de um bug, nem ignore um bug achando que foi azar.

O que um log de robô deveria registrar

Um log útil tem uma linha por evento, sempre com horário. No mínimo:

• Início e fim de sessão: conta (demo ou real), parâmetros carregados, stops configurados.
• Conexão: abertura do WebSocket, autorização, quedas, reconexões e o tempo de cada uma.
• Decisão: o sinal que motivou a entrada (qual regra disparou e com quais valores).
• Envio: o pedido de compra, com valor, contrato e um identificador próprio da requisição.
• Resposta: o identificador do contrato devolvido pela corretora, ou o erro recebido.
• Fechamento: resultado, lucro ou prejuízo, saldo após a operação.
• Limites: cada vez que um stop ou teto de operações é atingido e o que o robô fez em seguida.

Se o seu robô não grava algum desses pontos, você vai ter buracos justamente na hora de investigar. A organização desses componentes dentro do código está em arquitetura de bot de trading.

Anatomia de uma linha de log

Um formato simples e legível, que dá para filtrar depois:

`` 2026-11-08T09:14:03.512Z INFO sess=a41 req=118 BUY sent stake=1.00 contract=DIGITEVEN sym=R_100 2026-11-08T09:14:03.791Z INFO sess=a41 req=118 BUY ok contract_id=... latency_ms=279 2026-11-08T09:14:05.020Z INFO sess=a41 contract_id=... CLOSED result=loss pnl=-1.00 balance=9874.20 ``

Três detalhes fazem diferença:

1. Horário em UTC com milissegundos. Facilita comparar com o extrato da corretora e medir atrasos. Se preferir horário local, deixe o fuso explícito.
2. Identificador da requisição. A API WebSocket da Deriv permite enviar um campo próprio de identificação (como req_id) que volta na resposta. É ele que liga "mandei comprar" a "a compra foi aceita". Detalhes do fluxo em Deriv API WebSocket.
3. Nível do evento. INFO para o normal, WARN para o que merece atenção, ERROR para falhas. Isso permite filtrar só o que importa em sessões longas.

Como ler o log: a ordem certa

Quando algo parece errado, não comece pelo fim. Siga esta ordem:

1. Cabeçalho da sessão. Confirme a conta, os parâmetros e os stops que o robô realmente carregou. Muitos "bugs" são configuração diferente da que você imaginava.
2. Linha do tempo de conexão. Procure quedas e reconexões. Anote os intervalos sem conexão.
3. Pares envio/resposta. Para cada compra enviada, deve existir exatamente uma resposta (sucesso ou erro). Envio sem resposta é suspeito; duas respostas de sucesso para uma mesma decisão é mais suspeito ainda.
4. Fechamentos e saldo. Some os resultados registrados e compare com a variação de saldo da sessão.
5. Eventos de limite. Verifique se, depois de cada stop, não houve nenhuma nova compra.

Só depois disso faz sentido olhar estatísticas da sessão.

Padrões que indicam problema técnico

Envio sem resposta

Uma compra enviada que não recebe confirmação nem erro costuma coincidir com queda de conexão. O risco está no que o robô faz depois: se ele reenviar a compra sem checar se a primeira foi executada, você pode acabar com duas posições. A prática segura é, após reconectar, consultar as posições abertas ou o extrato antes de repetir qualquer ordem.

Erros repetidos da API

Respostas com o campo error trazem um código e uma mensagem. Alguns exemplos comuns:

• falhas de autorização (token inválido, expirado ou revogado);
• limite de requisições excedido, quando o robô envia mensagens rápido demais;
• saldo insuficiente para a entrada pedida;
• validação do contrato recusada (parâmetro fora do permitido).

Um erro isolado acontece. O mesmo erro várias vezes seguidas indica que o robô está insistindo em algo que não vai funcionar — e deveria pausar, não tentar de novo em laço.

Latência crescente

Compare o horário de envio com o de resposta. Se esse intervalo começa em poucas centenas de milissegundos e vai subindo ao longo da sessão, pode haver rede saturada, máquina sobrecarregada ou fila de mensagens acumulando. Como medir e interpretar isso está em latência em robô de trading.

Buracos no tempo

Um intervalo de vários minutos sem nenhuma linha — nem tick, nem ping — normalmente significa processo travado, máquina suspensa ou log parado. Se o robô estava com posição aberta nesse período, investigue antes de religar.

Saldo que não fecha

Se a soma dos resultados registrados não bate com a diferença de saldo, existe operação fora do log: execução duplicada, outra ferramenta usando a mesma conta ou registro que falhou. Isso, sozinho, já é motivo de pausa.

Do log às métricas

Com o log limpo e confiável, dá para calcular taxa de acerto, resultado médio, drawdown e maior sequência de perdas sem depender da memória. O detalhamento de cada métrica está em métricas de desempenho de robô.

Duas cautelas:

• Amostra pequena engana. Uma sessão boa ou ruim, com poucas dezenas de operações, diz pouco sobre a regra.
• Separe sessões com bug. Se uma sessão teve ordem duplicada ou stop que falhou, os números dela medem o defeito, não a estratégia.

Quando o log manda pausar

Defina antes, por escrito, quais padrões encerram a sessão. Alguns candidatos:

• qualquer compra registrada depois de um stop atingido;
• o mesmo erro de API três vezes seguidas;
• saldo que não fecha com os resultados;
• reconexões frequentes em pouco tempo;
• latência muito acima do normal da sua máquina.

Esses critérios conversam com o roteiro de quando pausar o robô de trading. O log é o que transforma "parece estranho" em um motivo objetivo para parar.

Boas práticas de registro

• Nunca grave o token de API nem dados de login. Se precisar identificar a conta, registre só o tipo (demo/real) e um apelido.
• Um arquivo por dia ou por sessão, com rotação, para não encher o disco de uma VPS.
• Guarde por um período definido (por exemplo, 30 a 90 dias) para comparar semanas.
• Escreva antes de agir: registre a decisão antes de enviar a compra, para que, se o processo cair, a intenção esteja documentada.
• Teste o log na demo, provocando erros de propósito (token inválido, rede desligada) e conferindo se cada um aparece como esperado.

Resumo

Um bom log tem horário preciso, identificador de cada requisição, nível do evento e todas as etapas: sessão, conexão, decisão, envio, resposta, fechamento e limites. Para ler, comece pela configuração carregada, siga a conexão, case envios com respostas, confira o saldo e verifique os stops. Padrões como envio sem resposta, erro repetido, latência crescente e saldo que não fecha apontam problema técnico e justificam pausa. Nada disso garante resultado positivo; garante que você sabe o que o robô realmente fez.

Perguntas frequentes

O que é o log de um robô de trading?

É o registro, linha a linha e com horário, de tudo o que o robô fez: conexões, decisões, ordens enviadas, respostas da corretora, resultados e limites atingidos.

O que um log de robô deve registrar no mínimo?

Início e fim da sessão, conta usada, parâmetros e stops, eventos de conexão, cada compra enviada com sua resposta, o fechamento de cada contrato com o resultado e os momentos em que algum limite foi atingido.

Devo gravar o token de API no log?

Não. O token funciona como uma senha. Registre apenas se a conta é demo ou real e, se precisar, um apelido para identificá-la.

Como descobrir se o robô enviou ordem duplicada?

Case cada envio com sua resposta pelo identificador da requisição e compare a lista de contratos do log com o extrato da corretora. Dois contratos para uma única decisão indicam duplicação.

Por quanto tempo guardar os logs?

Um período fixo, como 30 a 90 dias, costuma bastar para comparar semanas e investigar problemas, sem lotar o disco. Use rotação de arquivos.

Ler logs ajuda a deixar o robô lucrativo?

Não diretamente. O log mostra se o robô executou o que foi configurado. Se a regra tem expectativa negativa, o log apenas registra isso com precisão.