ٹریڈنگ بوٹ کے لیے VPS میں اصل اہم چیزیں کیا ہیں؟

ٹریڈنگ بوٹ کو VPS سے کیا درکار ہے

ٹریڈنگ بوٹ کے لیے VPS کو چار امور کی بنیاد پر جانچا جاتا ہے: کیا process بند ہونے کے بعد دوبارہ چلتا ہے، کیا clock درست ہے، کیا API (application programming interface) keys کو چرانا مشکل ہے، اور کیا آپ کو معلوم ہو جاتا ہے کہ بوٹ کب رک گیا۔ retail بوٹ کے لیے خام رفتار اس فہرست میں بہت نیچے ہے، کیونکہ آپ کے order path کا سست حصہ broker اور اس تک network distance ہے، نہ کہ وہ host جس پر آپ کا Python چل رہا ہے۔

یہ ایک engineering guide ہے۔ اس میں مالی مشورہ شامل نہیں، اور کسی strategy پر گفتگو نہیں کی گئی۔

اپ ٹائم سیلز پیج پر درج کوئی عدد نہیں، بلکہ ری اسٹارٹ کا نظم ہے

دنیا کا ہر host 99.9 فیصد اپ ٹائم کی تشہیر کرتا ہے۔ یہ عدد hypervisor کو بیان کرتا ہے، آپ کے bot کو نہیں۔ کسی unhandled exception، دوبارہ کبھی reconnect نہ ہونے والے websocket، یا OOM (out of memory) killer کی وجہ سے bot بند ہو جاتا ہے، جبکہ server پورا وقت چلتا رہتا ہے۔ اس لیے مفید سوال یہ ہے کہ آپ کے process کے exit ہونے کے بعد دس سیکنڈ میں کیا ہوتا ہے۔

bot کو systemd service کے طور پر چلائیں اور restart کا اختیار init system کو دیں۔ ایک unit file یہ کام چھ لائنوں میں کرتی ہے۔

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 وہ لائن ہے جسے لوگ نظرانداز کر دیتے ہیں۔ بطور ڈیفالٹ systemd، 10 سیکنڈ میں 5 restarts کے بعد کوشش چھوڑ دیتا ہے اور unit کو ہمیشہ failed state میں رکھتا ہے۔ 03:00 بجے آپ کو بالکل یہی رویہ نہیں چاہیے۔ اسے 0 پر سیٹ کرنے سے rate limit غیر فعال ہو جاتی ہے، اس لیے مسلسل crash-loop کرنے والا bot خاموش رہنے کے بجائے دوبارہ کوشش کرتا رہتا ہے۔ RestartSec=10 اس loop کو exchange پر مسلسل reconnects بھیجنے سے روکتا ہے۔

فائل پر بھروسا کرنے سے پہلے اسے چیک کریں، پھر اسے شروع کریں:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable وہ حصہ ہے جو reboot کے بعد بھی برقرار رہتا ہے، اور kernel updates کا مطلب reboot ہوتا ہے۔ یہ دیکھنے کے لیے کہ آیا bot خاموشی سے بند ہوتا رہا ہے، systemd سے restart counter طلب کریں:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

ایک ہفتے کے بعد NRestarts=0 صحت مند bot کی علامت ہے۔ NRestarts=812 کا مطلب ہے کہ آپ پوری رات reconnect ہونے والے process پر trading کرتے رہے ہیں۔ مکمل unit file کی ساخت، جس میں روزانہ report جیسے scheduled jobs کے لیے timers بھی شامل ہیں، systemd service کے طور پر program چلانا میں بیان کی گئی ہے۔

گھڑی کو UTC پر سیٹ کریں اور ثابت کریں کہ یہ ہم وقت ساز ہے

Exchange APIs درخواستوں پر timestamp سے دستخط کرتی ہیں اور مقررہ ونڈو سے باہر کی ہر درخواست مسترد کر دیتی ہیں، جو اکثر 5 seconds یا اس سے کم ہوتی ہے۔ گھڑی کے وقت میں مسلسل فرق ایسی errors پیدا کرتا ہے جو authentication failures معلوم ہوتی ہیں، اس لیے لوگ وقت چیک کرنے سے پہلے کئی گھنٹوں تک keys تبدیل کرتے رہتے ہیں۔ Binance-style APIs پر پیغام واضح ہوتا ہے: Timestamp for this request was 1000ms ahead of the server's time۔

سرور کو UTC پر سیٹ کریں۔ مقامی time zones میں daylight saving کی ایسی تبدیلی آ سکتی ہے جو trading session کے دوران واقع ہو۔

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu کے ساتھ systemd-timesyncd آتا ہے، جو SNTP (simple network time protocol) client ہے۔ یہ logs کے لیے مناسب ہے، لیکن ایسی چیزوں کے لیے کمزور ہے جن میں وقت کا فرق چند milliseconds کے اندر رہنا ضروری ہو، کیونکہ یہ ایک server سے poll کرتا ہے اور گھڑی کو مسلسل درست نہیں کرتا۔ اس کے بجائے chrony استعمال کریں:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

chronyc tracking سے پڑھی جانے والی لائن System time ہے، مثلاً System time : 0.000031415 seconds fast of NTP time۔ چند milliseconds سے کم قدر صحت مند ہے۔ اگر اس میں Leap status : Not synchronised پڑھا جائے تو chrony ابھی کسی server تک نہیں پہنچا، عموماً اس لیے کہ outbound UDP 123 مسدود ہے۔ ایک minute انتظار کریں، پھر firewall rules میں تبدیلی کرنے سے پہلے دوبارہ چیک کریں۔

API keys کو ان جگہوں سے دور رکھیں جہاں سے آپ کاپی کرتے ہیں

لیک ہونے والی exchange key، لیک ہونے والی SSH key سے زیادہ خطرناک ہوتی ہے، کیونکہ withdrawal کی اجازت اسے فوراً رقم میں تبدیل کر دیتی ہے۔ دو عادات زیادہ تر خطرے کو کم کر دیتی ہیں۔

اول، bot key کو کبھی withdrawal کی اجازت نہ دیں۔ جہاں exchange یہ سہولت فراہم کرے، key کو اپنے server کے IP address کے ساتھ پابند کریں۔ یہ وہ واحد کنٹرول ہے جو چوری شدہ key کو تقریباً بے کار بنا دیتا ہے۔

دوم، secret کو code directory سے باہر رکھیں۔ /opt/tradingbot کے اندر موجود ہر چیز بالآخر git repository یا backup archive میں شامل ہو جاتی ہے۔ اسے root-owned فائل میں رکھیں جسے صرف systemd پڑھ سکے:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

فائل میں سادہ KEY=value لائنیں ہوں، جن میں quotes یا export نہ ہوں۔ group bot کے ساتھ mode 640 رکھنے سے service user فائل پڑھ سکتا ہے اور کوئی دوسرا اسے نہیں پڑھ سکتا۔ sudo -u bot cat /etc/tradingbot/api.env سے تصدیق کریں، پھر کسی دوسرے user کے ساتھ بھی آزمائیں؛ وہاں یہ عمل Permission denied کے ساتھ ناکام ہونا چاہیے۔

bot کو root یا اپنے login user کے طور پر نہیں چلنا چاہیے۔ ایسا system account بنائیں جس میں shell نہ ہو اور جس کا home directory نہ ہو، تاکہ اس میں login نہ کیا جا سکے:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

ان flags کی وجوہات اور ProtectSystem=strict کی اصل حد تک تفصیل غیر مراعات یافتہ user کے طور پر services چلانا میں موجود ہے۔ server کی باقی بنیادی ترتیب، یعنی SSH keys اور firewall، نئے VPS پر پہلے دس منٹ میں شامل ہے۔

اپنے بروکر سے پہلے معلوم کریں کہ یہ بند ہے

systemctl status بتاتا ہے کہ عمل چل رہا ہے۔ یہ نہیں بتاتا کہ bot کوئی کام کر رہا ہے۔ ایک مردہ websocket کے خلاف retry loop میں پھنسا ہوا عمل systemd کی ہر ممکنہ جانچ میں کامیاب ہو سکتا ہے۔

اس کے بجائے heartbeat استعمال کریں۔ Uptime Kuma میں push monitors موجود ہیں۔ یہ توقع کرتا ہے کہ آپ کا bot مقررہ وقفے سے ایک URL کو call کرے گا، اور جب یہ call آنا بند ہو جائے تو alert بھیجے گا۔ یہ call اپنے main loop کے آخر میں شامل کریں، اس حصے کے بعد جو ثابت کرتا ہے کہ bot فعال ہے، مثلاً market data کو کامیابی سے پڑھنے کے بعد۔

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Monitor کا interval اپنے loop time سے تقریباً دو گنا مقرر کریں، تاکہ معمولی jitter کی وجہ سے آپ کو page نہ کیا جائے۔ Monitor کو bot سے مختلف server پر چلائیں، کیونکہ جو monitor اس چیز کے ساتھ ہی بند ہو جائے جس کی وہ نگرانی کرتا ہے، وہ کچھ بھی report نہیں کرتا۔ Setup کی تفصیل Uptime Kuma کے ساتھ self-hosted status monitoring میں موجود ہے۔

Disk alert بھی شامل کریں۔ تفصیلی logs لکھنے والا bot چند ہفتوں میں root filesystem بھر دے گا۔ مکمل disk database write کو روک دیتی ہے، network call کو نہیں، اس لیے علامات غیر واضح ہوتی ہیں۔ journalctl --vacuum-time=14d اور SystemMaxUse= کی ایک line، /etc/systemd/journald.conf میں journal کا حجم محدود رکھتی ہے۔

دیانت دارانہ بات: زیادہ تر تاخیر آپ کے host کی وجہ سے نہیں ہوتی

یہ وہ مقام ہے جہاں trading VPS مصنوعات کی مارکیٹ تکنیکی نہیں رہتی۔ مارکیٹنگ صفحات sub-millisecond اعداد و شمار پیش کرتے ہیں اور یہ تاثر دیتے ہیں کہ fill تک پہنچنے میں رکاوٹ آپ کا host ہے۔ تقریباً ہر retail bot کے لیے ایسا نہیں ہے۔

آپ کا order bot سے exchange یا broker endpoint تک public internet کے ذریعے جاتا ہے۔ اس راستے پر physical distance اور آپ کے provider اور ان کے provider کے درمیان peering کا غالب اثر ہوتا ہے۔ Frankfurt میں موجود server جب Tokyo کے endpoint سے رابطہ کرتا ہے تو CPU کی رفتار سے قطع نظر تقریباً 250 milliseconds round trip لیتا ہے۔ اس کے بعد broker کے اپنے systems اپنی queue، risk checks اور rate limits شامل کرتے ہیں، جو retail account کے لیے عموماً دسیوں یا سینکڑوں milliseconds میں ناپے جاتے ہیں۔

اندازہ لگانے کے بجائے پیمائش کریں۔ curl کسی حقیقی endpoint کے لیے connection اور first-byte times دکھاتا ہے:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

فیصلہ کرنے سے پہلے اسے candidate server سے چلائیں۔ اگر connect 0.180 seconds ہے تو آپ غلط continent میں ہیں، اور اسے درست کرنا مفید ہوگا۔ اگر connect 0.004 seconds اور ttfb 0.140 seconds ہے تو باقی تاخیر broker کی processing کی وجہ سے ہے، اور host تبدیل کرنے سے اس پر کوئی اثر نہیں پڑے گا۔

تو host کب اہم ہوتا ہے؟ جب آپ venue کے ساتھ colocated یا cross-connected ہوں اور queue position کے لیے مقابلہ کر رہے ہوں۔ یہ ایک مختلف بجٹ والا مختلف کاروبار ہے۔ host اس وقت بھی اہم ہوتا ہے جب bottleneck آپ کا اپنا code ہو۔ ایسا bot جو ہر tick پر مکمل history کے indicators دوبارہ calculate کرتا ہے، ہر loop میں CPU کے 200 milliseconds صرف کر سکتا ہے۔ یہ حقیقی latency ہے جسے آپ بغیر اضافی لاگت کے کم کر سکتے ہیں۔ زیادہ تیز server تلاش کرنے سے پہلے loop کو profile کریں۔

آپ کے منتخب کردہ host میں geography، stable networking، اور اتنی memory اہم ہے کہ OOM killer کو کبھی فیصلہ کرنے کا موقع نہ ملے۔ July 2026 تک، چند سو symbols کو memory میں رکھنے والا single-strategy Python bot 2 GB of RAM اور 2 vCPU میں آسانی سے چلتا ہے۔ اگر آپ tick history کو local database میں رکھتے ہیں تو مزید memory شامل کریں۔

لائیو کرنے سے پہلے مختصر چیک لسٹ

1. systemctl is-enabled tradingbot، enabled پرنٹ کرتا ہے، اور سروس sudo reboot کے بعد بھی چلتی رہتی ہے۔
2. chronyc tracking سسٹم کے وقت کا آفسیٹ چند ملی سیکنڈ سے کم ظاہر کرتا ہے۔
3. API key کو trading کی اجازت حاصل ہے، withdrawal کی اجازت نہیں ہے، اور اگر exchange یہ سہولت فراہم کرتا ہو تو IP allowlist بھی فعال ہے۔
4. sudo systemctl kill -s SIGKILL tradingbot کے ذریعے process ختم کرنے پر وہ RestartSec کے اندر دوبارہ چل جاتا ہے۔
5. جب آپ bot کو جان بوجھ کر روک دیتے ہیں تو heartbeat monitor ایک interval کے اندر آپ کو page بھیج دیتا ہے۔
6. Logs کی حد مقرر ہے، اور df -h میں root filesystem پر کافی خالی جگہ موجود ہے۔

حقیقی funds استعمال کرنے سے پہلے پورے نظام کو exchange کے sandbox یا paper mode میں ایک ہفتے تک چلائیں۔ اس ہفتے میں اوپر دی گئی ہر شے کم از کم ایک بار ناکام ہوگی؛ یہی اس ہفتے کا مقصد ہے۔

FAQ

کیا trading bot کو کم تاخیر والے یا bare metal server کی ضرورت ہوتی ہے؟

صرف اس صورت میں جب آپ اسی venue پر موجود دیگر خودکار شرکا کے مقابلے میں execution speed پر مسابقت کر رہے ہوں۔ ایسی صورت میں عموماً general purpose VPS کے بجائے colocation درکار ہوتی ہے۔ retail bot کے لیے round trip پر geography اور broker کی اپنی processing کا زیادہ اثر ہوتا ہے۔ اس لیے API endpoint کے قریب server منتخب کریں، اور زیادہ تیز server کے لیے ادائیگی کرنے سے پہلے curl اور mtr سے پیمائش کریں۔

trading bot کو کتنی RAM اور CPU درکار ہوتی ہے؟

زیادہ تر single-strategy bots network-bound ہوتے ہیں اور events کے درمیان idle رہتے ہیں۔ July 2026 تک، 2 vCPU اور 2 GB RAM چند سو instruments کو track کرنے والے Python bot کے لیے کافی ہیں۔ جب آپ tick history کو process میں رکھتے ہیں یا local database چلاتے ہیں تو memory رکاوٹ بن سکتی ہے۔ اس لیے اندازہ لگانے کے بجائے free -h اور journal میں OOM kill messages کو monitor کریں۔

میری exchange API timestamp error کے ساتھ requests کیوں مسترد کرتی ہے؟

server clock exchange کی signing window سے باہر drift کر گئی ہے، جو عموماً چند seconds ہوتی ہے۔ chrony install کریں، تصدیق کریں کہ chronyc tracking میں معمولی System time offset اور synchronised leap status ظاہر ہو، اور machine کو UTC پر set کریں تاکہ daylight saving change سے وقت کبھی نہ بدلے۔ API key rotate کرنے سے clock کا مسئلہ حل نہیں ہوتا۔

میں اپنے bot کو رات بھر میرے علم کے بغیر بند ہونے سے کیسے روکوں؟

اسے systemd کے تحت Restart=always اور StartLimitIntervalSec=0 کے ساتھ چلائیں تاکہ crash loop مستقل طور پر رکنے کے بجائے دوبارہ کوشش کرتا رہے۔ پھر heartbeat شامل کریں، جو bot کے ہر کامیاب loop کے اختتام پر بھیجے۔ restart process کو سنبھالتا ہے۔ heartbeat اس صورت کی نشاندہی کرتا ہے جب process زندہ ہو لیکن stuck ہو۔

کیا میں bot اور اپنی monitoring ایک ہی VPS پر چلا سکتا ہوں؟

آپ چلا سکتے ہیں، لیکن اہم دن monitoring آپ کو غلط معلومات دے گی، کیونکہ bot کو بند کرنے والی outage monitor کو بھی بند کر دے گی۔ alerting کو الگ machine پر رکھیں، بہتر ہے کہ مختلف provider یا region استعمال کریں، اور bot کے server کو صرف bot اور اس کے logs کے لیے استعمال کریں۔