Self-hosted error tracking: Sentry-க்கு சிறந்த மாற்றுகள்

ஒரு நிகழ்வைச் சேமிக்கும் முன் self-hosted error tracking-க்கு ஆகும் செலவு

Self-hosted error tracking-ல் ஒட்டுமொத்த முடிவையும் தீர்மானிக்கும் ஒரு எண் உள்ளது, அது RAM-ன் குறைந்தபட்ச அளவு (RAM floor). Sentry-ன் சொந்த self-hosted ஆவணங்களின்படி, உங்கள் application ஒரு நிகழ்வை (event) அனுப்பும் முன்பே, 4 CPU cores, 16 GB RAM மற்றும் 16 GB swap, அத்துடன் 20 GB காலி வட்டு இடம் (free disk) தேவைப்படுகிறது. GlitchTip 512 MB-ஐ மட்டுமே கோருகிறது. இங்குள்ள அனைத்து விருப்பங்களும் ஒரே மாதிரியான Sentry SDK-களிலிருந்து நிகழ்வுகளை ஏற்றுக்கொள்கின்றன, எனவே இது உங்கள் குறியீட்டை (code) எவ்வாறு வடிவமைக்கிறீர்கள் என்பது குறித்த முடிவல்ல. மாறாக, நீங்கள் எவ்வளவு பெரிய server-க்கு பணம் செலுத்தவும், அதைத் தொடர்ந்து பராமரிக்கவும் தயாராக இருக்கிறீர்கள் என்பது குறித்த முடிவாகும்.

வெளியிடப்பட்ட வளங்களின் புள்ளிவிவரங்கள், அருகருகே

இவை ஆகஸ்ட் 2026 நிலவரப்படி, ஒவ்வொரு திட்டமும் தன்னைப்பற்றி வெளியிட்ட எண்கள் ஆகும். இவை ஒரே மாதிரியான அளவீடுகள் அல்ல, எனவே அவற்றை ஒப்பிடுவதற்கு முன் ஒவ்வொரு வரிசையிலும் உள்ள குறிப்பைப் படிக்கவும்.

[
  {
    "tool": "Sentry self-hosted",
    "published_ram_gb": 16,
    "notes": "documented minimum, plus 16 GB of swap"
  },
  {
    "tool": "Bugsink",
    "published_ram_gb": 4,
    "notes": "the vendor's own published benchmark box, 2 vCPU"
  },
  {
    "tool": "GlitchTip",
    "published_ram_gb": 0.5,
    "notes": "documented recommendation, 256 MB stated as the minimum"
  }
]

Sentry-ன் 16 GB என்பது ஆவணப்படுத்தப்பட்ட குறைந்தபட்ச அளவு, அதே பக்கம் 32 GB-ஐப் பரிந்துரைக்கிறது. GlitchTip-ன் 0.5 GB என்பது ஒரு பரிந்துரை, மேலும் இந்தத் திட்டம் 256 MB-ஐ செயல்பாட்டிற்கான குறைந்தபட்ச அளவாகவும், கவனமாக உள்ளமைக்கப்பட்டால் 128 MB மற்றும் swap-ஐயும் குறிப்பிடுகிறது. Bugsink-ன் 4 GB இவை இரண்டையும் குறிக்கவில்லை: இது விற்பனையாளர் தனது சொந்த throughput benchmark-க்காகப் பயன்படுத்திய கணினியின் அளவாகும். வெளியிடப்பட்ட ஒரு புள்ளிவிவரம் என்பது தொடக்கப் புள்ளி மட்டுமே, அது உங்கள் event volume-க்கான உறுதிமொழி அல்ல.

Sentry self-hosted: முழு தயாரிப்பு மற்றும் அதன் முழுமையான செலவு

இதன் அதிகாரப்பூர்வ stack என்பது getsentry/self-hosted ஆகும். இது Sentry தயாரிப்பு சூழலில் இயங்கும் அதே கூறுகளைக் கொண்ட ஒரு Docker Compose திட்டமாகும். இதன் ஆவணங்கள் இதை "குறைந்த பயன்பாடு மற்றும் மாதிரித் திட்டங்களுக்கு (proofs-of-concept) ஏற்ற முழுமையான வசதிகள் கொண்ட தொகுப்பு" என்று குறிப்பிடுகின்றன. இந்த வாக்கியமே இதற்கான உண்மையான சுருக்கமாகும். இதில் அனைத்து வசதிகளும், அந்த வசதிகளைச் செயல்படுத்தும் அனைத்து நுணுக்கமான பாகங்களும் அடங்கும்.

master-லிருந்து அல்லாமல், ஒரு குறிப்பிட்ட tagged release-லிருந்து நிறுவவும்:

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
./install.sh

பின்பு அதைத் தொடங்கவும்:

docker compose up --wait

Sentry இயல்பாக http://127.0.0.1:9000-ல் இயங்குகிறது. Docker Engine 19.03.6 அல்லது அதற்குப் பிந்தைய பதிப்பும், Docker Compose 2.32.2 அல்லது அதற்குப் பிந்தைய பதிப்பும் தேவை. பழைய Compose பதிப்புகள் Sentry-ன் செயல்பாட்டினால் அல்லாமல், கோப்பு அமைப்பில் (file syntax) ஏற்படும் பிழையினால் தோல்வியடையும்.

நீங்கள் உண்மையில் எதைத் தொடங்கினீர்கள் என்று பார்க்கவும்:

docker compose ps
free -h

docker compose ps இந்த stack-ல் உள்ள ஒவ்வொரு service-ஐயும் பட்டியலிடுகிறது, அந்தப் பட்டியல் மிக நீளமானது: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator மற்றும் பல worker மற்றும் cron செயல்முறைகள். இவற்றை ஒருமுறை எண்ணிப் பாருங்கள், ஏனெனில் அந்த எண்ணிக்கையே உங்கள் பராமரிப்புச் சுமையாகும். ஒவ்வொரு பதிவும் செயலிழக்கக்கூடிய, வட்டை நிரப்பக்கூடிய அல்லது migration தோல்வியடையக்கூடிய ஒரு செயல்முறையாகும்.

ஒரு service Restarting நிலையில் இருந்தால், மற்ற எதையும் பார்ப்பதற்கு முன் நினைவகத்தை (memory) சரிபார்க்கவும்:

dmesg -T | grep -i 'out of memory'

Out of memory: Killed process 3412 (java) போன்ற ஒரு வரி, கணினியில் RAM தீர்ந்துவிட்டதால் kernel-ன் OOM killer (out of memory killer) ஒரு container-ஐ நீக்கிவிட்டது என்று பொருள். இதனால் அந்த service ஆரோக்கியமான நிலையை அடையாது, stack-ம் முழுமையாகத் தொடங்காது. ஆவணப்படுத்தப்பட்ட குறைந்தபட்சத் தேவைகளுக்குக் குறைவாக முழு stack-ஐயும் இயக்கும்போது இதுவே நடக்கும். ஆவணங்கள் வட்டு வேகத்தையும் (disk speed) குறிப்பிடுகின்றன: iowait 10%-க்கு மேல் இருந்தால், தரவு உள்வாங்கும் வேகத்திற்கு (ingest pipeline) இயந்திரத்தால் ஈடுகொடுக்க முடியவில்லை என்று பொருள். இதை top-ல் உள்ள wa நெடுவரிசையிலிருந்தோ, அல்லது sysstat நிறுவப்பட்டிருந்தால் iostat -x 5 மூலமாகவோ பார்க்கலாம்.

மேம்படுத்தல்கள் (Upgrades) - மக்கள் குறைத்து மதிப்பிடும் பகுதி

Sentry self-hosted மாதந்தோறும் CalVer (calendar based version scheme) அடிப்படையில் வெளியிடப்படுகிறது. ஒவ்வொரு மாதமும் 15-ஆம் தேதி முதன்மை வெளியீடு இருக்கும். பழைய பதிப்பிலிருந்து நேரடியாகப் புதிய பதிப்பிற்கு மாற முடியாது. இந்தத் திட்டம் சில 'hard stop' பதிப்புகளை வரையறுத்துள்ளது. தரவுத்தள மாற்றங்களை (database migrations) முறையாகப் பெற, ஒவ்வொரு பதிப்பிற்கும் வரிசையாகச் செல்ல வேண்டும். ஆகஸ்ட் 2026 நிலவரப்படி, வெளியிடப்பட்ட hard stop பதிப்புகள்: 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 மற்றும் 26.7.0 ஆகும். 23.7.0, 25.9.0, 25.12.0 மற்றும் 26.3.0 முதல் 26.4.0 வரையிலான பதிப்புகள் போன்ற, migration சிக்கல்கள் காரணமாகத் தவிர்க்க வேண்டிய வெளியீடுகளையும் ஆவணங்கள் பட்டியலிடுகின்றன.

ஒரு மேம்படுத்தல் என்பது checkout செய்த பிறகு installer-ஐ மீண்டும் இயக்குவதாகும்:

git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait

தொடங்குவதற்கு முன் server-ன் snapshot-ஐ எடுக்கவும். ஏனெனில், பெரிய ClickHouse தரவுத்தொகுப்பில் migration பல மணிநேரம் ஆகலாம். இடையில் தோல்வியடைந்தால் தரவுத்தளம் இரண்டு schema-களுக்கு இடையில் சிக்கிக்கொள்ளும். சுய-ஹோஸ்ட் செய்யப்பட்ட Sentry மேம்படுத்தல்கள் தோல்வியடைவதற்குப் பொதுவான காரணம்: ஒரு வருடம் வரை ஒரே பதிப்பில் வைத்திருப்பதுதான். இதனால் ஒரே நேரத்தில் பல hard stop-களைத் தாண்ட வேண்டியிருக்கும், அப்போது தவிர்க்கப்பட்ட முக்கியமான migration ஏதேனும் ஒன்று விடுபட்டிருக்கலாம்.

நீங்கள் தொடங்குவதற்கு முன் தெரிந்துகொள்ள வேண்டிய மற்றொரு விஷயம்: Sentry self-hosted, Sentry நிறுவனத்தால் அறிமுகப்படுத்தப்பட்ட Functional Source License (FSL)-ன் கீழ் உள்ளது. இது OSI அங்கீகாரம் பெற்ற திறந்தநிலை மென்பொருள் (open source) அல்ல, மாறாக 'fair source' ஆகும்: நீங்கள் இதை உங்களுக்காக இயக்கலாம், ஆனால் போட்டியிடும் ஒரு சேவையாக இதை விற்கக்கூடாது. ஒவ்வொரு வெளியீடும் அது வெளியான இரண்டு ஆண்டுகளுக்குப் பிறகு Apache 2.0 உரிமத்திற்கு மாற்றப்படும்.

GlitchTip: 512 MB தேவைப்படும் தீர்வு

GlitchTip என்பது MIT உரிமம் பெற்றது. இது Sentry-ன் open source SDK-களிலிருந்து events-ஐப் பெறுகிறது. எனவே, ஒரு application-ஐ மாற்ற, அதன் DSN (data source name, உங்கள் SDK events-ஐ அனுப்பும் URL) மதிப்பை மட்டும் மாற்றினால் போதுமானது. இதற்கு PostgreSQL 14 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. Valkey அல்லது Redis 7 அல்லது அதற்குப் பிந்தைய பதிப்பு விருப்பத்தேர்வுதான், ஆனால் இது பெரிய instances-ன் வேகத்தை அதிகரிக்கும்.

இதனை நிறுவ Docker மற்றும் ஒரு compose file போதுமானது:

sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml

எந்தவொரு பணியையும் தொடங்கும் முன் environment பகுதியைத் திருத்தவும். நீங்கள் கட்டாயம் அமைக்க வேண்டிய மதிப்புகள்: secret, domain மற்றும் mail path:

SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587

மாதிரி கோப்பில் ஏற்கனவே DATABASE_URL அதன் சொந்த postgres service-உடன் இணைக்கப்பட்டுள்ளது. நீங்கள் வேறொரு இடத்தில் இயங்கும் database-ஐப் பயன்படுத்தவில்லை என்றால், அந்த வரியை மாற்ற வேண்டாம். GLITCHTIP_DOMAIN-ல் கட்டாயம் scheme இருக்க வேண்டும். முன்னால் https:// இல்லையென்றால், எச்சரிக்கை மின்னஞ்சல்களில் உள்ள இணைப்புகள் தவறாக உருவாக்கப்பட்டு, பதிலளிக்காத URL-க்குச் செல்லும்.

இதைத்தொடங்கி, முதல் boot-ஐ கவனிக்கவும்:

docker compose up -d
docker compose logs -f web

ஆகஸ்ட் 2026 நிலவரப்படி, மாதிரி கோப்பில் உள்ள image tags postgres:18, valkey/valkey:9 மற்றும் glitchtip/glitchtip:6 ஆகும். இவற்றை அப்படியே வைத்திருக்கவும். latest என்று குறிப்பிடப்பட்ட compose file, அடுத்த docker compose pull-ன் போது உங்கள் database engine-ஐ upgrade செய்துவிடும். இயங்கிக்கொண்டிருக்கும் instance-ல் Postgres-ன் major பதிப்பை திடீரென உயர்த்துவது, error tracker இயங்குவதை நிறுத்திவிடும்.

256 MB முதல் 512 MB வரம்பிற்குள் கொண்டுவர, மாதிரி கோப்பில் உள்ள குறிப்புகளைப் பின்பற்றி எவற்றை நிறுத்த வேண்டும் என்று பார்க்கவும். Valkey மற்றும் விருப்பத்தேர்வாக உள்ள log மற்றும் uptime அம்சங்களை முதலில் நிறுத்தலாம். Valkey இல்லாமல் இயங்கினால், GlitchTip அதன் cache மற்றும் queue பணிகளுக்கு database-ஐப் பயன்படுத்தும்; இது சற்று மெதுவானது, ஆனால் சரியாகச் செயல்படும். All in one mode-ல் worker-ஐ web process-க்குள்ளேயே இயக்குவதால், இரண்டு container-களுக்குப் பதிலாக ஒரு application container-ஐ மட்டும் பராமரித்தால் போதும்.

இதற்கு முன்னால் ஒரு proxy-ஐ அமைக்கவும். GlitchTip-ன் ஆவணங்கள், கோரிக்கைகளை buffer செய்து chunked Transfer-Encoding-ஐக் கையாளக்கூடிய ஒரு proxy அல்லது load balancer-ஐப் பயன்படுத்தப் பரிந்துரைக்கின்றன. இதற்கு nginx ஒரு சிறந்த எடுத்துக்காட்டு. buffering இல்லையென்றால், மெதுவான client ஒரு application worker-ஐ முழு upload முடியும் வரை பிடித்து வைத்திருக்கும். இதனால் சில மெதுவான senders-கள் உங்கள் அனைத்து worker-களையும் ஆக்கிரமித்துக்கொள்ள, சரியான client-களுக்கு timeout ஏற்படும்.

Upgrades செய்வது எளிது:

docker compose pull
docker compose stop
docker compose up -d

Database migrations தொடங்கும்போதே தானாகவே நடைபெறும். இருப்பினும், முதலில் ஒரு dump எடுத்துக்கொள்ளவும், ஏனெனில் தானியங்கி migration என்றாலும் அது ஒரு மாற்றமே.

Bugsink: ஒரு container, மற்றும் நீங்கள் படிக்க வேண்டிய உரிமம்

மூன்றில் Bugsink மிகவும் இலகுவானது. இது Sentry SDK protocol-ஐப் பயன்படுத்துகிறது. இதற்கு message queue தேவையில்லை, database-ஐத் தவிர வேறு எந்த external service-உம் தேவையில்லை. SQLite இயல்பாகவே உள்ளது; உங்கள் தேவை அதிகரிக்கும்போது MySQL மற்றும் PostgreSQL-ஐப் பயன்படுத்தலாம்.

நீங்கள் முடிவெடுக்கும் முன் அதன் interface-ஐப் பார்க்க ஒரு தற்காலிக instance:

docker pull bugsink/bugsink:latest
docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e CREATE_SUPERUSER=admin@example.org:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

http://localhost:8000/-ஐத் திறந்து, CREATE_SUPERUSER-ல் நீங்கள் குறிப்பிட்ட முகவரி மற்றும் கடவுச்சொல்லைக் கொண்டு உள்நுழையவும். அந்த container நிறுத்தப்படும்போது எதையும் சேமிக்காது. உண்மையான பயன்பாட்டிற்கு, project-ன் compose sample-ஐப் பயன்படுத்தவும். இது bugsink/bugsink:2-ஐ postgres:17-alpine-உடன் இணைத்து, DATABASE_URL, BASE_URL மற்றும் BEHIND_HTTPS_PROXY ஆகியவற்றை அமைக்கிறது. secret-ஐச் சரியாக உருவாக்கவும்:

openssl rand -base64 50

BASE_URL என்பது உங்கள் பயனர்களும் SDK-களும் பயன்படுத்தும் உண்மையான URL-ஆக இருக்க வேண்டும் (scheme உட்பட). நீங்கள் https://errors.example.com மூலம் அணுகும் server-ல் இதை http://localhost:8000 என்று விட்டுவிட்டால், notification email-ல் உள்ள அனைத்து இணைப்புகளும் பயனருக்குத் தெரியாத ஒரு host-ஐக் காட்டும். Nginx அல்லது Caddy இதற்கு முன்னால் TLS (transport layer security) termination செய்யும்போது, BEHIND_HTTPS_PROXY-ஐ true என அமைக்கவும். இல்லையெனில், உங்கள் https:// proxy-க்கு பின்னால் Bugsink http:// URL-களை உருவாக்கும், இதனால் browsers mixed content-ஐத் தடுக்கும்.

இதன் தயாரிப்பாளர் அதன் throughput அளவுகளை வெளியிட்டுள்ளனர்: 2 vCPU மற்றும் 4 GB VPS-ல், தலா 50 KB அளவுள்ள 18 events-களை ஒரு வினாடிக்குக் கையாள முடியும். இது ஒரு நாளைக்கு 1.5 மில்லியன் events-க்குச் சமம். இதை ஒரு உத்தரவாதமாகக் கருதாமல், கருவியின் திறனைப் புரிந்துகொள்ளும் அளவீடாகக் கொள்ளவும். ஒரு சிறிய application உருவாக்கும் அளவை விட இதன் உச்ச வரம்பு மிக அதிகம் என்பதை இது காட்டுகிறது.

இப்போது உரிமம் (licence). உங்கள் stack-ல் இதைச் சேர்க்கும் முன் இதைப் படிக்க வேண்டும். Bugsink, PolyForm Shield License 1.0.0-ன் கீழ் வெளியிடப்பட்டுள்ளது. இது source available, open source அல்ல: நீங்கள் இதை இயக்கலாம், மாற்றியமைக்கலாம், ஆனால் Bugsink-உடன் போட்டியிடும் எதையும் உருவாக்க இதைப் பயன்படுத்தக்கூடாது. உள்நாட்டு error tracker-க்கு இந்தத் தடை பொருந்தாது. உங்கள் நிறுவனம் developer tooling-ஐ விற்பனை செய்கிறது என்றால், உரிம உரையை முதலில் ஒருமுறை படித்துப் பார்க்கவும்.

பிழை கண்காணிப்பு (Error tracking) மற்றும் LLM கண்காணிப்பு (Observability) ஆகிய இரண்டும் இன்னும் தனித்தனி கருவிகளாகவே உள்ளன

பிழை கண்காணிப்பு மற்றும் பெரிய மொழி மாதிரி (LLM) கண்காணிப்பு ஆகிய இரண்டையும் ஒரே கருவியில் தேடினால், இரண்டு வசதிகளையும் தருவதாகக் கூறும் தயாரிப்புகளை நீங்கள் காணலாம். ஆனால், தரவுகளின் வடிவம் வெவ்வேறாக இருப்பதால், இந்த ஒருங்கிணைப்பு இன்னும் முழுமையடையவில்லை. ஒரு பிழை கண்காணிப்பு கருவி (Error tracker), stack trace உடன் கூடிய exception-ஐப் பெற்று, அதிலிருந்து ஒரு fingerprint-ஐ உருவாக்கி, ஆயிரக்கணக்கான நிகழ்வுகளை ஒரே சிக்கலாகக் குறைத்து எண்ணும். ஒரு LLM tracing கருவி, prompt, response, token எண்ணிக்கை மற்றும் latency ஆகியவற்றைக் கொண்ட ஒரு span-ஐப் பெறுகிறது. இதில் ஒவ்வொரு நிகழ்வையும் அது அப்படியே வைத்திருக்க வேண்டும், ஏனெனில் ஒரே மாதிரியான உள்ளீடுகளைக் கொண்ட இரண்டு அழைப்புகளும் தனித்தனி நிகழ்வுகளாகவே கருதப்பட்டு ஆய்வு செய்யப்பட வேண்டியவை.

எனவே, இரண்டையும் தனித்தனியாக இயக்குங்கள். பிழைகளை (exceptions) பிழை கண்காணிப்பு கருவிக்கும், model அழைப்புகளை அவற்றுக்கென உருவாக்கப்பட்ட இடத்திற்கும் அனுப்புங்கள்: agent tracing-க்கான self-hosted Langfuse அந்தப் பகுதியை உள்ளடக்கியது, மேலும் self-hosted AI observability அதே பணியை வேறு கோணத்தில் அணுகுகிறது. உங்கள் application ஏற்கனவே இவ்விரு வகையான தோல்விகளையும் உருவாக்குகிறது. தவறான தகவலை உறுதியாகத் தரும் ஒரு model அழைப்பு எந்த exception-ஐயும் உருவாக்குவதில்லை, எனவே பிழை கண்காணிப்பு கருவி அதை உங்களுக்குக் காட்டாது.

வட்டு இடவசதி குறைபாடு என்பது பிற்காலத்தில் பாதிப்பை ஏற்படுத்தும் ஒரு தோல்வியாகும்

ஒவ்வொரு error tracker-ம் அதிகப்படியான எழுதும் செயல்பாடுகளைக் கொண்ட ஒரு database ஆகும், இதற்கு வரம்பற்ற உள்ளீடு (input) உள்ளது. உங்கள் application எவ்வளவு தரவை எழுதுகிறது என்பதை அதுவே தீர்மானிக்கிறது; ஒரு hot code path-ல் ஏற்படும் புதிய bug, ஒரே இரவில் மில்லியன் கணக்கான நிகழ்வுகளை (events) உருவாக்கக்கூடும்.

GlitchTip ஒரு முக்கியமான புள்ளிவிவரத்தை வழங்குகிறது: ஒரு மாதத்திற்கு ஒரு மில்லியன் நிகழ்வுகளைக் கையாளும் instance-க்கு 30 GB வட்டு இடம் தேவைப்படலாம். இது அந்த வேகத்தில் ஒரு மாதத்திற்கான தரவைச் சேமிக்க உதவும், உங்கள் retention window-வைப் பொறுத்தே நீங்கள் எத்தனை மாதங்களுக்கான தரவைச் சேமிக்கிறீர்கள் என்பது அமையும்.

Bugsink இதை வேறு கோணத்தில் அணுகுகிறது. நிலையான ஒதுக்கீட்டிற்குப் பதிலாக, இது நிகழ்வுகளின் எண்ணிக்கை மற்றும் காலத்தின் அடிப்படையில் ஒரு retention algorithm-ஐப் பயன்படுத்துகிறது. இது வரம்புகளை நேரடியாக வெளிப்படுத்துகிறது: முழு installation-க்கும் MAX_RETENTION_EVENT_COUNT, ஒவ்வொரு project-க்கும் MAX_RETENTION_PER_PROJECT_EVENT_COUNT, மற்றும் முழுமையான உச்சவரம்பாக MAX_EVENT_AGE_DAYS. ஒரு installation-ன் ஒட்டுமொத்த நிகழ்வு வரம்பை அமைப்பதே வட்டு அளவைத் தீர்மானிக்க நேர்மையான வழியாகும், ஏனெனில் அந்த வரம்பே வட்டின் அளவை நிர்ணயிக்கிறது.

Server-ல் உள்ள உண்மையான எண்களைக் கவனியுங்கள்:

df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*

docker system df -v ஒவ்வொரு volume-ன் அளவையும் காட்டும், இதன் மூலம் எந்த service அதிக இடத்தைப் பிடிக்கிறது என்பதை நீங்கள் அறியலாம். Traffic-ல் எந்த மாற்றமும் இல்லாமல் ஒரு volume வாரத்திற்கு பல gigabytes வளர்ந்தால், retention சரியாக configure செய்யப்படவில்லை என்று அர்த்தம்; இதனால் எதுவும் நீக்கப்படாமல், partition-ன் அளவு மட்டுமே ஒரே வரம்பாக உள்ளது.

Memory-ம் இதே போன்ற சிக்கல்தான், ஆனால் வேறு வடிவில் வெளிப்படுகிறது. எந்த வரம்பும் இல்லாத stack, kernel வழங்கும் அனைத்து memory-யையும் எடுத்துக்கொள்ளும். machine-ல் memory தீர்ந்துவிட்டால், OOM killer மிகப்பெரிய process-ஐத் தேர்ந்தெடுக்கும்; அது சிக்கலை ஏற்படுத்திய tracker-ஆக இல்லாமல், உங்கள் web server-ஆக இருக்க வாய்ப்புள்ளது. ஒவ்வொரு service-க்கும் ஒரு உச்சவரம்பை நிர்ணயியுங்கள்: memory limits in Docker Compose என்பது இதற்கான syntax-ஐயும், ஒரு container அதன் வரம்பை எட்டும்போது என்ன நடக்கும் என்பதையும் விளக்குகிறது. அதன் சொந்த வரம்பில் நிறுத்தப்படும் ஒரு container, அந்தத் தோல்வியை அதனுள்ளேயே கட்டுப்படுத்துகிறது. kernel-ஆல் நிறுத்தப்படும் ஒரு container, தன்னுடன் சேர்த்து அருகில் உள்ள மற்ற service-களையும் பாதிக்கும்.

எந்த VPS-க்கு எந்த stack பொருத்தமானது

• 1 GB, அல்லது கூடுதல் இடவசதியுடன் 2 GB: Valkey முடக்கப்பட்ட நிலையில் GlitchTip-ஐ all-in-one mode-ல் இயக்கலாம், அல்லது SQLite-ல் Bugsink-ஐப் பயன்படுத்தலாம். இவை இரண்டிற்கும் ஒரு சில applications-ஐக் கையாள்வதற்கு இந்த அளவு போதுமானது.
• 4 GB: PostgreSQL-உடன் Bugsink, அல்லது Valkey இயக்கப்பட்ட நிலையில் தனி worker service-உடன் GlitchTip-ஐப் பயன்படுத்தலாம். இந்த அளவில் நீங்கள் எதையும் மாற்றியமைக்கத் தேவையில்லை, நேரடியாக இயக்கலாம்.
• 8 GB: இது அதிகாரப்பூர்வ Sentry stack-க்கு இன்னும் போதாது. நீங்கள் தேர்ந்தெடுத்த இலகுவான விருப்பத்திற்கு, நீண்ட கால தரவு சேமிப்பு (retention window) மற்றும் கூடுதல் disk space-க்கு இந்த நினைவகத்தைப் பயன்படுத்தவும்.
• குறைந்தது 16 GB, 32 GB பரிந்துரைக்கப்படுகிறது: இது அதிகாரப்பூர்வ Sentry self-hosted stack-க்கான அளவு. இலகுவான திட்டங்களில் இல்லாத ஏதேனும் ஒரு குறிப்பிட்ட Sentry வசதி உங்களுக்குத் தேவைப்படும்போது மட்டுமே இதைத் தேர்ந்தெடுக்கவும். இலகுவான திட்டங்களே பொதுவான வசதிகளைக் கொண்டிருப்பதால், முதலில் அந்தந்த திட்டத்தின் ஆவணங்களைச் சரிபார்த்துவிட்டு, பிறகு முடிவெடுக்கவும்.

நீங்கள் எதை இயக்கினாலும், error tracker தனது சொந்த செயலிழப்பைப் பதிவு செய்ய முடியாது. எனவே, வேறொரு கணினியிலிருந்து அதைத் தொடர்ந்து கண்காணிக்கவும்: வேறொரு கணினியிலிருந்து கண்காணிக்கும் Uptime Kuma உங்கள் tracker செயலிழந்துள்ளதை உங்களுக்குத் தெரிவிக்கும். சரியாக அந்த நேரத்தில்தான் உங்கள் application பிழைகளை உருவாக்கத் தொடங்கும், ஆனால் அவற்றை யாரும் பதிவு செய்ய முடியாது.

ஹோஸ்ட் செய்யப்பட்ட திட்டம் எப்போது மலிவான தீர்வாகிறது

தரவு இருப்பிட விதிகள் (data residency rules) கட்டாயப்படுத்தும்போதோ அல்லது நிகழ்வுகளின் எண்ணிக்கை (event volume) அதிகமாக இருந்து, ஒவ்வொரு நிகழ்விற்கும் கட்டணம் செலுத்துவது பொருளாதார ரீதியாகப் பாதிக்கும்போதோ, error tracker-ஐ நீங்களே ஹோஸ்ட் செய்வது பலனளிக்கும். இந்தச் சூழல்களைத் தவிர, கணக்கீட்டை நேர்மையாகச் செய்யுங்கள். Sentry-க்குத் தேவையான குறைந்தபட்சத் தேவை 16 GB RAM, 4 cores மற்றும் வேகமான disk கொண்ட server ஆகும்; இவ்வளவு திறன் கொண்ட VPS மலிவானது அல்ல. அதனுடன் செயல்பாட்டு வேலைகளையும் சேர்த்துக்கொள்ளுங்கள்: ஒவ்வொரு hard stop-ஐயும் வரிசையாகக் கடப்பது, ஒவ்வொரு migration-க்கு முன்பும் snapshot எடுப்பது என ஆண்டுக்குச் சில முறை இதைச் செய்ய வேண்டியிருக்கும்.

GlitchTip மற்றும் Bugsink ஆகியவை இந்தக் கணக்கீட்டை முழுமையாக மாற்றுகின்றன, ஏனெனில் 512 MB முதல் 4 GB RAM கொண்ட ஒரு மலிவான server-லேயே இவற்றை இயக்க முடியும், மேலும் upgrade செய்வது ஒரு docker compose pull ஆகும். இதனால்தான், இந்த கேள்வியைக் கேட்கும் பெரும்பாலானோர் அதிகாரப்பூர்வ stack-க்குச் செல்வதற்குப் பதிலாக, இணக்கமான திட்டங்களில் ஒன்றைத் தேர்ந்தெடுக்கிறார்கள். அவர்களுக்குத் தேவை error tracking மட்டுமே, பராமரிக்க வேண்டிய distributed data pipeline அல்ல.

எந்தெந்தச் சேவைகளை server-ல் வைத்திருக்கலாம் என்று நீங்கள் இன்னும் முடிவு செய்யவில்லை என்றால், சுயமாக ஹோஸ்ட் செய்யத் தகுதியான சேவைகளின் விரிவான பட்டியல், error tracking-ஐ அதே RAM-க்காகப் போட்டியிடும் பிற சேவைகளுடன் ஒப்பிட்டுப் பார்க்க உதவுகிறது.

FAQ

2 GB VPS-ல் Sentry-ஐ என்னால் self-host செய்ய முடியுமா?

முடியாது. Sentry-ன் self-hosted ஆவணங்களின்படி, குறைந்தபட்சம் 4 CPU cores, 16 GB RAM, 16 GB swap மற்றும் 20 GB காலி வட்டு இடம் தேவை. இந்த stack-ல் Postgres, ClickHouse, Kafka, Redis மற்றும் பல worker processes ஒரே நேரத்தில் இயங்குவதால், சிறிய server-களில் நிறுவல் முடிவதற்கு முன்பே kernel containers-ஐ நிறுத்திவிடும். இதை உறுதிப்படுத்த dmesg -T | grep -i 'out of memory' கட்டளையைப் பயன்படுத்தவும்; இது நிறுத்தப்பட்ட process-ன் பெயரைத் திரையில் காட்டும். 2 GB VPS-க்கு 512 MB தேவைப்படும் GlitchTip-ஐப் பயன்படுத்தவும், அல்லது SQLite-ல் ஒரே container-ஆக இயங்கும் Bugsink-ஐப் பயன்படுத்தவும்.

Sentry-லிருந்து GlitchTip அல்லது Bugsink-க்கு மாறும்போது எனது application code-ஐ மாற்ற வேண்டுமா?

தேவையில்லை. இவை இரண்டுமே Sentry-ன் open source SDK-களிலிருந்து வரும் events-ஐ ஏற்கும். எனவே, நீங்கள் ஏற்கனவே நிறுவிய SDK-ஐ அப்படியே வைத்துக்கொண்டு, DSN என்ற ஒரே ஒரு மதிப்பை மட்டும் மாற்றினால் போதும். இது SDK events-ஐ அனுப்பும் URL ஆகும். இது hardcode செய்யப்பட்டிருந்தால், அதை environment variable-க்கு மாற்றி, புதிய host-க்குச் சுட்டிக்காட்டவும். பின் ஒரு test exception-ஐ உருவாக்கி, அது வந்து சேருகிறதா என்று கவனிக்கவும். எதுவும் வரவில்லை என்றால், DSN-ல் உள்ள project identifier புதிய server-ல் உள்ள project-உடன் ஒத்துப்போகிறதா என்பதையும், உங்கள் firewall அந்த host மற்றும் port-க்குத் தொடர்பை அனுமதிக்கிறதா என்பதையும் சரிபார்க்கவும்.

Self-hosted error tracking-க்கு எவ்வளவு வட்டு இடம் தேவை?

இது நீங்கள் பயன்படுத்தும் கருவியை விட, உங்கள் event அளவு மற்றும் retention window-ஐப் பொறுத்தது. மாதம் பத்து லட்சம் events-ஐக் கையாளும் instance-க்கு 30 GB தேவைப்படும் என்று GlitchTip குறிப்பிடுகிறது. Bugsink-ல் MAX_RETENTION_EVENT_COUNT மற்றும் MAX_EVENT_AGE_DAYS மூலம் நீங்கள் நேரடியாக வரம்பை அமைக்கலாம்; எனவே நீங்கள் நிர்ணயிக்கும் உச்சவரம்பைப் பொறுத்தே வட்டுத் தேவை அமையும். முதல் நாளிலேயே retention-ஐ configure செய்யவும். Retention policy இல்லாத tracker, df -h 100% ஆகும் வரை வளர்ந்துகொண்டே இருக்கும். அந்த நிலையில் ingest நின்றுவிடும், நீங்கள் பார்க்க விரும்பிய முக்கியமான பிழைகளை இழக்க நேரிடும்.

Self-hosted Sentry-ஐ upgrade செய்யும்போது ஏன் தோல்வியடைகிறது?

ஏனெனில், upgrade செய்யும்போது ஒரு கட்டாய இடைநிறுத்தத்தை (hard stop) நீங்கள் தவிர்த்திருக்கலாம். Sentry self-hosted-ல் சில குறிப்பிட்ட பதிப்புகள் உள்ளன; அவற்றின் வழியாகவே database migrations-ஐ மேற்கொள்ள வேண்டும். ஆகஸ்ட் 2026 நிலவரப்படி, அவை 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 மற்றும் 26.7.0 ஆகும். பழைய பதிப்பிலிருந்து நேரடியாகப் புதிய பதிப்பிற்கு மாறும்போது இந்த migrations விடுபட்டுவிடும். இதனால் schema மற்றும் code ஒத்துப்போகாமல் upgrade பாதியிலேயே நின்றுவிடும். ஒவ்வொரு hard stop-ஐயும் வரிசையாகச் சரிபார்த்து, ஒவ்வொன்றிலும் ./install.sh கட்டளையை இயக்கவும். தொடங்குவதற்கு முன் server-ஐ snapshot எடுக்கவும். 23.7.0, 25.9.0 மற்றும் 25.12.0 போன்ற தவிர்க்க வேண்டிய பதிப்புகளின் பட்டியலை ஆவணங்களில் சரிபார்க்கவும்.