Rustrak は、Sentry の SDK が送るエラーやトレースを受け取るセルフホスト型のエラー監視サーバーだ。Rust で書かれ、既定では SQLite を使う1プロセスで動く。2026-10-16 時点の GitHub Star は567、サーバーの最新版は v0.16.4(2026-10-14 公開)、ライセンスは GPL-3.0。本記事ではソースからビルドして Linux で起動し、Python の Sentry SDK で実際にイベントを送り、2万件のバーストで README の性能の記述を確かめた。あわせて、AI エージェントのトレース画面と、管理操作を AI アシスタントに渡す MCP サーバーも動かした。
WHAT IT REPLACES何を代替するか
Sentry の SDK はそのまま、受け手を1プロセスにする
Sentry セルフホスト
Docker Compose で一式を動かす
- 最小要件 4コア・RAM 16GB+swap 16GB公式ドキュメントの記載
- Kafka などのサービスを単一ノードで同居ディスク I/O が重い
- ライセンスは FSL-1.1-Apache-2.0self-hosted リポジトリ
Rustrak 0.16.4
Rust 製の単一バイナリ+SQLite
- バイナリ 24.4MB・起動 0.3秒当サイトでソースからビルド
- DSN を1行差し替えるだけsentry-sdk 2.72.0 で送信を確認
- エラー・トレース・ログ・AIエージェントライセンスは GPL-3.0
30秒でわかる Rustrak(2026-10-16時点)
- ・正体:Sentry の SDK をそのまま受ける Rust 製のエラー監視サーバー。既定は SQLite、PostgreSQL にも切り替えられる
- ・何ができる:エラーの集約、トランザクション、ログ、リリースのクラッシュ率、AI エージェントのトレース、Slack・メール・Webhook への通知
- ・実測:2万件のバーストを毎秒 1,753〜2,474件で全件受け付けた。ピークのメモリは 117〜135MiB で、README の「60MB未満」には届かなかった
- ・AI:LLM 呼び出しとツール実行の span を集計する画面と、68ツールの MCP サーバーを確認した
- ・注意:公式イメージは匿名テレメトリが既定で有効。止めるのは環境変数1つ
自前で持つ運用ツールの全体像は AI自動化ツール|ノーコードからコードまで2026年版の比較と選び方 にまとめている。
Rustrakとは:Sentry SDKをそのまま受けるRust製のエラー監視
エラー監視は、SaaS に払うか、重い自前の一式を建てるかの二択になりがちだ。Rustrak はその間を狙う。README は「Sentry のプロトコルそのものを話すので、SDK は文字列を1つ変えるだけで向き先が変わる」と書く。新しいエージェントもライブラリの入れ替えもいらない。
扱えるデータは次のとおりで、どれも Sentry の SDK が送る形式のまま受ける。
・エラー:SDK が送った指紋、無ければ例外の型・メッセージの1行目・トランザクション名でまとめる
・パフォーマンス:トランザクションと span を p95 の順に並べる
・ログ:trace から fatal までの6段階。span の中で出したログは trace_id でリクエストにつながる
・リリースの健全性:クラッシュしなかったセッションとユーザーの割合
・AI エージェント:LLM 呼び出し、ツール実行、エージェント間の引き継ぎ
ダッシュボードはサーバー自身が静的ファイルとして配る。API と画面が同じ1プロセス・1ポートに乗るので、別のホストやポートを用意しなくてよい。
TWO-PHASE INGEST取り込みの仕組み
受け取りはディスクに書いて即 200、DB の処理は後から
-
Sentry SDK
DSN の宛先だけ変える
-
envelope 受付
/api/{id}/envelope/ で鍵を確認
-
ディスクに保存
書けたら 200 を返す
-
digest
指紋で issue にまとめる
-
SQLite
画面・REST API・MCP から読む
取り込みは2段に分かれている。受付は envelope を解釈してディスクに書いた時点で 200 を返し、DB への書き込みと issue へのまとめ(digest)は別のタスクが後から行う。アプリ側の SDK が DB の遅さを待たないので、障害時にエラーが集中してもアプリのタイムアウトになりにくい。後で測る「受付の速さ」と「処理完了までの時間」が別の数字になるのはこのためだ。
Rustrakを動かす:ソースからビルドしてPython SDKで送るまで
公式の手順は Docker Compose だ。今回の環境は Docker デーモンが動かず、Docker Hub もリクエスト上限で取得できなかった。そこでリポジトリの apps/server を cargo でビルドした。rust-toolchain.toml が Rust 1.98 を指定しており、rustup が自動で取得する。
git clone --depth 1 https://github.com/rustrak/rustrak
cd rustrak/apps/server
cargo build --release --locked # 4コアで7分00秒。途中の target/ は約1.1GB
ls -l target/release/rustrak # 24,413,616 バイト(strip 済み)
起動は環境変数で設定する。初期ユーザーは CREATE_SUPERUSER で作り、既定のパスワードは無い。RUSTRAK_BOOTSTRAP_TOKEN を付けると、初回だけ API トークンが標準エラーに1度表示される。
mkdir -p data
export DATABASE_URL=sqlite://$PWD/data/rustrak.db
export INGEST_DIR=$PWD/data/ingest SOURCEMAP_STORAGE_PATH=$PWD/data/sourcemaps
export HOST=127.0.0.1 PORT=8080
export SESSION_SECRET_KEY=$(openssl rand -hex 32)
export CREATE_SUPERUSER=[email protected]:changeme123
export RUSTRAK_BOOTSTRAP_TOKEN=1 # 初回だけ API トークンを標準エラーに1度表示
./target/release/rustrak
空の DB でマイグレーションを済ませ、GET /health が 200 を返すまで 0.29秒だった。プロジェクトを作って DSN を受け取り、Python の SDK から送る。
TOKEN='起動ログに出た Token の値'
curl -s -X POST http://127.0.0.1:8080/api/projects \
-H "Authorization: Bearer $TOKEN" -H 'content-type: application/json' \
-d '{"name":"aih-demo","platform":"python"}' # 返り値の dsn を控える
pip install sentry-sdk
python3 -c 'import sentry_sdk as s; s.init(dsn="<dsn>"); s.capture_message("hello rustrak"); s.flush()'
curl -s -H "Authorization: Bearer $TOKEN" http://127.0.0.1:8080/api/projects/1/issues
sentry-sdk 2.72.0 から、例外(ZeroDivisionError)・メッセージ・構造化ログ・span を含むトランザクションを送り、どれも API から読めた。ログには SDK が付けた属性が型つきで残っていた。
検証環境:Linux(x86_64・4コア・16GB)/2026-10-16
- ・サーバー:v0.16.4 をソースからビルド(SQLite の既定構成)。ダッシュボードは pnpm でビルドして同じプロセスから配信
- ・送信:Python 3.13 の sentry-sdk 2.72.0 と anthropic 1.15.0、負荷は Node 22 の自作スクリプト
- ・確認:受付・issue への集約・ログ・トランザクション・AI エージェントの集計・MCP の起動とツール呼び出し
2万件を流して測った:受付速度・メモリ・ディスク
README は「4コアの機械で SQLite を使い、2万件のバーストを毎秒約5千件で受け付け、メモリのピークは60MB未満」と書く。同じ件数を、エラーの event として300種類に振り分けて送った。負荷を出すスクリプトも同じ4コアの VM で動かしている点は、Rustrak 側の計測(開発者ブログ)と同じ条件だ。
MEASURED2万件を流した結果
受付は毎秒1.8〜2.5千件、メモリはREADME の公称を超えた
2,474件/秒
受付の最高値
3回で 1,753〜2,474・全件 200
120MiB
ピークのメモリ
VmRSS・3回で 117〜135MiB
42秒
2万件の処理完了
4.7KB の event・SQLite 108MB
| 回 | event の大きさ・並列数 | 受付(全件 200) | ピークのメモリ(VmRSS) | 全件の処理完了 |
|---|---|---|---|---|
| 1 | 約0.6KB・64並列 | 2,420件/秒 | 135MiB | 43.1秒 |
| 2 | 4.7KB・32並列 | 2,474件/秒 | 117MiB | 162.8秒 |
| 3 | 4.7KB・32並列 | 1,753件/秒 | 120MiB | 42.3秒 |
3回とも2万件すべてに 200 が返り、300種類の event はちょうど300件の issue にまとまった。処理の途中で取りこぼした件数はゼロだった。
受付の速さは README の約5千件/秒の半分前後、メモリは60MB未満の2倍ほどだった。差の理由として考えられるものは2つある。1つはメモリの測り方で、当サイトはプロセスの VmRSS を0.1秒ごとに読んだ。開発者ブログはアイドル時を約25MBとしているが、こちらでは何も受けていない状態ですでに約52MiB あった。もう1つはディスクで、2回目は SQLite のチェックポイント1回に8.2秒かかったという警告がログに出た。この回は処理中に API を0.5秒ごとに叩いており、トークンの最終利用日時の更新が書き込みロックを奪い合ったことも重なったと見ている。API を叩かなかった3回目は42.3秒で済んだ。
ディスクは、4.7KB の event 2万件で SQLite のファイルが108MB になった。送った本文の合計は約94MB だ。保存期間を設定すれば古いデータは削除できるが、容量を見積もるときは送る量と同じくらいを見込んでおくと安全だ。
未検証の範囲
- ・公式の Docker イメージ(Docker デーモンが無く、Docker Hub もリクエスト上限で取得できなかった)
- ・PostgreSQL 構成、ソースマップ、アラートの送信(Slack・SMTP・Webhook)、OIDC のシングルサインオン
- ・README の「毎秒約5千件・60MB未満」を同じ条件で再現すること(Docker の統計値で測る条件は用意できなかった)
- ・JavaScript の SDK と Vercel AI SDK による AI トレース、リリースの健全性(セッション)の画面
AIエージェントのトレースとMCPサーバー:何が見えて、何に気をつけるか
Rustrak の AI 機能は2つある。SDK から届いた AI 関係の span を集計する「Agents」画面と、管理 API を AI アシスタントに渡す MCP サーバー @rustrak/mcp だ。
LLM呼び出しとツール実行の集計
サーバーは、op が gen_ai. か ai. で始まる span と、gen_ai.operation.name などの属性を持つ span を AI の span として扱う。そこからモデル名、入力・出力・キャッシュ・推論のトークン数、ツール名を取り出して列に持つ。README は料金の表示をわざと置いていない。モデルごとの単価はすぐ古くなるので、正確なトークン数だけを出して掛け算は利用者に任せる、という方針だ。
上の画面は、エージェント実行・LLM 呼び出し・ツール実行の span を Python SDK から手で付けて送った結果だ(モデル名は送った値をそのまま表示している)。手で付けた属性だけでは SDK の実際の連携と同じとは言えない。そこで、sentry-sdk の Anthropic 連携を有効にし、anthropic の Python クライアントを手元の偽 API サーバーに向けて1回呼んだ。LLM 呼び出しが1件増え、偽 API が返したトークン数(入力42・出力7)がそのまま集計に入った。README が検証済みと書くのは Node.js の @sentry/node と Vercel AI SDK の組み合わせで、こちらは試していない。
MCPサーバーは68ツール、削除系も含む
@rustrak/mcp 0.16.4 は、URL と API トークンの2つの環境変数で起動する。
RUSTRAK_API_URL=http://127.0.0.1:8080 RUSTRAK_API_TOKEN=$TOKEN npx -y @rustrak/[email protected]
MCP の SDK でツール一覧を取ると68個あり、issue の一覧取得を呼ぶと上で送ったデータが返った。issue の解決・ミュート・担当割り当て、AI エージェントの集計の取得まで揃う。一方で、issue の削除や一括削除、ストレージの掃除の実行、API トークンの発行と失効も含む。ソース上で削除系の注記(destructiveHint)が付いたツールは8個ある。
API トークンには権限の範囲を絞る設定が無い。ソースを読むと、ユーザーにひもづくトークンはそのユーザーの役割(Admin・Member・Viewer)で動き、ユーザーを持たないトークンはインスタンス全体の管理者として扱われる。起動時に自動で作るトークンは後者だ。AI アシスタントに渡すなら、Viewer の役割のユーザーを作ってそのユーザーのトークンを使うのが安全だ(Viewer で書き込みが拒まれることは未検証)。
公開前に確かめること:テレメトリ・認証・待ち受けアドレス
テレメトリは公式イメージで既定オン
サーバーは6時間ごとに約2KBの匿名レポートを送る。最初の1通は起動の10分後だ。中身は版・OS・CPU 数・メモリの使用量・SQLite のファイルの大きさ・件数(上2桁に丸める)・ルートごとの 5xx の数などで、IP アドレス・ホスト名・DSN・イベントの本文は送らないとドキュメントに一覧がある。送り先はソース上 PostHog の US リージョンだ。
送信には、ビルド時に埋め込む鍵が要る。ソースからビルドしたバイナリは鍵を持たないため、起動ログに「Telemetry is off: no telemetry key was compiled into this binary.」と出て送らなかった。公式イメージは鍵を入れてビルドするので既定で送る(実際の送信は未検証)。止めるには RUSTRAK_TELEMETRY=off か DO_NOT_TRACK=1 を設定する。送る直前の中身は認証つきの GET /api/telemetry/preview で見られ、認証なしでは 401 が返った。
認証と待ち受けの既定値
・新規登録は招待制。POST /auth/register は 403 を返した
・初期ユーザーは CREATE_SUPERUSER で自分で決める。DB にユーザーがいれば作らない
・SESSION_SECRET_KEY を省くと起動ごとに鍵が変わり、再起動でログインが切れる(64文字未満は起動を拒否)
・待ち受けの既定は 0.0.0.0:8080。バイナリを直接動かすなら HOST=127.0.0.1 にしてリバースプロキシを前に置く
・DSN の鍵が違う送信は 401、認証なしの管理 API も 401 だった
ダッシュボードとセルフホストの運用の型は、同じく自前で持つ解析ツールの Rybbit:Google Analytics代替のOSSアナリティクスをDockerでセルフホスト と共通する部分が多い。
RustrakとSentryセルフホスト・GlitchTip・Bugsinkの違い
Sentry の SDK を受けるセルフホストの選択肢は Rustrak だけではない。各公式リポジトリとドキュメントで確かめられた範囲を並べる。性能は Rustrak 以外を測っていないので載せない。
| 項目 | Rustrak | Sentry セルフホスト | GlitchTip | Bugsink |
|---|---|---|---|---|
| ライセンス | GPL-3.0 | FSL-1.1-Apache-2.0 | MIT | PolyForm Shield 1.0.0(一部を除く) |
| 実装 | Rust(Actix-web) | Docker Compose 一式(Kafka を含む) | Python・Django | Python・Django |
| 既定のデータ置き場 | SQLite(PostgreSQL も可) | 単一ノードに複数のサービス | PostgreSQL(Valkey は任意) | SQLite(DATABASE_URL で切替) |
| 公式の要件・公称 | バースト時60MB未満(README) | 4コア・RAM 16GB+swap 16GB・空き20GB | 512MB の RAM から(README) | 本記事では確認していない |
| AI エージェントの画面 | あり(本記事で確認) | 本記事では確認していない | 本記事では確認していない | 本記事では確認していない |
小さなチームが1台のサーバーに置くなら、Rustrak と Bugsink はどちらも SQLite で始められる。違いはライセンスと実装言語で、Bugsink の PolyForm Shield は競合製品への利用に制限がある。Rustrak の GPL-3.0 は、改変して配布するならソースの公開が求められる。AI エージェントのトークンやツール呼び出しまで同じ画面で見たいなら、本記事で確かめた範囲では Rustrak が当てはまる。
監視とアラートの層まで広げるなら、Prometheus 互換の Nightingale - Prometheus対応のOSS監視・アラート統合プラットフォーム と組み合わせる手もある。アプリの例外は Rustrak、インフラの指標は Nightingale という分担だ。
この記事の結論
- ・Sentry の SDK を変えずに DSN だけ差し替えて、エラー・トレース・ログ・AI の span が届いた
- ・2万件のバーストは全件受け付けた。速度とメモリは README の数字に届かず、環境とディスクの影響が大きい
- ・MCP サーバーは削除系を含む68ツール。渡すトークンは役割を絞ったユーザーのものにする
- ・公式イメージを使うなら、テレメトリを止めるかを最初に決める
参照ソース
・rustrak/rustrak(GitHub):README・CLAUDE.md・apps/server のソース(v0.16.4)
・Rustrak Documentation:Telemetry
・Rustrak 開発者ブログ:Half the memory, twice the throughput(リポジトリ内の原稿)
・@rustrak/mcp(npm)
・Self-Hosted Sentry(Sentry Developer Documentation)
・getsentry/self-hosted LICENSE.md
・GlitchTip backend(GitLab)
・bugsink/bugsink(GitHub)





