Ano ang Kailangan ng Trading Bot sa VPS?

Mga kailangan ng trading bot mula sa isang VPS

Sinusuri ang VPS para sa mga trading bot batay sa apat na bagay: awtomatikong bumabalik ba ang process kapag huminto ito, tama ba ang oras ng system, mahirap bang manakaw ang mga API (application programming interface) key, at malalaman mo ba kapag huminto ito. Hindi gaanong mahalaga ang raw speed para sa isang retail bot, dahil ang mabagal na bahagi ng order path ay ang broker mo at ang layo nito, hindi ang host na nagpapatakbo ng iyong Python.

Gabay ito sa engineering. Hindi ito payo sa pananalapi, at walang tinatalakay na strategy.

Ang uptime ay disiplina sa pag-restart, hindi numero sa sales page

Ina-advertise ng bawat host sa mundo ang 99.9 porsiyentong uptime. Inilalarawan ng numerong iyon ang hypervisor, hindi ang bot mo. Maaaring huminto ang bot dahil sa hindi nahawakang exception, websocket na hindi kailanman muling kumokonekta, o OOM (out of memory) killer, habang nananatiling gumagana ang server. Kaya ang kapaki-pakinabang na tanong ay kung ano ang nangyayari sa sampung segundo pagkatapos lumabas ang iyong proseso.

Patakbuhin ang bot bilang isang systemd service at ipaubaya sa init system ang pag-restart. Magagawa ito ng isang unit file sa anim na linya.

[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

Ang StartLimitIntervalSec=0 ang linyang madalas nakakaligtaan. Bilang default, sumusuko ang systemd pagkatapos ng 5 pag-restart sa loob ng 10 segundo at iniiwan ang unit sa failed state nang tuluyan. Ito mismo ang ayaw mong mangyari sa 03:00. Kapag itinakda ito sa 0, dini-disable nito ang rate limit. Kaya patuloy na susubukang mag-restart ang bot na paulit-ulit na nagka-crash, sa halip na tahimik na huminto. Pinipigilan ng RestartSec=10 ang loop na iyon na paulit-ulit na bombahin ng reconnects ang exchange.

Suriin ang file bago mo ito pagkatiwalaan, pagkatapos ay simulan ito:

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

Ang enable ang bahaging nananatili pagkatapos ng reboot, at nangangahulugan ang kernel updates ng mga reboot. Para makita kung tahimik na namamatay ang bot, hingin sa systemd ang restart counter:

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

Ang NRestarts=0 pagkatapos ng isang linggo ay indikasyon ng maayos na bot. Ang NRestarts=812 ay nangangahulugang nagte-trade ka gamit ang prosesong buong gabi na muling kumokonekta. Tinalakay sa pagpapatakbo ng program bilang systemd service ang kumpletong anatomy ng unit file, kabilang ang mga timer para sa mga naka-schedule na trabaho gaya ng daily report.

Itakda ang orasan sa UTC at patunayang naka-synchronize ito

Nagse-sign ang Exchange APIs ng mga request gamit ang timestamp at tinatanggihan ang anumang lumampas sa window, na kadalasan ay 5 segundo o mas maikli. Nagdudulot ang lumilihis na orasan ng mga error na mukhang authentication failure, kaya ilang oras na nagro-rotate ng mga key ang mga tao bago tingnan ang oras. Sa mga Binance-style API, literal ang mensahe: Timestamp for this request was 1000ms ahead of the server's time.

Itakda ang server sa UTC. Nagdudulot ang mga lokal na time zone ng daylight saving jump na maaaring mangyari sa gitna ng trading session.

sudo timedatectl set-timezone UTC
timedatectl

Kasama sa Ubuntu ang systemd-timesyncd, isang SNTP (simple network time protocol) client. Sapat ito para sa mga log ngunit hindi maaasahan para sa anumang kailangang manatili sa loob ng ilang millisecond, dahil isang server lang ang kine-query nito at hindi nito patuloy na dini-disiplina ang orasan. Sa halip, gamitin ang chrony:

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

Ang linyang dapat basahin mula sa chronyc tracking ay System time, halimbawa System time : 0.000031415 seconds fast of NTP time. Malusog ang anumang mas mababa sa ilang millisecond. Kung Leap status : Not synchronised ang mabasa, hindi pa nakakaabot ang chrony sa isang server, karaniwan dahil naka-block ang outbound UDP 123. Maghintay ng isang minuto, pagkatapos ay suriin muli bago baguhin ang mga firewall rule.

Panatilihin ang mga API key sa labas ng mga lugar na kinokopyahan mo

Mas malala ang na-leak na exchange key kaysa sa na-leak na SSH key, dahil kapag may withdrawal permission ito, agad itong nagiging pera. Kadalasan, sapat na ang dalawang gawi para mabawasan ang panganib.

Una, huwag kailanman magbigay ng withdrawal permission sa bot key. Kung sinusuportahan ito ng exchange, i-bind ang key sa IP address ng server mo. Ito ang pinakamahalagang control na halos nagpapawalang-silbi sa ninakaw na key.

Ikalawa, panatilihin ang secret sa labas ng code directory. Anumang nasa loob ng /opt/tradingbot ay kalaunan mapupunta sa git repository o backup archive. Ilagay ito sa file na pagmamay-ari ng root at systemd lamang ang nagbabasa:

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

Ang file ay naglalaman ng mga plain KEY=value line na walang quotes at walang export. Sa mode 640 at group na bot, mababasa ito ng service user at walang iba. I-verify gamit ang sudo -u bot cat /etc/tradingbot/api.env, at pagkatapos ay gamit ang ibang user, kung saan dapat mabigo ito gamit ang Permission denied.

Hindi dapat tumakbo ang bot bilang root o bilang login user mo. Gumawa ng system account na walang shell at walang home directory na maaaring pag-login-an:

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

Ipinaliwanag sa pagpapatakbo ng mga service bilang unprivileged user ang dahilan ng bawat flag na iyon at kung gaano kalawak ang aktuwal na saklaw ng ProtectSystem=strict. Ang iba pang server baseline, kabilang ang SSH key at firewall, ay dapat ilagay sa unang sampung minuto sa bagong VPS.

Alamin kung down na ito bago malaman ng broker

Sinasabi ng systemctl status na tumatakbo ang proseso. Hindi nito sinasabi na may ginagawa ang bot. Ang prosesong na-stuck sa retry loop laban sa patay na websocket ay nakakapasa sa lahat ng check na kayang gawin ng systemd.

Sa halip, gumamit ng heartbeat. May push monitor ang Uptime Kuma: inaasahan nitong tatawag ang bot sa isang URL ayon sa iskedyul, at magpapadala ito ng alert kapag hindi na dumarating ang mga tawag. Ilagay ang tawag sa dulo ng main loop, pagkatapos ng bahaging nagpapatunay na buhay ang bot, gaya ng matagumpay na pagbasa ng market data.

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

Itakda ang pagitan ng monitor sa humigit-kumulang dalawang beses ng tagal ng loop para hindi ka ma-page dahil sa karaniwang jitter. Patakbuhin ang monitor sa ibang server kaysa sa bot, dahil walang iuulat ang monitor kapag namatay ito kasabay ng mino-monitor nito. Saklaw ng self-hosted status monitoring gamit ang Uptime Kuma ang setup.

Magdagdag din ng disk alert. Mapupuno ng bot na nagsusulat ng detalyadong log ang root filesystem sa loob ng ilang linggo, at kapag puno ang disk, napipigilan ang database write, hindi ang network call, kaya nagiging kakaiba ang mga sintomas. Nililimitahan ng journalctl --vacuum-time=14d at isang linyang SystemMaxUse= sa /etc/systemd/journald.conf ang laki ng journal.

Ang tapat na bahagi: kadalasan, hindi ang iyong host ang pinagmumulan ng latency

Dito nawawala ang teknikal na batayan ng market para sa mga trading VPS product. Nagbabanggit ang mga marketing page ng mga value na mas mababa sa isang millisecond at ipinahihiwatig na ang host ang nasa pagitan mo at ng pagkaka-fill ng order. Para sa halos lahat ng retail bot, hindi ito totoo.

Naglalakbay ang order mo mula sa bot papunta sa exchange o broker endpoint gamit ang public internet. Ang path na ito ay pangunahing naaapektuhan ng pisikal na distansya at ng peering sa pagitan ng provider mo at provider nila. Ang isang server sa Frankfurt na kumokonekta sa endpoint sa Tokyo ay may humigit-kumulang 250 milliseconds na round trip, gaano man kabilis ang CPU. Pagkatapos, idinadagdag ng sariling mga system ng broker ang queue, risk checks, at rate limits nila. Para sa isang retail account, karaniwang nasa sampu o daan-daang milliseconds ang mga ito.

Sukatin ito sa halip na manghula. Iniuulat ng curl ang connection at first-byte time para sa isang aktuwal na endpoint:

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

Patakbuhin ito mula sa candidate server bago ka magpasya. Kung ang connect ay 0.180 seconds, nasa maling kontinente ka, at dapat itong ayusin. Kung ang connect ay 0.004 seconds at ang ttfb ay 0.140 seconds, ang natitirang delay ay nagmumula sa processing ng broker, at walang pagpapalit ng host ang makapagbabago nito.

Kailan mahalaga ang host? Kapag colocated o cross-connected ka sa venue at nakikipagkumpitensya sa queue position. Ibang negosyo ito at iba rin ang budget. Mahalaga rin ang host kapag ang sarili mong code ang bottleneck. Ang bot na muling nagko-compute ng indicators sa buong history sa bawat tick ay maaaring gumamit ng 200 milliseconds ng CPU sa bawat loop. Totoong latency ito na kaya mong kontrolin nang walang dagdag na gastos. I-profile muna ang loop bago maghanap ng mas mabilis na server.

Ang mahalaga sa host na pipiliin mo ay ang lokasyon, stable na networking, at sapat na memory upang hindi kailanman magkaroon ng pagkakataong makialam ang OOM killer. Noong July 2026, komportableng tumatakbo sa 2 GB ng RAM at 2 vCPU ang isang Python bot na may iisang strategy at ilang daang symbol na nasa memory. Magdagdag ng memory kung nag-iimbak ka ng tick history sa isang local database.

Maikling checklist bago ang live deployment

1. Nagpi-print ang systemctl is-enabled tradingbot ng enabled, at nagpapatuloy ang serbisyo pagkatapos ng sudo reboot.
2. Nag-uulat ang chronyc tracking ng system time offset na mas mababa sa ilang milliseconds.
3. May trading permission ang API key, walang withdrawal permission, at may IP allowlist kung nag-aalok nito ang exchange.
4. Kapag winakasan ang proseso gamit ang sudo systemctl kill -s SIGKILL tradingbot, bumabalik ito sa loob ng RestartSec.
5. Nagpapadala sa iyo ng page ang heartbeat monitor sa loob ng isang interval kapag sinadya mong ihinto ang bot.
6. May limitasyon ang laki ng mga log, at may sapat na bakanteng espasyo ang root filesystem sa df -h.

Patakbuhin ang buong setup sa sandbox ng exchange o sa paper mode sa loob ng isang linggo bago gumamit ng totoong pondo. Bumabagsak nang kahit isang beses ang bawat item sa itaas sa loob ng linggong iyon. Iyon ang layunin ng linggong ito.

FAQ

Kailangan ba ng trading bot ng low-latency o bare metal server?

Kailangan lamang kung nakikipagkumpitensya ka sa bilis ng execution laban sa ibang automated participant sa parehong venue. Karaniwang colocation ang kailangan dito, hindi general-purpose VPS. Para sa retail bot, karaniwang geography at sariling processing ng broker ang pangunahing nakaaapekto sa round trip. Pumili ng server na malapit sa API endpoint at magsukat gamit ang curl at mtr bago magbayad para sa mas mabilis na serbisyo.

Gaano karaming RAM at CPU ang kailangan ng trading bot?

Karamihan sa mga bot na gumagamit ng iisang strategy ay network-bound at idle sa pagitan ng mga event. Noong July 2026, sapat ang 2 vCPU at 2 GB ng RAM para sa isang Python bot na sumusubaybay sa ilang daang instrumento. Nagiging constraint ang memory kapag pinananatili mo sa process ang tick history o nagpapatakbo ka ng local database. Kaya i-monitor ang free -h at journal para sa mga mensaheng OOM kill sa halip na manghula.

Bakit nire-reject ng exchange API ko ang mga request na may timestamp error?

Lumampas ang drift ng server clock sa signing window ng exchange, karaniwan nang ilang segundo. I-install ang chrony, kumpirmahing ipinapakita ng chronyc tracking ang maliit na System time offset at synchronized leap status, at itakda ang machine sa UTC upang hindi ito mailipat ng daylight saving change. Hindi maaayos ng pag-rotate ng API key ang problema sa clock.

Paano ko mapipigilan na mamatay ang bot ko overnight nang hindi ko nalalaman?

Patakbuhin ito gamit ang systemd at Restart=always at StartLimitIntervalSec=0 upang patuloy na mag-retry ang crash loop sa halip na tuluyang huminto. Pagkatapos, magdagdag ng heartbeat na ipinapadala ng bot sa dulo ng bawat matagumpay na loop. Ang restart ang humahawak sa process. Nahuhuli ng heartbeat ang sitwasyong buhay ang process ngunit stuck.

Maaari ko bang patakbuhin ang bot at monitoring ko sa parehong VPS?

Maaari, ngunit magsisinungaling sa iyo ang monitoring sa araw na pinakamahalaga ito. Kapag nagdulot ng outage ang paghinto ng bot, mawawala rin ang monitor. Ilagay ang alerting sa hiwalay na machine, mas mabuti kung ibang provider o region, at gamitin ang server ng bot para lamang sa bot at mga log nito.