VPS bora kwa ajili ya trading bot: Vigezo muhimu

Mahitaji ya VPS kwa ajili ya trading bot

VPS inayotumika kwa trading bot hupimwa kwa mambo manne: je, mchakato huanza upya baada ya kufa, je, saa iko sahihi, je, API (application programming interface) keys ni ngumu kuibwa, na je, unapata taarifa pale bot inaposimama. Kasi ya CPU si kipaumbele kikubwa kwa bot ya kawaida, kwa sababu sehemu inayochelewesha maagizo yako ni broker na umbali wa seva yake, si seva inayochezesha Python yako.

Huu ni mwongozo wa kiufundi. Hakuna ushauri wa kifedha hapa, na hakuna mkakati wowote unaojadiliwa.

Uptime ni nidhamu ya kuanzisha upya, si namba kwenye ukurasa wa mauzo

Kila seva duniani hutangaza uptime ya asilimia 99.9. Namba hiyo inahusu hypervisor, si bot yako. Bot hufa kutokana na exception isiyoshughulikiwa, websocket inayoshindwa kuunganisha tena, au OOM (out of memory) killer, huku seva ikiwa imewaka muda wote. Kwa hiyo, swali la msingi ni nini kinatokea katika sekunde kumi baada ya mchakato wako kusimama.

Endesha bot kama systemd service na uache mfumo wa init usimamie kuanzisha upya. Faili la unit hufanya hivi kwa mistari sita.

[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 ndio mstari ambao watu husahau. Kwa kawaida, systemd huacha kujaribu baada ya restart 5 ndani ya sekunde 10 na kuiacha unit katika hali ya failed milele, jambo ambalo hutaki litokee saa 03:00. Kuweka thamani hiyo kuwa 0 huzima kikomo cha kasi (rate limit), hivyo bot inayokwama kwenye loop ya crash itaendelea kujaribu badala ya kunyamaza. RestartSec=10 huzuia loop hiyo isifurike maombi ya kuunganisha kwenye exchange.

Kagua faili kabla ya kuliweka kwenye matumizi, kisha uliwashe:

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

enable ndio nusu inayookoka baada ya reboot, na masasisho ya kernel yanamaanisha reboot. Ili kuona kama bot imekuwa ikifa kimya kimya, iulize systemd kuhusu counter ya restart:

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

NRestarts=0 baada ya wiki moja ni ishara ya bot yenye afya. NRestarts=812 inamaanisha umekuwa ukifanya biashara kwa mchakato unaounganisha tena usiku kucha. Muundo kamili wa faili la unit, ikijumuisha vipima muda (timers) kwa ajili ya kazi zilizopangwa kama ripoti ya kila siku, imeelezewa katika kuendesha programu kama systemd service.

Weka saa kwenye UTC na uthibitishe kuwa imesawazishwa

API za kubadilishana fedha (exchange APIs) husaini maombi kwa kutumia timestamp na kukataa chochote kilicho nje ya muda uliopangwa, mara nyingi sekunde 5 au chini ya hapo. Saa inayopoteza usahihi (drifting clock) husababisha makosa yanayoonekana kama kufeli kwa uthibitishaji (authentication failures), hivyo watu huzungusha funguo (rotate keys) kwa saa nyingi kabla ya kuangalia muda. Kwenye API za mtindo wa Binance, ujumbe huwa wa moja kwa moja: Timestamp for this request was 1000ms ahead of the server's time.

Weka seva kwenye UTC. Kanda za saa za ndani (local time zones) huleta mabadiliko ya saa za kiangazi (daylight saving) ambayo yanaweza kutokea katikati ya kipindi cha biashara.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu inakuja na systemd-timesyncd, ambayo ni mteja wa SNTP (simple network time protocol). Hii inafaa kwa logi lakini ni dhaifu kwa chochote kinachohitaji kubaki ndani ya milisekunde chache, kwa sababu hupiga kura (poll) seva moja na haidhibiti saa kwa kuendelea. Tumia chrony badala yake:

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

Mstari wa kusoma kutoka chronyc tracking ni System time, kwa mfano System time : 0.000031415 seconds fast of NTP time. Chochote chini ya milisekunde chache ni salama. Ikiwa inasoma Leap status : Not synchronised, chrony bado haijafikia seva, kwa kawaida kwa sababu UDP 123 ya kutoka nje imezuiwa. Subiri dakika moja, kisha uangalie tena kabla ya kugusa sheria za firewall.

Weka funguo za API mbali na maeneo unayokopi

Ufunguo wa kubadilishana (exchange key) uliovuja ni mbaya zaidi kuliko ufunguo wa SSH uliovuja, kwa sababu idhini ya kutoa fedha huugeuza kuwa pesa papo hapo. Tabia mbili hufunika hatari nyingi.

Kwanza, usitoe kamwe idhini ya kutoa fedha kwa ufunguo wa bot, na pale ambapo exchange inaruhusu, funga ufunguo huo kwenye anwani ya IP ya seva yako. Hii ndiyo hatua pekee ya udhibiti inayofanya ufunguo ulioibwa kuwa karibu kutokuwa na manufaa.

Pili, weka siri hiyo nje ya saraka ya msimbo (code directory). Kitu chochote kilicho ndani ya /opt/tradingbot huishia kwenye git repository au archive ya backup mapema au baadaye. Iweke kwenye faili inayomilikiwa na root ambayo systemd pekee ndiyo inaisoma:

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

Faili hiyo hushikilia mistari ya KEY=value ya kawaida bila alama za kunukuu na bila export. Mode 640 na kundi bot inamaanisha mtumiaji wa huduma anaweza kuisoma na hakuna mwingine anayeweza. Thibitisha kwa sudo -u bot cat /etc/tradingbot/api.env na kisha kwa mtumiaji mwingine yeyote, ambapo lazima ifeli kwa Permission denied.

Bot yenyewe haipaswi kuendeshwa kama root au kama mtumiaji wako wa kuingia (login user). Unda akaunti ya mfumo isiyo na shell na isiyo na saraka ya nyumbani ya kuingia:

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

Sababu za kila moja ya flag hizo, na jinsi ProtectSystem=strict inavyofanya kazi kwa kina, ziko katika kuendesha huduma kama mtumiaji asiye na upendeleo. Msingi mwingine wa seva, funguo za SSH na firewall, unapatikana katika dakika kumi za kwanza kwenye VPS mpya.

Tambua huduma imekufa kabla ya broker wako

systemctl status inaonyesha kuwa mchakato unafanya kazi. Hii haimaanishi kuwa bot inafanya kazi yoyote. Mchakato uliokwama kwenye mzunguko wa kujaribu tena (retry loop) dhidi ya websocket iliyokufa hupita kila ukaguzi ambao systemd inaweza kufanya.

Tumia heartbeat badala yake. Uptime Kuma ina push monitors: inatarajia bot yako iite URL kwa ratiba maalum, na inatoa tahadhari wakati wito huo unapoacha kufika. Weka wito huo mwishoni mwa main loop yako, baada ya sehemu inayothibitisha kuwa bot iko hai, kama vile kusoma data ya soko kwa mafanikio.

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

Weka muda wa monitor kuwa takriban mara mbili ya muda wa loop yako ili jitter ya kawaida isikuletee tahadhari zisizo za lazima. Endesha monitor kwenye seva tofauti na ile ya bot, kwa sababu monitor inayokufa pamoja na kitu inachokifuatilia haitoi taarifa yoyote. Usanidi umeelezwa katika ufuatiliaji wa hali ya huduma uliopo kwenye seva yako kwa kutumia Uptime Kuma.

Ongeza pia tahadhari ya diski. Bot inayoandika logi nyingi itajaza root filesystem ndani ya wiki chache, na diski iliyojaa husimamisha uandishi wa database, si wito wa mtandao, kwa hivyo dalili zake huwa za ajabu. journalctl --vacuum-time=14d na mstari wa SystemMaxUse= katika /etc/systemd/journald.conf huweka kikomo kwa journal.

Ukweli mtupu: latency mara nyingi haisababishwi na seva yako

Hapa ndipo soko la bidhaa za trading VPS linapoacha kuwa la kiufundi. Kurasa za masoko hutoa takwimu za chini ya millisecond na kudokeza kuwa seva ndiyo inayokuzuia kupata oda. Kwa karibu kila bot ya rejareja, si kweli.

Oda yako husafiri kutoka kwa bot kwenda kwenye exchange au endpoint ya broker kupitia mtandao wa umma. Njia hiyo hutawaliwa na umbali wa kijiografia na makubaliano ya peering kati ya mtoa huduma wako na wao. Seva iliyopo Frankfurt inayowasiliana na endpoint ya Tokyo hutumia takriban 250 milliseconds kwa safari ya kwenda na kurudi, bila kujali kasi ya CPU. Kisha, mifumo ya broker huongeza foleni yao, ukaguzi wa hatari, na vikomo vya kasi (rate limits), ambavyo kwa akaunti ya rejareja hupimwa kwa makumi au mamia ya milliseconds.

Pima latency badala ya kukisia. curl huripoti muda wa muunganisho na muda wa kupokea byte ya kwanza kwa endpoint halisi:

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

Tekeleza amri hiyo kutoka kwa seva unayotaka kuikodisha kabla ya kufanya uamuzi. Ikiwa connect ni 0.180 seconds, uko kwenye bara lisilo sahihi, na hilo ni jambo la kurekebisha. Ikiwa connect ni 0.004 seconds na ttfb ni 0.140 seconds, ucheleweshaji uliobaki ni usindikaji wa broker, na hakuna mabadiliko ya seva yatakayosaidia.

Kwa hiyo, seva inakuwa na umuhimu lini? Inapokuwa imewekwa kwenye kituo kimoja (colocated) au imeunganishwa moja kwa moja na soko na unashindania nafasi kwenye foleni, jambo ambalo ni biashara tofauti yenye bajeti tofauti. Pia, inakuwa muhimu wakati code yako ndiyo kikwazo: bot inayokokotoa viashiria upya kwa kutumia historia nzima kila tick inaweza kutumia 200 milliseconds za CPU kwa kila mzunguko, ambayo ni latency halisi unayoweza kuiondoa bila gharama. Fanya profiling ya mzunguko wako kabla ya kutafuta seva yenye kasi zaidi.

Kinachojalisha katika seva unayochagua ni jiografia, mtandao thabiti, na kumbukumbu (RAM) ya kutosha ili OOM killer asipate nafasi ya kuingilia kati. Kufikia Julai 2026, bot ya Python yenye mkakati mmoja na alama (symbols) mia chache kwenye kumbukumbu huendesha vizuri kwa 2 GB ya RAM na 2 vCPU. Ongeza kumbukumbu ikiwa unahifadhi historia ya tick kwenye database ya ndani.

Orodha fupi ya ukaguzi kabla ya kwenda live

1. systemctl is-enabled tradingbot inachapisha enabled, na huduma inaendelea kufanya kazi baada ya sudo reboot.
2. chronyc tracking inaripoti tofauti ya muda wa mfumo (system time offset) ya chini ya milisekunde chache.
3. API key ina ruhusa ya kufanya biashara, haina ruhusa ya kutoa fedha (withdrawal), na ina IP allowlist ikiwa soko la hisa (exchange) linatoa chaguo hilo.
4. Kusitisha mchakato (process) kwa kutumia sudo systemctl kill -s SIGKILL tradingbot kunaufanya uanze upya ndani ya RestartSec.
5. Mfumo wa heartbeat unakutumia ujumbe ndani ya muda wa interval moja unaposimamisha bot kwa makusudi.
6. Logs zina ukomo na root filesystem ina nafasi ya kutosha katika df -h.

Endesha mfumo mzima katika sandbox ya exchange au katika hali ya paper mode kwa wiki moja kabla ya kutumia fedha halisi. Kila kipengele hapo juu kitashindwa angalau mara moja katika wiki hiyo, na hiyo ndiyo maana ya wiki hiyo ya majaribio.

FAQ

Je, trading bot inahitaji seva ya low-latency au bare metal?

Inahitaji hivyo tu ikiwa unashindana kwa kasi ya utekelezaji dhidi ya washiriki wengine wa kiotomatiki kwenye soko hilo hilo, jambo ambalo kwa kawaida linamaanisha colocation badala ya VPS ya kawaida. Kwa bot ya rejareja, muda wa safari ya data (round trip) hutawaliwa na jiografia na usindikaji wa broker mwenyewe, kwa hivyo chagua seva iliyo karibu na API endpoint na upime kwa kutumia curl na mtr kabla ya kulipia huduma ya kasi zaidi.

Trading bot inahitaji kiasi gani cha RAM na CPU?

Bots nyingi za mkakati mmoja hutegemea mtandao na huwa hazifanyi kazi kati ya matukio. Kufikia Julai 2026, 2 vCPU na 2 GB ya RAM zinatosha kuendesha Python bot inayofuatilia mamia machache ya vyombo vya biashara. Kumbukumbu huwa kikwazo unapohifadhi historia ya tick kwenye mchakato (process) au unapoendesha database ya ndani, kwa hivyo fuatilia free -h na journal kwa ajili ya ujumbe wa OOM kill badala ya kukisia.

Kwa nini API ya exchange inakataa maombi yangu kwa kosa la timestamp?

Saa ya seva imepotoka nje ya muda ulioruhusiwa na exchange kwa ajili ya kusaini maombi, ambao kwa kawaida ni sekunde chache. Sakinisha chrony, thibitisha kuwa chronyc tracking inaonyesha System time ndogo na hali ya synchronised leap, na uweke mashine kwenye UTC ili mabadiliko ya saa za msimu (daylight saving) yasiiathiri. Kubadilisha API key hakutatui tatizo la saa.

Ninawezaje kuzuia bot yangu isife usiku bila mimi kujua?

Iendeshe chini ya systemd ukitumia Restart=always na StartLimitIntervalSec=0 ili mzunguko wa crash uendelee kujaribu tena badala ya kusimama kabisa, kisha ongeza heartbeat ambayo bot hutuma mwishoni mwa kila mzunguko uliofanikiwa. Restart hushughulikia mchakato wenyewe. Heartbeat hutambua hali ambapo mchakato unaendelea lakini umekwama.

Je, ninaweza kuendesha bot na ufuatiliaji (monitoring) kwenye VPS moja?

Unaweza, lakini ufuatiliaji huo utakupotosha siku ya tukio muhimu, kwa sababu hitilafu inayozima bot itazima pia mfumo wa ufuatiliaji. Weka mfumo wa tahadhari kwenye mashine tofauti, ikiwezekana kwa mtoa huduma mwingine au eneo lingine, na utumie seva ya bot kwa ajili ya bot na logi zake pekee.