1 votos

¿sugerencias para mejorar la supervisión de los bots de negociación?

Simplemente estoy buscando consejos e ideas para hacer mi sistema un poco más profesional.

La estructura: El botting script está alojado en un VPS. Hay una base de datos alojada en otro VPS. Hay una webapp alojada periódicamente en local.

El botting script ejecuta las analíticas y operaciones y actualiza periódicamente la base de datos (MongoDB) con nuevos valores; métricas de rendimiento, posiciones y estados actuales / errores.

La webapp se conecta al MongoDB, saca los últimos datos y los muestra en una simple tabla de datos junto a unos simples gráficos (también he añadido una sencilla función que me permite pausar el script para ciertas bolsas y cuentas).

Esta es una pregunta bastante vaga / ambigua por lo que podría ser marcada por ser demasiado amplia, pero estoy buscando sugerencias generales para mejorar el sistema (lo he estado ejecutando durante casi dos años y simplemente estoy buscando maneras de mejorarlo; no sólo por el bien de mejorar el rendimiento, sino también porque me gustaría mejorar mis habilidades y enfoque).

Para empezar, alguien podría sugerir SQL en lugar de MongoDB (de momento no guardo los datos de las transacciones; esto se debe a que algunas de las bolsas en las que comercio carecen de suficiente soporte de la API para ello, pero estoy considerando empezar ya que permitirá un mejor análisis en una etapa posterior cuando tenga más datos).

También estoy ejecutando la base de datos y el propio script en diferentes servidores, tal vez haya una manera de simplemente ejecutarlos juntos y así mejorar un poco el rendimiento (ahora mismo lo he estructurado de tal manera que la actualización de los valores de la base de datos ocurre en un intervalo predecible y no interrumpe ninguno de los ciclos).

Estaré encantado de responder a cualquier pregunta. Ah, debo señalar que soy un programador mediocre en el mejor de los casos (principalmente programando en Python).

4voto

Timothy Carter Puntos 7079

No hay una forma correcta de hacerlo. Algunos consejos universales que puedo dar son:

Seguimiento operativo y estratégico

En la primera pasada, hay que distinguir entre estos dos, ya que las herramientas de seguimiento operativo y estratégico serán diferentes.

Seguimiento operativo

La supervisión operativa puede incluir lo siguiente:

  • Un latido para garantizar que su VPS sigue vivo, algún tipo de sistema de notificación (podría ser un sistema de mensajería de texto con Twilio, una alerta sonora, una notificación por correo electrónico con IMAP, un gráfico en un panel de control basado en la web).

  • Programación del registro automatizado en el diario y persistencia de los registros del sistema en un lugar centralizado. Una operación de mayor envergadura puede utilizar herramientas como ELK (Elasticsearch, Logstash, Kibana).

  • Una operación más sencilla puede limitarse a utilizar trabajos cron para registrar, comprimir y enviar los archivos de registro del sistema (por ejemplo, en /var/log ) a un servidor de registro o a su estación de trabajo. Las herramientas y los demonios que se encuentran con frecuencia aquí son fluentd , collectd , Nagios.

  • También puede crear su propia base de datos para aprovechar las garantías de persistencia, replicación y redundancia disponibles, así como los componentes de conectividad. Mongo está bien aquí, pero Postgres también tiene un gran soporte para datos no estructurados. Redis tiene la ventaja de soportar de forma nativa la semántica pub-sub, mientras que en Mongo es posible que haya que replicar ese comportamiento con cursores de cola. InfluxDB también tiende a ser utilizado en conjunto con las herramientas típicas aquí.

  • Algún tipo de visualización y panel de control para la utilización de la CPU y la memoria, etc. Las fugas de memoria en tu aplicación pueden hacer caer tu servidor, y los VPS tienden a estar faltos de recursos.

Seguimiento de la estrategia

Una gran parte del seguimiento de la estrategia es una cuestión de saber qué registrar. Un problema relacionado es decidir la estrategia de serialización tanto en el disco como en el cable, donde hay incluso más opciones sensatas para elegir que en los sistemas de gestión de bases de datos.

Desgraciadamente, este es un problema del tipo "el huevo y la gallina", en el que el hecho de haberlo visto en un entorno de producción maduro o de saber cómo será tu cartera a escala te dará una enorme ventaja a la hora de diseñarlo. Si no se sabe cómo serán las estrategias cuando se negocie con cientos de miles de órdenes al día y miles de millones de exposición nocional, entonces resolverlo a partir de los primeros principios hará que se pierda mucho tiempo.

Un consejo universal que puedo dar aquí sería:

  • Asegúrese de que su formato de registro tiene cierta compatibilidad con el pasado.
  • No optimices prematuramente, todos los graduados de primer año de CS han intentado crear a mano su propio formato de serialización binaria propietario.
  • La legibilidad humana (json, texto plano unicode), un formato autodescriptivo (Avro), un lenguaje de descripción de interfaces (thrift) y el soporte multilingüe (protobuf) son todas propiedades bastante deseables, decida qué es lo más importante para usted.
  • Descargue alguna plataforma de negociación gratuita y utilícela para inspirarse en los tipos de campos que registraría, por ejemplo, el lado de la orden, la marca de tiempo, la cantidad de la orden, el tiempo en vigor, el símbolo, etc. son todos bastante estándar y puede componer métricas más complejas a partir de estos a posteriori al final del día o más tarde.

Finanhelp.com

FinanHelp es una comunidad para personas con conocimientos de economía y finanzas, o quiere aprender. Puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X