[[左メニューのアラートに移動し、設定したアラート一覧を見ます。新しいアラートを作成するには、”Create Alert "をクリックします。]]

[[ここではissueアラートを設定してみます。Sentryのけるissueとは、類似のスタックトレースを持つエラーをグループ化したものです。開発者のためにSentryはエラーを自動的にグループ化することで、データのノイズを減らします。]]

[[ここで、どの環境か（本番環境、ステージング環境、テスト環境など）の選択を忘れないようにしましょう。デフォルトはすべての環境です。緊急度やエラー発生後のワークフローは、例えば本番環境のアラートとQA環境のアラートでは異なるため、このフィルタが役に立ちます。Sentryでは、プロジェクト毎にアラートを設定することもできます。]]

[["When"条件（またはトリガー）を設定します。 "When "条件（またはトリガー）は、issueに対してどのような種類のアクティビティを監視するかを指定します。トリガーは任意です。トリガーを選択しない場合、"When"条件はデフォルトで満たされ、つまり、すべてのイベントがこの条件を満たすことになります。]]

  ステータス変更の設定 - issueの状態が変更されたときのトリガーを設定

新しいissueが作成されたとき

issueが解決済みから未解決に変わったとき

issueがarchivedからescalatingに変わったとき


[[ノイズを減らすために、issueの頻度条件を設定します。アラートが増えすぎないように慎重に検討して設定しましょう。]]

頻度（フリークエンシー）に基づくトリガー

 イベント数トリガー：よく利用されます。必ずしも頻度が全てではなく、低い頻度で発生する重大なエラーもありえます。

影響を受けたユーザー数：非常に少数のユーザーから大量のエラーが発生することもあるため、エラーの頻度よりも、ユーザーに対するアラートの方が重要な場合があります。

影響を受けたセッションの割合（%）：セッションをキャプチャするようにプロジェクトを構成している場合、issueがユーザーセッションの何%以上でアラートを出す、という設定ができます。


[["when"条件に加えてif条件を設定しノイズを制御]]

条件オプション

Issueが少なくとも(x)回発生している：平均issue数を割り出し、ノイズを排除するために閾値を超えた場合のみアラートを出す。

最新リリースからのイベント：最新リリースの新しいissueからアラートを出し、古いリリースからのアラートを減らすことができます。

イベント属性値 ：各イベントには、OS、デバイス、リリース、スタックトレースデータなど多くの属性があります。 イベント属性でフィルタリングし、ノイズを調整できます。


[[トリガーの条件が満たされた場合、次のアクションを選択します。Slack、Discord、Pager Duty、Microsoft Teamsに通知を送る、またはJiraやAzure DevOpsに課題を作成することもできます。]]

[[Slack通知：特定のSlackチャンネル、チームの特定のメンバーに通知を送ることができます。チーム内の誰にどのアラートを送るべきかを考え、ノイズを排除しましょう。]]

Having rate limiting problems? Enter a channel or user ID.

[[通知をテストして動作することを確認。]]

[[アラートプレビューでは、どのissueがアラートのトリガーとなるか確認できます。アラートに繋がるエラーの特徴が、実際に優先したいエラーと一致していることを確認してください。イベント量、ユーザー量、および課題の割り当て先が正しいかを確認しましょう。]]

[[アラートには、影響を受けるチームやアラートのトピックなど、わかりやすい名前を付けましょう。例えば、"フロントエンドのレイテンシー"、"バックエンドの障害率 "など。その後、ルールを保存します。]]

Issueアラートのベストプラクティス - 重要なエラーを特定し、アラートノイズを低減