সেরা self-hosted error tracking এবং Sentry-এর বিকল্প

একটি ইভেন্ট জমা করার আগেই self-hosted error tracking-এর খরচ

Self-hosted error tracking-এর ক্ষেত্রে একটি সংখ্যাই পুরো সিদ্ধান্ত নির্ধারণ করে, আর তা হলো RAM-এর ন্যূনতম প্রয়োজনীয়তা। Sentry-এর নিজস্ব self-hosted ডকুমেন্টেশন অনুযায়ী, আপনার অ্যাপ্লিকেশন একটি ইভেন্ট পাঠানোর আগেই 4টি CPU কোর, 16 GB RAM, 16 GB swap এবং 20 GB খালি ডিস্কের প্রয়োজন হয়। অন্যদিকে, GlitchTip-এর জন্য মাত্র 512 MB RAM-এর প্রয়োজন। এখানে উল্লিখিত সব অপশনই একই 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 এর কোনোটিই নয়: এটি সেই হার্ডওয়্যার যা ভেন্ডর তাদের নিজস্ব থ্রুপুট বেঞ্চমার্কের জন্য ব্যবহার করেছে। একটি প্রকাশিত পরিসংখ্যান কেবল শুরুর একটি বিন্দু, আপনার ইভেন্ট ভলিউম সম্পর্কে কোনো নিশ্চয়তা নয়।

Sentry self-hosted: সম্পূর্ণ পণ্য এবং সম্পূর্ণ দায়ভার

অফিসিয়াল স্ট্যাকটি হলো getsentry/self-hosted, যা একটি Docker Compose প্রজেক্ট। এটি Sentry প্রোডাকশনে যে উপাদানগুলো ব্যবহার করে, ঠিক সেগুলোই চালায়। এর নিজস্ব ডকুমেন্টেশনে একে "লো-ভলিউম ডেপ্লয়মেন্ট এবং প্রুফ-অফ-কনসেপ্টের জন্য ফিচার-সম্পূর্ণ এবং প্যাকেজড" হিসেবে বর্ণনা করা হয়েছে। এই বাক্যটিই এর সৎ সারসংক্ষেপ। আপনি প্রতিটি ফিচার পাবেন এবং সেই ফিচারগুলোকে সচল রাখার জন্য প্রয়োজনীয় প্রতিটি চলমান অংশও পাবেন।

master থেকে নয়, বরং একটি ট্যাগড রিলিজ থেকে ইনস্টল করুন:

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-এর কোনো ত্রুটির কারণে নয়, বরং ফাইল সিনট্যাক্সের কারণে ব্যর্থ হবে।

আপনি আসলে কী চালু করেছেন তা দেখুন:

docker compose ps
free -h

docker compose ps স্ট্যাকের প্রতিটি সার্ভিস তালিকাভুক্ত করে এবং এই তালিকাটি বেশ দীর্ঘ: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator এবং বেশ কয়েকটি ওয়ার্কার ও ক্রন প্রসেস। এগুলো একবার গুনে দেখুন, কারণ এই সংখ্যাটিই আপনার রক্ষণাবেক্ষণের কাজের পরিমাণ। প্রতিটি এন্ট্রি এমন একটি প্রসেস যা ক্র্যাশ করতে পারে, ডিস্ক পূর্ণ করে ফেলতে পারে অথবা মাইগ্রেশনে ব্যর্থ হতে পারে।

যদি কোনো সার্ভিস Restarting অবস্থায় আটকে থাকে, তবে অন্য কিছুর আগে মেমোরি চেক করুন:

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

Out of memory: Killed process 3412 (java)-এর মতো একটি লাইন মানে হলো কার্নেলের OOM killer (আউট অফ মেমোরি কিলার) একটি কন্টেইনারকে বন্ধ করে দিয়েছে কারণ সার্ভারে RAM শেষ হয়ে গিয়েছিল। ফলে সার্ভিসটি কখনোই সুস্থ অবস্থায় আসে না এবং স্ট্যাকটি পুরোপুরি চালু হতে পারে না। ডকুমেন্টেশনে উল্লিখিত ন্যূনতম রিকোয়ারমেন্টের নিচে পুরো স্ট্যাকটি চালানোর ক্ষেত্রে এটি একটি সাধারণ ফলাফল। ডকুমেন্টেশনে ডিস্কের গতির কথাও উল্লেখ আছে: iowait 10%-এর বেশি হওয়া মানে হলো মেশিনটি ইনজেস্ট পাইপলাইনের সাথে তাল মিলিয়ে চলতে পারছে না। এটি top-এর wa কলাম থেকে পড়ুন, অথবা আপনার কাছে sysstat ইনস্টল করা থাকলে iostat -x 5 থেকে দেখুন।

আপগ্রেড হলো সেই অংশ যা মানুষ অবমূল্যায়ন করে

Sentry self-hosted প্রতি মাসে CalVer বা ক্যালেন্ডার-ভিত্তিক ভার্সন স্কিম অনুযায়ী রিলিজ হয়, যার প্রধান রিলিজটি প্রতি মাসের 15 তারিখে আসে। আপনি পুরনো ভার্সন থেকে সরাসরি লেটেস্ট ভার্সনে যেতে পারবেন না। প্রজেক্টটি কিছু হার্ড-স্টপ ভার্সন নির্ধারণ করে দেয় এবং ডাটাবেস মাইগ্রেশনগুলো সম্পন্ন করার জন্য আপনাকে প্রতিটি ভার্সন ক্রমানুসারে চেকআউট করতে হবে। আগস্ট 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। ডকুমেন্টেশনে এমন কিছু রিলিজের তালিকাও আছে যা মাইগ্রেশন সমস্যার কারণে এড়িয়ে চলতে বলা হয়েছে, যার মধ্যে রয়েছে 23.7.0, 25.9.0, 25.12.0 এবং 26.3.0 থেকে 26.4.0 রেঞ্জ।

একটি আপগ্রেড মানে হলো চেকআউট করা এবং ইনস্টলারটি পুনরায় চালানো:

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

শুরু করার আগে সার্ভারের স্ন্যাপশট নিন, কারণ বড় ClickHouse ডেটাসেটের মাইগ্রেশন কয়েক ঘণ্টা ধরে চলতে পারে এবং মাঝপথে ব্যর্থ হলে ডাটাবেস দুটি স্কিমার মাঝামাঝি অবস্থায় আটকে যায়। বেশিরভাগ ব্যর্থ self-hosted Sentry আপগ্রেডের মূল কারণ হলো: সার্ভারটি এক বছর ধরে একটি ভার্সনে পড়ে ছিল, ফলে এক লাফে অনেকগুলো হার্ড-স্টপ পার হতে গিয়ে গুরুত্বপূর্ণ কোনো মাইগ্রেশন বাদ পড়ে গেছে।

কমিট করার আগে আরও একটি বিষয় জেনে রাখা ভালো। Sentry self-hosted বর্তমানে Functional Source License (FSL)-এর অধীনে রয়েছে, যা Sentry নিজেই প্রবর্তন করেছে। এটি OSI অনুমোদিত ওপেন সোর্স নয়, বরং ফেয়ার সোর্স: আপনি এটি নিজের জন্য চালাতে পারবেন, কিন্তু প্রতিদ্বন্দ্বী সার্ভিস হিসেবে বিক্রি করতে পারবেন না। প্রতিটি রিলিজ শিপ হওয়ার দুই বছর পর Apache 2.0 লাইসেন্সে রূপান্তরিত হয়।

GlitchTip: 512 এমবি (MB) সমাধান

GlitchTip একটি MIT লাইসেন্সপ্রাপ্ত সফটওয়্যার যা Sentry-এর ওপেন সোর্স SDK থেকে ইভেন্ট গ্রহণ করে। তাই একটি ইনস্ট্রুমেন্টেড অ্যাপ্লিকেশনকে এখানে স্থানান্তর করতে কেবল একটি মান পরিবর্তন করতে হয়: DSN (ডেটা সোর্স নেম, যে URL-এ আপনার SDK ইভেন্ট পাঠায়)। এর জন্য 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 পাথ সেট করতে হবে:

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-এর সময় আপনার ডেটাবেস ইঞ্জিনকে আপগ্রেড করে ফেলবে। আর চলমান ইনস্ট্যান্সের নিচে Postgres-এর মেজর ভার্সন পরিবর্তন করলে একটি সচল এরর ট্র্যাকার কাজ করা বন্ধ করে দিতে পারে।

256 এমবি (MB) থেকে 512 এমবি (MB) র‍্যামের মধ্যে সীমাবদ্ধ থাকতে, স্যাম্পল ফাইলের কমেন্টগুলো অনুসরণ করে Valkey এবং ঐচ্ছিক লগ ও আপটাইম ফিচারগুলো বন্ধ করে দিন। Valkey ছাড়া চালানোর অর্থ হলো GlitchTip ক্যাশ এবং কিউ (queue) কাজের জন্য তার ডেটাবেস ব্যবহার করবে, যা কিছুটা ধীরগতির হলেও নির্ভুল। অল-ইন-ওয়ান মোডে worker-কে ওয়েব প্রসেসের ভেতরেই চালানো হয়, ফলে আপনাকে দুটি আলাদা অ্যাপ্লিকেশন কন্টেইনারের পরিবর্তে একটিই রক্ষণাবেক্ষণ করতে হয়।

এর সামনে একটি প্রক্সি বসান। GlitchTip-এর ডকুমেন্টেশনে এমন একটি প্রক্সি বা লোড ব্যালেন্সার ব্যবহারের পরামর্শ দেওয়া হয়েছে যা রিকোয়েস্ট বাফার করতে পারে এবং chunked Transfer-Encoding হ্যান্ডেল করতে পারে; উদাহরণ হিসেবে তারা Nginx-এর কথা উল্লেখ করেছে। বাফারিং ছাড়া, একটি ধীরগতির ক্লায়েন্ট পুরো আপলোডের সময় একটি অ্যাপ্লিকেশন worker-কে আটকে রাখে। ফলে অল্প কিছু ধীরগতির প্রেরক আপনার সব worker দখল করে নিতে পারে এবং সুস্থ ক্লায়েন্টদের রিকোয়েস্ট টাইম-আউট হতে শুরু করে।

আপগ্রেড করা খুবই সহজ:

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-গুলো বাস্তবে ব্যবহার করে, যার মধ্যে scheme-ও অন্তর্ভুক্ত। যদি আপনি https://errors.example.com ঠিকানায় সার্ভারটি অ্যাক্সেস করেন, তবে এটিকে http://localhost:8000-এ রেখে দেবেন না; অন্যথায় নোটিফিকেশন ইমেইলের প্রতিটি লিঙ্ক এমন একটি হোস্টের দিকে নির্দেশ করবে যা ব্যবহারকারীর কাছে কাজ করবে না। যখন Nginx বা Caddy এর সামনে TLS (transport layer security) টার্মিনেট করে, তখন BEHIND_HTTPS_PROXY-কে true হিসেবে সেট করুন। অন্যথায়, Bugsink আপনার https:// প্রক্সির পেছনে http:// URL তৈরি করবে এবং ব্রাউজারগুলো mixed content হিসেবে সেগুলোকে ব্লক করে দেবে।

ভেন্ডর তাদের নিজস্ব throughput পরিসংখ্যান প্রকাশ করেছে: প্রতি সেকেন্ডে 18টি ইভেন্ট (প্রতিটি 50 KB), যার মানে দিনে 1.5 মিলিয়ন ইভেন্ট, একটি 2 vCPU এবং 4 GB RAM-এর VPS-এ। এটিকে আপনার কাজের চাপের নিশ্চয়তা হিসেবে না ধরে টুলটির সক্ষমতার একটি ধারণা হিসেবে দেখুন। এটি প্রমাণ করে যে, এর সক্ষমতা একটি ছোট অ্যাপ্লিকেশনের চাহিদার চেয়ে অনেক বেশি।

এখন লাইসেন্সের কথায় আসা যাক, এটি আপনার স্ট্যাকে যুক্ত করার আগে অবশ্যই পড়ে নেওয়া উচিত। Bugsink-কে PolyForm Shield License 1.0.0-এর অধীনে রিলিজ করা হয়েছে। এটি source available, open source নয়: আপনি এটি চালাতে এবং পরিবর্তন করতে পারবেন, কিন্তু Bugsink-এর সাথে প্রতিযোগিতা করে এমন কোনো কিছু তৈরি করতে এটি ব্যবহার করতে পারবেন না। অভ্যন্তরীণ এরর ট্র্যাকার হিসেবে ব্যবহারের ক্ষেত্রে এই সীমাবদ্ধতা কোনো সমস্যা তৈরি করে না। যদি আপনার কোম্পানি ডেভেলপার টুলিং বিক্রি করে, তবে লাইসেন্স টেক্সটটি আগে কাউকে দিয়ে যাচাই করিয়ে নিন।

এরর ট্র্যাকিং এবং LLM অবজার্ভেবিলিটি এখনো দুটি আলাদা টুল

এরর ট্র্যাকিং এবং লার্জ ল্যাঙ্গুয়েজ মডেল (LLM) অবজার্ভেবিলিটি উভয়ই করে এমন একটি টুলের খোঁজ করলে আপনি এমন অনেক প্রোডাক্ট পাবেন যারা উভয় সুবিধার দাবি করে। কিন্তু ডেটার গঠন ভিন্ন হওয়ার কারণে এই দুটি ক্ষেত্র এখনো একত্রিত হয়নি। একটি এরর ট্র্যাকার স্ট্যাক ট্রেসসহ এক্সেপশন গ্রহণ করে, তা থেকে একটি ফিঙ্গারপ্রিন্ট তৈরি করে এবং হাজার হাজার ঘটনাকে একটি ইস্যু হিসেবে কাউন্টারে জমা করে। অন্যদিকে, একটি LLM ট্রেসিং টুল প্রম্পট, রেসপন্স, টোকেন কাউন্ট এবং ল্যাটেন্সি ধারণকারী স্প্যান গ্রহণ করে। একে প্রতিটি ডেটা আলাদাভাবে সংরক্ষণ করতে হয়, কারণ একই ইনপুটসহ দুটি কলও আলাদা ইভেন্ট হিসেবে গণ্য হয় এবং তা বিশ্লেষণ করা প্রয়োজন।

তাই দুটি টুলই ব্যবহার করুন। এক্সেপশনগুলো এরর ট্র্যাকারে পাঠান এবং মডেল কলগুলো এমন কোথাও পাঠান যা বিশেষভাবে তাদের জন্য তৈরি। এজেন্ট ট্রেসিংয়ের জন্য সেলফ-হোস্টেড Langfuse এই দিকটি কভার করে এবং সেলফ-হোস্টেড AI অবজার্ভেবিলিটি একই কাজকে ভিন্ন দৃষ্টিকোণ থেকে সমাধান করে। আপনার অ্যাপ্লিকেশন ইতিমধ্যেই উভয় ধরনের ব্যর্থতা তৈরি করছে। একটি মডেল কল যদি আত্মবিশ্বাসের সাথে ভুল তথ্য প্রদান করে, তবে সেটি কোনো এক্সেপশন তৈরি করে না, তাই এরর ট্র্যাকার আপনাকে সেটি কখনোই দেখাবে না।

ডিস্কের আকার বৃদ্ধি এমন একটি ব্যর্থতা যা আপনাকে পরে ভোগাবে

প্রতিটি এরর ট্র্যাকার হলো একটি রাইট-হেভি (write-heavy) ডাটাবেস যার ইনপুট অনিয়ন্ত্রিত। আপনার অ্যাপ্লিকেশন সিদ্ধান্ত নেয় এটি কতটা লিখবে, এবং হট কোড পাথে (hot code path) একটি নতুন বাগ রাতারাতি দশ লক্ষ ইভেন্ট তৈরি করতে পারে।

GlitchTip একটি পরিসংখ্যান প্রকাশ করেছে যা পরিকল্পনা করার জন্য গুরুত্বপূর্ণ: প্রতি মাসে দশ লক্ষ ইভেন্ট হ্যান্ডেল করে এমন একটি ইনস্ট্যান্সের 30 GB ডিস্কের প্রয়োজন হতে পারে। এটি ওই হারে এক মাসের ইনজেস্ট (ingest) কভার করে, এবং আপনার রিটেনশন উইন্ডো (retention window) নির্ধারণ করে যে আপনি একসাথে কত মাসের ডেটা সংরক্ষণ করছেন।

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-এর জন্য উপযুক্ত

• 1 GB, অথবা 2 GB (কিছুটা খালি জায়গা থাকলে): Valkey বন্ধ রেখে all-in-one মোডে GlitchTip, অথবা SQLite-এর ওপর Bugsink। অল্প কিছু অ্যাপ্লিকেশনের জন্য এই কনফিগারেশন বেশ আরামদায়ক।
• 4 GB: PostgreSQL-এর সাথে Bugsink, অথবা Valkey চালু রেখে আলাদা worker service-সহ GlitchTip। এই সাইজের সার্ভারে আপনাকে আর টিউনিং নিয়ে ভাবতে হবে না, সরাসরি ব্যবহার করতে পারবেন।
• 8 GB: এটি এখনও অফিসিয়াল Sentry স্ট্যাকের জন্য পর্যাপ্ত নয়। এর চেয়ে বরং আপনার বেছে নেওয়া হালকা অপশনটির জন্য retention window বাড়িয়ে দিন এবং ডিস্কের আকার বড় করুন।
• 16 GB সর্বনিম্ন, 32 GB সুপারিশকৃত: অফিসিয়াল Sentry self-hosted স্ট্যাকের জন্য এটি প্রয়োজন। তবে শুধুমাত্র তখনই এটি ব্যবহার করুন যখন আপনার এমন কোনো Sentry ফিচারের প্রয়োজন হয় যা হালকা প্রজেক্টগুলোতে নেই। প্রতিটি প্রজেক্টের ডকুমেন্টেশনের সাথে আপনার প্রয়োজনীয় ফিচারটি মিলিয়ে দেখুন, কারণ সামঞ্জস্যপূর্ণ প্রজেক্টগুলো সাধারণ ফিচারগুলো কভার করে।

আপনি যা-ই চালান না কেন, error tracker নিজের অকার্যকারিতা নিজে রিপোর্ট করতে পারে না। তাই অন্য একটি মেশিন থেকে এর ওপর নজর রাখুন: অন্য একটি বক্স থেকে Uptime Kuma দিয়ে পর্যবেক্ষণ আপনাকে জানিয়ে দেবে যে ট্র্যাকারটি ডাউন হয়েছে। ঠিক সেই মুহূর্তেই আপনার অ্যাপ্লিকেশন এরর তৈরি করা শুরু করবে, যা অন্যথায় কেউ রেকর্ড করতে পারবে না।

কখন হোস্টেড প্ল্যান সাশ্রয়ী সমাধান

যখন ডেটা রেসিডেন্সি বা ডেটা সংরক্ষণের নিয়মাবলি অনুযায়ী নিজস্ব সার্ভারে ডেটা রাখা বাধ্যতামূলক হয়, অথবা ইভেন্ট ভলিউম এত বেশি হয় যে প্রতি ইভেন্টের জন্য মূল্য পরিশোধ করা ব্যয়বহুল হয়ে পড়ে, তখন এরর ট্র্যাকার সেলফ-হোস্ট করা লাভজনক। এই ক্ষেত্রগুলোর বাইরে থাকলে, হিসাবটি সততার সাথে করুন। Sentry-এর নথিপত্র অনুযায়ী ন্যূনতম 16 জিবি র‍্যাম, 4 কোর এবং দ্রুতগতির ডিস্কসহ সার্ভার প্রয়োজন, আর এই আকারের একটি VPS সস্তা নয়। এর সাথে যুক্ত করুন অপারেশনাল কাজের চাপ: প্রতিটি হার্ড স্টপ ধারাবাহিকভাবে অতিক্রম করা এবং বছরে কয়েকবার মাইগ্রেশনের আগে স্ন্যাপশট নেওয়া।

GlitchTip এবং Bugsink এই হিসাবটি পুরোপুরি বদলে দেয়, কারণ 512 এমবি থেকে 4 জিবি র‍্যামের সার্ভার বেশ সাশ্রয়ী এবং আপগ্রেড প্রক্রিয়াটি একটি docker compose pull। এই কারণেই যারা এই প্রশ্নটি করেন, তাদের বেশিরভাগই অফিশিয়াল স্ট্যাকের পরিবর্তে সামঞ্জস্যপূর্ণ প্রজেক্টগুলোর একটি বেছে নেন। তারা মূলত এরর ট্র্যাকিং চেয়েছিলেন, কোনো ডিস্ট্রিবিউটেড ডেটা পাইপলাইন নয় যা সার্বক্ষণিক দেখাশোনা করতে হয়।

আপনি যদি এখনো সিদ্ধান্ত না নিয়ে থাকেন যে সার্ভারে আসলে কী রাখা উচিত, তবে সেলফ-হোস্ট করার যোগ্য পরিষেবাগুলোর বিস্তৃত তালিকা দেখুন, যেখানে এরর ট্র্যাকিংকে একই র‍্যামের জন্য প্রতিদ্বন্দ্বী অন্যান্য পরিষেবার পাশাপাশি রাখা হয়েছে।

FAQ

আমি কি 2 জিবি ভিপিএস-এ Sentry সেলফ-হোস্ট করতে পারি?

না। Sentry-এর সেলফ-হোস্টেড ডকুমেন্টেশন অনুযায়ী ন্যূনতম 4টি সিপিইউ কোর, 16 জিবি র‍্যাম, 16 জিবি সোয়াপ এবং 20 জিবি খালি ডিস্ক প্রয়োজন। এই স্ট্যাকটি একই সাথে Postgres, ClickHouse, Kafka, Redis এবং বেশ কয়েকটি ওয়ার্কার প্রসেস চালায়, তাই ছোট সার্ভারে ইনস্টলেশন শেষ হওয়ার আগেই কার্নেল কন্টেইনারগুলোকে বন্ধ (kill) করে দেয়। এটি নিশ্চিত করতে dmesg -T | grep -i 'out of memory' কমান্ডটি চালান, যা বন্ধ হয়ে যাওয়া প্রসেসের নামসহ একটি লাইন দেখাবে। 2 জিবি ভিপিএস-এর জন্য GlitchTip ব্যবহার করুন, যার জন্য 512 এমবি র‍্যামের প্রয়োজন, অথবা Bugsink ব্যবহার করুন, যা SQLite-এর ওপর ভিত্তি করে একটি মাত্র কন্টেইনার হিসেবে চলে।

Sentry থেকে GlitchTip বা Bugsink-এ যাওয়ার জন্য কি আমার অ্যাপ্লিকেশনের কোড পরিবর্তন করতে হবে?

না। উভয়ই Sentry-এর ওপেন সোর্স এসডিকে (SDK) থেকে ইভেন্ট গ্রহণ করতে পারে। তাই আপনার ইনস্টল করা এসডিকে রেখে শুধু একটি মান পরিবর্তন করলেই হবে: DSN, অর্থাৎ যে ইউআরএল-এ এসডিকে ইভেন্ট পাঠায়। যদি এটি কোডের ভেতরে হার্ডকোড করা থাকে, তবে সেটিকে এনভায়রনমেন্ট ভেরিয়েবলে সরিয়ে নিন, নতুন হোস্টের দিকে নির্দেশ করুন, তারপর একটি টেস্ট এক্সেপশন তৈরি করে দেখুন সেটি পৌঁছাচ্ছে কি না। যদি কিছু না আসে, তবে নিশ্চিত করুন যে DSN-এ থাকা প্রজেক্ট আইডেন্টিফায়ারটি নতুন সার্ভারে বিদ্যমান প্রজেক্টের সাথে মিলছে এবং আপনার ফায়ারওয়াল অ্যাপ্লিকেশনটিকে সেই হোস্ট ও পোর্টে পৌঁছানোর অনুমতি দিচ্ছে।

সেলফ-হোস্টেড এরর ট্র্যাকিংয়ের জন্য কতটুকু ডিস্ক প্রয়োজন?

এটি টুলের চেয়ে আপনার ইভেন্টের পরিমাণ এবং রিটেনশন উইন্ডোর ওপর বেশি নির্ভর করে। GlitchTip প্রতি মাসে দশ লক্ষ ইভেন্ট হ্যান্ডেল করার জন্য 30 জিবি ডিস্কের কথা উল্লেখ করে। Bugsink-এ আপনি সরাসরি MAX_RETENTION_EVENT_COUNT এবং MAX_EVENT_AGE_DAYS দিয়ে বাজেট নির্ধারণ করতে পারেন, তাই আপনি সর্বোচ্চ সীমা নির্ধারণ করলে ডিস্কের প্রয়োজনীয়তা সেই অনুযায়ী নির্ধারিত হয়। প্রথম দিনেই রিটেনশন কনফিগার করুন। কোনো রিটেনশন পলিসি ছাড়া ট্র্যাকার বাড়তে থাকে যতক্ষণ না df -h 100% পূর্ণ হয়, আর তখন ইনজেস্ট বন্ধ হয়ে যায় এবং আপনি সেই এররগুলো হারাবেন যা আপনার সবচেয়ে বেশি প্রয়োজন ছিল।

সেলফ-হোস্টেড Sentry আপগ্রেড কেন বারবার ব্যর্থ হয়?

কারণ আপগ্রেড করার সময় একটি হার্ড স্টপ (hard stop) এড়িয়ে যাওয়া হয়েছে। Sentry সেলফ-হোস্টেড নির্দিষ্ট কিছু ভার্সন নির্ধারণ করে দেয় যেগুলোর মধ্য দিয়ে ডাটাবেস মাইগ্রেশন সম্পন্ন করতে হয়। 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। পুরনো রিলিজ থেকে সরাসরি নতুন ভার্সনে গেলে এই মাইগ্রেশনগুলো বাদ পড়ে যায়, ফলে স্কিমা এবং কোডের মধ্যে অমিল দেখা দেয় এবং আপগ্রেড মাঝপথে আটকে যায়। প্রতিটি হার্ড স্টপ ক্রমানুসারে চেক করুন এবং প্রতিটিতে ./install.sh চালান। শুরু করার আগে সার্ভারের একটি স্ন্যাপশট নিন এবং যে রিলিজগুলো এড়িয়ে চলতে হবে তার তালিকাটি পড়ুন, যার মধ্যে 23.7.0, 25.9.0 এবং 25.12.0 অন্তর্ভুক্ত।