Trading bot-க்கு சிறந்த VPS-ஐ தேர்வு செய்வது எப்படி?

Trading bot-க்கு VPS-ல் தேவைப்படுபவை

Trading bot-களுக்கான VPS-ன் தரம் நான்கு விஷயங்களை அடிப்படையாகக் கொண்டது: ஒரு process செயலிழந்தால் அது தானாக மீண்டும் தொடங்குகிறதா, system clock சரியாக உள்ளதா, API (application programming interface) keys திருடப்படாமல் பாதுகாப்பாக உள்ளனவா, மற்றும் bot இயங்குவதை நிறுத்திவிட்டால் உங்களுக்குத் தெரிய வருகிறதா என்பதுதான் அவை. ஒரு retail bot-ஐப் பொறுத்தவரை, அதன் raw speed என்பது மிகக் குறைந்த முக்கியத்துவமே கொண்டது. ஏனெனில், உங்கள் order path-ல் மெதுவான பகுதி என்பது உங்கள் broker மற்றும் அதற்கான தூரம் மட்டுமே; உங்கள் Python code-ஐ இயக்கும் host அல்ல.

இது ஒரு பொறியியல் வழிகாட்டி. இதில் நிதி ஆலோசனைகள் எதுவும் இல்லை, எந்தவொரு வர்த்தக உத்தியும் விவாதிக்கப்படவில்லை.

Uptime என்பது மறுதொடக்கம் செய்யும் ஒழுக்கம், விற்பனைப் பக்கத்தில் உள்ள எண் அல்ல

விளம்பரப்படுத்தப்படும் uptime உறுதிமொழிகள் மாறுபடும். ஒரு தனி EC2 instance-க்கு குறைந்தது 99.5 சதவீதமும், பல availability zones-ல் அமையும் தகுதியான deployments-க்கு 99.99 சதவீதமும் uptime-ஐ AWS உறுதி செய்கிறது. இந்த உறுதிமொழிகள் உள்கட்டமைப்பின் இருப்பை மட்டுமே குறிக்கும், உங்கள் bot-ன் ஆரோக்கியத்தை அல்ல. ஒரு unhandled exception, மீண்டும் இணையாத websocket, அல்லது OOM (out of memory) killer ஆகியவற்றால் bot செயலிழக்கலாம், ஆனால் server தொடர்ந்து இயங்கிக்கொண்டே இருக்கும். எனவே, உங்கள் process நின்ற பிறகு வரும் பத்து வினாடிகளில் என்ன நடக்கிறது என்பதே முக்கியமான கேள்வி.

Bot-ஐ ஒரு systemd service-ஆக இயக்கவும், மறுதொடக்கம் செய்யும் பொறுப்பை 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 என்பது மக்கள் கவனிக்கத் தவறும் வரியாகும். Upstream systemd-ன் இயல்புநிலை அமைப்புகள் 10 வினாடிகளில் 5 முறை தொடங்குவதற்கு அனுமதிக்கின்றன; இதில் ஆரம்பத் தொடக்கம் மற்றும் கைமுறையாகச் செய்யப்படும் தொடக்கங்களும் அடங்கும். Manager configuration மூலம் இந்த இயல்புநிலைகளை மாற்றலாம். இந்த வரம்பை எட்டினால் தானியங்கி மறுதொடக்கம் நின்றுவிடும், ஆனால் குறிப்பிட்ட கால இடைவெளிக்குப் பிறகு unit-ஐ கைமுறையாகவோ அல்லது timer அல்லது socket மூலமாகவோ தொடங்கலாம். இதை 0 என அமைத்தால் rate limit முடக்கப்படும், இதனால் crash-loop-ல் இருக்கும் bot அமைதியாகிவிடாமல் மீண்டும் மீண்டும் முயன்று கொண்டே இருக்கும். RestartSec=10 அந்த loop-ஐத் தடுத்து, exchange-க்கு மீண்டும் மீண்டும் இணைப்பை ஏற்படுத்தி சுமையேற்றுவதைத் தவிர்க்கிறது.

கோப்பை நம்புவதற்கு முன் சரிபார்க்கவும், பிறகு அதைத் தொடங்கவும்:

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 என்பது கடைசியாக reset செய்யப்பட்டதிலிருந்து எத்தனை தானியங்கி மறுதொடக்கம் நடந்துள்ளது என்பதைக் கணக்கிடுகிறது; இது ஒரு வாரம் முழுவதும் bot ஆரோக்கியமாக அல்லது crash ஆகாமல் இயங்கியது என்பதற்குச் சான்றல்ல. கைமுறை மறுதொடக்கங்கள் மற்றும் systemctl reset-failed ஆகியவை இந்த counter-ஐ reset செய்யும், மேலும் முடங்கிய நிலையில் உள்ள bot கூட பூஜ்ஜியத்தைக் காட்டலாம். NRestarts=812 என்பது 812 மறுதொடக்கம் செய்யப்பட்ட பணிகளைக் குறிக்கிறது, இது வெற்றிகரமான exchange இணைப்புகளையோ அல்லது வர்த்தகங்களையோ குறிக்காது, மேலும் அவை எப்போது நிகழ்ந்தன என்பதையும் கூறாது. Bot இணைப்பதற்கு முன்பான தோல்விகள் உட்பட, நேரத்தையும் காரணத்தையும் அறிய journal-ஐச் சரிபார்க்கவும். தினசரி அறிக்கை போன்ற திட்டமிடப்பட்ட பணிகளுக்கான timers உட்பட, unit file-ன் முழுமையான அமைப்பு running a program as a systemd service பகுதியில் விளக்கப்பட்டுள்ளது.

நேரத்தை UTC-க்கு அமைத்து அது ஒத்திசைக்கப்பட்டுள்ளதை உறுதிப்படுத்துதல்

Exchange API-கள் கையொப்பமிடப்பட்ட கோரிக்கைகளைச் சரிபார்க்க timestamps-ஐப் பயன்படுத்துகின்றன; Binance Spot இயல்பாக 5-வினாடி receive window-ஐக் கொண்டுள்ளது, மேலும் சர்வர் நேரத்தை விட 1 வினாடி அல்லது அதற்கு மேல் முன்னதாக இருக்கும் timestamps-ஐ நிராகரிக்கிறது. கடிகாரத்தில் ஏற்படும் கால விலகல் (drifting clock), authentication தோல்விகள் போன்ற பிழைகளை உருவாக்குகிறது; எனவே, நேரத்தைச் சரிபார்க்காமல் பல மணிநேரம் மக்கள் keys-ஐ மாற்றிக்கொண்டிருப்பார்கள். Binance-முறை API-களில் வரும் செய்தி நேரடியானது: Timestamp for this request was 1000ms ahead of the server's time.

சர்வரை UTC-க்கு அமைக்கவும். உள்ளூர் நேர மண்டலங்கள் (Local time zones) காட்டப்படும் நேரங்களில் daylight saving மாற்றங்களை உருவாக்குகின்றன; API-கள் பயன்படுத்தும் Unix timestamps, display timezone மாறும்போது மாறுவதில்லை.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu 25.10 முதல் இயல்பாக chrony-ஐப் பயன்படுத்துகிறது; பழைய நிறுவல்களில் systemd-timesyncd-ஐப் பயன்படுத்தலாம், இது ஒரு SNTP (simple network time protocol) client ஆகும். systemd-timesyncd கடிகாரத்தைச் சரிசெய்யும், ஆனால் தவறான நேர மூலத்தைக் கண்டறிய ஒரே நேரத்தில் பல சர்வர்களைப் polling செய்ய முடியாது. அதற்குப் பதிலாக 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. சிறிய மதிப்பு, chrony-ன் NTP கடிகாரத்தில் எஞ்சியுள்ள சிறிய திருத்தத்தைக் காட்டுகிறது; துல்லியத்தை மதிப்பிடுவதற்கு முன் ஒத்திசைவு, Root delay மற்றும் Root dispersion ஆகியவற்றையும் சரிபார்க்கவும். அது Leap status : Not synchronised என்று காட்டினால், சர்வர்கள் பதிலளித்திருந்தாலும் chrony ஒத்திசைக்கப்படவில்லை என்று அர்த்தம்; அளவீடுகள் மிகவும் துல்லியமற்றவை எனக் கருதப்பட்டு நிராகரிக்கப்படலாம். ஒரு நிமிடம் காத்திருந்து, firewall விதிகளை மாற்றும் முன் மீண்டும் சரிபார்க்கவும்.

API keys-ஐ நீங்கள் நகலெடுக்கும் இடங்களில் வைக்காதீர்கள்

கசிந்த exchange key, கசிந்த SSH key-ஐ விட ஆபத்தானது. ஏனெனில், withdrawal அனுமதி இருந்தால் அது உடனடியாக பணமாக மாற்றப்படலாம். இரண்டு பழக்கங்கள் பெரும்பாலான அபாயங்களைக் குறைக்கின்றன.

முதலாவதாக, bot key-க்கு ஒருபோதும் withdrawal அனுமதியை வழங்காதீர்கள். exchange ஆதரிக்கும் இடங்களில், அந்த key-ஐ உங்கள் server-ன் IP address-உடன் பிணைத்துவிடுங்கள் (bind). திருடப்பட்ட key-ஐ பயனற்றதாக மாற்றும் ஒரே கட்டுப்பாடு இதுதான்.

இரண்டாவதாக, secret-ஐ code directory-க்குள் வைக்காதீர்கள். /opt/tradingbot-க்குள் இருக்கும் எதுவாக இருந்தாலும், அது விரைவில் git repository அல்லது backup archive-ல் சேர்ந்துவிடும். அதை root உரிமையுள்ள கோப்பில் வைத்து, 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

இந்தக் கோப்பில் மேற்கோள் குறிகள் (quotes) மற்றும் export இல்லாமல், சாதாரண KEY=value வரிகள் இருக்க வேண்டும். Mode 640, root உரிமையாளருக்கு read/write அனுமதியையும், bot குழுவில் உள்ளவர்களுக்கு read அனுமதியையும் வழங்கும்; மற்ற பயனர்களுக்கு எந்த அனுமதியும் இருக்காது. sudo -u bot cat /etc/tradingbot/api.env மூலம் சரிபார்க்கவும், பின்னர் bot குழுவில் இல்லாத ஒரு சாதாரண பயனர் மூலம் சரிபார்க்கவும்; அங்கு அது Permission denied பிழையுடன் தோல்வியடைய வேண்டும்.

Bot-ஐ root பயனராகவோ அல்லது உங்கள் login பயனராகவோ இயக்கக்கூடாது. service-ஐத் தொடங்குவதற்கு அல்லது bot குழுவிற்குச் சொந்தமான கோப்புகளை உருவாக்குவதற்கு முன்பு, nologin shell மற்றும் /var/lib/tradingbot-ஐ home directory-ஆகக் கொண்ட ஒரு system account-ஐ உருவாக்கவும்:

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

அந்த ஒவ்வொரு flag-ன் பின்னணியில் உள்ள காரணம் மற்றும் ProtectSystem=strict எந்த அளவிற்குச் செயல்படுகிறது என்பது unprivileged பயனராக services-ஐ இயக்குதல் பகுதியில் உள்ளது. server-ன் அடிப்படை பாதுகாப்பு, SSH keys மற்றும் firewall பற்றிய தகவல்கள் புதிய VPS-ல் முதல் பத்து நிமிடங்கள் பகுதியில் உள்ளன.

உங்கள் broker அறிவதற்கு முன்பே அது செயலிழந்துவிட்டதைக் கண்டறியவும்

systemctl status அந்த process இயங்கிக்கொண்டிருப்பதாகக் கூறுகிறது. ஆனால், bot எதையும் செய்கிறது என்று அது அர்த்தமல்ல. ஒரு dead websocket-ஐ மீண்டும் மீண்டும் இணைக்க முயலும் process, மேலே உள்ள unit சோதனைகளில் தேர்ச்சி பெற்றுவிடும்.

அதற்குப் பதிலாக heartbeat-ஐப் பயன்படுத்தவும். Uptime Kuma-வில் push monitors உள்ளன: உங்கள் bot ஒரு குறிப்பிட்ட கால இடைவெளியில் ஒரு URL-ஐ அழைக்க வேண்டும் என்று அது எதிர்பார்க்கிறது, அந்த அழைப்பு வராவிட்டால் அது எச்சரிக்கை செய்யும். உங்கள் main loop-ன் இறுதியில், சந்தை தரவுகளை வெற்றிகரமாகப் படித்தது போன்ற, bot உயிர்ப்புடன் இருப்பதை உறுதிப்படுத்தும் பகுதிக்குக் கீழே இந்த அழைப்பைச் சேர்க்கவும்.

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

Monitor இடைவெளியை உங்கள் loop நேரத்தைப் போல இரண்டு மடங்காக அமைக்கவும், அப்போதுதான் சாதாரண காலதாமதத்தால் உங்களுக்குத் தேவையற்ற எச்சரிக்கைகள் வராது. Monitor-ஐ bot இயங்கும் server-லிருந்து வேறொரு server-ல் இயக்கவும், ஏனெனில் கண்காணிக்கும் கருவியே அந்தச் சேவையுடன் சேர்ந்து செயலிழந்தால், அது எதையும் தெரிவிக்காது. இதன் அமைப்பு Uptime Kuma மூலம் சுய-ஹோஸ்ட் செய்யப்பட்ட நிலை கண்காணிப்பு பகுதியில் விவரிக்கப்பட்டுள்ளது.

Disk எச்சரிக்கையையும் சேர்க்கவும். அதிகப்படியான logs-ஐ எழுதும் bot, சில வாரங்களிலேயே root filesystem-ஐ நிரப்பிவிடும். Disk நிறைந்தால் database-ல் எழுதுவது நின்றுவிடும், ஆனால் network அழைப்பு தொடரும், எனவே அறிகுறிகள் குழப்பமாக இருக்கும். journalctl --vacuum-time=14d மற்றும் /etc/systemd/journald.conf-ல் உள்ள ஒரு SystemMaxUse= வரி ஆகியவை journal-ன் அளவைக் கட்டுக்குள் வைத்திருக்கும்.

உண்மை என்னவென்றால்: latency பெரும்பாலும் உங்கள் host-ஆல் ஏற்படுவதில்லை

இங்குதான் trading VPS தயாரிப்புகளுக்கான சந்தை தொழில்நுட்ப ரீதியாக இருப்பதில்லை. சந்தைப்படுத்தல் பக்கங்கள் மில்லி-செகண்டிற்கும் குறைவான வேகத்தைக் குறிப்பிடுகின்றன, மேலும் ஒரு வர்த்தகத்தை முடிப்பதில் (fill) உங்கள் host தான் முக்கிய பங்கு வகிக்கிறது என்று உணர்த்துகின்றன. ஆனால், பெரும்பாலான retail bot-களுக்கு இது உண்மையல்ல.

உங்கள் order, bot-லிருந்து பொது இணையம் வழியாக exchange அல்லது broker endpoint-க்குச் செல்கிறது. அந்தப் பாதையில், இயற்பியல் தூரம் மற்றும் உங்கள் provider-க்கும் அவர்களின் provider-க்கும் இடையிலான peering ஆகியவையே முக்கியப் பங்கு வகிக்கின்றன. அதன்பிறகு, broker-ன் சொந்த அமைப்புகள் அவற்றின் queue, risk checks மற்றும் rate limits ஆகியவற்றைச் சேர்க்கின்றன.

ஊகிப்பதை விட, அளவிடுவது சிறந்தது. curl ஒரு உண்மையான endpoint-க்கான இணைப்பு மற்றும் முதல்-byte நேரத்தை (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

நீங்கள் ஒரு server-ஐத் தேர்ந்தெடுக்கும் முன், அதை இயக்கிப் பாருங்கள். connect என்பது 0.180 வினாடிகள் என்றால், அதில் DNS resolution மற்றும் TCP இணைப்பு அடங்கும்; நீங்கள் எந்தக் கண்டத்தில் இருக்கிறீர்கள் என்பதை இது உறுதிப்படுத்தாது. connect என்பது 0.004 வினாடிகள் மற்றும் ttfb என்பது 0.140 வினாடிகள் என்றால், அந்த வித்தியாசத்தில் TLS setup, request transmission, network delays மற்றும் server processing ஆகியவை அடங்கும். Host-ஐ மாற்றுவது இதில் சில கூறுகளைப் பாதிக்கலாம், எனவே வெவ்வேறு இடங்களில் இருந்து எடுக்கப்பட்ட அளவீடுகளை ஒப்பிட்டுப் பாருங்கள்.

அப்படியானால், host எப்போது முக்கியமானது? நீங்கள் ஒரு venue-வுடன் colocated அல்லது cross-connected ஆக இருந்து, queue position-க்காகப் போட்டியிடும்போது இது முக்கியமானது; இது முற்றிலும் மாறுபட்ட பட்ஜெட் கொண்ட வேறொரு வணிகம். மேலும், உங்கள் சொந்த code bottleneck-ஆக இருக்கும்போது இது முக்கியமானது: ஒவ்வொரு tick-க்கும் முழு வரலாற்றையும் மீண்டும் கணக்கிடும் ஒரு bot, ஒவ்வொரு loop-க்கும் 200 மில்லி-செகண்ட் CPU-வை வீணாக்கலாம்; இது நீங்கள் இலவசமாகக் கட்டுப்படுத்தக்கூடிய உண்மையான latency ஆகும். வேகமான server-ஐ வாங்குவதற்கு முன், உங்கள் loop-ஐ profile செய்யுங்கள்.

நீங்கள் தேர்ந்தெடுக்கும் host-ல் முக்கியமானது புவியியல் அமைப்பு, நிலையான networking மற்றும் OOM killer ஒருபோதும் தலையிடாத அளவுக்குப் போதுமான memory ஆகும். நீங்கள் tick வரலாற்றை local database-ல் வைத்திருந்தால், கூடுதல் memory-ஐச் சேர்க்கவும்.

நேரடி பயன்பாட்டிற்கு முந்தைய சரிபார்ப்புப் பட்டியல்

1. systemctl is-enabled tradingbot கட்டளையை இயக்கும்போது enabled வெளியீடு கிடைக்கிறது, மேலும் sudo reboot நிகழ்விற்குப் பிறகும் சேவை தொடர்ந்து இயங்குகிறது.
2. chronyc tracking கட்டளையானது ஒத்திசைவு (synchronisation), சில மில்லி விநாடிகளுக்குக் குறைவான நேர வேறுபாடு (system time offset), மற்றும் உங்கள் கால வரம்பிற்குள் (timing budget) root delay மற்றும் dispersion ஆகியவற்றைக் காட்டுகிறது.
3. API key-க்கு வர்த்தகம் செய்யும் அனுமதி உள்ளது, ஆனால் பணம் எடுக்கும் (withdrawal) அனுமதி இல்லை; மேலும் exchange வசதி இருந்தால், IP allowlist அமைக்கப்பட்டுள்ளது.
4. sudo systemctl kill -s SIGKILL tradingbot மூலம் செயல்முறையை (process) நிறுத்திய பிறகு, RestartSec காலதாமதம் மற்றும் தொடக்க நேரத்திற்குப் பிறகு அது தானாகவே மீண்டும் இயங்குகிறது.
5. நீங்கள் திட்டமிட்ட இடைவெளிக்குப் பிறகு heartbeat monitor உங்களுக்கு எச்சரிக்கை அனுப்புகிறது; நீங்கள் bot-ஐ வேண்டுமென்றே நிறுத்தும்போது அது மீண்டும் முயற்சிக்கிறது.
6. Logs அளவு கட்டுப்படுத்தப்பட்டுள்ளது மற்றும் df -h-ல் root filesystem-க்குத் தேவையான கூடுதல் இடம் (headroom) உள்ளது.

உண்மையான பணத்தைப் பயன்படுத்துவதற்கு முன்பு, ஒரு வாரம் முழுவதும் exchange-ன் sandbox அல்லது paper mode-ல் முழு அமைப்பையும் இயக்கவும். அந்த ஒரு வாரத்தில் மேலே உள்ள ஒவ்வொரு அம்சமும் குறைந்தது ஒரு முறையாவது தோல்வியடையும்; அந்தத் தோல்விகளைக் கண்டறிவதே இந்த ஒரு வார கால சோதனையின் நோக்கமாகும்.

FAQ

Trading bot-க்கு low-latency அல்லது bare metal server அவசியமா?

அதே சந்தையில் மற்ற தானியங்கி பங்கேற்பாளர்களை விட வேகமான execution தேவைப்பட்டால் மட்டுமே இது அவசியம்; இதற்கு பொதுவாக VPS-ஐ விட colocation சிறந்தது. சில்லறை வர்த்தக bot-களைப் பொறுத்தவரை, round trip நேரம் புவியியல் மற்றும் broker-ன் செயலாக்கத்தையே சார்ந்துள்ளது. எனவே, API endpoint-க்கு அருகில் உள்ள server-ஐத் தேர்வு செய்யவும். எதையும் வாங்குவதற்கு முன் curl மற்றும் mtr மூலம் அளவீடு செய்யவும்.

Trading bot-க்கு எவ்வளவு RAM மற்றும் CPU தேவைப்படும்?

பெரும்பாலான ஒற்றை-உத்தி (single-strategy) bot-கள் network-ஐச் சார்ந்தே இயங்குகின்றன, நிகழ்வுகளுக்கு இடையில் இவை செயலற்ற நிலையில் இருக்கும். tick history-ஐ process-ல் வைத்திருக்கும்போதோ அல்லது local database-ஐ இயக்கும்போதோ memory ஒரு தடையாக மாறலாம். எனவே, ஊகங்களைச் செய்யாமல் free -h மற்றும் journal-ல் உள்ள OOM kill செய்திகளைக் கவனிக்கவும்.

எனது exchange API ஏன் timestamp பிழையுடன் கோரிக்கைகளை நிராகரிக்கிறது?

கோரிக்கையின் timestamp, exchange அனுமதிக்கும் காலக்கெடுவிற்கு வெளியே உள்ளது; clock drift மற்றும் கோரிக்கை தாமதங்கள் ஆகிய இரண்டுமே இதற்கு முக்கியக் காரணங்கள். chrony-ஐ நிறுவி, chronyc tracking-ல் சிறிய System time offset மற்றும் synchronised leap status உள்ளதா என்பதை உறுதிப்படுத்தவும். மேலும் root delay மற்றும் dispersion-ஐயும் சரிபார்க்கவும். machine-ஐ UTC-க்கு அமைப்பது நேரத்தை சீராகக் காட்டும், ஆனால் clock drift-ஐ சரிசெய்யாது. API key-ஐ மாற்றுவது clock சிக்கலைத் தீர்க்காது.

நான் அறியாமல் இரவு நேரத்தில் bot நின்றுவிடுவதை எப்படித் தடுப்பது?

அதை systemd-ன் கீழ் Restart=always மற்றும் StartLimitIntervalSec=0 பயன்படுத்தி இயக்கவும். இதனால் start rate limit-ஐத் தொடாமல், crash loop மீண்டும் மீண்டும் முயற்சிக்கும். ஒவ்வொரு வெற்றிகரமான loop-ன் முடிவிலும் bot ஒரு heartbeat-ஐ அனுப்பும்படி செய்யவும். process நின்றுவிட்டால் restart அதைச் சரிசெய்துவிடும். process உயிருடன் இருந்து ஆனால் முடங்கியிருந்தால், இந்த heartbeat அதை அடையாளம் காணும்.

Bot-ஐயும் எனது monitoring-ஐயும் ஒரே VPS-ல் இயக்கலாமா?

இயக்கலாம், ஆனால் சிக்கல் ஏற்படும் நாளில் monitoring தவறான தகவலைத் தரும். ஏனெனில் bot-ஐ பாதிக்கும் ஒரு outage, monitoring-ஐயும் செயலிழக்கச் செய்யும். alerting-ஐ தனி machine-ல், முடிந்தால் வேறு provider அல்லது region-ல் வைத்திருக்கவும். bot-ன் server-ஐ bot மற்றும் அதன் logs-க்கு மட்டுமே பயன்படுத்தவும்.