著者 Sentry self-hostedの代替をRAM・運用コストで比較
Sentry self-hostedは初回イベント前に16 GB RAMが必要です。512 MBで動くGlitchTipと、ディスク増加、コンテナ数、アップグレードの手間を比較します。
1 件のイベントを保存する前に必要な self-hosted エラー追跡のコスト
self-hosted のエラー追跡では、選択全体を左右する数値が 1 つあります。それは必要な RAM の下限です。Sentry の公式 self-hosted ドキュメントでは、アプリケーションが 1 件のイベントを送信する前に、4 CPU コア、16 GB の RAM と 16 GB の swap、20 GB の空きディスク容量が必要とされています。GlitchTip のドキュメントでは 512 MB とされています。ここで扱う選択肢はすべて、同じ Sentry SDK からのイベントを受け付けます。そのため、これはコードの計測方法に関する選択ではありません。どの程度の規模のサーバーに費用をかけ、稼働を維持するかという選択です。
公開されているリソース値を並べて比較
以下は、2026年8月時点で各プロジェクトが自ら公開している数値です。測定の種類は同じではないため、比較する前に各行の注記を確認してください。
The data behind this chart
[
{
"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 です。Sentry が本番環境で実行するものと同じコンポーネントを動かす Docker Compose プロジェクトです。公式ドキュメントでは、「機能を完全に備え、低ボリュームのデプロイと概念実証向けにパッケージ化されている」と説明されています。この一文が実態を正確に表しています。すべての機能を利用できますが、それらを動かすためのすべての構成要素も運用することになります。
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 --waitSentry はデフォルトで http://127.0.0.1:9000 を待ち受けます。Docker Engine 19.03.6 以降と Docker Compose 2.32.2 以降が必要です。古い Compose を使うと、Sentry の処理ではなくファイル構文の解釈で失敗します。
実際に起動した内容を確認します。
docker compose ps
free -hdocker compose ps にはスタック内のすべてのサービスが表示されます。その一覧は長く、Postgres、ClickHouse、Kafka、Redis、Relay、Snuba、Symbolicator に加え、複数の worker と cron プロセスが含まれます。一度数えてください。その数がメンテナンス対象の規模です。各項目は、クラッシュ、ディスク容量の枯渇、マイグレーションの失敗が発生し得るプロセスです。
サービスが Restarting 状態で止まっている場合は、何より先にメモリを確認します。
dmesg -T | grep -i 'out of memory'Out of memory: Killed process 3412 (java) のような行は、ホストの RAM が不足したため、カーネルの OOM killer（out of memory killer）がコンテナを終了したことを示します。そのため、該当サービスは正常にならず、スタックの起動も完了しません。これは、公式に示された最小要件の環境でフルスタックを実行した場合によく起きる結果です。公式ドキュメントではディスク速度にも注意を促しています。iowait が 10% を超える場合、マシンは取り込みパイプラインに追従できていません。top の wa 列から確認するか、sysstat がインストールされている場合は iostat -x 5 から確認します。
アップグレードは過小評価されやすい作業です
Sentry self-hosted は CalVer（カレンダーに基づくバージョン方式）で毎月リリースされ、毎月 15 日に主要リリースが公開されます。古いバージョンから最新バージョンへ直接移行することはできません。プロジェクトではハードストップバージョンが定義されており、データベースマイグレーションを適用するため、それぞれを順番に checkout する必要があります。2026 年 8 月時点で公開されているハードストップは、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 までの範囲が含まれます。
アップグレードは checkout とインストーラーの再実行で行います。
git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait開始前にサーバーのスナップショットを取得してください。大規模な ClickHouse データセットのマイグレーションには数時間かかることがあり、途中で失敗すると、データベースが 2 つのスキーマの中間状態に残るためです。self-hosted Sentry のアップグレードで失敗する主な原因は明確です。サーバーを 1 年間同じバージョンのまま運用したため、複数のハードストップを一度にまたいでしまい、スキップ対象だったマイグレーションの 1 つが必要なものだったというケースです。
導入を決める前に、もう 1 つ確認すべき点があります。Sentry self-hosted は、Sentry 自身が導入した Functional Source License（FSL）の下で提供されています。これは OSI が承認したオープンソースではなく、fair source です。自分で実行することはできますが、競合サービスとして販売することはできません。各リリースは、リリースから 2 年後に Apache 2.0 へ移行します。
GlitchTip: 512 MB で運用する方法
GlitchTip は MIT ライセンスで提供され、Sentry のオープンソース SDK からイベントを受信します。そのため、計測済みのアプリケーションは DSN（data source name。SDK がイベントを送信する URL）を 1 か所変更するだけで移行できます。PostgreSQL 14 以降が必要です。Valkey または Redis 7 以降は任意ですが、より大きなインスタンスでは処理が高速になります。
インストールに必要なのは Docker と 1 つの compose ファイルです。
sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml何も起動する前に、environment セクションを編集します。設定が必要な値は、Secret、ドメイン、メールの送信先です。
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 web2026 年 8 月時点で、サンプルに指定されている image tag は postgres:18、valkey/valkey:9、glitchtip/glitchtip:6 です。これらは固定してください。compose ファイルに latest と記述すると、次回の docker compose pull でデータベースエンジンがアップグレードされます。稼働中のインスタンスで Postgres のメジャーバージョンを上げると、正常に動作していたエラートラッカーが起動しなくなることがあります。
256 MB から 512 MB の範囲で運用するには、サンプルファイル内のコメントに従って機能を無効化します。まず Valkey、その後に任意のログ機能と uptime 機能を無効にします。Valkey なしで実行すると、GlitchTip は代わりにデータベースでキャッシュとキューを処理します。処理は遅くなりますが、動作は正しいままです。All in one モードでは、worker が web process 内で動作します。そのため、アプリケーションコンテナを 2 つではなく 1 つだけ管理できます。
前段にプロキシを配置してください。GlitchTip のドキュメントでは、リクエストをバッファリングし、chunked Transfer-Encoding を処理するプロキシまたはロードバランサーを使用するよう求めています。動作例には nginx が使われています。バッファリングしない場合、低速なクライアントがアップロード中ずっと application worker を占有します。そのため、少数の低速な送信元だけで全 worker が塞がり、正常なクライアントもタイムアウトし始めます。
アップグレードは簡単です。
docker compose pull
docker compose stop
docker compose up -dデータベースのマイグレーションは起動時に自動実行されます。それでも、先に dump を取得してください。自動マイグレーションもマイグレーションであることに変わりはありません。
Bugsink: 1 つのコンテナと、事前に読む必要があるライセンス
Bugsink は 3 つの中で最も軽量です。Sentry SDK プロトコルに対応し、メッセージキューや、データベース以外の外部サービスを必要とせずに動作します。デフォルトは 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/bugsinkhttp://localhost:8000/ を開き、CREATE_SUPERUSER で指定したアドレスとパスワードでサインインします。このコンテナは停止するとすべてのデータを保持しません。実運用のインスタンスでは、プロジェクトの compose サンプルを使用します。このサンプルでは、bugsink/bugsink:2 と postgres:17-alpine を組み合わせ、DATABASE_URL、BASE_URL、BEHIND_HTTPS_PROXY を設定します。Secret は正しい方法で生成してください。
openssl rand -base64 50BASE_URL には、ユーザーと SDK が実際に使用する URL を設定する必要があります。スキームも含めて一致させてください。https://errors.example.com でアクセスするホスト上で http://localhost:8000 のままにすると、通知メール内のすべてのリンクが、メールを読む人から名前解決できないホストを指します。nginx または Caddy が前段で TLS（transport layer security）を終端する場合は、BEHIND_HTTPS_PROXY を true に設定してください。そうしないと、Bugsink は https:// プロキシの背後で http:// URL を生成し、ブラウザーが混在コンテンツをブロックします。
ベンダーは独自の処理性能の数値を公開しています。2 vCPU、4 GB の VPS で、1 件 50 KB のイベントを毎秒 18 件処理でき、これは 1 日あたり 150 万件に相当します。この数値は、実際のワークロードに対する保証ではなく、ツールの規模感を示すものとして扱ってください。ただし、小規模なアプリケーションが生成するイベント数を大幅に上回る上限であることは分かります。
次にライセンスについて説明します。これはスタックに組み込む前に読むべき重要な部分です。Bugsink は PolyForm Shield License 1.0.0 の下でリリースされています。これはオープンソースではなく、ソースコードが公開されているソフトウェアです。実行や変更はできますが、Bugsink と競合するものの構築に使用することはできません。社内向けのエラートラッカーであれば、この制限が問題になることはありません。会社で開発者向けツールを販売している場合は、まず誰かにライセンス本文を確認してもらってください。
エラー追跡と LLM オブザーバビリティは、依然として別のツールです
エラー追跡と大規模言語モデル（LLM）オブザーバビリティを一体で扱えるツールを探すと、両方に対応すると主張する製品が見つかります。しかし、データの形式が異なるため、統合は進みません。エラー追跡ツールはスタックトレース付きの例外を受け取り、そこからフィンガープリントを計算します。そして、数千件の発生をカウンター付きの1件の issue にまとめます。LLM トレーシングツールは、プロンプト、レスポンス、トークン数、レイテンシを保持する span を受け取ります。入力が同じ2回の呼び出しでも、確認する価値のある別々のイベントであるため、すべてを保持する必要があります。
そのため、両方を使います。例外はエラー追跡ツールに送信し、モデル呼び出しはそれ専用に設計された場所へ送信します。エージェントトレーシング用のセルフホスト Langfuseでこの側を処理でき、セルフホスト AI オブザーバビリティも別の観点から同じ役割を担います。アプリケーションは、すでにこの2種類の障害をどちらも生成しています。モデル呼び出しが自信ありげな誤情報を返しても、例外はまったく発生しません。そのため、エラー追跡ツールには決して表示されません。
ディスク容量の増加は、後から問題になる障害です
すべてのエラートラッカーは、書き込み負荷が高く、入力に上限のないデータベースです。書き込む量はアプリケーションによって決まるため、負荷の高いコードパスに新しいバグが1つ入るだけで、一晩で100万件のイベントが生成されることがあります。
GlitchTip は、計画時の基準となる数値を公開しています。月間100万件のイベントを処理するインスタンスでは、30 GB のディスク容量が必要になる場合があります。これは、その速度で1か月分のイベントを取り込む場合の容量です。実際に同時に保存する月数は、保持期間によって決まります。
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 はボリュームごとのサイズを表示するため、どのサービスが増加しているかを確認できます。トラフィックに変化がないのに、あるボリュームが毎週数 GB ずつ増えている場合、通常は保持設定が未構成です。その場合、データは削除されず、唯一の上限はパーティション容量になります。
メモリも同じ問題ですが、現れ方が異なります。上限のないスタックは、カーネルが提供できるメモリをすべて使用します。マシンのメモリが不足すると、OOM killer は最大のプロセスを選択して終了させます。そのプロセスは、原因となったトラッカーではなく Web サーバーである可能性もあります。すべてのサービスに上限を設定してください。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 スタックには不足します。選択した軽量な構成で、保持期間を延ばすか、より大容量のディスクに割り当ててください。
- 最低 16 GB、推奨 32 GB: 公式の Sentry self-hosted stack が適しています。ただし、軽量なプロジェクトでは実装されていない Sentry の機能が必要な場合に限ります。まず、必要な機能が各プロジェクトのドキュメントで対応しているか確認してください。一般的な機能には、対応するプロジェクトが存在します。
どの構成を運用する場合でも、エラートラッカーは自分自身の停止を報告できません。別のマシンから監視してください。別のマシンから監視する Uptime Kuma を使えば、トラッカーが停止したことを検知できます。まさにその時点で、アプリケーションがエラーを記録できないままエラーを発生させ始めます。
ホスティングプランのほうが安く済む場合
データレジデンシーの規則で自前運用が必要な場合や、イベント量が多く、イベント単位の料金が負担になる場合は、エラートラッカーのセルフホスティングにメリットがあります。それ以外では、費用を正確に計算してください。Sentry の公式ドキュメントに記載された最小要件は、16 GB のメモリ、4 コア、高速ディスクを備えたサーバーです。この規模の VPS は安価ではありません。さらに、運用作業も必要です。すべてのハードストップを順番に解消し、移行の前に毎回スナップショットを取得する作業を、年に数回行うことになります。
GlitchTip と Bugsink では、この費用計算が大きく変わります。512 MB から 4 GB のサーバーは安価で、アップグレードは docker compose pull だからです。そのため、この質問をする人の多くは、公式スタックではなく、互換プロジェクトのいずれかを選びます。必要だったのはエラートラッキングであり、常時監視が必要な分散データパイプラインではありません。
サーバー上で何を運用するべきかまだ検討中であれば、セルフホスティングに適したサービスの全体リストで、同じ RAM を競合する他のサービスとともにエラートラッキングを確認できます。
FAQ
2 GB の VPS で Sentry をセルフホストできますか？
いいえ。Sentry のセルフホスト向けドキュメントでは、最低要件として 4 CPU コア、16 GB の RAM と 16 GB の swap、20 GB の空きディスク容量を示しています。スタックは Postgres、ClickHouse、Kafka、Redis、および複数のワーカープロセスを同時に実行するため、容量の小さいサーバーではインストールが完了する前にカーネルがコンテナを kill します。dmesg -T | grep -i 'out of memory' を実行すると、kill されたプロセス名を含む行が表示されるため、これを確認できます。2 GB の VPS では、512 MB を必要量として記載している GlitchTip、または SQLite 上で単一コンテナとして動作する Bugsink を使用してください。
Sentry から GlitchTip または Bugsink に移行するには、アプリケーションコードを変更する必要がありますか？
いいえ。どちらも Sentry のオープンソース SDK からイベントを受け取れるため、すでにインストールしている SDK はそのまま使用し、1 つの値だけ変更します。その値は DSN、つまり SDK がイベントを POST する URL です。DSN がまだハードコードされている場合は環境変数に移し、新しいホストを指定してから、テスト例外を発生させ、イベントが到着することを監視します。何も表示されない場合は、DSN のプロジェクト識別子が新しいサーバー上に存在するプロジェクトと一致しているか確認します。ファイアウォールが、アプリケーションからそのホストとポートへの接続を許可しているかも確認してください。
セルフホストのエラートラッキングには、どの程度のディスク容量が必要ですか？
必要量はツールではなく、イベント量と保持期間によって決まります。GlitchTip は、月間 1 million 件のイベントを処理するインスタンスに 30 GB を公開しています。Bugsink では MAX_RETENTION_EVENT_COUNT と MAX_EVENT_AGE_DAYS を使用して予算を直接設定できるため、上限を選択すると、それに応じて必要なディスク容量が決まります。初日に保持期間を設定してください。保持ポリシーのないトラッカーは、df -h が 100% を示すまで増え続けます。その時点で取り込みが停止し、最も確認したかったエラーを失うことになります。
セルフホストの Sentry のアップグレードが何度も失敗するのはなぜですか？
アップグレードで、必ず通過しなければならない停止点を飛ばしているためです。Sentry self-hosted では、通過が必要なデータベースマイグレーションを含む特定のバージョンが定められています。2026 年 8 月時点では、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 が該当します。古いリリースから最新リリースへ直接移行すると、これらのマイグレーションがスキップされます。その結果、スキーマとコードが一致せず、アップグレードが途中で停止します。各停止点を順番に checkout し、それぞれで ./install.sh を実行してください。開始前にサーバーのスナップショットを作成し、避けるべきリリースのドキュメント一覧も確認してください。23.7.0、25.9.0、25.12.0 などが含まれます。