スマート・アラート

静的しきい値は、スマート・アラートの作成後は変更されません。 しきい値自体は、単純な定数値にすることも、スマート・アラート構成の作成時に過去に発生した季節変動を考慮することもできます。 履歴データに基づいて事前に計算された 1 日または 1 週間のすべてのポイント・イン・タイムのルックアップ・テーブルとして、後のものを想像できます。

基礎となるメトリックが大幅に変更されると、しきい値が関連しなくなる可能性があります。 それに応じて、任意の時点でしきい値を手動で調整または再計算することができます。 詳しくは、「 アラートしきい値」を参照してください。

静的しきい値は、以下の状況で 「低速呼び出し (Slow Calls)」 や 「誤った呼び出し (Erron示された呼び出し)」 などの青写真に対して最適に機能します。

• 基礎となるメトリックの季節性に関係なく。 メトリックが定数値より大きくなったり小さくなったりすることは望ましくありません。
• 基礎となるメトリックは季節性であるため、日または週の時点に応じて異なるしきい値が存在します。 ただし、これらのしきい値自体は時間の経過とともに変化することはなく、長期間にわたってこれらのしきい値を段階的に変更することは望ましくありません。

適応しきい値は、 Instana によって観測された新しいデータに応じて、継続的に変化し、調整されます。 つまり、しきい値は、人の介入なしに、基礎となるメトリックに対する季節的な変化を継続的に考慮します。 詳細については、 適応しきい値に関するドキュメントを参照してください。

以下のオプションは、アラートの評価および通知の粒度を制御するもので、粗い粒度（アプリケーションレベル）から細かい粒度（エンドポイントレベル）のアラートへと段階的に設定できます。

アプリケーション・パースペクティブには通常、複数のサービスが含まれているため、このスマート・アラートのスコープ内にある呼び出しを判別する必要があります。

このアプリケーション・パースペクティブへの呼び出しを (フロントエンドまたはアップストリーム・サービスからのみ) 制限するには、「インバウンド呼び出し」を選択します。 このアプリケーション・パースペクティブ内のサービス間の呼び出しは除外されます。

このアプリケーション・パースペクティブへの呼び出しを (フロントエンドまたはアップストリーム・サービスからの) 宛先としてだけでなく、アプリケーション・パースペクティブ内のサービス間の呼び出しも含めるには、「すべての呼び出し」を選択します。

オプションで、内部呼び出しまたは合成呼び出しを含めることができます。 デフォルトでは、このような呼び出しは両方とも除外されます。

内部呼び出しは、サービス内で実行される作業を表す特定のタイプの呼び出しです。 これは、カスタム・トレースを介して送信される中間スパンから作成できます。 内部呼び出しについて詳しくは、 トレースの概念を参照してください。

合成呼び出しは、ヘルス・チェック・エンドポイントの呼び出しなど、宛先として合成エンドポイントを持つものです。

オプションで、アプリケーション・パースペクティブの名前に対してドロップダウン・リストを使用して、このスマート・アラートのスコープを制限する必要がある個々のサービスを手動で選択または除外します。 選択されたサービスまたは除外されたサービス内で、選択されたスコープをそのエンドポイントごとにさらに定義できます。

ユーザー選択でソートを有効にすると、選択したサービスとエンドポイントが最上部に維持されます。

検索フィールドを使用すると、選択ツリーは、名前が検索キーワードと一致するサービスとエンドポイントのみに縮小されます。

オプションで、任意のブール・ロジックを使用する、より高度で細分化されたフィルター要件に対して「フィルターの追加」を使用します。

このステップは、「低速通話」ブループリントを選択する場合に関係します。25th、50th、75th、90th、95th、98th、および 99th パーセンタイルとともに、算術平均、最小、および最大の各オプションを選択できます。

選択したブループリントに基づいて、<、<=、>、>=の間にオプションがあります。

ここでは、以下の静的しきい値タイプから選択できます。

• 静的しきい値: 定数値をしきい値として取ります。
• 静的日次季節性 (Static Daily Seasonality): しきい値を使用して、毎日の動作がほぼ同じであるが、1 日を通じて異なる、メトリックの毎日の繰り返しパターンを収集します。 例として、夜間と比較して 1 日の間により多くの呼び出しを受け取るアプリケーションがあります。
• 静的週次季節性: しきい値を使用して、週の毎日の動作がほぼ同じであるが、週全体で異なる、メトリックの週次繰り返しパターンを収集します。 例として、週末と比較して就業日により多くの呼び出しを受け取るアプリケーションがあります。

静的日次季節性 (Static Daily Seasonality)の場合、少なくとも 5 日分の連続したメトリック・データが必要ですが、7 日分のデータが推奨されます。 静的週次季節性 (Static Weekly Seasonality)の場合、少なくとも 2 週間の連続する履歴メトリック・データが必要です。 これらの要件が満たされていない場合は、スマート・アラートを作成できません。

「適応しきい値」には、少なくとも 14 日分の連続したメトリック・データが必要です。 この要件が満たされない場合でも、スマート・アラートを作成できます。 問題検出およびアラートは、使用されるモデルを初期化するためのデータ要件が満たされるとすぐに機能を開始します。

「静的しきい値」 を選択した場合、 Instana はデフォルトで警告の深刻度を選択し、推奨されるしきい値を提示します。 この推奨値を使用するか、手動で独自の値を定義することができます。 「重大」などの追加の深刻度レベルを設定するには、 「重大」 チェックボックスをオンにし、アラートを「重大」としてトリガーする独自の閾値を設定してください。

感度レベルを選択すると、 Instana は自動的に警告の深刻度を割り当てます。 スライダーを使って感度レベルを調整できます。 「 重大 」の深刻度に対して個別の感度レベルを設定するには、「重大」チェックボックスを選択し、必要に応じて感度を設定してください。

感度を上げると、異常検知の上限と下限が狭まり、その結果、アラート通知の数が増加します。 感度を下げると、これらの境界が広がり、アラートの数が減少します。 この調整により、指標の期待値の範囲が設定されます。 使用されているしきい値演算子に基づき、いずれかの境界値を超えたメトリクスは違反とみなされ、アラートがトリガーされる可能性があります。

指定された数の連続する評価ウィンドウに違反するまでアラート通知のディスパッチを遅らせる場合は、このオプションを選択します。

以下の手順に従います。

1. 評価ウィンドウまたは細分度を選択します。
2. アラート通知が発行される前に連続して違反する必要がある評価ウィンドウの数を選択します。

N out of M 評価ウィンドウに違反するまでアラート通知のディスパッチを遅らせたい場合は、このオプションを選択します。

時間閾値の設定を超えた違反の例を、次の画像に示します。 メトリクスの評価間隔を5分とした場合、過去15分間に少なくとも2回のメトリクス違反が発生すると、アラートがトリガーされます。

以下の手順に従います。

1. 評価ウィンドウまたは細分度を選択します。 個々のメトリック値は、このサイズのウィンドウに集計されます。
2. 追跡する評価ウィンドウの数（M）を選択してください。
3. アラート通知を送信するために、追跡対象の評価ウィンドウのうち、違反が必要となる最小数を設定します。

以下の例では、この構成による2つの評価サイクルを示しています。

メトリクスは5分間の評価ウィンドウごとに集計されます。 直近の3回の評価期間のうち2回で基準が満たされなかった場合、アラートが送信されます。

指定した数の トレース が影響を受けるまでアラート通知のディスパッチを遅らせる場合は、このオプションを選択します。

以下の手順に従います。

1. 評価ウィンドウまたは細分度を選択します。
2. 評価ウィンドウ内のしきい値に違反するトレースの数を入力します。

Instana 使用されているブループリントの種類と関連する設定オプションに基づいて、デフォルトのタイトルを提案します。 ただし、デフォルトのタイトルを独自の静的テキストで上書きしたり、プレースホルダーを挿入して動的なタイトルを使用したりすることも可能です。

たとえば、 このアプリケーション・パースペクティブでサービスごとの個別アラートを選択した場合、 ${application.name} と ${service.name} は利用可能ですが、 は利用できません ${endpoint.name}。 この制限が存在するのは、アラートが個々のサービス単位で設定されるためです。これにより、単一のアプリケーション・パースペクティブやサービス名への参照は可能ですが、サービスごとに異なる可能性がある特定のエンドポイント名への参照はできません。

さらに、アラートのタイトルにプレースホルダーとして `` を ${severity} 指定することで、深刻度レベルを示すことができます。

このトグルを有効にすると、インシデントが追加で作成されます。この問題はトリガー・イベントとして参照され、このインシデントに関連するその他のイベントは関連イベントとして参照されます。

オプションで、アラートに説明を追加します。 適切な説明には、このアラートの簡単な要約と、アラートが受信されたときに実行するステップが含まれます。 また、 「プレースホルダーの挿入」 ドロップダウンから選択できるプレースホルダーを挿入することで、動的な説明文を作成することもできます。

ただし、既存のカスタムイベントをスマートアラートに移行する際の手助けとして、 Instana のUIには基本的な移行ツールが用意されています。 アプリケーション、 サービス、 またはエンドポイントエンティティのカスタムイベントの詳細ページには、スマートアラートの移行に関連する2つのボタンが表示されます：

• 「マイグレーション済みとしてマーク (Mark as migrated)」: 非推奨のカスタム・イベントにマイグレーション済みのマークを付け、それを無効にします。 これは、このカスタム・イベントをスマート・アラートに手動でマイグレーションした場合に役立ちます。 マイグレーション済みのマークを付けた後も、リストにそのマークを表示することができます。また、将来参照するためにいつでもその構成を確認することができます。 これは、代わりにこの構成を削除する場合には当てはまりません。 さらに、この機能により、マイグレーションの進行状況を追跡し、カスタム・イベントが複数回マイグレーションされないようにすることができます。
• スマート・アラートへのマイグレーション: 名前、説明、重大度、インシデント、エンティティー・タイプ、メトリック、評価の細分度、集約、演算子、しきい値など、各フィールドの値を含む「スマート・アラート」ダイアログを開きます。 カスタムイベントのフィールドは、必ずしもスマートアラートのフィールドにマッピングできるとは限りませんが、 Instana は、可能な限りこれらのフィールドをカスタムイベントからスマートアラートへ移行するよう努めます。 さらに、DFQ または選択したアプリケーション・パースペクティブの有効範囲は、明示的に、または照会ビルダー・タグ・フィルターを使用して、それぞれのエンティティーを選択することによって引き継がれます。 一部のダイナミック・フォーカス照会は、エンティティー選択フィルターまたはクエリー・ビルダー・タグ・フィルターに部分的にのみマップすることも、まったくマップしないこともできます。 このような場合は、それぞれの警告メッセージが表示されます。 マイグレーション・ツールによって DFQ を完全にマップできない場合は、 エンティティー・タイプ・マッピングおよびスコープ選択 を参照して、スマート・アラートのスコープを手動で選択することができます。 そのスマート・アラートを保存すると、前のカスタム・イベントが自動的に無効になり、マイグレーション済みとしてマークされます。

カスタムイベントをSmart Alertsに手動で移行することができます。

1. settings.hclファイルで機能フラグを有効にします。

   ...
   feature "smartAlertsLogsBlueprintEnabled" {
       enabled=true
   }
   ...
    

2. instana updateコマンドを使用して変更を適用します。

1. ファイル core.yaml 内で、次のように機能フラグを有効にしてください：

   apiVersion: instana.io/v1beta2
   kind: Core
   metadata:
     name: instana-core
     namespace: core
   spec:
     ...
     featureFlags:
       - name:  feature.smart.alerts.logs.blueprint.enabled
         enabled: true
     ...
    

2. コマンド kubectl apply -f core.yaml を使用して変更を適用します。