เปรียบเทียบ Sentry กับทางเลือกอื่นสำหรับ Self-hosted

ต้นทุนของระบบติดตามข้อผิดพลาดแบบ self-hosted ก่อนเริ่มจัดเก็บเหตุการณ์แรก

ระบบติดตามข้อผิดพลาดแบบ self-hosted มีตัวเลขหนึ่งตัวที่ใช้ตัดสินใจเลือกใช้งานทั้งหมด นั่นคือค่า RAM ขั้นต่ำ เอกสารประกอบของ Sentry สำหรับการติดตั้งแบบ self-hosted ระบุความต้องการไว้ที่ CPU 4 คอร์, RAM 16 GB รวมกับ swap อีก 16 GB และพื้นที่ดิสก์ว่าง 20 GB ก่อนที่แอปพลิเคชันของคุณจะส่งเหตุการณ์แรกเข้ามาเสียอีก ในขณะที่ GlitchTip ระบุความต้องการไว้ที่ 512 MB ตัวเลือกทั้งหมดนี้รองรับการรับเหตุการณ์จาก Sentry SDK ชุดเดียวกัน ดังนั้นนี่จึงไม่ใช่การตัดสินใจว่าคุณจะทำ instrumentation ในโค้ดอย่างไร แต่เป็นการตัดสินใจว่าคุณยินดีที่จะจ่ายเงินและดูแลรักษาเซิร์ฟเวอร์ขนาดใหญ่เพียงใดเพื่อให้ระบบทำงานได้

ตัวเลขทรัพยากรที่เผยแพร่ เปรียบเทียบเคียงข้างกัน

นี่คือตัวเลขที่แต่ละโปรเจกต์เผยแพร่เกี่ยวกับตนเอง ณ เดือนสิงหาคม 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 นั้นไม่ใช่ทั้งสองกรณี แต่เป็นขนาดของเครื่องที่ผู้ให้บริการใช้สำหรับการทดสอบประสิทธิภาพ (throughput benchmark) ของตนเอง ตัวเลขที่เผยแพร่เป็นเพียงจุดเริ่มต้น ไม่ใช่การรับประกันปริมาณเหตุการณ์ (event volume) ที่คุณจะได้รับ

Sentry แบบ self-hosted: ทั้งผลิตภัณฑ์และภาระที่ต้องแบกรับ

Stack อย่างเป็นทางการคือ getsentry/self-hosted ซึ่งเป็นโปรเจกต์ Docker Compose ที่รันคอมโพเนนต์เดียวกับที่ Sentry ใช้ในระบบ production เอกสารประกอบระบุไว้ว่าเป็น "ฟีเจอร์ครบถ้วนและบรรจุมาเพื่อการใช้งานในปริมาณน้อยและการทำ proof-of-concept" ประโยคนั้นคือบทสรุปที่ตรงไปตรงมาที่สุด คุณจะได้รับทุกฟีเจอร์และทุกส่วนประกอบที่ทำให้ฟีเจอร์เหล่านั้นทำงานได้

ให้ติดตั้งจาก 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 จะแสดงรายการทุก service ใน stack ซึ่งมีรายการยาวมาก ได้แก่ Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator และกระบวนการ worker กับ cron อีกหลายรายการ ให้ลองนับดูสักครั้ง เพราะนั่นคือภาระในการดูแลรักษาของคุณ แต่ละรายการคือกระบวนการที่อาจ crash, ทำให้ดิสก์เต็ม หรือการทำ migration ล้มเหลวได้

หาก service ค้างอยู่ในสถานะ Restarting ให้ตรวจสอบหน่วยความจำก่อนเป็นอันดับแรก:

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

บรรทัดที่ระบุว่า Out of memory: Killed process 3412 (java) หมายความว่า OOM killer (out of memory killer) ของ kernel ได้สั่งปิด container นั้นไปเนื่องจากเครื่อง RAM ไม่พอ ทำให้ service นั้นไม่สามารถทำงานได้ตามปกติและ stack ไม่สามารถเริ่มการทำงานได้จนเสร็จ นี่เป็นผลลัพธ์ปกติของการรัน stack เต็มรูปแบบโดยใช้ทรัพยากรต่ำกว่าขั้นต่ำที่ระบุไว้ในเอกสาร นอกจากนี้เอกสารยังระบุถึงความเร็วของดิสก์ไว้ด้วย: หาก iowait สูงกว่า 10% หมายความว่าเครื่องไม่สามารถรองรับปริมาณข้อมูลที่เข้ามาได้ ให้ตรวจสอบจากคอลัมน์ wa ใน top หรือจาก iostat -x 5 หากคุณติดตั้ง sysstat ไว้

การอัปเกรดคือสิ่งที่คนมักประเมินต่ำไป

Sentry แบบ self-hosted ออกเวอร์ชันใหม่ทุกเดือนภายใต้ CalVer ซึ่งเป็นรูปแบบการตั้งชื่อเวอร์ชันตามปฏิทิน โดยมีการปล่อย release หลักในวันที่ 15 ของทุกเดือน คุณไม่สามารถข้ามจากเวอร์ชันเก่าไปยังเวอร์ชันล่าสุดได้โดยตรง โปรเจกต์ได้กำหนดเวอร์ชันที่เป็น hard stop ไว้ และคุณต้อง checkout ทีละเวอร์ชันตามลำดับเพื่อดำเนินการ database migration ให้ครบถ้วน ณ เดือนสิงหาคม 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 ที่ควรข้ามเนื่องจากปัญหาการ 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 ขนาดใหญ่อาจใช้เวลาหลายชั่วโมง และหากล้มเหลวระหว่างทางจะทำให้ฐานข้อมูลค้างอยู่ระหว่างสอง schema สาเหตุหลักที่ทำให้การอัปเกรด Sentry แบบ self-hosted ล้มเหลวคือการที่เครื่องไม่ได้อัปเกรดเป็นเวลาหนึ่งปี ทำให้การข้ามเวอร์ชันต้องผ่าน hard stop หลายจุดพร้อมกัน และหนึ่งใน migration ที่ถูกข้ามไปนั้นเป็นจุดที่สำคัญ

อีกสิ่งหนึ่งที่ควรทราบก่อนตัดสินใจใช้งาน Sentry แบบ self-hosted อยู่ภายใต้สัญญาอนุญาต Functional Source License (FSL) ซึ่งทาง Sentry เป็นผู้กำหนดขึ้นเอง นี่เป็นสัญญาอนุญาตแบบ fair source ไม่ใช่ open source ที่ผ่านการรับรองจาก OSI: คุณสามารถรันเพื่อใช้งานเองได้ แต่ห้ามนำไปขายเป็นบริการที่แข่งขันกับผู้ให้บริการหลัก โดยแต่ละ release จะเปลี่ยนเป็น Apache 2.0 หลังจากผ่านไปสองปีนับจากวันที่ปล่อยออกมา

GlitchTip: คำตอบสำหรับหน่วยความจำ 512 MB

GlitchTip เป็นซอฟต์แวร์ภายใต้สัญญาอนุญาต MIT ที่รองรับการรับ event จาก SDK แบบโอเพนซอร์สของ Sentry ดังนั้นแอปพลิเคชันที่ติดตั้งเครื่องมือวัด (instrumented) อยู่แล้วสามารถย้ายมาใช้งานได้ทันทีเพียงแค่เปลี่ยนค่าเดียว คือ DSN (data source name ซึ่งเป็น URL ที่ SDK ของคุณใช้ส่ง event ไปยังปลายทาง) โดยต้องการ 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 คือ postgres:18, valkey/valkey:9 และ glitchtip/glitchtip:6 ควรตรึงเวอร์ชันไว้เสมอ ไฟล์ compose ที่ระบุ latest จะอัปเกรดเอนจินฐานข้อมูลของคุณในการสั่ง docker compose pull ครั้งถัดไป และการข้ามเวอร์ชันหลักของ Postgres ในขณะที่อินสแตนซ์กำลังทำงานอยู่เป็นสาเหตุที่ทำให้ระบบติดตามข้อผิดพลาดที่เคยใช้งานได้หยุดทำงาน

เพื่อให้การใช้งานอยู่ในช่วง 256 MB ถึง 512 MB ความคิดเห็นในไฟล์ตัวอย่างจะระบุสิ่งที่คุณสามารถปิดได้ โดยเริ่มจาก Valkey และฟีเจอร์ log กับ uptime ที่เป็นทางเลือกเสริม การรันโดยไม่มี Valkey หมายความว่า GlitchTip จะใช้ฐานข้อมูลสำหรับงานแคชและคิวแทน ซึ่งจะช้ากว่าแต่ยังคงทำงานได้ถูกต้อง โหมด all in one จะรัน worker ไว้ภายในกระบวนการของเว็บ ทำให้คุณดูแลคอนเทนเนอร์แอปพลิเคชันเพียงตัวเดียวแทนที่จะเป็นสองตัว

ควรวาง proxy ไว้ด้านหน้า GlitchTip เอกสารของ GlitchTip แนะนำให้ใช้ proxy หรือ load balancer ที่สามารถบัฟเฟอร์คำขอและจัดการ chunked Transfer-Encoding ได้ โดยยกตัวอย่างการใช้งาน nginx หากไม่มีการบัฟเฟอร์ ไคลเอนต์ที่ช้าจะทำให้ worker ของแอปพลิเคชันถูกจองค้างไว้ตลอดระยะเวลาการอัปโหลด ส่งผลให้ไคลเอนต์ที่ทำงานปกติเริ่มเกิด timeout เนื่องจาก worker ถูกใช้งานจนเต็ม

การอัปเกรดเป็นเรื่องง่าย:

docker compose pull
docker compose stop
docker compose up -d

การทำ database migration จะทำงานโดยอัตโนมัติเมื่อเริ่มระบบ อย่างไรก็ตามควรทำ dump ข้อมูลไว้ก่อนเสมอ เพราะการ migration แบบอัตโนมัติก็ยังถือเป็นการเปลี่ยนแปลงโครงสร้างฐานข้อมูลอยู่ดี

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 ให้สร้าง secret อย่างถูกต้องดังนี้:

openssl rand -base64 50

BASE_URL ต้องตรงกับ URL ที่ผู้ใช้และ SDK ของคุณใช้งานจริง รวมถึง scheme ด้วย หากปล่อยไว้เป็น http://localhost:8000 บนเครื่องที่คุณเข้าถึงผ่าน https://errors.example.com ลิงก์ทั้งหมดในอีเมลแจ้งเตือนจะชี้ไปยังโฮสต์ที่ผู้รับอีเมลไม่สามารถเข้าถึงได้ ให้ตั้งค่า BEHIND_HTTPS_PROXY เป็น true เมื่อคุณใช้ Nginx หรือ Caddy ทำ TLS termination อยู่ด้านหน้า เพราะมิฉะนั้น Bugsink จะสร้าง URL แบบ 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 ไม่ใช่ open source คุณสามารถเรียกใช้งานและแก้ไขได้ แต่คุณไม่สามารถนำไปใช้สร้างผลิตภัณฑ์ที่แข่งขันกับ Bugsink ได้ สำหรับการใช้งานเป็นเครื่องมือติดตามข้อผิดพลาดภายในองค์กร ข้อจำกัดนี้ไม่มีผลกระทบใดๆ แต่หากบริษัทของคุณทำธุรกิจขายเครื่องมือสำหรับนักพัฒนา ควรให้ผู้ที่มีหน้าที่เกี่ยวข้องอ่านข้อความในใบอนุญาตก่อนใช้งาน

การติดตามข้อผิดพลาดและการสังเกตการณ์ LLM ยังคงเป็นเครื่องมือสองประเภท

หากคุณค้นหาเครื่องมือที่ทำทั้งการติดตามข้อผิดพลาด (error tracking) และการสังเกตการณ์โมเดลภาษาขนาดใหญ่ (LLM observability) ในตัวเดียว คุณจะพบผลิตภัณฑ์ที่อ้างว่าทำได้ทั้งสองอย่าง อย่างไรก็ตาม รูปแบบของข้อมูลนั้นแตกต่างกัน ซึ่งเป็นเหตุผลว่าทำไมการรวมสองสิ่งนี้เข้าด้วยกันจึงไม่เกิดขึ้นจริง เครื่องมือติดตามข้อผิดพลาดจะรับข้อยกเว้น (exception) พร้อม stack trace จากนั้นจะคำนวณ fingerprint และรวมเหตุการณ์ที่เกิดขึ้นนับพันครั้งให้เป็นปัญหาเดียวพร้อมตัวนับ ในขณะที่เครื่องมือติดตาม LLM จะรับ span ที่เก็บ prompt, response, จำนวน token และค่า latency โดยที่เครื่องมือต้องเก็บข้อมูลทุกรายการไว้ทั้งหมด เพราะการเรียกใช้งานสองครั้งที่มี input เหมือนกันก็ยังถือเป็นเหตุการณ์แยกต่างหากที่ควรค่าแก่การตรวจสอบ

ดังนั้น ให้ใช้งานทั้งสองอย่าง ส่งข้อยกเว้นไปยังเครื่องมือติดตามข้อผิดพลาด และส่งการเรียกใช้งานโมเดลไปยังเครื่องมือที่สร้างมาเพื่อการนั้นโดยเฉพาะ การติดตั้ง Langfuse บนเซิร์ฟเวอร์ตนเองเพื่อติดตาม agent ครอบคลุมในส่วนนั้น และ การติดตั้งเครื่องมือสังเกตการณ์ AI บนเซิร์ฟเวอร์ตนเอง เป็นแนวทางในการทำงานเดียวกันจากมุมมองที่ต่างออกไป แอปพลิเคชันของคุณสร้างความล้มเหลวทั้งสองรูปแบบอยู่แล้ว การเรียกใช้งานโมเดลที่ส่งคืนคำตอบที่ดูมั่นใจแต่ไร้สาระจะไม่ทำให้เกิดข้อยกเว้นใดๆ ดังนั้นเครื่องมือติดตามข้อผิดพลาดจึงไม่แสดงข้อมูลส่วนนี้ให้คุณเห็น

การเพิ่มขึ้นของพื้นที่ดิสก์คือความล้มเหลวที่จะพบในภายหลัง

ระบบติดตามข้อผิดพลาดทุกตัวคือฐานข้อมูลที่เน้นการเขียนข้อมูลปริมาณมากและมีอินพุตที่ไม่จำกัด แอปพลิเคชันของคุณเป็นตัวกำหนดปริมาณการเขียน และบั๊กใหม่เพียงจุดเดียวในโค้ดส่วนที่ทำงานบ่อยอาจสร้างเหตุการณ์นับล้านรายการได้ในชั่วข้ามคืน

GlitchTip ได้เผยแพร่ตัวเลขที่ควรนำมาใช้ในการวางแผน: อินสแตนซ์ที่จัดการเหตุการณ์หนึ่งล้านรายการต่อเดือนอาจต้องใช้พื้นที่ดิสก์ 30 GB ตัวเลขนี้ครอบคลุมการรับข้อมูลหนึ่งเดือนในอัตราดังกล่าว และระยะเวลาการเก็บรักษา (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 killer จะเลือกยุติโพรเซสที่ใหญ่ที่สุด ซึ่งอาจเป็นเว็บเซิร์ฟเวอร์ของคุณแทนที่จะเป็นตัวติดตามที่ก่อปัญหา ควรจำกัดเพดานการใช้งานให้ทุกบริการ: การจำกัดหน่วยความจำใน Docker Compose แสดงไวยากรณ์และสิ่งที่คอนเทนเนอร์จะทำเมื่อถึงขีดจำกัด คอนเทนเนอร์ที่ถูกยุติการทำงานที่ขีดจำกัดของตัวเองถือเป็นความล้มเหลวที่ถูกจำกัดวงไว้ แต่คอนเทนเนอร์ที่ถูกยุติโดยเคอร์เนลจะส่งผลกระทบต่อบริการข้างเคียงไปด้วย

สแต็กที่เหมาะสมกับ VPS แต่ละขนาด

• 1 GB หรือ 2 GB ที่มีพื้นที่เหลือ: GlitchTip ในโหมด all-in-one โดยปิดการใช้งาน Valkey หรือ Bugsink ที่ใช้ SQLite ทั้งสองตัวนี้ทำงานได้อย่างราบรื่นสำหรับแอปพลิเคชันจำนวนไม่มาก
• 4 GB: Bugsink ที่ใช้ PostgreSQL หรือ GlitchTip ที่เปิดใช้งาน Valkey และแยก service ของ worker ออกมา ขนาดนี้เป็นจุดที่คุณไม่ต้องปรับแต่งอะไรเพิ่มเติมและสามารถใช้งานได้ทันที
• 8 GB: ยังคงไม่เพียงพอสำหรับ Sentry stack อย่างเป็นทางการ ให้ใช้ทรัพยากรส่วนนี้ไปกับการเพิ่มระยะเวลาการเก็บข้อมูล (retention window) และขยายขนาดดิสก์สำหรับตัวเลือกแบบเบาที่คุณเลือกใช้
• 16 GB เป็นอย่างน้อย และแนะนำที่ 32 GB: สำหรับ Sentry self-hosted stack อย่างเป็นทางการ และควรใช้เฉพาะเมื่อคุณจำเป็นต้องใช้ฟีเจอร์ของ Sentry ที่โปรเจกต์ขนาดเบาไม่มีให้เท่านั้น โปรดตรวจสอบฟีเจอร์ที่ต้องการเทียบกับเอกสารของแต่ละโปรเจกต์ก่อน เนื่องจากโปรเจกต์ทางเลือกส่วนใหญ่ครอบคลุมฟีเจอร์ที่ใช้งานทั่วไปอยู่แล้ว

ไม่ว่าคุณจะรันอะไรก็ตาม ระบบติดตามข้อผิดพลาด (error tracker) ไม่สามารถแจ้งเตือนเมื่อตัวมันเองหยุดทำงานได้ ดังนั้นควรตั้งค่าการตรวจสอบจากเครื่องอื่น: Uptime Kuma ที่เฝ้าดูจากเครื่องอื่น จะแจ้งให้คุณทราบหากระบบติดตามล่ม ซึ่งเป็นช่วงเวลาเดียวกับที่แอปพลิเคชันของคุณเริ่มเกิดข้อผิดพลาดโดยที่ไม่มีใครบันทึกไว้

เมื่อแผนบริการแบบโฮสต์เป็นทางเลือกที่ประหยัดกว่า

การทำ self-host ระบบติดตามข้อผิดพลาด (error tracker) จะคุ้มค่าก็ต่อเมื่อกฎระเบียบด้านถิ่นที่อยู่ของข้อมูล (data residency) บังคับให้ต้องทำ หรือเมื่อปริมาณเหตุการณ์ (event volume) ของคุณสูงจนการคิดราคาต่อเหตุการณ์ส่งผลกระทบต่อต้นทุน นอกเหนือจากกรณีเหล่านี้ ให้คำนวณตัวเลขอย่างตรงไปตรงมา ข้อกำหนดขั้นต่ำของ Sentry คือเซิร์ฟเวอร์ขนาด 16 GB พร้อม 4 คอร์และดิสก์ความเร็วสูง ซึ่ง VPS ขนาดดังกล่าวไม่ใช่ VPS ราคาถูก จากนั้นให้บวกภาระงานด้านการดูแลระบบเข้าไปด้วย เช่น การทำตามขั้นตอนที่ซับซ้อนตามลำดับ และการทำ snapshot ก่อนการอัปเกรดแต่ละครั้ง ซึ่งต้องทำปีละหลายครั้ง

GlitchTip และ Bugsink เปลี่ยนสมการต้นทุนนี้ไปโดยสิ้นเชิง เนื่องจากเซิร์ฟเวอร์ขนาด 512 MB ถึง 4 GB เป็นเครื่องที่มีราคาไม่แพง และการอัปเกรดก็เป็นเพียง docker compose pull นี่คือเหตุผลที่คนส่วนใหญ่ที่ถามคำถามนี้ลงเอยด้วยการเลือกใช้โปรเจกต์ที่รองรับแทนที่จะใช้ stack อย่างเป็นทางการ เพราะพวกเขาต้องการเพียงระบบติดตามข้อผิดพลาด ไม่ใช่ระบบท่อส่งข้อมูลแบบกระจายศูนย์ที่ต้องคอยเฝ้าดูแล

หากคุณยังตัดสินใจไม่ได้ว่าควรนำบริการใดมาไว้บนเซิร์ฟเวอร์บ้าง รายการบริการที่คุ้มค่าแก่การทำ self-host ได้จัดวางระบบติดตามข้อผิดพลาดไว้เคียงข้างกับบริการอื่นๆ ที่ต้องแย่งชิงทรัพยากร RAM บนเซิร์ฟเวอร์เดียวกัน

FAQ

ฉันสามารถ self-host Sentry บน VPS ขนาด 2 GB ได้หรือไม่

ไม่ได้ เอกสารประกอบของ Sentry แบบ self-hosted ระบุความต้องการขั้นต่ำไว้ที่ 4 CPU cores, RAM 16 GB พร้อม swap 16 GB และพื้นที่ดิสก์ว่าง 20 GB เนื่องจาก stack นี้รัน Postgres, ClickHouse, Kafka, Redis และ worker process หลายตัวพร้อมกัน บนเครื่องขนาดเล็ก kernel จะสั่ง kill คอนเทนเนอร์ก่อนการติดตั้งจะเสร็จสิ้น ให้ตรวจสอบเรื่องนี้ด้วย dmesg -T | grep -i 'out of memory' ซึ่งจะแสดงบรรทัดที่ระบุชื่อ process ที่ถูก kill สำหรับ VPS ขนาด 2 GB ให้ใช้ GlitchTip ซึ่งระบุความต้องการไว้ที่ 512 MB หรือใช้ Bugsink ซึ่งรันเป็นคอนเทนเนอร์เดี่ยวบน SQLite

ฉันต้องแก้ไขโค้ดแอปพลิเคชันเพื่อเปลี่ยนจาก Sentry ไปใช้ GlitchTip หรือ Bugsink หรือไม่

ไม่จำเป็น ทั้งสองบริการรองรับการรับ event จาก SDK แบบ open source ของ Sentry ดังนั้นคุณสามารถใช้ SDK เดิมที่ติดตั้งไว้แล้วได้ เพียงแค่เปลี่ยนค่าเดียวคือ DSN ซึ่งเป็น URL ที่ SDK ใช้ส่ง event หากยังมีการ hardcode ไว้ในโค้ด ให้ย้ายไปไว้ใน environment variable แล้วชี้ไปยัง host ใหม่ จากนั้นลองสร้าง test exception ขึ้นมาแล้วตรวจสอบว่าได้รับข้อมูลหรือไม่ หากไม่มีอะไรปรากฏขึ้น ให้ตรวจสอบว่า project identifier ใน DSN ตรงกับโปรเจกต์ที่มีอยู่บนเซิร์ฟเวอร์ใหม่ และ firewall ของคุณอนุญาตให้แอปพลิเคชันเข้าถึง host และพอร์ตนั้นได้

การทำ error tracking แบบ self-hosted ต้องใช้พื้นที่ดิสก์เท่าใด

ขึ้นอยู่กับปริมาณ event และระยะเวลาการเก็บข้อมูล (retention window) ของคุณ ไม่ใช่ขึ้นอยู่กับตัวเครื่องมือ GlitchTip ระบุว่าต้องใช้พื้นที่ 30 GB สำหรับ instance ที่รองรับ event หนึ่งล้านรายการต่อเดือน ส่วน Bugsink ให้คุณกำหนดงบประมาณได้โดยตรงด้วย MAX_RETENTION_EVENT_COUNT และ MAX_EVENT_AGE_DAYS ดังนั้นคุณสามารถเลือกเพดานที่ต้องการและพื้นที่ดิสก์ที่ต้องใช้จะแปรผันตามนั้น ควรตั้งค่า retention ตั้งแต่วันแรก เครื่องมือติดตามที่ไม่มีนโยบาย retention จะขยายขนาดขึ้นเรื่อยๆ จนกระทั่ง df -h แสดงค่า 100% ซึ่ง ณ จุดนั้นการรับข้อมูลจะหยุดลงและคุณจะสูญเสีย error ที่คุณต้องการตรวจสอบมากที่สุดไป

ทำไมการอัปเกรด Sentry แบบ self-hosted ถึงล้มเหลวอยู่ตลอด

เพราะการอัปเกรดข้ามขั้นตอนสำคัญ (hard stop) ไป Sentry แบบ self-hosted ได้กำหนดเวอร์ชันเฉพาะที่มีการทำ database migration ซึ่งคุณจำเป็นต้องผ่านเวอร์ชันเหล่านั้นตามลำดับ โดย ณ เดือนสิงหาคม 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 เก่าไปยังเวอร์ชันล่าสุดโดยตรงจะทำให้ข้ามขั้นตอน migration เหล่านี้ไป ส่งผลให้ schema และโค้ดไม่สอดคล้องกันและการอัปเกรดจะหยุดชะงักกลางคัน ให้ตรวจสอบแต่ละ hard stop ตามลำดับและรัน ./install.sh ในทุกขั้นตอน พร้อมทั้งทำ snapshot เซิร์ฟเวอร์ก่อนเริ่มดำเนินการ และอ่านรายการ release ที่ควรหลีกเลี่ยงตามเอกสารประกอบ ซึ่งรวมถึง 23.7.0, 25.9.0 และ 25.12.0