Logging implementeren in je bot om fouten op te sporen
Je bot draait, je ziet cijfers voorbijkomen, maar ineens loopt hij vast of je mist een trade. Herkenbaar?
Logging is dan je beste vriend. Het voelt soms als extra werk, maar zonder goede logs zit je in het duister te tasten.
Stel je voor dat je bot om 03:17 ’s nachts crasht en je hebt geen idee waarom. Dat is frustrerend en kost je geld. Met slimme logging weet je precies wat er gebeurt, wanneer en waarom. Je bent sneller terug online en je voorkomt dat kleine fouten uitgroeien tot grote problemen. Laten we een paar veelgemaakte fouten doornemen en hoe je ze oplost.
Fout 1: Geen logniveau’s gebruiken
Veel traders dumpen alles als info of debug, zonder onderscheid. Je bot logt elke tick, elke orderbevestiging en elke foutmelding in één grote bak. Dat werkt niet. Je ziet door de bomen het bos niet meer en je mist de echte problemen tussen de ruis.
Bovendien schiet je logbestand vol en loop je tegen limieten aan bij je broker of cloud.
Gebruik niveaus: debug voor ruis, info voor normale stappen, warning voor iets om in de gaten te houden, error voor mislukte acties, critical voor crash-level. In Python doe je dit simpel met de logging-module.
Stel je voor: je bot draait op een VPS van €20 per maand en je logt elke seconde een debugregel. Binnen een uur heb je een logbestand van 500 MB en loopt je schijf vol. Gevolg: je bot stopt, je mist posities, en je moet handmatig schoonmaken.
Zet je logger zo op dat je in productie alleen info en hoger logt, en tijdens development debug toevoegt. Oplossing: definieer een logger per module en zet de juiste niveau’s. Gebruik een formatter die tijd, niveau en boodschap netjes toont.
Test met een kleine run en filter op niveau. Zo hou je overzicht en voorkom je dat je logbestand onnodig groot wordt.
Fout 2: Logs niet draaien of rotatie vergeten
Een logbestand dat oneindig groeit, is een klassieker. Je bot draait dagenlang en je log wordt steeds groter totdat je VPS vastloopt.
Je broker API geeft dan timeout-fouten omdat je schijf vol is, en je bot crasht.
Je mist trades en je moet handmatig oude logs verwijderen. Logboeken horen te rollen. Je bewaakt de grootte en het aantal bestanden.
Een collega-trader draaide een bot op Binance met een log zonder rotatie. Na 3 dagen had hij een 2 GB log en liep de VPS vol. Gevolg: orderaanvragen mislukten, hij verloor €150 aan gemiste trades. Sindsdien gebruikt hij rotatie en checkt hij elke ochtend de loggrootte.
Zo blijft je log overzichtelijk en beheersbaar. Zonder rotatie verlies je snel controle.
Gebruik RotatingFileHandler voor dagelijkse rollen op grootte of tijd. Stel in: max 10 MB per bestand, bewaar 5 bestanden. Als je bot 24/7 draait, weet je zeker dat je nooit zonder schijfruimte komt te zitten. Stel je limieten in en monitor ze. Zo voorkom je dat je bot stilvalt door iets simpels als te veel logregels.
Fout 3: Geen context bij fouten
Een foutmelding als “Order failed” zegt je weinig. Welk symbool? Welke broker? Welke API-call? Zonder context duur je lang om het probleem te vinden, zeker als je meerdere bots draait op verschillende exchanges.
Je verliest tijd en je riskeert verkeerde beslissingen. Context betekent: symbol, order_id, timestamp, broker, account, eventuele parameters. Log dit altijd bij een error of warning.
Zo weet je direct wat er misging en waar. Voeg een extra veld toe aan je logformat: “%(symbol)s %(broker)s %(order_id)s”.
Stel je voor: je logt “Order failed” zonder symbool. Je moet door 500 regels scrollen om te zien dat het om ETH-BTC ging, bij exchange X, tijdens een hoge spread. Tijdverspilling. Met context weet je het in 5 seconden.
Bij een fout log je de volledige traceback én je eigen context. Gebruik structlog of een simpele dict voor extra duidelijkheid. Probeer dit: bij een error, log ook de laatste market data, je posities en bereken voor de zekerheid je logaritmische returns vs simpele returns in Python. Zo krijg je een compleet beeld en los je sneller op.
Fout 4: Logging blokkeert je bot
Logging lijkt onschuldig, maar als je synchronistisch naar een bestand schrijft, kan het je event loop blokkeren. Je bot mist een websocket-update en daardoor een order.
Zeker bij Python bots die draaien op asyncio of multithreading, merk je dat snel. Als je daarnaast 80+ technische indicatoren met FinTA berekent, loopt je bot vast op piekmomenten. Oplossing: gebruik asynchrone logging of schrijf naar een queue.
De logging-module ondersteunt dit met QueueHandler en QueueListener. Zo blijft je bot responsief, zelfs als je veel logt.
Een trader draaide een bot op Kraken met een WebSocket-stream. Zijn synchrone logging zorgde voor een kleine vertraging per tick. Na een uur had hij een backlog van seconden en miste hij een entry met €80 winst. Met QueueHandler was dat voorkomen.
Stel een queue in en start een aparte listener die de logs wegschrijft. Je bot blijft draaien en de logs worden netjes afgehandeld. Dit is vooral handig als je meerdere threads gebruikt of een event loop zoals asyncio. Test je bot onder load.
Kijk of je logs bijblijven en of je bot soepel blijft draaien. Pas je logging aan als je merkt dat het bottlenecks veroorzaakt.
Fout 5: Gevoelige data in logs
Je logt per ongeluk je API-sleutel of privédata. Dat is riskant. Als je logs in de cloud opslaat of deelt met collega’s, loop je veiligheidsrisico’s.
Bovendien overtreed je mogelijk regels van je broker of exchange. Log nooit volledige API-sleutels, wachtwoorden of persoonlijke data. Anonimiseer waar nodig. Gebruik een veilige opslag voor gevoelige info en log alleen een referentie, zoals “account_id: 12345”.
Gebruik filters of vervangende strings. Bijvoorbeeld: vervang “key=abc123” door “key=***”.
Een trader deelde een logbestand met een forum om hulp te vragen. Per ongeluk stond er een API-key in. Binnen een uur was die key misbruikt. Sindsdien scant hij elke log op gevoelige data voordat hij het deelt.
Gebruik een formatter die gevoelige velden herkent en maskert. Test je logs regelmatig op onbedoelde data. Zorg dat je logopslag beveiligd is. Gebruik encrypted volumes of een beveiligde bucket. Zo blijft je data veilig en voldoe je aan compliance.
Fout 6: Geen gestructureerde logs
Logregels in vrije tekst zijn moeilijk te doorzoeken. Je zoekt naar een specifieke order en je moet met grep door 10.000 regels.
Dat traag en foutgevoelig. Zonder structuur kun je geen dashboards bouwen of alerts instellen.
Gebruik gestructureerde logging. Voeg velden toe als JSON, zodat je later kunt filteren op symbool, broker, order_id of status. Tools zoals ELK (Elasticsearch, Logstash, Kibana) of Grafana Loki helpen hierbij.
Een trader met 3 bots op verschillende exchanges had chaos in zijn logs. Na overstap op JSON-logging bouwde hij een simpel dashboard in Grafana. Nu ziet hij in één oogopslag welke bot welk symbool trade en waar errors optreden.
Pas je formatter aan naar JSON. Log bijvoorbeeld: {“time”: “2025-04-01T10:00:00Z”, “level”: “info”, “symbol”: “ETH-BTC”, “action”: “buy”, “amount”: 0.5, “price”: 0.062}.
Zo kun je snel zoeken en visualiseren. Begin klein: log één bot als JSON en bouw stap voor stap verder. Je zult versteld staan hoeveel inzicht dit geeft.
Fout 7: Geen alerting op fouten
Je logt netjes, maar je mist een alert als er iets misgaat. Je bot crasht en je merkt het pas ’s ochtends.
Of een order mislukt en je ziet het te laat. Zonder alerting loop je geld mis en vertraag je je reactie. Stel eenvoudige alerts in op error- en critical-level.
Gebruik een Telegram- of Slack-bot voor directe notificaties. Een Telegram bot koppelen aan je Python script is ideaal: als een error wordt gelogd, stuur je direct een bericht.
Een trader kreeg om 02:00 een critical-error: een API-timeout bij een grote order. Zijn alert kwam binnen op zijn telefoon. Hij kon handmatig ingrijpen en voorkwam een verlies van €300. Zonder alert had hij pas ’s ochtends gereageerd.
Gebruik een library zoals python-telegram-bot of een webhook. Beperk het aantal alerts om spam te voorkomen. Test je alerting met een paar oefen-errors.
Stel een alert-strategie op: per bot, per exchange, per foutsoort. Zo blijf je bovenop je trades en voorkom je verrassingen.
Checklist: voorkom problemen met logging
- Gebruik niveaus: debug, info, warning, error, critical.
- Rotatie: max 10 MB per bestand, bewaar 5 bestanden.
- Context: log symbool, broker, order_id, timestamp bij elke fout.
- Asynchroon: gebruik QueueHandler om je bot responsief te houden.
- Veiligheid: masker API-sleutels en gevoelige data in logs.
- Structuur: log als JSON voor zoekbaarheid en dashboards.
- Alerting: stel Telegram/Slack in op error en critical.
- Test: draai een korte run en controleer je logbestand op kwaliteit.
Met deze aanpak voelt je bot stabieler en je workflow rustiger. Je bent sneller terug online en je verliest minder trades. Logging is geen extra werk, maar een fundament voor betere trading. Probeer één stap per keer en je ziet snel resultaat.