Cloud Cost Intelligenceのアラート条件

アラート条件に名前を付ける

条件の命名のベストプラクティスとして、重要な情報がひと目でわかる構造化された形式があります。条件名には次の要素を含めます。

• 優先度：アラートの重大度または緊急度を、P1、P2、P3のように示します。

• 信号：高平均レイテンシや低スループットなど、監視するメトリクスや条件を指定します。

• エンティティ：影響を受けるシステム、アプリケーション、またはコンポーネントを識別します。

  この構造に従うと、適切な条件名の例は「P2 | High Avg Latency | Cloud Cost Intelligence」になります。

既存のポリシー

アラート条件に接続するポリシーが既にある場合は、既存のポリシーを選択します。詳細については、アラートポリシーを参照してください。

新しいポリシー

アラート戦略では応答性と疲労のバランスを取ることが重要です。ポリシーのオプションを見てみましょう。

1. ポリシーごとに1つのイシュー（デフォルト）:

   • 長所：ノイズを軽減し、即時のアクションを保証します。
   • 短所：異なる条件によって引き起こされた場合でも、すべてのインシデントが1つのイシューにグループ化されます。複数ページビューを扱う場合には理想的ではありません。

2. 条件ごとに1つのイシュー：

   • 長所：条件ごとに個別のイシューを作成するため、特定のレイテンシ問題を分離して対処するのに最適です。
   • 短所：より多くのアラートが生成され、疲労を引き起こす可能性があります。

3. 各インシデントに対するイシュー:

   • 長所：外部システムに詳細な情報を提供しますが、過負荷になる可能性があるため、内部利用には最適ではありません。
   • 短所: これは最もノイズの多いオプションであり、より広範なトレンドを追跡し、効果的に優先順位を付けることが困難です。

   詳細については、ポリシーの作成を参照してください。

閉じる 開く イベント

対象の信号が条件の閾値で示された期間にわたって非違反状態に戻ると、インシデントは自動的に終了します。この待ち時間を回復期間と呼びます。

インシデントが自動的にクローズされる場合:

1. クロージングのタイムスタンプは、リカバリー期間の開始時にさかのぼって表示されます。

2. 評価はリセットされ、前のインシデントが終了した時点から再開されます。

   すべての条件には、長時間続くインシデントを自動的に強制終了する、インシデントの時間制限が設定されています。 New Relicでは自動的にデフォルトで3日間が設定されるため、最初のアラートにはデフォルト設定を使用することをお勧めします。

   信号がデータを返さない場合に未解決のインシデントを閉じるもう 1 つの方法は、loss of signal閾値を設定することです。詳細については、上記の損失信号閾値のセクションを参照してください。

タイトルテンプレート

unblended costにレイテンシの問題があるかどうかを知らせるアラート条件を作成しているため、開発者がこのインシデントについて通知されたときに必要な情報をすべて入手できるようにする必要があります。インシデントが作成されたときに、ワークフローを使用してチームのSlackチャネルに通知します。詳細については、カスタムインシデントを参照してください。

説明テンプレート

タイトルテンプレートの使用はオプションですが、推奨されます。アラート条件は、モニターしたい一連の閾値を定義します。これらの閾値のいずれかに違反があった場合、インシデントが作成されます。意味のあるタイトルテンプレートを使用することで、問題を正確に特定し、稼働停止の解決を迅速化できます。詳細については、タイトルテンプレートを参照してください。

ランブックの URL

調査、トリアージ、修復手順を詳述した運用ランブックは、このフィールドにリンクされることがよくあります。