Sentry पर्याय: self-hosted error tracking साठी तुलना

एक event साठवण्यापूर्वी self-hosted error tracking चा खर्च

self-hosted error tracking निवडताना एक आकडा संपूर्ण निर्णय ठरवतो: RAM ची किमान आवश्यकता. Sentry च्या अधिकृत self-hosted दस्तऐवजांनुसार, तुमच्या अॅप्लिकेशनकडून एकही event पाठवला जाण्यापूर्वी 4 CPU cores, 16 GB RAM, त्यासोबत 16 GB swap आणि 20 GB मोकळी disk space आवश्यक आहे. GlitchTip साठी 512 MB आवश्यकता नमूद केली आहे. येथे दिलेले सर्व पर्याय समान Sentry SDKs कडून events स्वीकारतात. त्यामुळे हा निर्णय तुम्ही तुमच्या कोडमध्ये instrumentation कसे केले आहे याबद्दल नाही. तुम्ही किती मोठ्या 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 हे कार्यरत किमान मूल्य आहे; काळजीपूर्वक configuration केल्यास 128 MB आणि swap पुरेसे ठरू शकतात. Bugsink चे 4 GB यांपैकी कोणतेही नाही. विक्रेत्याने स्वतःच्या throughput benchmark साठी वापरलेला सर्व्हर हा आकडा दर्शवतो. प्रकाशित आकडा हा सुरुवातीचा संदर्भ असतो; तुमच्या event volume बद्दलची हमी नसते.

Sentry self-hosted: संपूर्ण उत्पादन आणि संपूर्ण बिल

अधिकृत stack म्हणजे getsentry/self-hosted. हा Docker Compose project Sentry production मध्ये चालवत असलेलेच components चालवतो. त्याच्या documentation मध्ये याचे वर्णन “low-volume deployments आणि proofs-of-concept साठी feature-complete आणि packaged up” असे केले आहे. हेच त्याचे प्रामाणिक सारांश आहे. तुम्हाला प्रत्येक feature मिळतो आणि ते features कार्यरत ठेवणारे प्रत्येक moving part देखील मिळते.

master ऐवजी tagged release मधून install करा:

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 default ने http://127.0.0.1:9000 वर listen करते. Docker Engine 19.03.6 किंवा त्यानंतरची आवृत्ती आणि Docker Compose 2.32.2 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. जुने Compose Sentry मुळे नव्हे, तर file syntax मुळे fail होते.

तुम्ही प्रत्यक्षात काय सुरू केले ते पाहा:

docker compose ps
free -h

docker compose ps stack मधील प्रत्येक service दाखवते आणि ही यादी मोठी आहे: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator तसेच अनेक worker आणि cron processes. ही संख्या एकदा मोजा, कारण तेच तुमचे maintenance load आहे. प्रत्येक entry हा crash होऊ शकणारा, disk भरू शकणारा किंवा migration fail करू शकणारा process आहे.

एखादी service Restarting state मध्ये राहिल्यास, इतर कशापूर्वी memory तपासा:

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

Out of memory: Killed process 3412 (java) सारखी line म्हणजे kernel च्या OOM killer (out of memory killer) ने container बंद केला. मशीनची RAM संपली होती. त्यामुळे ती service healthy होत नाही आणि stack सुरू होण्याची प्रक्रिया पूर्ण होत नाही. Document केलेल्या minimum पेक्षा कमी resources असताना full stack चालवल्याचा हा सामान्य परिणाम आहे. Documentation disk speed कडेही लक्ष वेधते: iowait 10% पेक्षा जास्त असल्यास machine ingest pipeline च्या वेगाने प्रक्रिया करू शकत नाही. हे top मधील wa column मधून वाचा किंवा sysstat installed असल्यास iostat -x 5 मधून वाचा.

Upgrades हा लोकांच्या अंदाजापेक्षा अधिक कठीण भाग आहे

Sentry self-hosted CalVer अंतर्गत दर महिन्याला release होते. CalVer ही calendar-based version scheme आहे. प्रत्येक महिन्याच्या 15 तारखेला primary release होते. जुन्या version वरून थेट latest version वर जाता येत नाही. Project hard stop versions निश्चित करते. Database migrations लागू करण्यासाठी प्रत्येक version क्रमाने checkout करणे आवश्यक आहे. August 2026 पर्यंत प्रकाशित hard stops 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 आहेत. Migration problems मुळे काही releases skip करण्यासही documentation सांगते. त्यात 23.7.0, 25.9.0, 25.12.0 आणि 26.3.0 ते 26.4.0 हा range समाविष्ट आहे.

Upgrade म्हणजे checkout आणि installer पुन्हा चालवणे:

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

सुरुवात करण्यापूर्वी server चा snapshot घ्या. मोठ्या ClickHouse dataset वर migration ला अनेक तास लागू शकतात. मध्येच failure झाल्यास database दोन schemas च्या मधल्या स्थितीत राहतो. बहुतेक failed self-hosted Sentry upgrades चे स्पष्ट कारण हे असते: machine वर्षभर एका version वर राहिली. त्यामुळे jump मध्ये एकाच वेळी अनेक hard stops पार होतात आणि skip केलेल्या migrations पैकी महत्त्वाची migration वगळली जाते.

तुम्ही हा पर्याय स्वीकारण्यापूर्वी आणखी एक गोष्ट जाणून घ्या. Sentry self-hosted हे Functional Source License (FSL) अंतर्गत येते. FSL ची सुरुवात Sentry नेच केली. हा fair source आहे, OSI-approved open source नाही. तुम्ही ते स्वतःसाठी चालवू शकता; परंतु competing service म्हणून ते विकू शकत नाही. प्रत्येक release निघाल्यानंतर दोन वर्षांनी Apache 2.0 अंतर्गत रूपांतरित होते.

GlitchTip: 512 MB साठी उत्तर

GlitchTip MIT परवान्याखाली उपलब्ध आहे आणि Sentry च्या open source SDKs कडून events स्वीकारते. त्यामुळे instrumented application दुसरीकडे नेण्यासाठी एकच मूल्य बदलावे लागते: DSN (data source name; तुमचा SDK events ज्या URL वर पाठवतो तो URL). यासाठी PostgreSQL 14 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. Valkey किंवा Redis 7 किंवा त्यानंतरची आवृत्ती ऐच्छिक आहे. मोठ्या instances वर त्यांच्यामुळे कार्यक्षमता वाढते.

Installation साठी Docker आणि एक compose file पुरेसे आहेत:

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

काहीही सुरू करण्यापूर्वी environment section संपादित करा. 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:// नसल्यास alert emails मधील links चुकीच्या पद्धतीने तयार होतात आणि प्रतिसाद न देणाऱ्या URL वर जातात.

ते सुरू करा आणि पहिल्या boot वर लक्ष ठेवा:

docker compose up -d
docker compose logs -f web

August 2026 नुसार नमुन्यातील image tags postgres:18, valkey/valkey:9 आणि glitchtip/glitchtip:6 आहेत. ते pinned ठेवा. latest असे असलेली compose file पुढील docker compose pull वेळी तुमचे database engine upgrade करेल. चालू instance अंतर्गत Postgres major version बदलल्यास कार्यरत error tracker सुरू होणे थांबू शकते.

256 MB ते 512 MB या श्रेणीत राहण्यासाठी नमुना file मधील comments मध्ये कोणती वैशिष्ट्ये बंद करायची ते दिले आहे. सर्वप्रथम Valkey आणि optional log व uptime features बंद करा. Valkey शिवाय चालवल्यास GlitchTip cache आणि queue कामांसाठी database वापरते. हे धीमे असते, पण योग्यरीत्या कार्य करते. All in one mode मध्ये worker web process मध्येच चालतो. त्यामुळे दोनऐवजी एक application container सांभाळावा लागतो.

त्याच्या पुढे proxy ठेवा. GlitchTip च्या documentation मध्ये requests buffer करणारा आणि chunked Transfer-Encoding हाताळणारा proxy किंवा load balancer आवश्यक असल्याचे सांगितले आहे. त्यात nginx चे उदाहरण दिले आहे. Buffering नसल्यास slow client संपूर्ण upload चालू असताना application worker व्यापून ठेवतो. त्यामुळे काही slow senders तुमचे सर्व workers व्यापू शकतात आणि निरोगी clients साठी timeout सुरू होतात.

Upgrades हा सोपा भाग आहे:

docker compose pull
docker compose stop
docker compose up -d

Start वेळी database migrations आपोआप चालतात. तरीही आधी dump घ्या, कारण automatic migration ही migrationच असते.

Bugsink: एक कंटेनर आणि तुम्ही वाचलेच पाहिजे असा परवाना

Bugsink हा तिघांपैकी सर्वात हलका आहे. तो Sentry SDK protocol वापरतो. तो message queue शिवाय आणि database व्यतिरिक्त कोणत्याही external service शिवाय चालतो. SQLite हे default आहे. वापराचा विस्तार झाल्यावर 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 मध्ये दिलेला address आणि password वापरून sign in करा. हा container थांबल्यावर त्यात कोणताही data टिकत नाही. प्रत्यक्ष instance साठी प्रकल्पाचा compose sample वापरा. त्यात bugsink/bugsink:2 सोबत postgres:17-alpine जोडलेले आहेत आणि DATABASE_URL, BASE_URL आणि BEHIND_HTTPS_PROXY सेट केलेले आहेत. secret योग्य पद्धतीने generate करा:

openssl rand -base64 50

BASE_URL हे users आणि SDKs प्रत्यक्षात वापरत असलेल्या URL शी जुळले पाहिजे. त्यात scheme देखील समाविष्ट आहे. https://errors.example.com वरून box पर्यंत पोहोचत असाल आणि http://localhost:8000 तसेच ठेवले, तर notification email मधील प्रत्येक link वाचणाऱ्या व्यक्तीच्या host कडे निर्देश करेल, पण तो resolve होणार नाही. nginx किंवा Caddy समोरील TLS (transport layer security) termination करत असल्यास BEHIND_HTTPS_PROXY हे true वर सेट करा. अन्यथा Bugsink तुमच्या https:// proxy मागे http:// URLs तयार करेल आणि browsers mixed content अवरोधित करतील.

Vendor स्वतःचे throughput आकडे प्रकाशित करतो: प्रत्येकी 50 KB आकाराचे 18 events प्रति second. हे दररोज 1.5 million events इतके होते. ही क्षमता 2 vCPU आणि 4 GB VPS वर मोजली आहे. हे आकडे तुमच्या workload ची हमी समजू नका. त्याऐवजी ते या tool ची क्षमता कशा प्रकारची आहे हे दर्शवतात. एका लहान application कडून निर्माण होणाऱ्या events पेक्षा ही कमाल मर्यादा बरीच जास्त आहे.

आता licence बद्दल. हे तुमच्या stack मध्ये समाविष्ट करण्यापूर्वी वाचण्याचा महत्त्वाचा भाग आहे. Bugsink हे PolyForm Shield License 1.0.0 अंतर्गत released आहे. याचा source उपलब्ध आहे, पण तो open source नाही. तुम्ही ते चालवू आणि modify करू शकता. मात्र Bugsink शी स्पर्धा करणारे काहीतरी तयार करण्यासाठी त्याचा वापर करू शकत नाही. Internal error tracker साठी हे बंधन लागू होत नाही. तुमची company developer tooling विकत असल्यास, आधी कोणीतरी licence text वाचून घ्यावा.

एरर ट्रॅकिंग आणि LLM observability ही अजूनही दोन स्वतंत्र साधने आहेत

एरर ट्रॅकिंग आणि large language model (LLM) observability एकत्र करणारे एखादे साधन शोधले, तर दोन्ही सुविधा असल्याचा दावा करणारी उत्पादने आढळतील. मात्र या दोन्हींच्या डेटाची रचना वेगळी असते. त्यामुळे त्यांचे एकत्रीकरण अजूनही व्यवस्थित झालेले नाही. एरर ट्रॅकरला stack trace सह exception मिळतो. तो त्यावरून fingerprint तयार करतो आणि हजारो occurrences एकाच issue मध्ये एकत्र करतो; त्यासाठी counter ठेवला जातो. LLM tracing tool ला prompt, response, token count आणि latency असलेला span मिळतो. त्याला या प्रत्येक नोंदी जतन कराव्या लागतात, कारण समान input असलेले दोन calls तरीही स्वतंत्र आणि तपासण्यासारखे events असतात.

म्हणून दोन्ही साधने वापरा. Exceptions एरर ट्रॅकरकडे पाठवा. Model calls साठी त्यांच्यासाठी तयार केलेले साधन वापरा: agent tracing साठी self-hosted Langfuse ही बाजू हाताळते, तर self-hosted AI observability वेगळ्या दृष्टिकोनातून तेच काम करते. तुमचा application आधीपासूनच या दोन्ही प्रकारच्या failures निर्माण करतो. एखादा model call आत्मविश्वासपूर्ण पण निरर्थक उत्तर देऊ शकतो आणि कोणतेही exception निर्माण करणार नाही. त्यामुळे एरर ट्रॅकर ते तुम्हाला कधीही दाखवणार नाही.

डिस्कची वाढ नंतर समोर येणारी अडचण आहे

प्रत्येक error tracker हा अमर्याद input स्वीकारणारा, मोठ्या प्रमाणात write करणारा database असतो. अॅप्लिकेशन किती डेटा लिहिते हे त्यावर अवलंबून असते. सक्रिय code path मधील एका नवीन bug मुळे एका रात्रीत दहा लाख events निर्माण होऊ शकतात.

GlitchTip नियोजनासाठी उपयुक्त असा एक आकडा देते: दरमहा दहा लाख events हाताळणाऱ्या instance ला 30 GB disk आवश्यक असू शकते. त्या दराने एका महिन्यात ingest होणारा डेटा यात समाविष्ट आहे. तुम्ही एकाच वेळी किती महिने डेटा साठवता हे retention window ठरवते.

Bugsink याकडे उलट्या पद्धतीने पाहते. निश्चित quota ऐवजी ते event count आणि event age वर retention algorithm लागू करते. तसेच ते मर्यादा थेट उपलब्ध करून देते: संपूर्ण installation साठी MAX_RETENTION_EVENT_COUNT, प्रत्येक project साठी MAX_RETENTION_PER_PROJECT_EVENT_COUNT आणि absolute cut-off म्हणून MAX_EVENT_AGE_DAYS. Installation-wide event budget निश्चित करणे हा disk चा आकार ठरवण्याचा योग्य मार्ग आहे, कारण तो budget म्हणजेच disk ची गरज आहे.

सर्व्हरवरील प्रत्यक्ष आकडे तपासा:

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

docker system df -v प्रत्येक volume चा आकार दाखवते. त्यामुळे कोणती service वाढत आहे हे पाहता येते. Traffic मध्ये बदल नसताना एखाद्या volume चा आकार दर आठवड्याला अनेक gigabytes ने वाढत असेल, तर retention कधीच configure केलेले नसण्याची शक्यता असते. त्यामुळे काहीही delete होत नाही आणि एकमेव मर्यादा partition ची क्षमता राहते.

Memory ची समस्या याच प्रकारची आहे, फक्त तिचे स्वरूप वेगळे आहे. Limits नसलेला stack kernel कडून उपलब्ध असलेली संपूर्ण memory वापरतो. Machine ची memory संपल्यावर OOM killer सर्वात मोठी process बंद करते. ती process tracker मुळे समस्या निर्माण झाली नसली, तरी तुमचा web server असू शकतो. प्रत्येक service साठी कमाल मर्यादा निश्चित करा: Docker Compose मधील memory limits येथे syntax आणि container आपली मर्यादा गाठल्यावर काय होते हे दाखवले आहे. स्वतःच्या मर्यादेमुळे बंद झालेला container ही मर्यादित failure असते. Kernel मुळे बंद झालेला container शेजारच्या container वरही परिणाम करू शकतो.

कोणता stack कोणत्या VPS साठी योग्य आहे

• 1 GB, किंवा अतिरिक्त मोकळ्या क्षमतेसह 2 GB: Valkey बंद केलेल्या all in one mode मधील GlitchTip किंवा SQLite वरील Bugsink. काही मोजक्या अॅप्लिकेशन्ससाठी दोन्ही पर्याय येथे सहज चालतात.
• 4 GB: PostgreSQL सह Bugsink किंवा Valkey सुरू केलेले आणि स्वतंत्र worker service असलेले GlitchTip. या क्षमतेपासून tuning थांबवून सेवा थेट चालवता येते.
• 8 GB: तरीही अधिकृत Sentry stack साठी अपुरे. तुम्ही निवडलेल्या हलक्या पर्यायासाठी दीर्घ retention window आणि मोठ्या disk साठी ही क्षमता वापरा.
• किमान 16 GB, शिफारस केलेले 32 GB: अधिकृत Sentry self-hosted stack. हा पर्याय फक्त हलके projects implement करत नसलेले Sentry feature आवश्यक असेल तेव्हाच वापरा. प्रत्येक project's documentation मध्ये त्या specific feature ची आधी पडताळणी करा, कारण compatible projects मध्ये सामान्य feature समाविष्ट असतात.

तुम्ही कोणताही पर्याय चालवला तरी error tracker स्वतः बंद पडल्याची नोंद करू शकत नाही. वेगळ्या machine वरून त्याची तपासणी करा: दुसऱ्या box वरून पाहणारे Uptime Kuma tracker down आहे हे कळवेल. नेमक्या त्या वेळी तुमचे application errors निर्माण करू लागते, पण त्यांची नोंद कोणीही करत नसते.

होस्टेड योजना स्वस्त पर्याय ठरते तेव्हा

डेटा स्थानाविषयक नियमांमुळे error tracker स्वतः होस्ट करणे आवश्यक असेल किंवा event ची संख्या इतकी जास्त असेल की प्रत्येक event साठीचे शुल्क महाग पडत असेल, तेव्हा self-hosting फायदेशीर ठरते. या परिस्थितींबाहेर मात्र गणित प्रामाणिकपणे करा. Sentry च्या दस्तऐवजीकरणानुसार किमान आवश्यकता 16 GB RAM, 4 cores आणि जलद disk असलेला server आहे. या आकाराचा VPS स्वस्त VPS नसतो. त्यानंतर operational कामही येते: प्रत्येक hard stop क्रमाने पार करणे आणि प्रत्येक migration पूर्वी snapshot घेणे. हे वर्षातून काही वेळा करावे लागते.

GlitchTip आणि Bugsink हे गणित पूर्णपणे बदलतात, कारण 512 MB ते 4 GB क्षमतेचा box स्वस्त असतो आणि upgrade हा docker compose pull असतो. म्हणून हा प्रश्न विचारणारे बहुतेक लोक official stack ऐवजी compatible projects पैकी एखादा प्रकल्प निवडतात. त्यांना error tracking हवे होते; सतत देखरेख करावी लागणारा distributed data pipeline नव्हता.

Server वर नेमके काय ठेवायचे हे तुम्ही अजून ठरवत असाल, तर self-hosting साठी योग्य असलेल्या सेवांची विस्तृत यादी error tracking ला त्याच RAM साठी स्पर्धा करणाऱ्या इतर सेवांच्या शेजारी ठेवते.

FAQ

मी 2 GB VPS वर Sentry self-host करू शकतो का?

नाही. Sentry च्या self-hosted दस्तऐवजात किमान 4 CPU cores, 16 GB RAM तसेच 16 GB swap आणि 20 GB मोकळी disk जागा आवश्यक असल्याचे नमूद केले आहे. हा stack एकाच वेळी Postgres, ClickHouse, Kafka, Redis आणि अनेक worker processes चालवतो. त्यामुळे लहान server वर install पूर्ण होण्यापूर्वी kernel containers बंद करते. बंद केलेल्या process चे नाव असलेली line दाखवणाऱ्या dmesg -T | grep -i 'out of memory' ने याची खात्री करा. 2 GB VPS साठी GlitchTip वापरा; त्याच्या दस्तऐवजानुसार 512 MB पुरेसे आहे. SQLite वर single container म्हणून चालणारे Bugsink देखील वापरता येते.

Sentry वरून GlitchTip किंवा Bugsink कडे बदलताना application code बदलावा लागतो का?

नाही. दोन्ही Sentry च्या open source SDKs कडून events स्वीकारतात. त्यामुळे आधीपासून install केलेला SDK तसाच ठेवा आणि एकच value बदला: DSN, म्हणजे SDK events पाठवतो तो URL. तो अजून hardcoded असल्यास environment variable मध्ये हलवा आणि नवीन host कडे निर्देश करा. त्यानंतर test exception निर्माण करून तो event प्राप्त होत आहे का ते monitor करा. काहीही दिसत नसल्यास DSN मधील project identifier नवीन server वरील अस्तित्वात असलेल्या project शी जुळतो का ते तपासा. तसेच firewall application ला त्या host आणि port पर्यंत पोहोचू देतो का ते तपासा.

self-hosted error tracking साठी किती disk जागा आवश्यक आहे?

हे tool पेक्षा तुमच्या event volume आणि retention window वर अधिक अवलंबून असते. दरमहा one million events हाताळणाऱ्या instance साठी GlitchTip 30 GB जागा प्रकाशित करते. Bugsink मध्ये MAX_RETENTION_EVENT_COUNT आणि MAX_EVENT_AGE_DAYS वापरून budget थेट सेट करता येतो. त्यामुळे कमाल मर्यादा तुम्ही ठरवता आणि disk ची आवश्यकता त्यानुसार ठरते. पहिल्याच दिवशी retention configure करा. Retention policy नसलेला tracker df -h 100% दाखवेपर्यंत वाढत राहतो. त्या वेळी ingest थांबते आणि तुम्हाला सर्वाधिक आवश्यक असलेल्या errors गमावता.

self-hosted Sentry चे upgrade वारंवार का अयशस्वी होते?

कारण upgrade प्रक्रियेत आवश्यक hard stop वगळला गेला. Sentry self-hosted मध्ये database migrations असलेल्या विशिष्ट versions मधून क्रमाने जाणे आवश्यक आहे. August 2026 नुसार हे versions 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 वरून थेट नवीनतम release कडे गेल्यास ही migrations वगळली जातात. त्यामुळे schema आणि code यांच्यात विसंगती निर्माण होते आणि upgrade मधेच थांबते. प्रत्येक hard stop क्रमाने checkout करा आणि प्रत्येक version वर ./install.sh चालवा. सुरुवात करण्यापूर्वी server चा snapshot घ्या. टाळावयाच्या releases ची दस्तऐवजीकृत यादी वाचा; त्यात 23.7.0, 25.9.0 आणि 25.12.0 यांचा समावेश आहे.