Sentryを開かずに毎朝プロダクションエラーを分類

Zeroを毎日実行するようスケジュールします。SentryとAxiomから未解決のエラーを取得し、ソース間で重複排除し、完全なスタックトレース付きのGitHub issueを開き、自動的に適切なエンジニアにアサインします。

Zeroの接続先:

朝のエラー分類がエンジニアリング時間の最初の1時間を消費する理由

毎朝、誰かがSentryを開き、未解決のエラーをスクロールし、どれが新しく、どれが重複で、どれが本当に深刻かを判断し、各エラーの担当者を決めなければなりません。それは実際の作業が始まる前の20〜30分の集中したエンジニアリング時間です。Zeroは午前8時45分に実行し、SentryとAxiomをチェックし、両方のソースで重複排除し、重要なエラーを選び、完全なスタックトレースが添付されたGitHub issueを開き、誰もがラップトップを開く前に各issueをアサインします。

Zeroで毎日の自動エラー分類を設定する方法

@Zero 平日の毎朝8:45に、SentryとAxiomから過去24時間の未解決エラーを取得してください。ソース間で重複排除してください。5回以上発生したものについて、vm0-ai/vm0にスタックトレース付きのGitHub issueを作成し、関連するコードオーナーにアサインしてください。

試してみる

ZeroがSentryとAxiomからエラーを取得、重複排除、記録する方法

ZeroがSentryとAxiomからエラーを取得

Zeroが指定された時間ウィンドウ内の未解決エラーについて両方のソースをクエリします。発生閾値を適用してノイズをフィルタリングし、実際に大規模に発生しているエラーに焦点を当てます。

ソース間でエラーを重複排除

同じエラーがSentryとAxiomの両方に異なるフォーマットで表示されることが多いです。Zeroが重複を特定し、両方のソースのデータを含む単一のレコードにマージします。

GitHub issueを作成してアサイン

条件を満たす各ユニークなエラーに対し、Zeroが完全なスタックトレース、発生回数、最初と最後の発生タイムスタンプを含む構造化されたGitHub issueを開き、そのコード領域を最も担当する可能性が高いエンジニアにアサインします。

issueのアサイン、閾値の調整、スタンドアップブリーフィングとの統合

閾値を調整

ノイズを減らしたり、より多くの問題を検出するために発生フィルターを変更

@Zero 毎日の分類スケジュールを更新し、10回以上発生したエラーのみissueを作成してください。それ以下のものは#devにサマリーを投稿するだけにしてください。

試してみる

モーニングブリーフィングに追加

プロダクトヘルスブリーフィングのユースケースと統合

@Zero 今日のエラー分類出力を#standupに投稿する9時のプロダクトヘルスブリーフィングに含めてください。

試してみる

デプロイ後の安全チェック

プロダクションデプロイの直後に分類を実行

@Zero vm0-ai/vm0のmainにPRがマージされるたびに、15分待ってからSentryのエラーチェックを実行して新しいエラーを確認してください。

試してみる

必要な連携: Sentry、GitHub、Axiom

Sentry

ZeroがSentryの未解決エラーをクエリし、スタックトレースとイベントカウントを読みます。

必須

GitHub

Zeroが完全なエラー詳細を含む構造化されたGitHub issueを作成し、コードオーナーにアサインします。

必須

Axiom

ZeroがAxiomのエラーログをクエリし、Sentryの発見とクロスリファレンスおよび重複排除します。任意ですが推奨。

オプション

スケジュールされたプロダクションエラー分類のベストプラクティス

●issue数を管理可能に保つために発生閾値を設定しましょう。5回以上が良い出発点です。ボリュームに応じて調整してください。

●Sentryのプロジェクトタグまたは環境を使用して、Zeroのクエリをプロダクションのみに絞りましょう。ステージングは含めません。

●プロダクトヘルスブリーフィングと連携させましょう：8:45に分類を実行し、9:00のブリーフィングに出力を含めれば、チームがすべてを一箇所で確認できます。