Discussing the article: "Native MQL5 Prometheus Exporter: Real-Time Observability for Live Trading Models"

[MetaQuotes]

Check out the new article: Native MQL5 Prometheus Exporter: Real-Time Observability for Live Trading Models.

This article shows how to build a fully native MQL5 metrics pipeline for a live EA without DLLs or sidecar processes. It implements counters, gauges, and histograms, safe text/label encoding, and an HTTP client that pushes one exposition payload to a Prometheus Pushgateway on a timer. You will wire metrics into OnTick/OnTimer, export equity, drawdown, trade P&L, and latency, and learn configuration, testing, and limitations for reliable observability.

Most MQL5 observability articles stop at logging to a file or pushing rows into a database. That works until you need to watch a live model — equity, floating drawdown, inference latency, whether the model's confidence is drifting — continuously and without opening the terminal. Logs can answer many of those questions, especially with log shipping and alert rules on top. But questions like "is inference latency creeping up right now?" or "is this EA still pushing data at all?" are numeric and time-based. A time-series system answers them more directly: a metric is a number sampled on a schedule, queryable with rates, percentiles and thresholds, with no text parsing.

Prometheus is a natural target: it is the de facto standard for collecting numeric time series. Once your EA exports the Prometheus text format, Grafana dashboards, alert rules, and other ecosystem tools work with it without additional integration. That format itself is unremarkable — plain text, one metric per line, a HELP and a TYPE comment above each. What matters is the surrounding design: pick the correct metric type for each quantity, and reliably export the values from MQL5.

The catch is that MQL5 cannot be a Prometheus target in the way you would expect. Prometheus normally works by scraping — it polls a /metrics HTTP endpoint on your service at regular intervals. That requires your service to accept an incoming connection and answer it, which means running a listening socket. Native MQL5 sockets do not support listening sockets, which rules out the usual scrape-based design and shapes everything that follows.

Author: Adesewa Tolulope Gbadebo