חלופות ל-Sentry בניהול עצמי: השוואת משאבים וביצועים

מה העלות של מעקב שגיאות בניהול עצמי לפני אחסון אירוע בודד

למעקב שגיאות בניהול עצמי יש נתון אחד שקובע את ההחלטה כולה, והוא רף ה-RAM המינימלי. התיעוד הרשמי של Sentry לניהול עצמי דורש 4 ליבות CPU, 16 GB של RAM בתוספת 16 GB של swap, ו-20 GB של שטח דיסק פנוי, עוד לפני שהיישום שלך שלח אירוע אחד. GlitchTip מצידה דורשת 512 MB. כל האפשרויות כאן מקבלות אירועים מאותם ה-SDKs של Sentry, כך שזו אינה החלטה לגבי אופן הטמעת הקוד. זו החלטה לגבי גודל השרת שאתה מוכן לשלם עבורו ולתחזק אותו פעיל.

נתוני משאבים מפורסמים, זה לצד זה

אלו המספרים שכל פרויקט מפרסם אודות עצמו, נכון לאוגוסט 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"
  }
]

הערך 16 GB של Sentry הוא מינימום מתועד, ואותו דף ממליץ על 32 GB. הערך 0.5 GB של GlitchTip הוא המלצה, כאשר הפרויקט מציין 256 MB כמינימום לעבודה, או 128 MB בתוספת swap עם הגדרה זהירה. הערך 4 GB של Bugsink אינו אף אחד מאלה: זוהי החומרה שבה השתמש הספק עבור מדד ביצועי התעבורה שלו. נתון מפורסם הוא נקודת התחלה, לא הבטחה לגבי נפח האירועים שלכם.

Sentry בגרסת self-hosted: המוצר המלא והעלות הכרוכה בו

החבילה הרשמית היא getsentry/self-hosted, פרויקט Docker Compose המריץ את אותם רכיבים ש־Sentry מריצה בסביבת הייצור. התיעוד הרשמי מגדיר אותה כ"בעלת תכונות מלאות, ארוזה עבור פריסות בנפח נמוך וסביבות הוכחת היתכנות". משפט זה הוא סיכום כנה. אתם מקבלים כל תכונה, וכל רכיב פעיל שגורם לתכונות הללו לעבוד.

התקינו מגרסה מתויגת (tagged release) ולא מתוך 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, ומספר תהליכי worker ו־cron. ספרו אותם פעם אחת, כי מספר זה הוא נטל התחזוקה שלכם. כל רשומה היא תהליך שיכול לקרוס, למלא את הדיסק או להיכשל בביצוע migration.

אם שירות נמצא במצב Restarting, בדקו קודם כל את הזיכרון:

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

שורה כמו Out of memory: Killed process 3412 (java) משמעותה ש־OOM killer (מנגנון הריגת תהליכים עקב חוסר זיכרון) של הליבה עצר מכולה כי לשרת נגמר ה־RAM, לכן השירות לעולם לא יהיה תקין והחבילה לעולם לא תסיים לעלות. זו התוצאה הרגילה של הרצת החבילה המלאה מתחת לדרישות המינימום המתועדות. התיעוד מציין גם את מהירות הדיסק: iowait מעל 10% אומר שהמכונה אינה עומדת בקצב של צינור הנתונים (ingest pipeline). קראו זאת מעמודת wa בתוך top, או מתוך iostat -x 5 אם מותקן אצלכם sysstat.

שדרוגים הם החלק שאנשים ממעיטים בערכו

Sentry בגרסת self-hosted משוחררת מדי חודש תחת CalVer, שיטת גרסאות מבוססת לוח שנה, עם שחרור מרכזי ב-15 לכל חודש. אי אפשר לקפוץ מגרסה ישנה ישירות לגרסה האחרונה. הפרויקט מגדיר גרסאות "עצירה" (hard stop), ועליכם לבצע checkout לכל אחת מהן לפי הסדר כדי להחיל את ה-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. התיעוד מפרט גם גרסאות שיש לדלג עליהן בגלל בעיות ב-migration, כולל 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

בצעו Snapshot לשרת לפני שתתחילו, כיוון ש-migration על מאגר נתונים גדול של ClickHouse יכול להימשך שעות, וכישלון באמצע התהליך משאיר את מסד הנתונים בין שני מבנים (schemas). הסיבה הפשוטה לרוב הכישלונות בשדרוג Sentry בגרסת self-hosted: השרת נשאר על גרסה אחת במשך שנה, כך שהקפיצה חוצה כמה גרסאות עצירה בבת אחת, ואחד ה-migrations שדלגתם עליהם היה קריטי.

דבר נוסף שכדאי לדעת לפני שמתחייבים. Sentry בגרסת self-hosted מופצת תחת רישיון Functional Source License (FSL), ש-Sentry עצמה הציגה. זהו רישיון "קוד הוגן" (fair source) ולא קוד פתוח מאושר OSI: מותר לכם להריץ אותו עבור עצמכם, ואסור לכם למכור אותו כשירות מתחרה. כל גרסה הופכת ל-Apache 2.0 שנתיים לאחר שחרורה.

GlitchTip: הפתרון ל-512 MB

GlitchTip מופץ תחת רישיון MIT ומקבל אירועים מ-SDKs בקוד פתוח של Sentry. לכן, העברת יישום מנוטר מתבצעת על ידי שינוי ערך אחד: ה-DSN (קיצור של Data Source Name, ה-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 ונתיב הדואר:

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

תגיות ה-image בדוגמה נכון לאוגוסט 2026 הן postgres:18, valkey/valkey:9 ו-glitchtip/glitchtip:6. שמור עליהן מקובעות (pinned). קובץ compose שמגדיר latest ישדרג את מנוע מסד הנתונים שלך ב-docker compose pull הבא, וקפיצת גרסה ראשית של Postgres תחת מופע פעיל היא הדרך שבה כלי לניטור שגיאות מפסיק לעבוד.

כדי להגיע לטווח של 256 MB עד 512 MB, ההערות בקובץ הדוגמה מנחות אותך מה לכבות, החל מ-Valkey וכלה בתכונות האופציונליות של לוגים וניטור uptime. הרצה ללא Valkey משמעותה ש-GlitchTip ישתמש במסד הנתונים עבור עבודות cache ותור; זה איטי יותר אך עדיין תקין. מצב "הכל באחד" (all in one) מריץ את ה-worker בתוך תהליך ה-web, כך שאתה מתחזק מכולת יישום אחת במקום שתיים.

הצב proxy לפני השירות. התיעוד של GlitchTip דורש proxy או load balancer שמבצע buffering לבקשות ומטפל ב-Transfer-Encoding מקוטע (chunked), והוא מציע את nginx כדוגמה עובדת. ללא buffering, לקוח איטי מחזיק worker של היישום פתוח לאורך כל ה-upload, כך שמספר קטן של שולחים איטיים עלול לתפוס את כל ה-workers שברשותך, ולקוחות תקינים יתחילו לקבל שגיאות timeout.

שדרוגים הם החלק הפשוט:

docker compose pull
docker compose stop
docker compose up -d

מיגרציות של מסד הנתונים רצות אוטומטית בעת ההפעלה. בכל מקרה, בצע גיבוי (dump) תחילה, כיוון שמיגרציה אוטומטית היא עדיין מיגרציה.

Bugsink: מכולה אחת, ורישיון שחובה לקרוא

Bugsink הוא הקל ביותר מבין השלושה. הוא תומך בפרוטוקול ה-Sentry SDK, ורץ ללא תור הודעות וללא שירות חיצוני מלבד מסד נתונים. SQLite הוא ברירת המחדל, עם תמיכה ב-MySQL וב-PostgreSQL כאשר הצרכים גדלים מעבר לכך.

מופע זמני (throwaway), כדי להתרשם מהממשק לפני שמחליטים:

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. צרו את ה-secret בצורה תקינה:

openssl rand -base64 50

BASE_URL חייב להתאים ל-URL שהמשתמשים וה-SDKs שלכם משתמשים בו בפועל, כולל הסכימה. השאירו אותו כ-http://localhost:8000 בשרת שאליו אתם ניגשים ב-https://errors.example.com, וכל קישור בהודעת דוא"ל יצביע על מארח שלא יתורגם עבור האדם שקורא אותו. הגדירו את BEHIND_HTTPS_PROXY ל-true כאשר Nginx או Caddy מבצעים TLS termination לפניו, אחרת Bugsink יבנה כתובות http:// מאחורי ה-proxy שלכם ב-https://, ודפדפנים יחסמו את התוכן המעורב (mixed content).

הספק מפרסם נתוני תעבורה משלו: 18 אירועים בשנייה בגודל 50 KB כל אחד, מה שמסתכם ב-1.5 מיליון אירועים ביום, על גבי VPS עם 2 vCPU ו-4 GB זיכרון. התייחסו לנתונים אלו כאל הערכת יכולות ולא כהתחייבות לעומס העבודה שלכם. עם זאת, הם מעידים על כך שהתקרה גבוהה בהרבה ממה שיישום קטן אחד מייצר.

כעת הרישיון, וזה החלק שחובה לקרוא לפני שהוא נכנס ל-stack שלכם. Bugsink מופץ תחת רישיון PolyForm Shield License 1.0.0. זהו רישיון "source available", לא קוד פתוח: מותר לכם להריץ ולשנות אותו, אך אסור לכם להשתמש בו כדי לבנות מוצר שמתחרה ב-Bugsink. עבור מערכת פנימית למעקב אחר שגיאות, הגבלה זו אינה רלוונטית. אם החברה שלכם מוכרת כלי פיתוח, ודאו שמישהו קורא את טקסט הרישיון תחילה.

מעקב אחר שגיאות וניטור LLM הם עדיין שני כלים נפרדים

חפשו כלי אחד שמבצע גם מעקב אחר שגיאות וגם ניטור (observability) של מודלי שפה גדולים (LLM), ותמצאו מוצרים שטוענים שהם עושים את שניהם. מבני הנתונים שונים, וזו הסיבה שהמיזוג ביניהם לא מתרחש. כלי למעקב אחר שגיאות מקבל חריגה (exception) עם stack trace, מחשב עבורה טביעת אצבע (fingerprint), ומאחד אלפי מופעים לבעיה אחת עם מונה. כלי לניטור LLM מקבל span המכיל prompt, תגובה, ספירת tokens וזמן תגובה (latency), ועליו לשמור את כל אחד מהם בנפרד; זאת מכיוון ששתי קריאות עם קלטים זהים הן עדיין אירועים נפרדים שראוי לבחון.

לכן, הריצו את שניהם. שלחו חריגות לכלי המעקב אחר שגיאות, ושלחו קריאות למודל למקום שנבנה עבורן: Langfuse בהתקנה עצמית למעקב אחר סוכנים מכסה את הצד הזה, ו-ניטור AI בהתקנה עצמית ניגש לאותה משימה מזווית אחרת. היישום שלכם כבר מייצר את שני סוגי הכשלים. קריאה למודל שמחזירה תשובה שגויה בביטחון עצמי אינה זורקת חריגה כלל, ולכן כלי למעקב אחר שגיאות לעולם לא יציג לכם אותה.

גידול בנפח הדיסק הוא כשל שמתגלה מאוחר

כל מערכת למעקב אחר שגיאות היא מסד נתונים עתיר כתיבה עם קלט בלתי מוגבל. היישום שלכם קובע את היקף הכתיבה, ובאג חדש בנתיב קוד פעיל עלול לייצר מיליון אירועים במהלך לילה אחד.

GlitchTip מפרסמת נתון שכדאי לתכנן לפיו: מופע (instance) המטפל במיליון אירועים בחודש עשוי להזדקק ל-30 GB של שטח דיסק. נפח זה מכסה חודש אחד של קליטת נתונים בקצב הזה, וחלון השמירה (retention) שלכם הוא שקובע כמה חודשים יישמרו בו-זמנית.

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 מציג את גדלי הנפחים, כך שתוכלו לראות איזה שירות הוא זה שגדל. נפח שצובר כמה גיגה-בייטים בשבוע ללא שינוי בתעבורה מעיד בדרך כלל על כך ששמירת הנתונים מעולם לא הוגדרה, ולכן דבר אינו נמחק והמגבלה היחידה היא המחיצה עצמה.

זיכרון הוא אותה בעיה בתחפושת אחרת. מחסנית (stack) ללא מגבלות תצרוך את כל מה שה-kernel מציע, וכאשר המכונה תגיע לקצה גבול היכולת, ה-OOM killer יבחר בתהליך הגדול ביותר, שעלול להיות שרת ה-web שלכם ולא הכלי למעקב שגרם לבעיה. הגדירו לכל שירות תקרה: מגבלות זיכרון ב-Docker Compose מציג את התחביר ואת התנהגות המכולה כשהיא מגיעה למכסה שלה. מכולה שנסגרת בגלל מגבלה שהוגדרה לה היא כשל מבודד. מכולה שנסגרת על ידי ה-kernel עלולה להפיל איתה גם שירותים שכנים.

איזה stack מתאים לאיזה VPS

• 1 GB, או 2 GB עם מרווח נשימה: GlitchTip במצב all in one עם Valkey כבוי, או Bugsink על SQLite. שניהם ירוצו בנוחות על נפח זה עבור מספר קטן של יישומים.
• 4 GB: Bugsink עם PostgreSQL, או GlitchTip עם Valkey פעיל ושירות worker נפרד. זהו הגודל שבו אפשר להפסיק לבצע אופטימיזציות ולהריץ את המערכת כפי שהיא.
• 8 GB: עדיין לא מספיק עבור ה-stack הרשמי של Sentry. השקיעו את המשאבים האלו בחלון שמירת נתונים (retention) ארוך יותר ובדיסק גדול יותר עבור כל אחת מהאפשרויות הקלות שבחרתם.
• 16 GB מינימום, 32 GB מומלץ: ה-stack הרשמי של Sentry בהתקנה עצמית, ורק כאשר אתם זקוקים לתכונה של Sentry שפרויקטים קלים יותר אינם מיישמים. בדקו תחילה את התכונה הספציפית מול התיעוד של כל פרויקט, כיוון שהפרויקטים התואמים מכסים את רוב התכונות הנפוצות.

לא משנה מה תריצו, כלי מעקב השגיאות אינו יכול לדווח על מותו שלו. הגדירו בדיקת תקינות עבורו ממכונה אחרת: Uptime Kuma המנטר ממכונה אחרת יתריע בפניכם שהכלי אינו זמין, בדיוק ברגע שבו היישום שלכם מתחיל להציג שגיאות שאף אחד לא מתעד.

מתי תוכנית אירוח היא הפתרון הזול יותר

אירוח עצמי של מערכת לניטור שגיאות משתלם כאשר כללי שמירת נתונים מחייבים זאת, או כאשר נפח האירועים שלכם גבוה מספיק כדי שהתמחור לפי אירוע יהיה יקר. מחוץ למקרים אלו, בצעו את החישוב בכנות. הדרישה המינימלית המתועדת של Sentry היא שרת עם 16 GB זיכרון, 4 ליבות ודיסק מהיר, ושרת VPS בגודל כזה אינו זול. לאחר מכן, הוסיפו את העבודה התפעולית: מעבר על כל שלב קריטי לפי הסדר, וביצוע snapshot לפני כל שדרוג, כמה פעמים בשנה.

GlitchTip ו־Bugsink משנים את החישוב הזה לחלוטין, מכיוון ששרת עם 512 MB עד 4 GB הוא מכונה לא יקרה והשדרוג הוא docker compose pull. זו הסיבה שרוב האנשים ששואלים את השאלה הזו מסיימים עם אחד הפרויקטים התואמים במקום עם ה־stack הרשמי. הם רצו ניטור שגיאות, לא צינור נתונים מבוזר שצריך להשגיח עליו.

אם אתם עדיין מנסים להחליט מה בכלל כדאי להחזיק על השרת, הרשימה הרחבה של מה ששווה לארח באופן עצמי מציבה את ניטור השגיאות לצד שירותים אחרים שמתחרים על אותו הזיכרון.

FAQ

האם ניתן לארח Sentry באופן עצמאי על שרת VPS עם 2 GB RAM?

לא. התיעוד של Sentry לאירוח עצמי מציין דרישת מינימום של 4 ליבות CPU, 16 GB RAM בתוספת 16 GB של swap, ו-20 GB של שטח דיסק פנוי. ה-stack מריץ בו-זמנית את Postgres, ClickHouse, Kafka, Redis ומספר תהליכי worker, לכן על שרת קטן ה-kernel מסיים (kill) את המכולות לפני סיום ההתקנה. ניתן לאמת זאת בעזרת dmesg -T | grep -i 'out of memory', שמדפיס שורה המציינת את התהליך שנסגר. עבור שרת VPS עם 2 GB RAM, השתמשו ב-GlitchTip, שמתועד לעבודה עם 512 MB, או ב-Bugsink, שרץ כמכולה בודדת על גבי SQLite.

האם עלי לשנות את קוד היישום כדי לעבור מ-Sentry ל-GlitchTip או ל-Bugsink?

לא. שניהם מקבלים אירועים מה-SDKs בקוד פתוח של Sentry, לכן תוכלו להשאיר את ה-SDK שכבר התקנתם ולשנות ערך אחד בלבד: ה-DSN, כלומר ה-URL שאליו ה-SDK שולח אירועים. העבירו אותו למשתנה סביבה אם הוא עדיין מוטמע בקוד (hardcoded), כוונו אותו לשרת החדש, ולאחר מכן צרו חריגה (exception) לבדיקה וודאו שהיא מגיעה. אם דבר לא מופיע, בדקו שמזהה הפרויקט ב-DSN תואם לפרויקט שקיים בשרת החדש, ושה-firewall מאפשר ליישום להגיע לאותו host ופורט.

כמה שטח דיסק דורשת מערכת מעקב שגיאות באירוח עצמי?

זה תלוי בנפח האירועים שלכם ובתקופת השמירה (retention) ולא בכלי עצמו. GlitchTip מפרסמים דרישה של 30 GB עבור מופע המטפל במיליון אירועים בחודש. 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. מעבר ישיר מגרסה ישנה לחדשה ביותר מדלג על מיגרציות אלו, לכן ה-schema והקוד אינם תואמים והשדרוג נעצר באמצע. עברו דרך כל נקודת עצירה לפי הסדר והריצו את ./install.sh בכל אחת מהן, בצעו snapshot לשרת לפני תחילת התהליך, וקראו את רשימת הגרסאות שיש להימנע מהן, הכוללת את 23.7.0, 25.9.0 ו-25.12.0.