VPS para sa Trading Bot: Ano Talaga ang Mahalaga

Ano ang kailangan ng isang trading bot mula sa VPS

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

Gabay ito sa engineering. Hindi ito financial advice, at walang tinatalakay na strategy.

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

Sinasabing may 99.9 percent uptime ang bawat host sa mundo. Inilalarawan ng numerong iyon ang hypervisor, hindi ang bot mo. Maaaring huminto ang bot dahil sa unhandled exception, websocket na hindi muling kumokonekta, o OOM (out of memory) killer, habang nananatiling gumagana ang server. Kaya ang mahalagang tanong ay kung ano ang nangyayari sa loob ng sampung segundo matapos lumabas ang proseso mo.

Patakbuhin ang bot bilang 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

StartLimitIntervalSec=0 ang linyang madalas nakakaligtaan. Bilang default, sumusuko ang systemd matapos ang 5 restart sa loob ng 10 segundo at iniiwan ang unit sa failed state magpakailanman. Ito mismo ang behavior na ayaw mo sa 03:00. Kapag itinakda ito sa 0, dini-disable ang rate limit. Kaya patuloy na susubukan ng bot na mag-restart kapag paulit-ulit itong nagka-crash, sa halip na tahimik na huminto. Pinipigilan naman ng RestartSec=10 ang loop na iyon na paulit-ulit na mag-reconnect sa exchange.

Suriin muna 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

enable ang bahaging nananatili matapos ang reboot, at nangangailangan ng reboot ang kernel updates. Para malaman kung tahimik na paulit-ulit 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 pagkalipas ng isang linggo ay indikasyon ng maayos na bot. Ang NRestarts=812 ay nangangahulugang nagte-trade ka gamit ang prosesong buong gabing paulit-ulit na kumokonekta. Tinalakay sa pagpapatakbo ng isang program bilang systemd service ang buong anatomy ng unit file, kasama ang timers para sa mga naka-schedule na job gaya ng daily report.

Itakda ang oras sa UTC at patunayang naka-synchronize ito

Nagse-sign ang mga Exchange API ng mga request gamit ang timestamp at nire-reject ang anumang lampas sa itinakdang window, na kadalasang 5 segundo o mas maikli. Nagdudulot ang clock drift ng mga error na mukhang authentication failure, kaya ilang oras na nagro-rotate ng keys ang mga tao bago suriin 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 local time zone ng daylight saving jump na maaaring mangyari sa kalagitnaan 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 para sa anumang kailangang manatili sa loob ng ilang millisecond, dahil isang server lang ang tina-poll nito at hindi nito patuloy na dini-disiplina ang clock. 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. Healthy ang anumang mas mababa sa ilang millisecond. Kung Leap status : Not synchronised ang nakalagay, hindi pa nakakakonekta ang chrony sa isang server, karaniwan dahil naka-block ang outbound UDP 123. Maghintay ng isang minuto, saka suriin muli bago baguhin ang firewall rules.

Panatilihin ang API keys sa labas ng mga lugar na kinokopya mo

Mas mapanganib ang na-leak na exchange key kaysa sa na-leak na SSH key dahil kapag may withdrawal permission ito, agad itong nagiging pera. Sapat na ang dalawang gawi para matugunan ang karamihan ng 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 para maging halos walang silbi ang nanakaw na key.

Ikalawa, panatilihing nasa labas ng code directory ang secret. Anumang nasa loob ng /opt/tradingbot ay mapupunta sa git repository o backup archive paglipas ng panahon. 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 itong mabigo 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-log-inan:

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

Nasa pagpapatakbo ng mga serbisyo bilang unprivileged user ang paliwanag sa bawat flag na iyon at sa aktuwal na saklaw ng ProtectSystem=strict. Ang iba pang bahagi ng server baseline, gaya ng SSH keys at firewall, ay dapat ilagay sa unang sampung minuto sa bagong VPS.

Alamin kung down na ito bago pa malaman ng broker

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

Gumamit ng heartbeat sa halip. May push monitor ang Uptime Kuma: inaasahan nitong tumawag ang bot sa isang URL ayon sa iskedyul, at nagpapadala ito ng alert kapag tumigil 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 monitor interval sa humigit-kumulang dalawang beses ng loop time upang hindi ka ma-page dahil sa normal na jitter. Patakbuhin ang monitor sa ibang server kaysa sa bot, dahil walang maire-report ang monitor na namamatay kasama ng mino-monitor nito. Tinalakay ang setup sa self-hosted status monitoring gamit ang Uptime Kuma.

Magdagdag din ng disk alert. Mapupuno ng bot na nagsusulat ng verbose logs ang root filesystem sa loob ng ilang linggo, at kapag puno ang disk, database write ang titigil, hindi ang network call, kaya kakaiba ang mga sintomas. Pinananatiling may limit ang journal ng journalctl --vacuum-time=14d at isang linyang SystemMaxUse= sa /etc/systemd/journald.conf.

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

Dito nagiging hindi na teknikal ang market para sa mga trading VPS product. Naglalagay ang mga marketing page ng sub-millisecond na mga numero at ipinahihiwatig na ang host ang hadlang sa 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 sa public internet. Ang path na ito ay pangunahing naaapektuhan ng physical distance at ng peering sa pagitan ng provider mo at ng provider nila. Ang server sa Frankfurt na kumokonekta sa endpoint sa Tokyo ay karaniwang may humigit-kumulang 250 milliseconds na round-trip time, gaano man kabilis ang CPU. Pagkatapos, nagdaragdag ang sariling system ng broker ng queue, risk checks, at rate limits. Para sa 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 times 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 mag-commit. Kung ang connect ay 0.180 seconds, nasa maling continent ka, at sulit itong ayusin. Kung ang connect ay 0.004 seconds at ang ttfb ay 0.140 seconds, ang natitirang delay ay mula sa processing ng broker, at walang pagbabago ng host ang makakaapekto rito.

Kailan mahalaga ang host? Kapag colocated o cross-connected ka sa venue at nakikipagkumpitensya sa queue position. Ibang business ito na may ibang budget. Mahalaga rin ito kapag ang sarili mong code ang bottleneck. Halimbawa, maaaring umabot sa 200 milliseconds ng CPU time bawat loop ang bot na muling nagkakalkula ng indicators sa buong history sa bawat tick. Totoong latency ito na makokontrol mo 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 geography, stable na networking, at sapat na memory upang hindi kailanman magkaroon ng pagkakataong magpasya 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 pinananatili mo ang tick history sa isang local database.

Isang maikling checklist bago i-live

1. Ang systemctl is-enabled tradingbot ay nagpi-print ng enabled, at nananatiling tumatakbo ang service pagkatapos ng sudo reboot.
2. Iniuulat ng chronyc tracking na mas mababa sa ilang millisecond ang offset ng system time.
3. May trading permission ang API key, walang withdrawal permission, at may IP allowlist kung nag-aalok nito ang exchange.
4. Kapag pinatay ang process 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 limit ang laki ng logs, at may sapat na bakanteng espasyo ang root filesystem sa df -h.

Patakbuhin muna ang buong setup sa sandbox ng exchange o sa paper mode sa loob ng isang linggo bago gumamit ng aktuwal na pondo. Hindi bababa sa isang beses mabibigo ang bawat item sa itaas sa loob ng linggong iyon. Iyan ang layunin ng isang linggong test.

FAQ

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

Kailangan lamang ito kung nakikipagkumpitensya ka sa bilis ng execution laban sa ibang automated participant sa parehong venue, na karaniwang nangangahulugan ng colocation sa halip na general-purpose VPS. Para sa retail bot, karaniwang geography at sariling processing ng broker ang may pinakamalaking epekto sa round trip. Kaya pumili ng server na malapit sa API endpoint at magsukat gamit ang curl at mtr bago magbayad para sa mas mabilis na server.

Gaano karaming RAM at CPU ang kailangan ng trading bot?

Karamihan sa single-strategy bot ay network-bound at idle sa pagitan ng mga event. Hanggang July 2026, sapat ang 2 vCPU at 2 GB ng RAM para sa Python bot na sumusubaybay sa ilang daang instrumento. Nagiging constraint ang memory kapag pinapanatili mo sa process ang tick history o nagpapatakbo ka ng local database. Kaya i-monitor ang free -h at ang 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, na karaniwang ilang segundo lamang. Mag-install ng chrony. Kumpirmahing ipinapakita ng chronyc tracking ang maliit na System time offset at synchronized na leap status. Itakda rin ang machine sa UTC upang hindi ito magbago dahil sa daylight saving time. Hindi maaayos ng pag-rotate ng API key ang problema sa clock.

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

Patakbuhin ito sa ilalim ng systemd gamit ang Restart=always at StartLimitIntervalSec=0 upang patuloy itong mag-retry kapag nagka-crash loop sa halip na tuluyang huminto. Pagkatapos, magdagdag ng heartbeat na ipinapadala ng bot sa dulo ng bawat matagumpay na loop. Pinamamahalaan ng restart ang process. Nakikita naman ng heartbeat ang sitwasyong buhay ang process pero stuck ito.

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

Maaari, pero magsisinungaling sa iyo ang monitoring sa araw na pinakamahalaga ito, dahil kapag may outage na nagpabagsak sa bot, kasama nitong mawawala ang monitor. Panatilihin ang alerting sa hiwalay na machine, at kung maaari ay gumamit ng ibang provider o region. Gamitin lamang ang server ng bot para sa bot at mga log nito.