Observabilidade em sistemas de trading: checklist para esta semana

Um atraso de 500 ms no fluxo de ordens pode fazer com que uma ordem não seja executada pelo preço pretendido, gerar uma reclamação de cliente ou transformar uma oscilação rotineira de um venue em um incidente. Nesta semana, verifique se seus logs e alertas conseguem mostrar onde o atraso começou, quais ordens foram afetadas e se os controles de risco continuaram disponíveis. A observabilidade é útil quando responde a essas perguntas rapidamente, não quando produz o maior painel.

Registre o fluxo, não cada byte

Comece com uma sequência rastreável, da solicitação do cliente ao relatório de execução. Atribua a cada ordem um ID de correlação que permaneça o mesmo no gateway, no risco, no roteamento e nos adaptadores de venue. Registre separadamente o horário do evento e o horário de processamento. Use UTC para timestamps compartilhados e um relógio monotônico para medir durações dentro de um processo. Acompanhe o desvio dos relógios entre hosts: um timestamp que parece preciso, mas está dessincronizado, pode colocar os eventos na ordem errada.

Capture eventos de ordens e de risco

A cada transição de estado, registre o ID da ordem, o ID da conta ou do tenant, o instrumento, o lado, a quantidade, o tipo de ordem, a rota, o estado, o código de motivo e o componente. Inclua timestamps de recebimento, validação, decisão de risco, envio para a rota, confirmação do venue e execução ou rejeição final.

Registre o identificador da regra e o resultado da decisão nas verificações de risco, não apenas uma mensagem genérica de "bloqueado". Isso permite distinguir uma violação do cliente de um timeout ou de um cache de limites desatualizado.

Não inclua credenciais, tokens de acesso, dados de pagamento ou payloads completos de clientes nos logs gerais da aplicação. Mascarar dados pessoais e restringir o acesso a campos no nível da conta. Mantenha uma trilha de auditoria imutável para eventos de ordens e controles; não faça amostragem desses eventos. Para logs de debug detalhados, use retenção curta e amostragem controlada.

Em fluxos de baixa latência, emita logs de forma assíncrona e monitore a própria fila de logging. Um destino de logs não deve bloquear o processamento de ordens, mas eventos de auditoria descartados precisam gerar um sinal separado e de alta prioridade.

Meça os dados de mercado e as dependências

Para cada feed e grupo de instrumentos, capture números de sequência da bolsa ou do provedor, horário de recebimento, horário de processamento, lacunas, tentativas de recuperação e a idade da cotação utilizável mais recente. Registre a origem e o estado do failover. Um feed pode estar conectado enquanto seus dados estão desatualizados, então o status da conexão, por si só, não é uma verificação de integridade.

Instrumente também as dependências que ficam fora do fluxo de matching ou roteamento: DNS, chamadas ao banco de dados, falhas de cache, message brokers, serviços de identidade e recuperação de secrets. Mantenha limitadas as labels das métricas.

Usar cada ID de ordem como label cria uma cardinalidade incontrolável e pode levar o sistema de métricas à própria falha. Coloque identificadores de alta cardinalidade em traces ou logs e use labels de métricas como venue, região, adaptador e serviço.

Gere alertas sobre impacto para o cliente e perda de controle

Acione alertas que exijam ação, não para cada linha de erro. Separe sintomas que afetam a execução de avisos sobre a infraestrutura. Direcione os alertas a um responsável, com um runbook e uma primeira verificação clara. Um painel não é um alerta, e uma notificação sem responsável é apenas ruído.

Priorize as falhas que alteram o comportamento do trading

Use uma lista curta de condições para acionar alertas, vinculadas ao que o sistema já não consegue fazer com segurança:

• As ordens não são confirmadas dentro do objetivo de serviço, ou a latência de confirmação aumenta acentuadamente em uma rota.
• Os dados de mercado estão desatualizados, as lacunas de sequência não estão sendo recuperadas ou os feeds principal e de backup divergem além da tolerância configurada.
• As verificações de risco estão expirando, ignorando um controle obrigatório ou retornando decisões inconsistentes entre instâncias.
• As solicitações de cancelamento estão se acumulando, os relatórios de execução estão atrasados ou uma verificação de reconciliação encontra ordens cujo estado é desconhecido.

Acompanhe as rejeições por motivo e rota. Um aumento nas rejeições esperadas por margem ou faixa de preço pode exigir análise, mas não deve acionar um alerta como o de um adaptador com falha.

Por outro lado, um número modesto de respostas de "status desconhecido" pode exigir ação urgente se o sistema não conseguir determinar se há exposição. Defina a gravidade com base no modo de falha e na população afetada, não apenas na quantidade.

Alerta sobre saturação antes que as filas virem incidentes

A profundidade da fila, por si só, pode induzir a erro. Acompanhe a idade da mensagem mais antiga e o ritmo de crescimento da fila.

Combine essas medidas com a utilização dos workers, o volume de novas tentativas, o uso do pool de conexões e a latência dos sistemas downstream. Um serviço com CPU a 90% e latência estável pode estar saudável; uma fila crescente com CPU disponível pode indicar uma dependência bloqueada. Defina limites de aviso para tendência e capacidade, e acione um alerta quando houver evidências de impacto ou risco plausível de descumprir o objetivo de trading.

Agrupe alertas duplicados por serviço, venue e incidente. Suprima alertas secundários quando uma falha upstream conhecida os explicar, mas mantenha os sinais subjacentes para diagnóstico. Para contexto operacional e relatórios da plataforma, mantenha seu runbook junto da cobertura de infraestrutura da Trading Technology.

Defina limites com base nas consequências

Os números abaixo são faixas típicas do mercado, não objetivos de serviço universais. Defina limites separados para instrumentos líquidos e menos ativos, latência interna e de venue, e horários de mercado e janelas de manutenção. Estabeleça uma linha de base para cada rota antes de escolher o limite para acionar um alerta.

Use percentis, não médias, para medir latência. As médias escondem a cauda que afeta uma parcela pequena, mas importante, das ordens.

Gere alertas para violações persistentes, com um acionamento mais rápido para falhas graves, como lacunas na sequência do feed ou indisponibilidade das verificações de risco. Mantenha o intervalo de tempo do painel alinhado à janela do alerta para que o operador possa verificar o sinal sem precisar refazer a consulta.

Faça o checklist nesta semana

Comece por uma rota de ordens representativa. Inclua uma ordem normal, uma rejeição, um cancelamento e um relatório de execução. Evite usar uma ordem de cliente real para testar o tratamento de falhas, a menos que o procedimento seja aprovado e a exposição resultante esteja controlada.

1. Acompanhe uma ordem em todos os serviços e confirme que seu ID de correlação, timestamps e transições de estado continuam visíveis.
2. Verifique se o horário do evento e o horário de processamento são distintos, se os relógios são monitorados e se os logs não expõem secrets nem dados pessoais desnecessários.
3. Confirme que os eventos de auditoria não passam por amostragem e que uma falha no logging não pode bloquear o fluxo de ordens. Verifique se eventos descartados geram um alerta.
4. Confira a idade do feed, as lacunas de sequência, a idade da fila, a latência das ordens, os motivos de rejeição e os timeouts das verificações de risco em um painel atualizado.
5. Revise cada alerta que aciona uma notificação para confirmar que tem um responsável, gravidade, runbook, janela de avaliação e uma primeira ação testável. Remova os alertas que não podem orientar uma decisão.
6. Simule um atraso ou uma desconexão de dependência em um ambiente controlado. Confirme que os alertas identificam a rota afetada e que a recuperação encerra o alerta sem ocultar ordens ainda não resolvidas.

Anote as lacunas em vez de ampliar todos os limites. Uma revisão semanal útil pode começar com três medidas: tempo entre a falha e sua detecção, tempo para identificar o componente afetado e número de ordens com estado não resolvido. Verifique se algum alerta P1 sem confirmação já tem mais de 5 minutos.

#monitoramento de sistemas de trading #logs de trading #infraestrutura de broker #monitoramento da latência de ordens #alertas de dados de mercado #resposta a incidentes de trading #monitoramento do mecanismo de risco #checklist de observabilidade