Good logs make it possible to understand what an EA did and why. Many problems only show up in logs.
What to log:
Signal time and price, plus indicator values.
Order send time and requested price.
Fill time and price, slippage.
Spread at signal and at fill.
Errors and retries.
Exit reason.
Format:
CSV for analysis.
Text logs for debugging.
Unique IDs linking signal, order and fill.
Comparing logs from live trading and backtests shows where execution differs.
Log rotation is worth planning too: daily files with a clear naming scheme, kept for a fixed period, make it easier to find a specific day and prevent logs from filling the disk on a small VPS.
The row I added last and now value most is the signal the EA rejected. If it skipped a valid setup for spread or session time, I log the reason code, otherwise the live versus backtest comparison only shows trades that happened.
For the unique ID I build a string from symbol, magic number and the bar open time of the signal. It survives restarts, which a simple counter did not when my VPS rebooted mid session.
Timestamps need two clocks. I write server time plus a local millisecond count from GetTickCount, because server time alone cannot show the 300 to 400 ms gap I sometimes see between send and fill.
On MT5 the retcode gets its own column instead of hiding in free text. Grouping by it after a month showed most of my retries were price changed responses around the London open, not connection drops.
Rotation is easy to underrate. My daily CSV runs 1 to 2 MB on a busy day, so I keep 90 days, but verbose debug text is capped at 14 days.
Do you write to file on every tick, or buffer and flush once per bar? I moved to buffering after the writes started adding visible latency on a cheap VPS.
