Sentry के बेहतरीन self-hosted विकल्प और RAM की तुलना

Self-hosted error tracking में एक इवेंट स्टोर करने से पहले आने वाली लागत

Self-hosted error tracking में एक ही संख्या है जो पूरे निर्णय को निर्धारित करती है, और वह है RAM की न्यूनतम आवश्यकता। Sentry का अपना self-hosted documentation किसी भी application द्वारा एक भी इवेंट भेजने से पहले 4 CPU cores, 16 GB RAM के साथ 16 GB swap, और 20 GB free disk की मांग करता है। GlitchTip केवल 512 MB की आवश्यकता बताता है। यहाँ दिए गए सभी विकल्प समान Sentry SDKs से इवेंट स्वीकार करते हैं, इसलिए यह निर्णय इस बारे में नहीं है कि आप अपने कोड को कैसे instrument करते हैं। यह निर्णय इस बारे में है कि आप कितने बड़े सर्वर का खर्च उठाने और उसे चालू रखने के लिए तैयार हैं।

प्रकाशित संसाधन आंकड़े, साथ-साथ

ये वे आंकड़े हैं जिन्हें प्रत्येक प्रोजेक्ट अगस्त 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 एक प्रलेखित न्यूनतम (documented minimum) है, और उसी पृष्ठ पर 32 GB की अनुशंसा की गई है। GlitchTip का 0.5 GB एक अनुशंसा है, और प्रोजेक्ट 256 MB को कार्यशील न्यूनतम के रूप में बताता है, या सावधानीपूर्वक कॉन्फ़िगरेशन के साथ 128 MB और swap का सुझाव देता है। Bugsink का 4 GB इनमें से कुछ भी नहीं है: यह वह हार्डवेयर है जिसका उपयोग वेंडर ने अपने स्वयं के थ्रूपुट बेंचमार्क के लिए किया था। प्रकाशित आंकड़ा केवल एक शुरुआती बिंदु है, आपके इवेंट वॉल्यूम के बारे में कोई वादा नहीं।

Sentry self-hosted: पूरा उत्पाद, और पूरा खर्च

आधिकारिक stack getsentry/self-hosted है, जो एक Docker Compose प्रोजेक्ट है। यह वही components चलाता है जिन्हें Sentry production में उपयोग करता है। इसका अपना documentation इसे "feature-complete और low-volume deployments तथा proofs-of-concept के लिए packaged" बताता है। यह वाक्य ही इसका ईमानदार सारांश है। आपको हर feature मिलता है, और हर वह moving part भी मिलता है जो उन features को काम करने लायक बनाता है।

इसे 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

फिर इसे start करें:

docker compose up --wait

Sentry डिफ़ॉल्ट रूप से http://127.0.0.1:9000 पर listen करता है। Docker Engine 19.03.6 या बाद का version और Docker Compose 2.32.2 या बाद का version आवश्यक है। पुराना Compose version Sentry की किसी कमी के कारण नहीं, बल्कि file syntax के कारण fail हो जाता है।

देखें कि आपने वास्तव में क्या start किया है:

docker compose ps
free -h

docker compose ps stack में मौजूद हर service को list करता है, और यह सूची लंबी है: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator, और कई worker तथा cron processes। इन्हें एक बार गिन लें, क्योंकि यही संख्या आपका maintenance load है। प्रत्येक entry एक ऐसी process है जो crash हो सकती है, disk भर सकती है, या migration में fail हो सकती है।

यदि कोई 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 को बंद कर दिया है क्योंकि machine की RAM खत्म हो गई थी। इस कारण वह service कभी healthy नहीं होती और stack start होना पूरा नहीं कर पाता। documented minimum के नीचे पूरा stack चलाने पर यह सामान्य परिणाम है। documentation disk speed को भी रेखांकित करता है: iowait यदि 10% से ऊपर है, तो machine ingest pipeline के साथ तालमेल नहीं बिठा पा रही है। इसे top में wa column से पढ़ें, या यदि आपके पास sysstat installed है तो iostat -x 5 से देखें।

Upgrades वह हिस्सा है जिसे लोग कम आंकते हैं

Sentry self-hosted हर महीने CalVer (calendar based version scheme) के तहत release होता है, जिसका मुख्य release हर महीने की 15 तारीख को आता है। आप सीधे पुराने version से latest version पर नहीं जा सकते। प्रोजेक्ट में hard stop versions निर्धारित हैं, और database migrations को पूरा करने के लिए आपको क्रमवार हर एक version पर जाना होगा। अगस्त 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 हैं। documentation उन releases को भी सूचीबद्ध करता है जिन्हें migration समस्याओं के कारण छोड़ना है, जिनमें 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 को पार किया और छोड़े गए migrations में से कोई एक महत्वपूर्ण था।

commit करने से पहले एक और बात जान लें। Sentry self-hosted, Functional Source License (FSL) के अंतर्गत है, जिसे Sentry ने स्वयं पेश किया है। यह OSI द्वारा अनुमोदित open source के बजाय fair source है: आप इसे अपने लिए चला सकते हैं, और आप इसे प्रतिस्पर्धी सेवा (competing service) के रूप में नहीं बेच सकते। प्रत्येक release अपने ship होने के दो साल बाद Apache 2.0 में बदल जाता है।

GlitchTip: 512 MB का समाधान

GlitchTip MIT लाइसेंस प्राप्त है और Sentry के ओपन सोर्स SDKs से इवेंट्स प्राप्त करता है। इसलिए, एक instrumented application को केवल एक मान बदलकर माइग्रेट किया जा सकता है: DSN (data source name, वह URL जहाँ आपका SDK इवेंट्स पोस्ट करता है)। इसके लिए PostgreSQL 14 या बाद का संस्करण आवश्यक है। Valkey या Redis 7 या बाद का संस्करण वैकल्पिक है, और यह बड़े instances को तेज बनाता है।

इंस्टॉलेशन के लिए 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 तक सैंपल में इमेज टैग्स postgres:18, valkey/valkey:9 और glitchtip/glitchtip:6 हैं। इन्हें पिन करके रखें। यदि compose फ़ाइल में latest लिखा है, तो यह अगले docker compose pull पर आपके डेटाबेस इंजन को अपग्रेड कर देगा, और चल रहे instance के दौरान Postgres का मेजर वर्जन बदलना एक काम करते हुए error tracker को बंद कर सकता है।

256 MB से 512 MB की रेंज तक पहुँचने के लिए, सैंपल फ़ाइल की टिप्पणियाँ आपको बताती हैं कि क्या बंद करना है, जिसकी शुरुआत Valkey और वैकल्पिक log तथा uptime फीचर्स से होती है। Valkey के बिना चलाने का मतलब है कि GlitchTip कैश और कतार के काम के लिए अपने डेटाबेस का उपयोग करता है, जो धीमा है लेकिन सही है। All in one मोड worker को वेब प्रोसेस के अंदर चलाता है, इसलिए आप दो के बजाय एक ही application container को मेंटेन करते हैं।

इसके सामने एक proxy रखें। GlitchTip का डॉक्यूमेंटेशन एक ऐसे proxy या load balancer की मांग करता है जो requests को बफर करे और chunked Transfer-Encoding को हैंडल करे, और यह उदाहरण के तौर पर nginx का सुझाव देता है। बफरिंग के बिना, एक धीमा client पूरे अपलोड के दौरान एक application worker को व्यस्त रखता है, जिससे कुछ धीमे senders आपके सभी workers को भर सकते हैं और सही clients का टाइमआउट होने लगता है।

अपग्रेड करना आसान है:

docker compose pull
docker compose stop
docker compose up -d

डेटाबेस माइग्रेशन शुरुआत में अपने आप चलते हैं। फिर भी, पहले एक dump जरूर लें, क्योंकि एक स्वचालित माइग्रेशन भी अंततः एक माइग्रेशन ही होता है।

Bugsink: एक कंटेनर, और एक लाइसेंस जिसे आपको पढ़ना चाहिए

Bugsink इन तीनों में सबसे हल्का है। यह Sentry SDK प्रोटोकॉल का उपयोग करता है, और यह बिना किसी मैसेज क्यू (message queue) या डेटाबेस के अलावा किसी बाहरी सर्विस के चलता है। 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 sample का उपयोग करें, जो bugsink/bugsink:2 को postgres:17-alpine के साथ जोड़ता है और DATABASE_URL, BASE_URL तथा BEHIND_HTTPS_PROXY को सेट करता है। सीक्रेट को सही तरीके से जनरेट करें:

openssl rand -base64 50

BASE_URL को उस URL से मेल खाना चाहिए जिसका उपयोग आपके उपयोगकर्ता और SDK वास्तव में करते हैं, जिसमें स्कीम भी शामिल है। यदि आप इसे http://localhost:8000 पर छोड़ देते हैं और उस बॉक्स को https://errors.example.com पर एक्सेस करते हैं, तो नोटिफिकेशन ईमेल का हर लिंक ऐसे होस्ट पर पॉइंट करेगा जो उसे पढ़ने वाले व्यक्ति के लिए रिज़ॉल्व नहीं होगा। जब Nginx या Caddy इसके सामने TLS (transport layer security) को टर्मिनेट करते हैं, तो BEHIND_HTTPS_PROXY को true पर सेट करें। अन्यथा, Bugsink आपके https:// प्रॉक्सी के पीछे http:// URL बनाएगा और ब्राउज़र मिक्स्ड कंटेंट को ब्लॉक कर देंगे।

वेंडर अपने थ्रूपुट के आंकड़े स्वयं प्रकाशित करता है: 2 vCPU और 4 GB RAM वाले 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 तैयार करता है, और हजारों घटनाओं को एक counter के साथ एक ही issue में समेट देता है। एक LLM tracing उपकरण एक span प्राप्त करता है जिसमें prompt, response, token count और latency होती है, और उसे उन सभी को सुरक्षित रखना पड़ता है, क्योंकि समान इनपुट वाली दो calls भी अलग-अलग घटनाएं होती हैं जिन्हें पढ़ना आवश्यक है।

इसलिए दोनों का उपयोग करें। अपवादों को error tracker पर भेजें, और model calls को उनके लिए बनाए गए किसी स्थान पर भेजें: agent tracing के लिए self-hosted Langfuse इस पक्ष को कवर करता है, और self-hosted AI observability इसी कार्य को एक अलग दृष्टिकोण से देखती है। आपका application पहले से ही दोनों प्रकार की विफलताएं उत्पन्न कर रहा है। एक model call जो आत्मविश्वास के साथ गलत जानकारी (nonsense) लौटाती है, वह कोई exception नहीं फेंकती है, इसलिए एक error tracker उसे कभी नहीं दिखाएगा।

डिस्क का बढ़ना वह विफलता है जो आपको बाद में पता चलती है

हर error tracker एक write-heavy डेटाबेस होता है जिसमें इनपुट की कोई सीमा नहीं होती। आपका application तय करता है कि वह कितना डेटा लिखता है, और hot code path में आया एक नया बग रातों-रात दस लाख events पैदा कर सकता है।

GlitchTip एक ऐसा आंकड़ा प्रकाशित करता है जिसके आधार पर योजना बनाना उचित है: एक instance जो प्रति माह दस लाख events को handle करता है, उसे 30 GB डिस्क की आवश्यकता हो सकती है। यह उस दर पर एक महीने के ingest को कवर करता है, और आपका retention window यह तय करता है कि आप एक बार में कितने महीनों का डेटा स्टोर कर रहे हैं।

Bugsink इसे दूसरे दृष्टिकोण से देखता है। एक निश्चित कोटा के बजाय, यह event count और event age पर एक retention algorithm लागू करता है, और यह सीमाओं को सीधे उजागर करता है: पूरे installation के लिए MAX_RETENTION_EVENT_COUNT, प्रति project MAX_RETENTION_PER_PROJECT_EVENT_COUNT, और एक absolute cut के रूप में MAX_EVENT_AGE_DAYS। installation-wide event budget सेट करना डिस्क के आकार का निर्धारण करने का ईमानदार तरीका है, क्योंकि वही बजट डिस्क का आकार है।

सर्वर पर वास्तविक आंकड़ों पर नज़र रखें:

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

docker system df -v प्रति volume आकार को प्रिंट करता है, ताकि आप देख सकें कि कौन सी service बढ़ रही है। यदि कोई volume बिना किसी traffic परिवर्तन के प्रति सप्ताह कई gigabytes बढ़ रहा है, तो इसका मतलब है कि retention कभी configure नहीं किया गया था, इसलिए कुछ भी delete नहीं हो रहा है और एकमात्र सीमा partition है।

Memory भी वही समस्या है, बस उसका रूप अलग है। बिना सीमा वाला stack kernel द्वारा दी गई सारी memory ले लेगा, और जब मशीन की memory खत्म हो जाएगी, तो OOM killer सबसे बड़ी process को चुन लेगा, जो कि उस tracker के बजाय आपका web server हो सकता है जिसने समस्या पैदा की थी। हर service को एक अधिकतम सीमा दें: memory limits in Docker Compose में syntax दिखाया गया है और यह भी कि जब container अपनी सीमा तक पहुँच जाता है तो क्या होता है। अपनी सीमा पर kill हुआ container एक सीमित विफलता है। kernel द्वारा kill किया गया container अपने पड़ोसी को भी साथ ले डूबता है।

किस VPS के लिए कौन सा stack उपयुक्त है

• 1 GB, या 2 GB खाली जगह के साथ: Valkey को बंद करके all-in-one मोड में GlitchTip, या SQLite पर Bugsink। कुछ चुनिंदा applications के लिए ये दोनों यहाँ आसानी से चल जाते हैं।
• 4 GB: PostgreSQL के साथ Bugsink, या Valkey चालू करके और एक अलग worker service के साथ GlitchTip। यह वह आकार है जहाँ आपको tuning की चिंता छोड़कर बस इसे चलाने की आवश्यकता होती है।
• 8 GB: यह आधिकारिक Sentry stack के लिए अभी भी कम है। इसे आप जो भी हल्का विकल्प चुनते हैं, उसके लिए लंबे retention window और बड़ी disk पर खर्च करें।
• न्यूनतम 16 GB, 32 GB अनुशंसित: आधिकारिक Sentry self-hosted stack, और यह केवल तब जब आपको Sentry के किसी ऐसे feature की आवश्यकता हो जो हल्के projects में उपलब्ध न हो। पहले प्रत्येक project के documentation के साथ विशिष्ट feature की जाँच करें, क्योंकि संगत projects सामान्य features को कवर करते हैं।

आप जो भी चलाएं, error tracker अपनी खुद की विफलता की रिपोर्ट नहीं कर सकता है। इसे किसी दूसरी machine से monitor करें: किसी अन्य box से निगरानी करता Uptime Kuma आपको बताएगा कि tracker down है, और यही वह सटीक क्षण है जब आपकी application उन errors को देना शुरू करती है जिन्हें कोई record नहीं कर रहा है।

जब hosted plan एक सस्ता विकल्प होता है

जब data residency के नियम अनिवार्य हों, या जब event volume इतना अधिक हो कि प्रति event pricing महंगी पड़ने लगे, तब error tracker को self-host करना फायदेमंद होता है। इन स्थितियों के अलावा, ईमानदारी से गणना करें। Sentry के documentation के अनुसार न्यूनतम आवश्यकता 16 GB RAM, 4 cores और fast disk वाला सर्वर है, और इस आकार का VPS सस्ता नहीं होता। इसके बाद operational काम को जोड़ें: हर hard stop को क्रम से पूरा करना, और हर migration से पहले snapshot लेना, जो साल में कुछ बार करना पड़ता है।

GlitchTip और Bugsink इस गणना को पूरी तरह बदल देते हैं, क्योंकि 512 MB से 4 GB तक का box सस्ता होता है और upgrade करना एक docker compose pull है। यही कारण है कि जो लोग यह सवाल पूछते हैं, उनमें से अधिकांश official stack के बजाय किसी compatible project को चुनते हैं। उन्हें error tracking चाहिए थी, न कि एक distributed data pipeline जिसे संभालना पड़े।

यदि आप अभी भी यह तय कर रहे हैं कि सर्वर पर क्या रखना चाहिए, तो self-hosting के लिए उपयुक्त सेवाओं की व्यापक सूची error tracking को उन अन्य सेवाओं के साथ रखती है जो समान RAM के लिए प्रतिस्पर्धा करती हैं।

FAQ

क्या मैं 2 GB VPS पर Sentry को self-host कर सकता हूँ?

नहीं। Sentry के self-hosted documentation के अनुसार इसके लिए कम से कम 4 CPU cores, 16 GB RAM के साथ 16 GB swap, और 20 GB free disk की आवश्यकता होती है। यह stack एक साथ Postgres, ClickHouse, Kafka, Redis और कई worker processes चलाता है, इसलिए छोटे सर्वर पर installation पूरा होने से पहले ही kernel containers को kill कर देता है। इसकी पुष्टि dmesg -T | grep -i 'out of memory' से करें, जो उस process का नाम दिखाता है जिसे kill किया गया है। 2 GB VPS के लिए GlitchTip का उपयोग करें, जिसके लिए 512 MB की आवश्यकता होती है, या Bugsink का उपयोग करें, जो SQLite पर एक single container के रूप में चलता है।

क्या Sentry से GlitchTip या Bugsink पर स्विच करने के लिए मुझे अपना application code बदलना होगा?

नहीं। दोनों ही Sentry के open source SDKs से events स्वीकार करते हैं, इसलिए आप अपना मौजूदा SDK रख सकते हैं और केवल एक value बदलें: DSN, यानी वह URL जहाँ SDK events भेजता है। यदि यह hardcoded है, तो इसे environment variable में ले जाएँ, इसे नए host की ओर point करें, फिर एक test exception raise करें और देखें कि वह पहुँचता है या नहीं। यदि कुछ भी दिखाई न दे, तो जाँचें कि DSN में मौजूद project identifier नए सर्वर पर मौजूद project से मेल खाता है या नहीं, और यह भी कि आपका firewall application को उस host और port तक पहुँचने की अनुमति देता है या नहीं।

self-hosted error tracking के लिए कितनी disk की आवश्यकता होती है?

यह tool के बजाय आपके event volume और retention window पर निर्भर करता है। GlitchTip प्रति माह दस लाख events संभालने वाले instance के लिए 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 में कुछ विशिष्ट versions निर्धारित हैं जिनमें 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 से सीधे नवीनतम version पर जाने से ये migrations छूट जाते हैं, जिससे schema और code में असंगति हो जाती है और upgrade बीच में ही रुक जाता है। प्रत्येक hard stop को क्रम से देखें और हर एक पर ./install.sh चलाएँ, शुरू करने से पहले सर्वर का snapshot लें, और उन releases की documented सूची पढ़ें जिनसे बचना है, जिसमें 23.7.0, 25.9.0 और 25.12.0 शामिल हैं।