getsentry/sentryは、開発者向けのエラートラッキングとパフォーマンス監視のプラットフォームです。Django製バックエンドとReact製フロントエンドから成る大規模モノレポで、各言語のSDKが送信するエラー・トレース・ログを収集し、issueとして可視化します。今回参照したREADME断片は別リポジトリ由来のAIエージェント向けスキル文書のみで、製品本体の説明そのものは含まれていません。
ファイル構成から見ると、fixtures配下にはSDKが生成するartifact bundle(debug ID付きのソースマップ)があり、クラッシュのスタックトレースを元のソースコードへ復元する仕組みがうかがえます。.agents/skills以下にはhybrid-cloud-rpcやhybrid-cloud-outboxesなど、複数リージョンにまたがるサイロ間通信の作法をまとめたドキュメントが並び、Djangoモデルとサービス間RPCで機能が分割されていることが読み取れます。api-docs配下はOpenAPI定義をjson-refsで束ねてAPIドキュメントを生成する仕組みです。.github/workflows以下には選択的テスト実行やバックエンドテストのシャーディング、PRごとのgetsentry連携ディスパッチなど、巨大なテストスイートを高速に回すためのCI基盤が大量に存在します。
- STEP 01
まず.agents/skills/setup-dev/SKILL.mdを読み、Python・Node・Docker周りの前提環境を整える手順を確認することになります。
- STEP 02
docker composeでPostgres・Redis・Kafka・ClickHouseなど複数の依存サービスを起動する必要があり、初回起動には時間がかかります。
- STEP 03
pnpm installとPythonの仮想環境構築を行い、Djangoのマイグレーションを実行してからdevserverを立ち上げる流れになります。
- STEP 04
起動後はブラウザでローカルのSentry管理画面にアクセスし、サンプルプロジェクトへテストイベントを送ってissueが生成される様子を確認できます。
- STEP 05
バックエンドはpytest、フロントエンドはjestで実行しますが、.github/pytest.jsonなどの設定から分かる通りテスト数が非常に多く、全件実行には時間がかかります。
手元で動かせば、エラー監視・パフォーマンス計測・トレース探索・ログ・アップタイム監視といった機能を持つ自前のSentry管理画面が得られます。screenshotsディレクトリにあるinsights.png、trace-explorer.png、uptime.pngなどが示す通り、複数の観測系ダッシュボードを一つのUIから確認できる状態になります。
公式の自己ホスト構築は別リポジトリgetsentry/self-hostedが用意されており、本リポジトリ単体の開発環境構築はコントリビューター向けの重い作業です。
Postgres・Redis・Kafka・ClickHouse・Snubaなど依存サービスが多く、開発機のリソース消費が大きくなります。
今回参照できた範囲はCI・スキル文書・フィクスチャなどの周辺情報が中心で、sentry本体のアプリケーションコードそのものは十分に確認できていません。
README本文が製品説明ではなく別リポジトリのスキル文書の案内のみだったため、機能面の主張は主にファイル構成とスクリプトからの推測に基づいています。
自前でエラートラッキングやAPMを運用したいチーム、あるいはDjango・React混在の大規模モノレポでの開発体験に興味がある人向けの選択肢です。CI設定やskillsドキュメント、fixturesの作り込みから、テスト基盤と開発規約が非常に整備された成熟プロジェクトであることが読み取れ、実際に動かさなくても構成の信頼性は高いと判断できます。ただし本体アプリケーションコードの詳細確認はできていないため、機能の細部については公式ドキュメントも合わせて確認することをおすすめします。