Temps de lecture : … min

Observability des runtimes de trading algorithmique

Suivez le comportement de vos algorithmes de trading pendant leur exécution dans le cloud.

TradingHost fournit aux projets de trading algorithmique un environnement d'exécution cloud avec une visibilité directe sur la sortie du conteneur actif. Dès que votre stratégie, framework, connecteur ou application écrit sur la sortie standard, TradingHost capture ce flux et le rend accessible depuis la console d'administration.

Pour les traders qui passent d'un VPS à un runtime cloud-native, c'est une méthode simplifiée pour analyser le comportement d'une application, sans session de bureau à distance, fenêtre de terminal ou gestion manuelle de fichiers de logs.

Périmètre d'observabilité

  • Capture de STDOUT et STDERR
  • Sortie du conteneur d'exécution
  • Visible depuis la console d'administration
  • Indépendant du langage de programmation
  • Boucle de rétroaction basée sur GitHub
  • Sans session de bureau à distance
  • Aucun fichier de logs à gérer soi-même

Section 01 · Autour du runtime

Conçu autour du runtime, pas du bureau

Avec un VPS traditionnel, l'observabilité est souvent dispersée entre terminaux de bureau, logs de plateforme, fichiers locaux, scripts et sessions à distance. Vos outils se trouvent là où vous les avez laissés pour la dernière fois.

TradingHost adopte une approche différente. Votre projet s'exécute dans un conteneur managé, et la console d'administration vous donne une visibilité directe sur les flux générés par ce runtime. Vous pouvez vérifier le comportement après un déploiement, vous assurer que le processus a démarré correctement et suivre les rapports de votre application en temps réel.

L'observabilité n'est plus une tâche fastidieuse à effectuer sur un bureau à distance. Elle fait partie intégrante du runtime de trading.

L'observabilité, définie

Sur TradingHost, l'observabilité se résume aux logs d'exécution. La plateforme capture la sortie standard (STDOUT) et l'erreur standard (STDERR) du conteneur actif et les affiche sur la console d'administration, vous permettant de répondre aux questions opérationnelles sur votre déploiement sans ouvrir de session serveur.

Section 02 · STDOUT et STDERR

Logs d'exécution via STDOUT et STDERR

TradingHost s'appuie sur l'interface de journalisation standard des applications conteneurisées : STDOUT et STDERR. Si votre stratégie génère une sortie pendant son exécution, la plateforme l'affiche.

Messages de démarrage, logs de framework, événements de connexion au courtier, erreurs d'API de la plateforme d'échange, rejets d'ordres, tentatives de reconnexion, exceptions d'exécution. Si votre application écrit ces lignes sur la sortie standard ou d'erreur, elles s'affichent directement sur la console TradingHost.

  • STDOUT

    Sortie standard de l'application. Messages de démarrage, logs de framework, connexions au courtier, signaux d'activité (heartbeats), soumissions d'ordres et tout autre élément que votre stratégie envoie vers la sortie standard.

  • STDERR

    Sortie d'erreur de l'application. Erreurs d'API de la plateforme d'échange, messages d'ordres rejetés, échecs d'authentification, tentatives de reconnexion et exceptions d'exécution capturées pendant l'activité du processus.

Ce fonctionnement est identique pour tous les langages et frameworks supportés. Tout processus capable de s'exécuter dans un conteneur peut générer des sorties d'exécution capturées par TradingHost.

Compatible conteneur

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

Section 03 · Cas d'usage possibles

Les questions résolues par les logs d'exécution

Six questions opérationnelles qu'un trader se pose après un déploiement, et les réponses apportées par les logs d'exécution.

QuestionImportance
Mon runtime a-t-il démarré ?Confirme que le processus déployé a bien été lancé.
Ma stratégie est-elle entrée dans sa boucle d'exécution ?Confirme que l'application est active et ne s'est pas arrêtée silencieusement.
La connexion à mon courtier ou à ma plateforme d'échange a-t-elle réussi ?Aide à identifier les problèmes d'authentification, de réseau ou d'API.
Une erreur est-elle survenue après le déploiement ?Rend les problèmes de déploiement visibles sans avoir à ouvrir de session serveur.
Mon application s'est-elle reconnectée après une panne ?Aide à surveiller les processus de trading à exécution longue.
La dernière modification du code s'est-elle comportée comme prévu ?Fournit un retour immédiat après un déploiement basé sur GitHub.

La visibilité exacte dépend de ce que produit votre application. TradingHost fournit l'interface des journaux d'exécution. Votre projet reste responsable de la génération de journaux applicatifs pertinents.

Section 04 · Boucle basée sur GitHub

Conçu pour le déploiement basé sur GitHub

L'observabilité est particulièrement utile lorsqu'elle est liée au déploiement. TradingHost est conçu autour de flux de travail natifs GitHub. Vous poussez votre code, déployez un projet et inspectez les sorties d'exécution générées par ce déploiement.

Cela vous offre une boucle opérationnelle claire avec trois points de contrôle.

  • Étape 1

    Le code réside dans GitHub

    Votre stratégie, la configuration du framework et le manifeste de déploiement se trouvent dans un dépôt GitHub. GitHub est la source de vérité de ce qui doit être exécuté.

  • Étape 2

    Le déploiement s'exécute sur TradingHost

    TradingHost lit le dépôt, construit le conteneur et démarre l'environnement d'exécution. Le déploiement est le moment où la nouvelle itération de votre code devient active.

  • Étape 3

    La sortie d'exécution est visible

    La sortie standard (STDOUT) et l'erreur standard (STDERR) du conteneur en cours d'exécution remontent dans la console d'administration. Vous pouvez voir si le déploiement a démarré, s'il est resté actif et ce qu'il a signalé pendant son exécution.

Section 05 · Courtiers et frameworks

Utile pour les stratégies connectées aux courtiers et aux plateformes d'échange

Les systèmes de trading automatisés dépendent de connexions externes. Une stratégie peut avoir besoin de s'authentifier auprès d'une plateforme d'échange, d'ouvrir un flux WebSocket, d'appeler l'API d'un courtier, de vérifier les soldes, de soumettre des ordres, de gérer les rejets et de se rétablir après des pannes de connexion temporaires.

L'observabilité de TradingHost ne remplace pas les rapports des courtiers ou des plateformes d'échange. Elle vous donne de la visibilité sur ce que votre application signale lors de ses interactions avec ces systèmes, ce qu'aucune des deux parties ne vous indique habituellement.

Pages d'exécution des plateformes d'échange

Section 06 · Flux de travail assistés par IA

Conçu pour les flux de travail assistés par IA

L'observabilité de TradingHost prend également en charge le développement assisté par IA. Lorsque vous utilisez Cursor, Claude Code, VS Code ou des agents en ligne de commande (CLI), la sortie d'exécution devient une boucle de rétroaction essentielle.

Un agent peut aider à modifier le code. GitHub conserve la source de vérité. TradingHost exécute le projet. Les journaux générés guident l'itération suivante. Chaque étape a un responsable clairement défini.

Le rôle de MCP

MCP est l'interface de contrôle et de gestion pour le déploiement, l'observabilité et les opérations de runtime. C'est ainsi qu'un agent inspecte un runtime ou déclenche un redéploiement. Ce n'est pas le canal par lequel les transactions sont exécutées. Le routage des ordres reste au sein de votre stratégie, directement vers le broker ou l'exchange avec lequel votre code communique déjà.

Section 07 · Ce que ce n'est pas

Visibilité opérationnelle, pas analyse de performance

L'observabilité de TradingHost se concentre sur les opérations de runtime. Elle vous aide à savoir si votre processus de trading déployé fonctionne, échoue, se reconnecte ou produit les résultats attendus. Elle ne cherche pas à tout faire.

Ce que couvrent les journaux du runtime

Le déploiement a-t-il démarré ? La stratégie est-elle entrée dans sa boucle d'exécution ? La connexion au broker ou à l'exchange a-t-elle réussi ? Des erreurs sont-elles survenues ? L'application s'est-elle reconnectée après une panne ? La dernière modification du code s'est-elle comportée comme prévu ? Des questions opérationnelles avec des réponses opérationnelles.

  • Ce n'est pas un moteur de backtesting.
  • Ce n'est pas un broker.
  • Ce n'est pas un outil de création de stratégie.
  • Ce n'est pas une plateforme d'analyse de portefeuille.
  • Ce n'est pas un substitut aux relevés de broker ou à l'historique des transactions d'un exchange.

TradingHost est la couche d'infrastructure et de runtime de production pour le code de trading automatisé. La création de stratégies et le backtesting relèvent d'AlgoBuilder. L'analyse des performances et l'intelligence de trading relèvent de TrackATrader.

Sur le même sujet

Composants de la plateforme TradingHost

FAQ

Questions fréquentes

TradingHost offre une visibilité sur les sorties du conteneur en cours d'exécution, à commencer par les journaux STDOUT et STDERR. Tout ce que votre application écrit sur la sortie standard ou l'erreur standard peut être remonté depuis le plan de contrôle.

Non. L'observabilité de TradingHost est destinée aux opérations de runtime. L'analyse des transactions, l'attribution de performance, les courbes de capital et l'analyse de portefeuille relèvent d'outils d'analyse comme TrackATrader.

Oui. Tout langage capable de s'exécuter dans un conteneur et d'écrire sur la sortie standard peut générer des journaux capturés par TradingHost. Python, Node.js, Go, Rust, Java, C# et les autres langages compatibles avec les conteneurs partagent tous le même mécanisme d'observabilité.

Votre stratégie doit générer des sorties opérationnelles utiles. Si votre application reste silencieuse, il y aura moins d'éléments à inspecter depuis le plan de contrôle. La plupart des frameworks enregistrent déjà des événements pertinents par défaut, de sorte que pour de nombreux projets, la modification est minime, voire inexistante.

Oui, si votre application les consigne dans ses journaux. TradingHost affiche la sortie générée par votre code lors de ses interactions avec les brokers, les exchanges, les frameworks et les connecteurs. La plateforme n'invente pas d'erreurs, mais elle ne les masque pas non plus.

Les instructions détaillées de journalisation et d'implémentation se trouvent dans la documentation des Logs. Cette page explique comment écrire des sorties structurées, comment masquer les données sensibles et comment organiser vos lignes de log pour qu'elles restent exploitables à grande échelle.

Sur un VPS, vous devez souvent vous connecter au serveur, trouver le bon fichier de log, le parcourir et reconstituer le fil des événements. Sur TradingHost, le runtime capture directement STDOUT et STDERR depuis le conteneur et les affiche dans le plan de contrôle. L'observabilité fait ainsi partie intégrante du runtime, évitant les manipulations manuelles sur votre machine.

Non. Le runtime capture la sortie standard (STDOUT) et l'erreur standard (STDERR) du conteneur de manière native. Vous n'avez pas besoin d'installer d'agent de journalisation, de configurer de conteneur sidecar ou d'exécuter un collecteur de logs distinct pour obtenir une visibilité sur le runtime.

Non. TradingHost vous montre ce que votre application signale lorsqu'elle interagit avec le broker ou l'exchange. Le registre officiel des ordres, des exécutions (fills), des soldes et des relevés reste géré par le broker ou l'exchange.

Oui. Les frameworks qui s'exécutent dans un conteneur et écrivent sur STDOUT ou STDERR sont compatibles avec l'interface de logs du runtime. La plateforme traite les sorties des frameworks de la même manière que celles de votre application.

Visualisez votre runtime, en temps réel.

Connectez GitHub, déployez une stratégie et lisez la sortie du runtime en direct. Pas de session de bureau à distance, pas de fichiers de logs à gérer, juste le conteneur qui vous indique ses actions.