Tiempo de lectura: … min

Observabilidad para entornos de ejecución de trading automático

Comprenda qué hace su proceso de trading mientras se ejecuta en la nube.

TradingHost proporciona a los proyectos de trading automático un entorno de ejecución en la nube con visibilidad directa de la salida del contenedor activo. Cuando su estrategia, framework, conector o aplicación escribe en la salida estándar, TradingHost captura esa información y la muestra en el panel de control.

Para los traders que pasan de la ejecución en VPS a entornos en la nube, esta es una forma más sencilla de inspeccionar el comportamiento de la aplicación sin sesiones de escritorio remoto, ventanas de terminal ni archivos de registro gestionados manualmente.

Superficie de observabilidad

  • Captura de STDOUT y STDERR
  • Salida del contenedor en tiempo de ejecución
  • Visible desde el panel de control
  • Agnóstico del lenguaje
  • Bucle de retroalimentación basado en GitHub
  • Sin sesiones de escritorio remoto
  • Sin archivos de registro gestionados por el usuario

Sección 01 · En torno al runtime

Diseñado en torno al runtime, no al escritorio

El trading tradicional basado en VPS suele dejar la observabilidad dispersa en terminales de escritorio, registros de la plataforma, archivos locales, scripts y sesiones remotas. Las herramientas se quedan donde las dejó por última vez.

TradingHost adopta un enfoque diferente. Su proyecto se ejecuta dentro de un entorno de ejecución de contenedores gestionado, y el panel de control le ofrece visibilidad sobre la salida generada por ese entorno. Puede inspeccionar qué ocurrió después de un despliegue, si el proceso se inició correctamente y qué está reportando su aplicación mientras se ejecuta.

La observabilidad deja de ser un ritual independiente que se realiza en un escritorio. Se convierte en parte del propio entorno de ejecución de trading.

Definición de observabilidad

En TradingHost, la observabilidad es la superficie de registro del entorno de ejecución. La plataforma captura la salida estándar y el error estándar del contenedor activo y los muestra en el panel de control, lo que le permite responder a preguntas operativas sobre su despliegue sin necesidad de abrir una sesión en el servidor.

Sección 02 · STDOUT y STDERR

Registros de ejecución de STDOUT y STDERR

TradingHost parte de la interfaz de registro estándar utilizada por las aplicaciones en contenedores: STDOUT y STDERR. Si su estrategia imprime algo mientras se ejecuta, la plataforma puede mostrarlo.

Mensajes de inicio, registros del framework, eventos de conexión con el broker, errores de la API del exchange, mensajes de órdenes rechazadas, intentos de reconexión, excepciones en tiempo de ejecución. Si su aplicación escribe cualquiera de estas líneas en la salida estándar o en el error estándar, ese resultado se puede mostrar desde el panel de control de TradingHost.

  • STDOUT

    Salida normal de la aplicación. Mensajes de inicio, registros del framework, eventos de conexión con el broker, señales de vida del bucle de ejecución, líneas de envío de órdenes y cualquier otra cosa que su estrategia imprima en la salida estándar.

  • STDERR

    Salida de errores de la aplicación. Errores de la API del exchange, mensajes de órdenes rechazadas, fallos de autenticación, intentos de reconexión y excepciones en tiempo de ejecución capturadas mientras el proceso está activo.

El mismo proceso funciona para todos los lenguajes y frameworks compatibles. Cualquier elemento que pueda ejecutarse dentro de un contenedor puede generar una salida en tiempo de ejecución que TradingHost capturará.

Compatible con contenedores

  • Python
  • Node.js
  • Go
  • Rust
  • Java
  • C#

Sección 03 · Para qué puede utilizarlo

Las preguntas que los registros de ejecución ya responden

Seis preguntas operativas que un trader se hace después de un despliegue, y lo que la superficie del entorno de ejecución le indica sobre cada una de ellas.

PreguntaPor qué es importante
¿Se inició mi entorno de ejecución?Confirma que el proceso desplegado realmente se ha iniciado.
¿Entró mi estrategia en su bucle de ejecución?Confirma que la aplicación está activa en lugar de cerrarse silenciosamente.
¿Se realizó correctamente la conexión con mi broker o exchange?Ayuda a identificar problemas de autenticación, red o API.
¿Se produjo algún error tras el despliegue?Hace visibles los problemas de despliegue sin necesidad de abrir una sesión de servidor.
¿Se reconectó mi aplicación tras un fallo?Ayuda a monitorizar procesos de trading de larga ejecución.
¿Se comportó como se esperaba el último cambio de código?Ofrece feedback inmediato tras un despliegue basado en GitHub.

La visibilidad exacta depende de lo que emita su aplicación. TradingHost proporciona la superficie de logs del entorno de ejecución. Su proyecto sigue siendo responsable de generar logs significativos a nivel de aplicación.

Sección 04 · Ciclo basado en GitHub

Diseñado para despliegues basados en GitHub

La observabilidad es más útil cuando está conectada al despliegue. TradingHost está diseñado en torno a flujos de trabajo nativos de GitHub. Usted sube el código, despliega un proyecto e inspecciona la salida del entorno de ejecución generada por ese despliegue.

Esto le proporciona un ciclo operativo claro con tres puntos de control.

  • Paso 1

    El código reside en GitHub

    Su estrategia, la configuración del framework y el manifiesto de despliegue se encuentran en un repositorio de GitHub. GitHub es la fuente de verdad de lo que debe estar ejecutándose.

  • Paso 2

    El despliegue se ejecuta en TradingHost

    TradingHost lee el repositorio, compila el contenedor e inicia el entorno de ejecución. El despliegue es el momento en que la siguiente iteración de su código se activa.

  • Paso 3

    La salida del entorno de ejecución es visible

    La salida estándar y el error estándar del contenedor en ejecución se muestran en el panel de control. Puede ver si el despliegue se inició, si se mantuvo activo y qué reportó mientras se ejecutaba.

Sección 05 · Brokers y frameworks

Útil para estrategias conectadas a brokers y exchanges

Los sistemas de trading automático dependen de conexiones externas. Una estrategia puede necesitar autenticarse en un exchange, abrir un flujo WebSocket, llamar a la API de un broker, consultar saldos, enviar órdenes, gestionar rechazos y recuperarse de fallos de conexión temporales.

La observabilidad de TradingHost no sustituye a los informes del broker o del exchange. Le ofrece visibilidad sobre lo que reporta su aplicación mientras interactúa con esos sistemas, que es precisamente la parte de la que ninguna de las dos partes suele informarle.

Páginas del entorno de ejecución del exchange

Sección 06 · Flujos de trabajo asistidos por IA

Diseñado para flujos de trabajo asistidos por IA

La observabilidad de TradingHost también es compatible con el desarrollo asistido por IA. Al utilizar Cursor, Claude Code, VS Code o agentes basados en CLI, la salida del entorno de ejecución se convierte en un bucle de retroalimentación fundamental.

Un agente puede ayudar a modificar el código. GitHub puede albergar la fuente de verdad. TradingHost puede ejecutar el proyecto. Los logs resultantes pueden guiar la siguiente iteración. Cada etapa tiene un responsable claro.

El papel de MCP

MCP es la interfaz de control y gestión para el despliegue, la observabilidad y las operaciones del runtime. Así es como un agente inspecciona un runtime o activa un nuevo despliegue. No es la vía por la que se ejecutan las operaciones. El enrutamiento de órdenes permanece dentro de su estrategia, conectándose directamente con el broker o exchange con el que ya se comunica su código.

Sección 07 · Lo que no es

Visibilidad operativa, no análisis de rendimiento

La observabilidad de TradingHost se centra en las operaciones del runtime. Le ayuda a entender si su proceso de trading desplegado se está ejecutando, si falla, si se reconecta o si produce la salida esperada. No intenta abarcar nada más.

Qué cubre el registro de actividad del runtime

Si se inició el despliegue, si la estrategia entró en su bucle de ejecución, si la conexión con el broker o exchange fue exitosa, si ocurrieron errores, si la aplicación se reconectó tras un fallo, si el último cambio de código funcionó como se esperaba. Preguntas operativas con respuestas operativas.

  • No es un motor de backtesting.
  • No es un broker.
  • No es un creador de estrategias.
  • No es una plataforma de análisis de cartera.
  • No reemplaza los estados de cuenta del broker ni el historial de operaciones del exchange.

TradingHost es la capa de infraestructura y runtime de producción para código de trading automatizado. La creación y el backtesting de estrategias corresponden a AlgoBuilder. El análisis de rendimiento y la analítica de trading corresponden a TrackATrader.

Relacionado

Parte de la plataforma TradingHost

Preguntas frecuentes

Preguntas frecuentes

TradingHost ofrece visibilidad de la salida del runtime desde el contenedor en ejecución, empezando por los registros de STDOUT y STDERR. Cualquier dato que su aplicación escriba en la salida estándar o en la salida de errores se puede visualizar desde el panel de control.

No. La observabilidad de TradingHost está diseñada para operaciones de runtime. La analítica de trading, la atribución de rendimiento, las curvas de equidad y la inteligencia de cartera corresponden a herramientas de análisis como TrackATrader.

Sí. Cualquier lenguaje que pueda ejecutarse dentro de un contenedor y escribir en la salida estándar puede generar registros que TradingHost puede capturar. Python, Node.js, Go, Rust, Java, C# y otros lenguajes compatibles con contenedores comparten la misma vía de observabilidad.

Su estrategia debe escribir una salida operativa útil. Si su aplicación no genera registros, habrá menos que inspeccionar desde el panel de control. La mayoría de los frameworks ya registran eventos significativos de forma nativa, por lo que para muchos proyectos el cambio es mínimo o nulo.

Sí, siempre que tu aplicación los registre. TradingHost muestra la salida que genera tu código al interactuar con brokers, exchanges, frameworks y conectores. La plataforma no inventa errores, pero tampoco los oculta.

Las guías detalladas de implementación y registro se encuentran en la documentación de Logs. Esta página explica cómo escribir salidas estructuradas, cómo ocultar valores confidenciales y cómo organizar las líneas de registro para que sigan siendo útiles a gran escala.

En un VPS, a menudo tienes que conectarte al servidor, buscar el archivo de registro correcto, recorrerlo y reconstruir lo que ha pasado. En TradingHost, el entorno de ejecución captura STDOUT y STDERR directamente del contenedor y los muestra en el panel de control, por lo que la observabilidad forma parte del propio entorno en lugar de ser un proceso manual en tu equipo.

No. El entorno de ejecución captura la salida estándar y el error estándar del contenedor como parte del funcionamiento de la plataforma. No necesitas instalar un agente de logs, configurar un sidecar ni ejecutar un transportador de logs independiente para obtener visibilidad del entorno de ejecución.

No. TradingHost te muestra lo que reporta tu aplicación mientras interactúa con el broker o el exchange. El registro oficial de órdenes, ejecuciones, saldos y estados de cuenta sigue estando en manos del broker o del exchange.

Sí. Los frameworks que se ejecutan dentro de un contenedor y escriben en STDOUT o STDERR son compatibles con la interfaz de logs del entorno de ejecución. La plataforma trata la salida del framework de la misma manera que la salida de la aplicación.

Observa tu entorno de ejecución en el mismo instante en que corre.

Conecta GitHub, despliega una estrategia y lee la salida del entorno de ejecución en tiempo real. Sin sesiones de escritorio remoto ni gestión de archivos de registro: solo el contenedor indicándote lo que ha hecho.