モニタリング
リリースページ
SDK で release を設定し、パイプラインから release とデプロイを登録します(「リリースとソースマップ」を参照)。すると「リリース」ページに、各バージョンの状態、イシューの原因と思われる commit、コードのオーナーが表示されます。
1リリースヘルス
release ごとに、採用率(プロジェクトのセッションに占める割合)、クラッシュフリーセッション、クラッシュフリーユーザー、イベント、新規イシュー、リグレッション、最終デプロイを表示します。率は切り捨てられるため、1回のクラッシュが 100% と表示されることはありません。セッションは Sentry SDK、POST /api/v1/sessions、または autoSessionTracking: true と release を設定したブラウザ SDK から届きます。セッションは90日間保持されます。
2疑わしい commit
イシューページには、イシューが最初に現れた release の commit のうち、変更ファイルがアプリ内スタックフレームに一致するものが最大5件表示されます(パスの末尾2セグメントが一致する必要があるため、縮小化されたバンドルにはソースマップをアップロードしてください)。commit はトークンが保存されていれば GitHub の compare API から、そうでなければ CLI が送った内容から取得されます。
3GitHub トークン
「コードオーナー」ページでプロジェクトごとにトークンを保存します。暗号化され、先頭4文字と末尾4文字のヒントのみが表示され、api.github.com に対してのみ使用されます。
4コードオーナールール
ルールは、ファイルパスの glob または URL パターンを、メールアドレスまたは #payments のようなチームラベルに対応付けます。パスの glob:src/checkout/**、*.py、models/*.py。* はディレクトリ内に留まり、** はディレクトリをまたぎ、パターンは任意のディレクトリ境界で一致します。*/checkout* のような URL パターンは大文字小文字を区別しません。パターンごとに最大4個のワイルドカードと256文字、プロジェクトごとに200ルール。一致したオーナーはイシューページに表示され、メールアドレスのオーナーにはアラートのコピーが届きます。
src/checkout/** ana@example.com
models/*.py #odoo-team
*/checkout* payments@example.com知っておくと便利
- 「リリース」ページのリグレッションは、解決済みだったがその release で再発したイシューを数えます。
- クラッシュフリーユーザーにはユーザー ID 付きのセッションが必要です。集計セッション数にはユーザー ID がありません。
お困りですか?support@blipit.io までメールしてください。各プロジェクトのキーと正確な DSN は app.blipit.io の「APIキー」にあります。

