VPS Bora kwa Bot za Trading: Mambo Muhimu

Mahitaji ya bot ya trading kutoka kwa VPS

VPS ya bot za trading hupimwa kwa mambo manne: je, mchakato huanza tena baada ya kusitisha, saa imewekwa kwa usahihi, API (application programming interface) keys zinalindwa dhidi ya kuibiwa, na je, unapata taarifa inapositisha kufanya kazi. Kasi ghafi iko chini sana kwenye orodha hiyo kwa bot ya retail, kwa sababu sehemu inayochelewesha njia ya oda yako ni broker wako na umbali wa kumfikia, si host inayoendesha Python yako.

Huu ni mwongozo wa uhandisi. Hakuna ushauri wa kifedha humu, na hakuna mkakati unaojadiliwa.

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

Kila host duniani hutangaza uptime ya asilimia 99.9. Takwimu hiyo inaelezea hypervisor, si bot yako. Bot hufa kwa sababu ya exception ambayo haikushughulikiwa, websocket ambayo haiunganishi tena, au OOM (out of memory) killer, huku server ikiendelea kufanya kazi muda wote. Kwa hiyo, swali muhimu ni nini hutokea katika sekunde 10 baada ya mchakato wako kutoka.

Endesha bot kama huduma ya systemd na uache mfumo wa init usimamie uanzishaji upya. Faili ya unit hufanya hivyo kwa mistari 6.

[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 ni mstari ambao watu wengi husahau. Kwa chaguo-msingi, systemd huacha kujaribu baada ya kuwasha upya mara 5 ndani ya sekunde 10 na huacha unit katika hali ya failed milele. Huo ndio mwenendo usioutaka saa 03:00. Kuiweka kuwa 0 huzima kikomo cha kasi, kwa hiyo bot inayoingia kwenye mzunguko wa kuanguka huendelea kujaribu badala ya kunyamaza. RestartSec=10 huzuia mzunguko huo kuishambulia exchange kwa majaribio ya kuunganisha tena.

Kagua faili kabla ya kuiamini, kisha iwashe:

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

enable ndiyo sehemu inayodumu baada ya kuwasha upya, na masasisho ya kernel yanamaanisha kuwasha upya. Ili kuona kama bot imekuwa ikifa kimya, iombe systemd ikuonyeshe kaunta ya kuwasha upya:

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

NRestarts=0 baada ya wiki moja inaonyesha bot yenye afya. NRestarts=812 inamaanisha umekuwa ukifanya biashara kwa kutumia mchakato unaounganisha tena usiku mzima. Muundo kamili wa faili ya unit, pamoja na timers za kazi zilizopangwa kama ripoti ya kila siku, umeelezwa katika kuendesha programu kama huduma ya systemd.

Weka saa kuwa UTC na thibitisha kuwa imesawazishwa

API za kubadilishana hutia saini maombi kwa muhuri wa muda na hukataa maombi yaliyo nje ya kipindi kinachoruhusiwa, mara nyingi sekunde 5 au chini. Saa inayotangulia au kuchelewa husababisha makosa yanayoonekana kama kushindwa kwa uthibitishaji, hivyo watu hubadilisha funguo kwa saa nyingi kabla ya kuangalia muda. Kwenye API za mtindo wa Binance, ujumbe huo ni wa moja kwa moja: Timestamp for this request was 1000ms ahead of the server's time.

Weka seva itumie UTC. Majira ya saa ya eneo husababisha mabadiliko ya saa ya kuokoa mwanga wa mchana, ambayo yanaweza kutokea katikati ya kipindi cha biashara.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu huja na systemd-timesyncd, ambayo ni mteja wa SNTP (simple network time protocol). Inafaa kwa kumbukumbu, lakini si bora kwa chochote kinachohitaji kubaki ndani ya milisekunde chache, kwa sababu huuliza seva moja na haisawazishi 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. Thamani iliyo chini ya milisekunde chache ni nzuri. Ikiwa inaonyesha Leap status : Not synchronised, chrony bado haijafikia seva, kwa kawaida kwa sababu UDP 123 ya kutoka imezuiwa. Subiri dakika moja, kisha kagua tena kabla ya kubadilisha sheria za firewall.

Zuia funguo za API zisitoke kwenye maeneo unayonakili

Funguo ya exchange iliyovuja ni hatari zaidi kuliko ufunguo wa SSH uliovuja, kwa sababu ruhusa ya kutoa fedha huifanya pesa itolewe mara moja. Tabia mbili zinatosha kupunguza hatari kubwa.

Kwanza, usiwahi kutoa ruhusa ya kutoa fedha kwa ufunguo wa bot. Exchange inapowezesha, funga ufunguo huo kwenye anwani ya IP ya seva yako. Hiki ndicho kidhibiti kimoja kinachofanya ufunguo ulioibwa ukaribie kutokuwa na matumizi.

Pili, weka siri hiyo nje ya saraka ya msimbo. Kila kitu kilicho ndani ya /opt/tradingbot hatimaye kitaishia kwenye hazina ya git au kumbukumbu ya chelezo. Iweke kwenye faili inayomilikiwa na root ambayo systemd pekee huisoma:

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 ina mistari ya kawaida ya KEY=value bila alama za kunukuu na bila export. Mode 640 yenye group bot inamaanisha kuwa mtumiaji wa huduma anaweza kuisoma na hakuna mtu mwingine anayeweza. Thibitisha kwa sudo -u bot cat /etc/tradingbot/api.env, kisha thibitisha kwa mtumiaji mwingine yeyote; jaribio hilo lazima lishindwe kwa Permission denied.

Bot yenyewe haipaswi kuendeshwa kama root au kama mtumiaji unayetumia kuingia. Unda akaunti ya mfumo isiyo na shell na isiyo na saraka ya home ya kuingia:

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

Maelezo ya kila flag hiyo, na kiwango ambacho ProtectSystem=strict hufanya kazi, yako katika kuendesha huduma kama mtumiaji asiye na haki za ziada. Mipangilio mingine ya msingi ya seva, yaani funguo za SSH na firewall, inapaswa kuwekwa katika dakika kumi za kwanza kwenye VPS mpya.

Jua kuwa imeacha kufanya kazi kabla ya broker wako kujua

systemctl status inaonyesha kuwa mchakato unaendelea. Haimaanishi kuwa bot inafanya kazi yoyote. Mchakato uliokwama katika mzunguko wa majaribio tena dhidi ya websocket iliyokufa unaweza kupita kila ukaguzi ambao systemd inaweza kufanya.

Tumia heartbeat badala yake. Uptime Kuma ina vichunguzi vya push: inatarajia bot yako iite URL kwa ratiba, kisha itume arifa simu hizo zinapoacha kufika. Weka simu hiyo mwishoni mwa mzunguko wako mkuu, baada ya sehemu inayothibitisha kuwa bot iko hai, kama vile usomaji wa data ya soko uliofaulu.

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

Weka muda wa kichunguzi kuwa takribani mara mbili ya muda wa mzunguko wako ili mabadiliko ya kawaida ya muda yasikusababishie arifa. Endesha kichunguzi kwenye server tofauti na ile ya bot, kwa sababu kichunguzi kinachokufa pamoja na kitu kinachokifuatilia hakitaripoti chochote. Usanidi umeelezwa katika ufuatiliaji wa hali unaojihudumia kwa Uptime Kuma.

Ongeza pia arifa ya diski. Bot inayoandika logi zenye maelezo mengi itajaza mfumo wa faili wa root ndani ya wiki chache, na diski iliyojaa itazuia uandishi wa database, si simu ya mtandao, hivyo dalili zitakuwa zisizo za kawaida. journalctl --vacuum-time=14d na mstari wa SystemMaxUse= katika /etc/systemd/journald.conf huweka journal ndani ya kikomo.

Sehemu ya ukweli: ucheleweshaji kwa kiasi kikubwa hautokani na seva yako

Hapa ndipo soko la bidhaa za VPS za biashara linapoacha kuwa la kiufundi. Kurasa za masoko hutaja takwimu za chini ya millisekunde moja na kudokeza kwamba seva ndiyo kizuizi kati yako na utekelezaji wa agizo. Kwa karibu kila bot ya rejareja, si hivyo.

Agizo lako husafiri kutoka kwenye bot hadi kwenye endpoint ya exchange au broker kupitia intaneti ya umma. Njia hiyo huathiriwa zaidi na umbali wa kimwili na muunganisho wa peering kati ya mtoa huduma wako na wao. Seva iliyoko Frankfurt inayowasiliana na endpoint iliyoko Tokyo hupata takriban millisekunde 250 za safari ya kwenda na kurudi, bila kujali kasi ya CPU. Kisha mifumo ya broker huongeza foleni zake, ukaguzi wa hatari na vikomo vya kasi, ambavyo kwa akaunti ya rejareja kwa kawaida hupimwa kwa makumi au mamia ya millisekunde.

Pima badala ya kukisia. curl huripoti muda wa muunganisho na muda wa kufika kwa 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 hilo kutoka kwenye seva unayotarajia kutumia kabla ya kufanya uamuzi. Ikiwa connect ni sekunde 0.180, uko kwenye bara lisilofaa, na hilo linafaa kurekebishwa. Ikiwa connect ni sekunde 0.004 na ttfb ni sekunde 0.140, ucheleweshaji uliobaki unatokana na uchakataji wa broker, na kubadilisha seva hakutaupunguza.

Kwa hiyo, seva huwa muhimu wakati gani? Unapokuwa umeweka seva yako kwenye kituo kimoja au umeunganisha moja kwa moja na venue na mnashindania nafasi kwenye foleni. Hiyo ni biashara tofauti yenye bajeti tofauti. Pia huwa muhimu wakati msimbo wako wenyewe ndio kizuizi: bot inayokokotoa upya viashiria kwa kutumia historia nzima kwenye kila tick inaweza kutumia millisekunde 200 za CPU kwa kila mzunguko. Huo ni ucheleweshaji halisi unaoweza kuudhibiti bila gharama. Pima utendaji wa mzunguko huo kabla ya kutafuta seva yenye kasi zaidi.

Kinachojali katika seva unayochagua ni eneo la kijiografia, mtandao thabiti, na kumbukumbu ya kutosha ili OOM killer isiwahi kuwa na sababu ya kusimamisha michakato. Kufikia Julai 2026, bot ya Python ya mkakati mmoja yenye alama mia kadhaa katika kumbukumbu huendesha vizuri kwa 2 GB ya RAM na 2 vCPU. Ongeza kumbukumbu ikiwa unahifadhi historia ya tick katika database ya ndani.

Orodha fupi ya ukaguzi kabla ya kuanza uzalishaji

1. systemctl is-enabled tradingbot huchapisha enabled, na huduma inaendelea kufanya kazi baada ya sudo reboot.
2. chronyc tracking huripoti tofauti ya muda wa mfumo iliyo chini ya milisekunde chache.
3. API key ina ruhusa ya kufanya biashara, haina ruhusa ya kutoa fedha, na ina orodha ya IP zinazoruhusiwa ikiwa exchange inatoa chaguo hilo.
4. Kusitisha mchakato kwa sudo systemctl kill -s SIGKILL tradingbot huufanya uanze tena ndani ya RestartSec.
5. Kifuatiliaji cha heartbeat hukutumia arifa ndani ya muda mmoja wa ukaguzi unapoisimamisha bot kwa makusudi.
6. Kumbukumbu zina kikomo cha ukubwa, na mfumo wa faili wa root una nafasi ya kutosha katika df -h.

Endesha kila kitu kwenye sandbox ya exchange au katika hali ya paper kwa wiki moja kabla ya kutumia fedha halisi. Kila kipengee hapo juu hushindwa angalau mara moja ndani ya wiki hiyo. Hilo ndilo kusudi la wiki hiyo.

FAQ

Je, bot ya biashara inahitaji server yenye ucheleweshaji mdogo au bare metal?

Ni lazima tu ikiwa unashindana kwa kasi ya utekelezaji dhidi ya washiriki wengine wa kiotomatiki katika venue ileile. Kwa kawaida, hii humaanisha colocation badala ya VPS ya matumizi ya jumla. Kwa bot ya retail, muda wa kwenda na kurudi huathiriwa zaidi na umbali wa kijiografia na uchakataji wa broker mwenyewe. Kwa hiyo, chagua server iliyo karibu na endpoint ya API, kisha pima kwa curl na mtr kabla ya kulipia kitu chenye kasi zaidi.

Bot ya biashara inahitaji RAM na CPU kiasi gani?

Bot nyingi zinazotumia mkakati mmoja hutegemea mtandao na huwa hazitumii rasilimali nyingi kati ya matukio. Kufikia Julai 2026, 2 vCPU na 2 GB za RAM zinatosha kuendesha bot ya Python inayofuatilia instruments mia kadhaa. Memory huwa kikwazo unapohifadhi historia ya tick ndani ya process au unapoendesha database ya ndani. Kwa hiyo, fuatilia free -h na journal ili uone ujumbe wa OOM kill badala ya kukisia.

Kwa nini exchange API yangu inakataa requests zenye hitilafu ya timestamp?

Saa ya server imekengeuka zaidi ya muda wa kusaini unaokubaliwa na exchange, kwa kawaida kwa sekunde chache. Sakinisha chrony. Thibitisha kuwa chronyc tracking inaonyesha System time ndogo na hali ya leap iliyosawazishwa. Weka mashine itumie UTC ili mabadiliko ya daylight saving yasibadilishe muda wake. Kubadilisha API key hakutatui tatizo la saa.

Ninawezaje kuzuia bot yangu kuzimika usiku bila mimi kujua?

Iendeshe chini ya systemd kwa kutumia Restart=always na StartLimitIntervalSec=0 ili crash loop iendelee kujaribu tena badala ya kusimama kabisa. Kisha ongeza heartbeat ambayo bot hutuma mwishoni mwa kila loop iliyokamilika kwa mafanikio. Restart hushughulikia process. Heartbeat hugundua hali ambayo process bado iko hai lakini imekwama.

Je, ninaweza kuendesha bot na monitoring yangu kwenye VPS moja?

Unaweza, lakini monitoring itakupatia taarifa zisizo sahihi siku ambayo jambo hilo ni muhimu. Hii ni kwa sababu outage inayozima bot pia huizima monitor. Weka alerting kwenye mashine tofauti, ikiwezekana kwa provider au region tofauti. Tumia server ya bot kwa bot yenyewe na logs zake pekee.