Sentry కి బదులుగా ఉత్తమమైన self-hosted ఎర్రర్ ట్రాకింగ్

ఒక ఈవెంట్‌ను నిల్వ చేయడానికి ముందే self-hosted ఎర్రర్ ట్రాకింగ్ ఖర్చు ఎంత

Self-hosted ఎర్రర్ ట్రాకింగ్ విషయంలో మొత్తం నిర్ణయాన్ని ప్రభావితం చేసే ఒకే ఒక సంఖ్య ఉంది, అదే RAM కనీస అవసరం (RAM floor). Sentry యొక్క స్వంత self-hosted డాక్యుమెంటేషన్ ప్రకారం, మీ అప్లికేషన్ ఒక్క ఈవెంట్‌ను పంపకముందే, దానికి 4 CPU కోర్లు, 16 GB RAM మరియు 16 GB swap, అలాగే 20 GB ఖాళీ డిస్క్ స్థలం అవసరం. GlitchTip కేవలం 512 MB అవసరమని పేర్కొంటుంది. ఇక్కడ ఉన్న అన్ని ఎంపికలు ఒకే రకమైన Sentry SDKల నుండి ఈవెంట్‌లను స్వీకరిస్తాయి, కాబట్టి ఇది మీ కోడ్‌ను ఎలా ఇన్‌స్ట్రుమెంట్ చేయాలనే దానిపై తీసుకునే నిర్ణయం కాదు. ఇది మీరు ఎంత పెద్ద సర్వర్‌కు చెల్లించడానికి మరియు దానిని నిరంతరం నడపడానికి సిద్ధంగా ఉన్నారనే దానిపై తీసుకునే నిర్ణయం.

ప్రచురించబడిన వనరుల గణాంకాలు, పక్కపక్కన

ఇవి ఆగస్టు 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) బెంచ్‌మార్క్ కోసం ఉపయోగించిన సర్వర్ సామర్థ్యం. ప్రచురించబడిన గణాంకం అనేది ఒక ప్రారంభ బిందువు మాత్రమే, అది మీ ఈవెంట్ వాల్యూమ్‌కు సంబంధించిన హామీ కాదు.

Sentry self-hosted: పూర్తి ఉత్పత్తి మరియు పూర్తి బాధ్యత

అధికారిక stack అనేది getsentry/self-hosted, ఇది Sentry ప్రొడక్షన్‌లో ఉపయోగించే అదే భాగాలను నడిపే ఒక Docker Compose ప్రాజెక్ట్. దీని డాక్యుమెంటేషన్ దీన్ని "తక్కువ పరిమాణంలో వాడే డిప్లాయ్‌మెంట్‌లు మరియు ప్రూఫ్-ఆఫ్-కాన్సెప్ట్‌ల కోసం ఫీచర్-కంప్లీట్ మరియు ప్యాకేజ్ చేయబడినది" అని పేర్కొంటుంది. ఆ వాక్యం దీనికి నిజాయితీ గల సారాంశం. మీరు ప్రతి ఫీచర్‌ను పొందుతారు, మరియు ఆ ఫీచర్లు పనిచేయడానికి అవసరమైన ప్రతి భాగాన్ని కూడా పొందుతారు.

master నుండి కాకుండా, ట్యాగ్ చేయబడిన 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 పై వింటుంది (listens). Docker Engine 19.03.6 లేదా అంతకంటే కొత్తది మరియు Docker Compose 2.32.2 లేదా అంతకంటే కొత్తది అవసరం. పాత Compose వెర్షన్లు Sentry వల్ల కాకుండా, ఫైల్ సింటాక్స్ వల్ల విఫలమవుతాయి.

మీరు వాస్తవానికి ఏమి ప్రారంభించారో చూడండి:

docker compose ps
free -h

docker compose ps ఈ stack లోని ప్రతి సేవను జాబితా చేస్తుంది, మరియు ఈ జాబితా చాలా పెద్దది: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator, మరియు అనేక worker మరియు cron ప్రాసెస్‌లు. వీటిని ఒకసారి లెక్కించండి, ఎందుకంటే ఆ సంఖ్యే మీ నిర్వహణ భారం. ప్రతి ఎంట్రీ ఒక ప్రాసెస్; అది క్రాష్ అవ్వవచ్చు, డిస్క్ నింపేయవచ్చు లేదా మైగ్రేషన్ విఫలం కావచ్చు.

ఒక సేవ Restarting స్థితిలో ఉంటే, వేటికన్నా ముందు మెమరీని చూడండి:

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

Out of memory: Killed process 3412 (java) వంటి లైన్ ఉందంటే, సర్వర్‌లో RAM అయిపోవడం వల్ల కెర్నల్ యొక్క OOM killer (out of memory killer) ఒక కంటైనర్‌ను తొలగించిందని అర్థం. కాబట్టి ఆ సేవ ఆరోగ్యకరమైన స్థితికి రాదు మరియు stack ప్రారంభం పూర్తి కాదు. డాక్యుమెంటేషన్‌లో పేర్కొన్న కనీస అవసరాల కంటే తక్కువ వనరులతో పూర్తి stack ను నడపడం వల్ల ఇలా జరుగుతుంది. డాక్యుమెంటేషన్ డిస్క్ వేగాన్ని కూడా సూచిస్తుంది: పైన iowait 10% కంటే ఎక్కువ ఉంటే, ingest pipeline వేగాన్ని మెషిన్ అందుకోలేకపోతోందని అర్థం. దీన్ని top లోని wa కాలమ్ నుండి, లేదా మీరు sysstat ఇన్‌స్టాల్ చేసి ఉంటే iostat -x 5 నుండి చదవండి.

అప్‌గ్రేడ్‌లు అంటే ప్రజలు తక్కువ అంచనా వేసే అంశం

Sentry self-hosted ప్రతి నెలా 15వ తేదీన ప్రధాన release తో, CalVer (క్యాలెండర్ ఆధారిత వెర్షన్ స్కీమ్) ప్రకారం విడుదలవుతుంది. మీరు పాత వెర్షన్ నుండి నేరుగా తాజా వెర్షన్‌కు వెళ్లలేరు. ప్రాజెక్ట్ కొన్ని కచ్చితమైన stop వెర్షన్లను నిర్దేశిస్తుంది. డేటాబేస్ మైగ్రేషన్‌లను పూర్తి చేయడానికి మీరు ప్రతి వెర్షన్ ద్వారా వెళ్లాల్సిందే. ఆగస్టు 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. మైగ్రేషన్ సమస్యల కారణంగా దాటవేయవలసిన release లను కూడా డాక్యుమెంటేషన్ పేర్కొంటుంది; వీటిలో 23.7.0, 25.9.0, 25.12.0 మరియు 26.3.0 నుండి 26.4.0 పరిధి ఉన్నాయి.

అప్‌గ్రేడ్ అంటే కోడ్‌ను checkout చేయడం మరియు ఇన్‌స్టాలర్‌ను మళ్లీ రన్ చేయడం:

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

ప్రారంభించే ముందు సర్వర్ స్నాప్‌షాట్ తీసుకోండి, ఎందుకంటే పెద్ద ClickHouse డేటాసెట్‌పై మైగ్రేషన్ గంటల తరబడి జరగవచ్చు. మధ్యలో విఫలమైతే డేటాబేస్ రెండు స్కీమాల మధ్య చిక్కుకుపోతుంది. చాలా వరకు self-hosted Sentry అప్‌గ్రేడ్‌లు విఫలమవ్వడానికి ప్రధాన కారణం: సర్వర్ ఒకే వెర్షన్ వద్ద ఏడాది పాటు ఉండిపోవడం. దీనివల్ల అప్‌గ్రేడ్ చేసేటప్పుడు ఒకేసారి అనేక hard stop లను దాటాల్సి వస్తుంది, ఆ క్రమంలో ముఖ్యమైన మైగ్రేషన్ ఒకటి మిస్ అవుతుంది.

మీరు నిర్ణయం తీసుకునే ముందు తెలుసుకోవలసిన మరో విషయం. Sentry self-hosted అనేది Functional Source License (FSL) కింద ఉంది, దీన్ని Sentry స్వయంగా ప్రవేశపెట్టింది. ఇది OSI ఆమోదించిన ఓపెన్ సోర్స్ కాదు, ఇది "fair source": మీరు దీన్ని మీ సొంత అవసరాలకు వాడుకోవచ్చు, కానీ పోటీ సేవగా విక్రయించకూడదు. ప్రతి release విడుదలైన రెండు సంవత్సరాల తర్వాత Apache 2.0 లైసెన్స్‌లోకి మారుతుంది.

GlitchTip: 512 MB సమాధానం

GlitchTip అనేది MIT లైసెన్స్ కలిగిన సాఫ్ట్‌వేర్. ఇది Sentry యొక్క ఓపెన్ సోర్స్ SDKల నుండి ఈవెంట్‌లను స్వీకరిస్తుంది. కాబట్టి, ఒక అప్లికేషన్‌లో DSN (data source name, మీ SDK ఈవెంట్‌లను పంపే URL) విలువను మార్చడం ద్వారా మీరు సులభంగా దీనికి మారవచ్చు. దీనికి PostgreSQL 14 లేదా అంతకంటే కొత్త వెర్షన్ అవసరం. Valkey లేదా Redis 7 లేదా అంతకంటే కొత్త వెర్షన్ ఐచ్ఛికం, ఇది పెద్ద ఇన్‌స్టాన్స్‌లను వేగవంతం చేస్తుంది.

దీని ఇన్‌స్టాలేషన్ కోసం Docker మరియు ఒక compose ఫైల్ అవసరం:

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 సేవకు అనుసంధానిస్తుంది, కాబట్టి మీరు వేరే చోట డేటాబేస్‌ను రన్ చేస్తుంటే తప్ప, ఆ లైన్‌ను మార్చవద్దు. GLITCHTIP_DOMAIN లో తప్పనిసరిగా scheme ఉండాలి. ముందు భాగంలో https:// లేకపోతే, అలర్ట్ ఈమెయిల్‌లలోని లింక్‌లు తప్పుగా తయారవుతాయి మరియు స్పందించని URLకి దారితీస్తాయి.

దీనిని ప్రారంభించి మొదటి బూట్‌ను గమనించండి:

docker compose up -d
docker compose logs -f web

ఆగస్టు 2026 నాటికి ఈ నమూనాలోని image tags postgres:18, valkey/valkey:9 మరియు glitchtip/glitchtip:6 గా ఉన్నాయి. వీటిని అలాగే ఉంచండి. latest అని ఉన్న compose ఫైల్, తదుపరి docker compose pull సమయంలో మీ డేటాబేస్ ఇంజిన్‌ను అప్‌గ్రేడ్ చేస్తుంది. రన్ అవుతున్న ఇన్‌స్టాన్స్ కింద Postgres మేజర్ వెర్షన్ మారితే, పనిచేస్తున్న ఎర్రర్ ట్రాకర్ ఆగిపోయే అవకాశం ఉంది.

256 MB నుండి 512 MB పరిధిని చేరుకోవడానికి, నమూనా ఫైల్‌లోని కామెంట్లలో పేర్కొన్న విధంగా Valkey మరియు ఐచ్ఛిక log, uptime ఫీచర్లను ఆఫ్ చేయండి. Valkey లేకుండా రన్ చేయడం అంటే GlitchTip తన డేటాబేస్‌ను cache మరియు queue పనుల కోసం వాడుకుంటుందని అర్థం; ఇది నెమ్మదిగా ఉన్నప్పటికీ సరైనదే. All in one మోడ్, worker ను web ప్రాసెస్ లోపలే రన్ చేస్తుంది, కాబట్టి మీరు రెండు కంటైనర్లకు బదులుగా ఒక అప్లికేషన్ కంటైనర్‌ను మాత్రమే నిర్వహిస్తారు.

దీని ముందు ఒక proxy ని ఉంచండి. GlitchTip డాక్యుమెంటేషన్ అభ్యర్థనలను బఫర్ చేసే మరియు chunked Transfer-Encoding ను హ్యాండిల్ చేసే proxy లేదా load balancer ను సిఫార్సు చేస్తుంది. దీనికి nginx ను ఉదాహరణగా ఇచ్చారు. బఫరింగ్ లేకపోతే, నెమ్మదిగా ఉన్న క్లయింట్ అప్‌లోడ్ పూర్తయ్యే వరకు అప్లికేషన్ worker ను ఆక్రమిస్తుంది. దీనివల్ల కొన్ని నెమ్మదైన కనెక్షన్లు మీ వద్ద ఉన్న అన్ని worker లను ఆక్రమించి, ఆరోగ్యకరమైన క్లయింట్లు timeout అయ్యేలా చేస్తాయి.

అప్‌గ్రేడ్ చేయడం చాలా సులభం:

docker compose pull
docker compose stop
docker compose up -d

డేటాబేస్ మైగ్రేషన్లు ప్రారంభంలోనే ఆటోమేటిక్‌గా జరుగుతాయి. ఏది ఏమైనప్పటికీ, ముందుగా ఒక dump తీసుకోండి, ఎందుకంటే ఆటోమేటిక్ మైగ్రేషన్ అయినా అది మైగ్రేషనే.

Bugsink: ఒక కంటైనర్, మరియు మీరు తప్పక చదవాల్సిన లైసెన్స్

Bugsink ఈ మూడింటిలో అత్యంత తేలికైనది. ఇది Sentry SDK ప్రోటోకాల్‌ను ఉపయోగిస్తుంది, మరియు దీనికి మెసేజ్ క్యూ లేదా డేటాబేస్ తప్ప మరే ఇతర బాహ్య సేవ అవసరం లేదు. SQLite డిఫాల్ట్‌గా ఉంటుంది, ఒకవేళ మీకు ఇది సరిపోకపోతే MySQL మరియు PostgreSQL లను కూడా ఉపయోగించవచ్చు.

మీరు నిర్ణయం తీసుకునే ముందు ఇంటర్‌ఫేస్‌ను చూడటానికి, ఒక తాత్కాలిక ఇన్‌స్టాన్స్ ఇక్కడ ఉంది:

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 లో మీరు ఇచ్చిన అడ్రస్ మరియు పాస్‌వర్డ్‌తో సైన్ ఇన్ అవ్వండి. ఆ కంటైనర్ ఆగిపోయినప్పుడు ఏ సమాచారాన్ని దాచుకోదు. నిజమైన ఇన్‌స్టాన్స్ కోసం ప్రాజెక్ట్ యొక్క compose శాంపిల్‌ను తీసుకోండి, ఇది bugsink/bugsink:2 ని postgres:17-alpine తో జత చేస్తుంది మరియు DATABASE_URL, BASE_URL, మరియు BEHIND_HTTPS_PROXY లను సెట్ చేస్తుంది. సీక్రెట్‌ను సరిగ్గా జనరేట్ చేయండి:

openssl rand -base64 50

BASE_URL అనేది మీ వినియోగదారులు మరియు SDKలు నిజంగా ఉపయోగించే URLకి సరిపోలాలి, ఇందులో స్కీమ్ కూడా ఉండాలి. మీరు https://errors.example.com ద్వారా యాక్సెస్ చేసే సర్వర్‌లో దీన్ని http://localhost:8000 వద్దే వదిలేస్తే, నోటిఫికేషన్ ఈమెయిల్‌లోని ప్రతి లింక్ దాన్ని చదివే వ్యక్తికి రిజాల్వ్ కాని హోస్ట్‌కు దారితీస్తుంది. Nginx లేదా Caddy దీని ముందు TLS (transport layer security) ను టెర్మినేట్ చేస్తున్నప్పుడు BEHIND_HTTPS_PROXY ని true కి సెట్ చేయండి, లేకపోతే Bugsink మీ https:// ప్రాక్సీ వెనుక http:// URLలను నిర్మిస్తుంది మరియు బ్రౌజర్‌లు ఆ మిశ్రమ కంటెంట్‌ను బ్లాక్ చేస్తాయి.

వెండర్ తన సొంత త్రూపుట్ గణాంకాలను ప్రచురించారు: 2 vCPU మరియు 4 GB VPS పై, ఒక్కొక్కటి 50 KB పరిమాణం గల 18 ఈవెంట్‌లు సెకనుకు, అంటే రోజుకు 1.5 మిలియన్ ఈవెంట్‌లు. దీన్ని మీ వర్క్‌లోడ్‌కు గ్యారెంటీగా కాకుండా, టూల్ యొక్క సామర్థ్యంగా పరిగణించండి. ఇది ఒక చిన్న అప్లికేషన్ ఉత్పత్తి చేసే దానికంటే చాలా ఎక్కువ సామర్థ్యాన్ని కలిగి ఉందని తెలియజేస్తుంది.

ఇక లైసెన్స్ విషయం, ఇది మీ స్టాక్‌లో చేర్చుకునే ముందు మీరు తప్పక చదవాల్సిన భాగం. Bugsink ను PolyForm Shield License 1.0.0 కింద విడుదల చేశారు. ఇది సోర్స్ అవైలబుల్, ఓపెన్ సోర్స్ కాదు: మీరు దీన్ని రన్ చేయవచ్చు మరియు మార్పులు చేయవచ్చు, కానీ Bugsink తో పోటీ పడే దేనినైనా నిర్మించడానికి దీన్ని ఉపయోగించకూడదు. అంతర్గత ఎర్రర్ ట్రాకర్ కోసం ఈ నిబంధన ఎటువంటి సమస్యను కలిగించదు. ఒకవేళ మీ కంపెనీ డెవలపర్ టూలింగ్‌ను విక్రయిస్తుంటే, ముందుగా లైసెన్స్ టెక్స్ట్‌ను ఎవరైనా చదివేలా చూడండి.

Error tracking మరియు LLM observability ఇప్పటికీ రెండు వేర్వేరు సాధనాలు

Error tracking మరియు large language model (LLM) observability రెండింటినీ కలిపి అందించే ఒకే సాధనం కోసం వెతికితే, రెండింటినీ అందిస్తామని చెప్పుకునే ఉత్పత్తులు కనిపిస్తాయి. కానీ వాటి డేటా నిర్మాణాలు వేరుగా ఉండటం వల్ల, ఈ రెండింటి విలీనం సాధ్యపడటం లేదు. ఒక error tracker మినహాయింపును (exception) దాని stack trace తో సహా స్వీకరించి, దాని నుండి ఒక fingerprint ను రూపొందించి, వేలకొద్దీ సంఘటనలను ఒకే సమస్యగా మార్చి లెక్కిస్తుంది. ఒక LLM tracing సాధనం మాత్రం prompt, response, token count మరియు latency ఉన్న span ను స్వీకరిస్తుంది. ఇది ప్రతి సంఘటనను భద్రపరచాలి, ఎందుకంటే ఒకే రకమైన inputs ఉన్న రెండు calls కూడా విడివిడి సంఘటనలే, వాటిని విడిగా పరిశీలించాల్సి ఉంటుంది.

కాబట్టి రెండింటినీ ఉపయోగించండి. Exceptions ను error tracker కు పంపండి, మరియు model calls ను వాటి కోసం ప్రత్యేకంగా రూపొందించిన చోటికి పంపండి: agent tracing కోసం self-hosted Langfuse ఆ అవసరాన్ని తీరుస్తుంది, మరియు self-hosted AI observability అదే పనిని వేరొక కోణంలో చూస్తుంది. మీ అప్లికేషన్ ఇప్పటికే ఈ రెండు రకాల వైఫల్యాలను ఉత్పత్తి చేస్తోంది. ఒక model call నమ్మదగిన తప్పుడు సమాచారాన్ని (confident nonsense) ఇచ్చినప్పుడు ఎటువంటి exception రాదు, కాబట్టి error tracker దానిని మీకు ఎప్పటికీ చూపించదు.

డిస్క్ నిండిపోవడం అనేది ఆలస్యంగా తెలిసే వైఫల్యం

ప్రతి ఎర్రర్ ట్రాకర్ అనేది అపరిమితమైన ఇన్‌పుట్‌తో కూడిన రైట్-హెవీ డేటాబేస్. మీ అప్లికేషన్ ఎంత డేటాను రాస్తుందో అదే నిర్ణయిస్తుంది, కాబట్టి తరచుగా రన్ అయ్యే కోడ్ పాత్‌లో ఒక చిన్న బగ్ ఉన్నా, రాత్రికి రాత్రే మిలియన్ల కొద్దీ ఈవెంట్‌లు తయారవ్వచ్చు.

GlitchTip ఒక అంచనాను అందిస్తుంది: నెలకు మిలియన్ ఈవెంట్‌లను హ్యాండిల్ చేసే ఇన్‌స్టాన్స్‌కు 30 GB డిస్క్ అవసరం కావచ్చు. ఇది ఆ రేటుతో ఒక నెల ఇన్‌జెస్ట్‌ను కవర్ చేస్తుంది, మరియు మీరు ఎన్ని నెలల డేటాను నిల్వ ఉంచాలనుకుంటున్నారో దానిపై మీ రిటెన్షన్ విండో ఆధారపడి ఉంటుంది.

Bugsink దీనిని మరో కోణంలో చూస్తుంది. ఇది స్థిరమైన కోటాకు బదులుగా, ఈవెంట్ కౌంట్ మరియు ఈవెంట్ వయస్సు ఆధారంగా రిటెన్షన్ అల్గారిథమ్‌ను వర్తింపజేస్తుంది. ఇది పరిమితులను నేరుగా చూపిస్తుంది: మొత్తం ఇన్‌స్టాలేషన్ కోసం MAX_RETENTION_EVENT_COUNT, ప్రతి ప్రాజెక్ట్‌కు MAX_RETENTION_PER_PROJECT_EVENT_COUNT, మరియు ఖచ్చితమైన కట్-ఆఫ్ కోసం MAX_EVENT_AGE_DAYS. ఇన్‌స్టాలేషన్ మొత్తానికి ఈవెంట్ బడ్జెట్‌ను సెట్ చేయడం అనేది డిస్క్ పరిమాణాన్ని నిర్ణయించడానికి సరైన మార్గం, ఎందుకంటే ఆ బడ్జెట్టే డిస్క్ వినియోగాన్ని నిర్ణయిస్తుంది.

సర్వర్‌లోని అసలైన సంఖ్యలను గమనించండి:

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

docker system df -v ప్రతి వాల్యూమ్ పరిమాణాలను చూపుతుంది, దీని ద్వారా ఏ సర్వీస్ వల్ల డిస్క్ పెరుగుతుందో మీరు చూడవచ్చు. ట్రాఫిక్‌లో ఎటువంటి మార్పు లేకుండానే ఒక వాల్యూమ్ వారానికి కొన్ని గిగాబైట్ల డేటాను పెంచుకుంటుంటే, రిటెన్షన్ కాన్ఫిగర్ చేయబడలేదని అర్థం. అప్పుడు ఏదీ డిలీట్ అవ్వదు మరియు పార్టిషన్ నిండే వరకు డేటా పెరుగుతూనే ఉంటుంది.

మెమరీ సమస్య కూడా దాదాపు ఇలాంటిదే. ఎటువంటి పరిమితులు లేని స్టాక్, కెర్నల్ అనుమతించినంత మెమరీని తీసుకుంటుంది. మెమరీ అయిపోయినప్పుడు, OOM కిల్లర్ అతిపెద్ద ప్రాసెస్‌ను తొలగిస్తుంది. అది సమస్యను సృష్టించిన ట్రాకర్ కాకుండా, మీ వెబ్ సర్వర్ అయ్యే అవకాశం ఉంది. ప్రతి సర్వీస్‌కు ఒక గరిష్ట పరిమితిని విధించండి: memory limits in Docker Compose లో దీనికి సంబంధించిన సింటాక్స్ మరియు పరిమితిని చేరుకున్నప్పుడు కంటైనర్ ఎలా స్పందిస్తుందో చూడవచ్చు. తన సొంత పరిమితి వద్ద ఆగిపోయిన కంటైనర్ వల్ల వైఫల్యం అక్కడికే పరిమితమవుతుంది. కెర్నల్ ద్వారా తొలగించబడిన కంటైనర్ తనతో పాటు పక్కన ఉన్న సర్వీసులను కూడా పడగొడుతుంది.

ఏ VPS కు ఏ stack సరిపోతుంది

• 1 GB, లేదా ఖాళీ స్థలం ఉన్న 2 GB: Valkey ని ఆపివేసి all-in-one మోడ్‌లో GlitchTip, లేదా SQLite పై Bugsink. కొన్ని అప్లికేషన్ల వరకు ఇవి రెండూ ఇక్కడ సౌకర్యవంతంగా పనిచేస్తాయి.
• 4 GB: PostgreSQL తో Bugsink, లేదా Valkey ఆన్ చేసి ప్రత్యేక worker service తో GlitchTip. ఈ పరిమాణం వద్ద మీరు ట్యూనింగ్ ఆపి, నేరుగా రన్ చేయవచ్చు.
• 8 GB: ఇది ఇప్పటికీ అధికారిక Sentry stack కు సరిపోదు. మీరు ఎంచుకున్న ఏదైనా తేలికపాటి ఆప్షన్ కోసం ఎక్కువ retention window మరియు పెద్ద డిస్క్ కోసం దీనిని ఉపయోగించండి.
• కనీసం 16 GB, 32 GB సిఫార్సు చేయబడింది: అధికారిక Sentry self-hosted stack కోసం ఇది అవసరం. తేలికపాటి ప్రాజెక్టులలో లేని ఏదైనా Sentry ఫీచర్ మీకు అవసరమైనప్పుడు మాత్రమే దీనిని వాడండి. ముందుగా ప్రతి ప్రాజెక్ట్ డాక్యుమెంటేషన్‌లో ఆ ఫీచర్‌ను సరిచూసుకోండి, ఎందుకంటే అనుకూలమైన ప్రాజెక్టులు సాధారణ ఫీచర్లన్నింటినీ కవర్ చేస్తాయి.

మీరు దేనిని రన్ చేసినా, error tracker తన సొంత వైఫల్యాన్ని తానే రిపోర్ట్ చేయలేదు. వేరొక మెషీన్ నుండి దానిపై ఒక చెక్ ఉంచండి: మరొక బాక్స్ నుండి పర్యవేక్షిస్తున్న Uptime Kuma ట్రాకర్ డౌన్ అయిందని మీకు తెలియజేస్తుంది. మీ అప్లికేషన్ ఎర్రర్లను చూపడం మొదలుపెట్టి, వాటిని ఎవరూ రికార్డ్ చేయని సమయం అదే.

హోస్ట్ చేసిన ప్లాన్ ఎప్పుడు చౌకైన పరిష్కారం అవుతుంది

డేటా రెసిడెన్సీ నిబంధనలు తప్పనిసరి చేసినప్పుడు లేదా ఈవెంట్ వాల్యూమ్ ఎక్కువగా ఉండి, ప్రతి ఈవెంట్‌కు చెల్లించే ధర భారం అనిపించినప్పుడు ఎర్రర్ ట్రాకర్‌ను self-hosting చేయడం లాభదాయకం. ఆ సందర్భాలు కాకుండా, మిగిలిన సమయాల్లో లెక్కలను నిజాయితీగా వేసుకోవాలి. Sentry అధికారికంగా సూచించిన కనీస అవసరం 16 GB RAM, 4 cores మరియు వేగవంతమైన డిస్క్ కలిగిన సర్వర్. అంత సామర్థ్యం ఉన్న VPS చౌకైనది కాదు. ఆపై నిర్వహణ పనిని కూడా పరిగణనలోకి తీసుకోవాలి: ప్రతి అప్‌గ్రేడ్ సమయంలో కఠినమైన దశలను అనుసరించడం మరియు ప్రతి migration కు ముందు snapshot తీసుకోవడం వంటివి ఏడాదికి కొన్నిసార్లు చేయాల్సి ఉంటుంది.

GlitchTip మరియు Bugsink ఈ లెక్కలను పూర్తిగా మారుస్తాయి, ఎందుకంటే 512 MB నుండి 4 GB RAM కలిగిన సర్వర్ తక్కువ ధరకే లభిస్తుంది మరియు అప్‌గ్రేడ్ చేయడం కూడా ఒక docker compose pull మాత్రమే. అందుకే ఈ ప్రశ్న అడిగే వారిలో ఎక్కువ మంది అధికారిక స్టాక్‌కు బదులుగా ఈ అనుకూల ప్రాజెక్టుల వైపు మొగ్గు చూపుతారు. వారికి కావాల్సింది ఎర్రర్ ట్రాకింగ్ మాత్రమే, నిరంతరం పర్యవేక్షించాల్సిన distributed data pipeline కాదు.

సర్వర్‌లో దేనిని ఉంచాలో ఇంకా నిర్ణయించుకోలేకపోతే, self-hosting కు తగిన సేవల విస్తృత జాబితా లో ఎర్రర్ ట్రాకింగ్‌ను, అదే RAM కోసం పోటీ పడే ఇతర సేవల పక్కన ఉంచి చూడవచ్చు.

FAQ

నేను 2 GB VPS పై Sentry ని self-host చేయవచ్చా?

లేదు. Sentry యొక్క self-hosted డాక్యుమెంటేషన్ ప్రకారం కనీసం 4 CPU కోర్లు, 16 GB RAM, అదనంగా 16 GB swap మరియు 20 GB ఖాళీ డిస్క్ అవసరం. ఈ stack లో Postgres, ClickHouse, Kafka, Redis మరియు అనేక worker processes ఒకేసారి నడుస్తాయి, కాబట్టి చిన్న సర్వర్లలో ఇన్‌స్టాలేషన్ పూర్తికాకముందే kernel కంటైనర్లను నిలిపివేస్తుంది (kill చేస్తుంది). దీన్ని dmesg -T | grep -i 'out of memory' ద్వారా నిర్ధారించుకోవచ్చు, ఇది నిలిపివేయబడిన ప్రాసెస్ పేరును చూపిస్తుంది. 2 GB VPS కోసం GlitchTip వాడండి (దీనికి 512 MB సరిపోతుంది), లేదా SQLite పై ఒకే కంటైనర్‌గా నడిచే Bugsink ను వాడండి.

Sentry నుండి GlitchTip లేదా Bugsink కి మారడానికి నా అప్లికేషన్ కోడ్‌ను మార్చాలా?

అవసరం లేదు. రెండూ Sentry యొక్క open source SDKల నుండి వచ్చే ఈవెంట్‌లను స్వీకరిస్తాయి. కాబట్టి మీరు ఇప్పటికే ఇన్‌స్టాల్ చేసిన SDKని అలాగే ఉంచి, ఒక విలువను మాత్రమే మార్చాలి: అదే DSN, అంటే SDK ఈవెంట్‌లను పంపే URL. ఒకవేళ అది కోడ్‌లో hardcode చేసి ఉంటే, దాన్ని environment variable లోకి మార్చి, కొత్త host కి పాయింట్ చేయండి. ఆ తర్వాత ఒక test exception ని పంపి అది అందుతుందో లేదో చూడండి. ఒకవేళ ఏమీ కనిపించకపోతే, DSN లోని project identifier కొత్త సర్వర్‌లోని ప్రాజెక్ట్‌తో సరిపోలుతుందో లేదో, మరియు మీ firewall ఆ host మరియు port కి కనెక్ట్ అవ్వడానికి అనుమతిస్తుందో లేదో తనిఖీ చేయండి.

self-hosted error tracking కి ఎంత డిస్క్ అవసరం?

ఇది మీరు వాడే టూల్ కంటే, మీ ఈవెంట్ వాల్యూమ్ మరియు retention window పై ఆధారపడి ఉంటుంది. నెలకు పది లక్షల ఈవెంట్‌లను హ్యాండిల్ చేసే instance కోసం GlitchTip 30 GB డిస్క్ అవసరమని పేర్కొంది. Bugsink లో మీరు MAX_RETENTION_EVENT_COUNT మరియు MAX_EVENT_AGE_DAYS ద్వారా నేరుగా బడ్జెట్‌ను సెట్ చేయవచ్చు, కాబట్టి మీరు పరిమితిని నిర్ణయిస్తే దానికి తగినట్లుగా డిస్క్ అవసరం ఉంటుంది. మొదటి రోజే retention ను కాన్ఫిగర్ చేయండి. ఎటువంటి retention policy లేని tracker, df -h 100% అయ్యే వరకు పెరుగుతూనే ఉంటుంది. ఆ స్థితికి చేరుకున్నాక ingest ఆగిపోతుంది మరియు మీరు చూడాలనుకున్న ముఖ్యమైన errors కోల్పోతారు.

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. పాత release నుండి నేరుగా కొత్త దానికి వెళ్తే ఈ migrations జరగవు, ఫలితంగా schema మరియు code మధ్య వ్యత్యాసం వచ్చి upgrade మధ్యలోనే ఆగిపోతుంది. ప్రతి hard stop వెర్షన్‌ను క్రమపద్ధతిలో చెక్ చేసి, ప్రతి దశలో ./install.sh రన్ చేయండి. ప్రారంభించే ముందు సర్వర్ snapshot తీసుకోండి. అలాగే, 23.7.0, 25.9.0 మరియు 25.12.0 వంటి నివారించాల్సిన releases జాబితాను డాక్యుమెంటేషన్‌లో చదవండి.