Plataformas · Software · Proveedores · Mercados
Devin Hartcastle
Un retraso de 500 ms en el recorrido de una orden puede impedir que se ejecute al precio previsto, provocar una queja de un cliente o convertir una fluctuación rutinaria de un centro de negociación en un incidente. Esta semana, compruebe si sus registros y alertas pueden mostrar dónde comenzó el retraso, a qué órdenes afectó y si los controles de riesgo siguieron disponibles. La observabilidad resulta útil cuando responde rápidamente a esas preguntas, no cuando genera el panel más grande.
Registre el recorrido, no cada byte
Empiece con una secuencia trazable desde la solicitud del cliente hasta el informe de ejecución. Asigne a cada orden un ID de correlación que se mantenga en la pasarela, la gestión de riesgos, el enrutamiento y los adaptadores de los centros de negociación. Registre por separado la hora del evento y la hora de procesamiento. Use UTC para las marcas de tiempo compartidas y un reloj monótono para medir duraciones dentro de un proceso. Controle el desfase de los relojes entre hosts: una marca de tiempo que parece precisa, pero no está sincronizada, puede situar los eventos en el orden equivocado.
Capture los eventos de órdenes y riesgos
Para cada cambio de estado, registre el ID de la orden, el ID de cuenta o tenant, el instrumento, el lado, la cantidad, el tipo de orden, la ruta, el estado, el código de motivo y el componente. Incluya marcas de tiempo de la recepción, la validación, la decisión de riesgo, el envío a la ruta, la confirmación del centro de negociación y la ejecución o el rechazo final.
Registre el identificador de la regla y el resultado de la decisión para los controles de riesgo, no solo un mensaje genérico de "bloqueada". Esto permite distinguir una infracción del cliente de un tiempo de espera agotado o de una caché de límites obsoleta.
No incluya credenciales, tokens de acceso, datos de pago ni cargas completas de datos de clientes en los registros generales de la aplicación. Enmascare los datos personales y restrinja el acceso a los campos de nivel de cuenta. Mantenga un registro de auditoría inmutable para los eventos de órdenes y controles; no lo muestree. Para los registros de depuración detallados, use una retención breve y un muestreo controlado.
En las rutas de baja latencia, emita los registros de forma asíncrona y supervise también la cola de registro. Un destino de registro no debe bloquear el procesamiento de órdenes, pero la pérdida de eventos de auditoría debe generar una señal independiente y de alta prioridad.
Mida los datos de mercado y las dependencias
Para cada fuente de datos y grupo de instrumentos, capture los números de secuencia de la bolsa o el proveedor, la hora de recepción, la hora de procesamiento, las interrupciones, los intentos de recuperación y la antigüedad de la última cotización utilizable. Registre la fuente y el estado de conmutación por error. Una fuente puede estar conectada mientras sus datos están obsoletos, por lo que el estado de conexión por sí solo no sirve para comprobar su salud.
Instrumente también las dependencias que quedan fuera de la ruta de casación o enrutamiento: DNS, llamadas a bases de datos, fallos de caché, brokers de mensajes, servicios de identidad y recuperación de secretos. Mantenga acotadas las etiquetas de las métricas.
Etiquetar cada ID de orden crea una cardinalidad inmanejable y puede hacer que el propio sistema de métricas falle. Incluya los identificadores de alta cardinalidad en trazas o registros, y use etiquetas de métricas como centro de negociación, región, adaptador y servicio.
Genere alertas ante el impacto en los clientes y la pérdida de control
Envíe una alerta que requiera actuar, no por cada línea de error. Separe los síntomas que afectan a la ejecución de las advertencias de infraestructura. Dirija las alertas a una persona responsable, con un manual operativo y una primera comprobación clara. Un panel no es una alerta, y una notificación sin una persona responsable es solo ruido.
Priorice los fallos que cambian el comportamiento del trading
Use una lista breve de condiciones que requieran alertas y que estén vinculadas a lo que el sistema ya no puede hacer de forma segura:
- Las órdenes no reciben confirmación dentro del objetivo de servicio, o la latencia de confirmación aumenta bruscamente en una ruta.
- Los datos de mercado están obsoletos, las interrupciones de secuencia no se recuperan o las fuentes principales y de respaldo discrepan por encima de la tolerancia configurada.
- Los controles de riesgo agotan el tiempo de espera, omiten un control obligatorio o devuelven decisiones incoherentes entre instancias.
- Se acumulan solicitudes de cancelación, se retrasan los informes de ejecución o una comprobación de conciliación detecta órdenes cuyo estado se desconoce.
Haga seguimiento de los rechazos por motivo y ruta. Un aumento de los rechazos previstos por margen o banda de precios puede requerir una revisión, pero no debería generar una alerta urgente como la de un adaptador averiado.
Por el contrario, una cantidad moderada de respuestas de "estado desconocido" puede ser urgente si el sistema no puede determinar si existe exposición. Determine la gravedad según el tipo de fallo y la población afectada, no solo por el número de casos.
Genere alertas por saturación antes de que las colas provoquen incidentes
La profundidad de la cola por sí sola puede inducir a error. Mida la antigüedad del mensaje más antiguo y la velocidad a la que crece la cola.
Combine estas métricas con la utilización de los procesos de trabajo, el volumen de reintentos, el uso del conjunto de conexiones y la latencia de los servicios posteriores. Un servicio con un uso de CPU del 90% y una latencia estable puede estar funcionando correctamente; una cola en aumento con CPU disponible puede indicar una dependencia bloqueada. Defina umbrales de advertencia para las tendencias y la capacidad, y envíe una alerta urgente cuando haya indicios de impacto o un riesgo creíble de incumplir el objetivo de trading.
Agrupe las alertas duplicadas por servicio, centro de negociación e incidente. Suprima las alertas secundarias cuando un fallo conocido en un sistema previo las explique, pero conserve las señales subyacentes para el diagnóstico. Para conocer el contexto operativo y los informes de la plataforma, mantenga su manual operativo junto con la cobertura de infraestructura de Trading Technology.
Defina los umbrales según las consecuencias
Las cifras siguientes son rangos habituales del mercado, no objetivos de servicio universales. Defina límites independientes para instrumentos líquidos y menos activos, la latencia interna y la de los centros de negociación, y las horas de mercado y las ventanas de mantenimiento. Establezca una referencia para cada ruta antes de elegir un umbral de alerta urgente.
| Señal | Umbral de alerta habitual | Ventana de evaluación | Primera comprobación |
|---|---|---|---|
| Latencia de confirmación de órdenes | P99 superior a 250-500 ms | 1-5 minutos | Compare los tiempos del centro de negociación y la pasarela |
| Latencia interna de la ruta de órdenes | P99 superior a 10-50 ms | 1-5 minutos | Identifique el tramo de servicio más lento |
| Antigüedad de los datos de mercados líquidos | Superior a 1-3 segundos | 10-30 segundos | Compruebe las interrupciones de secuencia y el estado de la fuente |
| Antigüedad de la cola de ejecución | Superior a 100-500 ms | 30-120 segundos | Compruebe el retraso del consumidor y la respuesta del servicio posterior |
| Rechazos de órdenes inesperados | Más del 1-3% de las órdenes | 3-10 minutos | Desglose por ruta y código de motivo |
Use percentiles en lugar de promedios para la latencia. Los promedios ocultan la cola de la distribución que afecta a una proporción pequeña, pero importante, de las órdenes.
Genere alertas ante incumplimientos sostenidos, con una activación más rápida para fallos críticos, como interrupciones de secuencia en las fuentes de datos o controles de riesgo no disponibles. Alinee el intervalo de tiempo del panel con la ventana de alerta para que el operador pueda verificar la señal sin tener que reconstruir la consulta.
Aplique la lista de verificación esta semana
Empiece por revisar una ruta de órdenes representativa. Incluya una orden normal, un rechazo, una cancelación y un informe de ejecución. Evite usar una orden de un cliente en producción para probar la gestión de fallos, a menos que el procedimiento esté aprobado y la exposición resultante esté controlada.
- Siga una orden a través de todos los servicios y confirme que su ID de correlación, las marcas de tiempo y los cambios de estado sigan siendo visibles.
- Compruebe que la hora del evento y la hora de procesamiento sean distintas, que los relojes estén supervisados y que los registros no expongan secretos ni datos personales innecesarios.
- Verifique que los eventos de auditoría no se muestreen y que los fallos de registro no puedan bloquear la ruta de órdenes. Confirme que la pérdida de eventos genere una alerta.
- Compruebe en un panel en tiempo real la antigüedad de los datos de mercado, las interrupciones de secuencia, la antigüedad de las colas, la latencia de las órdenes, los motivos de rechazo y los tiempos de espera agotados en los controles de riesgo.
- Revise que cada alerta urgente tenga una persona responsable, gravedad, manual operativo, ventana de evaluación y una primera acción verificable. Elimine las alertas que no permitan tomar una decisión.
- Simule un retraso o una desconexión de una dependencia en un entorno controlado. Confirme que las alertas identifiquen la ruta afectada y que la recuperación las desactive sin ocultar órdenes sin resolver.
Anote las deficiencias en lugar de ampliar todos los umbrales. Una revisión semanal útil puede empezar con tres medidas: el tiempo desde el fallo hasta su detección, el tiempo para identificar el componente afectado y el número de órdenes con estado sin resolver. Compruebe si alguna alerta P1 sin confirmar ya tiene más de 5 minutos.
Preguntas frecuentes
¿Qué debe registrar un sistema de trading para cada orden?
Registre el ID de la orden, el ID de correlación, la cuenta o el tenant, el instrumento, la ruta, los cambios de estado, los códigos de motivo y las marcas de tiempo de cada etapa del procesamiento. Capture las decisiones de riesgo y las respuestas de los centros de negociación, sin incluir credenciales ni cargas completas con datos sensibles de clientes en los registros generales.
¿Qué métricas de un sistema de trading deben activar una alerta?
Priorice la latencia de confirmación de órdenes, los datos de mercado obsoletos, las interrupciones de secuencia, los tiempos de espera agotados en los controles de riesgo, los retrasos en las cancelaciones y los estados de órdenes sin resolver. La antigüedad de las colas y los rechazos inesperados ayudan a distinguir el impacto en los clientes del ruido inocuo de la infraestructura.
¿Cuál es un umbral habitual de alerta para la latencia de las órdenes?
Los rangos habituales para la latencia p99 de confirmación son de alrededor de 250-500 ms, mientras que los umbrales p99 de la ruta interna de órdenes pueden rondar los 10-50 ms. Los límites reales dependen del centro de negociación, la ruta, el instrumento y el objetivo de servicio, por lo que conviene establecer una referencia antes de generar alertas urgentes por un incumplimiento.
¿Cómo puede un broker reducir las alertas ruidosas de trading?
Envíe alertas urgentes ante condiciones sostenidas o de gran impacto y agrupe las señales duplicadas por servicio, centro de negociación e incidente. Use los códigos de motivo y el contexto de la ruta afectada para distinguir los rechazos previstos de los fallos de adaptadores, y asigne a cada alerta urgente una persona responsable y un manual operativo.
