このページの内容

Contrail Insights アラームの概要
Contrail Insights アラームの操作
アラーム定義
アラームルールの設定

Contrailコマンドを使用したContrail Insightsアラームの設定

Contrail Insights アラームでは、インフラストラクチャで条件を満たしたときに発生するアラームを設定できます。Contrail Insightsは、収集ポイントでメトリックの分散分析を実行し、アラームに一致するイベントを効率的かつ応答性の高い方法で検出します。Contrail Insights には 2 種類のアラームがあります。

Static	比較には、ユーザー提供の静的しきい値が使用されます。
Dynamic	比較には、動的に学習された適応閾値が使用されます。

注:

3.2.6より前のContrail Insightsリリースの場合: アラームを設定するには、Contrail Insightsライセンスサブスクリプションがアクティブである必要があります。

Contrail Insights アラームの概要

静的アラームと動的アラームの両方について、Contrail Insights Agent は、ホスト、インスタンス、ネットワークデバイスなど、さまざまなエンティティのメトリックの測定値を継続的に収集します(「 Contrail Insights によって収集されるメトリック』を参照)。エージェントは、単純な収集だけでなく、収集時のメトリックのストリームも分析して、一致するアラームルールを特定します。特定のアラームについては、エージェントはユーザー指定の関数(平均、標準偏差、最小値、最大値、合計)に従ってサンプルを集約し、ユーザーが指定した測定間隔ごとに単一の測定値を生成します。特定の測定間隔について、エージェントは各測定値をしきい値と比較します。静的しきい値を持つアラームの場合、ユーザー指定の比較関数(上、下、等しい)を使用して、測定値を固定値と比較します。動的しきい値の場合、測定値は、時間の経過とともに Contrail Insights によって学習された値と比較されます。

さらに、複数の間隔を一致させる必要があるアラームパラメーターを設定することができます。これにより、持続的な状況に合わせてアラームを設定し、短時間にわたるパフォーマンスを検出できます。広い時間範囲の最大値は、過度に誇張された条件になる可能性があります。しかし、平均は情報を希薄化させる可能性があります。バランスは、小さな間隔で測定し、複数の間隔で繰り返される一致を監視することでよりよく達成されます。例えば、3分間のCPU使用率を監視するために、5秒間隔の平均CPU使用率を比較するようにアラームを設定し、36(または36のサブセット)の間隔がアラーム条件に一致する場合にのみアラームを発生させることができます。これにより、3分間の単純な平均または最大よりも、持続的なパフォーマンス状態をよりよく可視化できます。

動的しきい値を使用すると、過去の傾向に基づいてリソース消費の外れ値を検出できます。リソース消費量は、時間帯や曜日によって大きく異なる場合があります。このため、メトリックに静的しきい値を設定することが困難になります。たとえば、月曜日の朝の午前 10:00 から午後 12:00 までの間は CPU 使用率 70% が正常と見なされる場合がありますが、土曜日の夜の午後 9:00 から午後 10:00 までの間は、同じ量の CPU 使用率が異常に高いと見なされる場合があります。

動的しきい値を使用すると、Contrail Insights はアラームが適用されるスコープ内のすべてのリソースにわたってメトリックの傾向を学習します。たとえば、ホストアグリゲートにアラームが設定されている場合、Contrail Insightsはそのアグリゲート内のホストに対して収集されたメトリック値からベースラインを学習します。同様に、プロジェクトに動的しきい値が設定されたアラームは、そのプロジェクトのインスタンスに対して収集されたメトリック値からベースラインを学習します。その後、測定値が特定の期間に学習されたベースライン値から逸脱した場合、エージェントはアラームを生成します。

動的しきい値を持つアラームを作成する場合、メトリック、ベースラインを確立する期間、ベースラインから逸脱した測定値に対する感度を選択します。感度は高、中、低に設定できます。感度が高いほど、ベースラインからの偏差が小さくなり、その逆も同様です。

Contrail Insights アラームの操作

Contrail Insights Agentは、時系列データストリームに対して分散型のリアルタイム統計分析を実行します。エージェントは、設定可能なスライディングウィンドウメカニズムを使用して、複数の測定間隔にわたってメトリックを分析します。アラームは、設定可能な測定間隔にわたってメトリックデータがアラーム基準に一致することを Contrail Insights エージェントが判断すると生成されます。サンプル集約のタイプとアラームのしきい値は設定可能です。静的と動的の2種類のアラームをサポートしています。違いは、しきい値の決定方法と、測定されたメトリックデータの比較に使用される方法です。次のセクションでは、全体的なスライディングウィンドウ分析について説明し、分析で使用される静的しきい値と動的ベースラインの詳細について説明します。

スライディングウィンドウ解析
静的アラーム
ダイナミックアラーム

スライディングウィンドウ解析

Contrail Insights Agent は、スライディングウィンドウ分析を使用してアラームを評価します。スライディングウィンドウ分析は、設定可能な測定間隔内のメトリックのストリームを、静的なしきい値または動的ベースラインと比較します。各測定間隔の長さは、1 秒単位に設定できます。各測定間隔では、生の時系列データサンプルが 、平均、最大、最小などの集約関数を使用して結合されます。集計された値は、上または下などの設定可能な比較機能を使用して、静的しきい値または動的ベースラインと比較されます。複数の測定間隔は、スライドウィンドウで構成されています。スライディングウィンドウで設定可能なインターバル数は、エージェントがアラームの通知を生成するためのルール基準に一致する必要があります。

図1:アラーム生成メカニズム Time series analysis visualization with a sliding window approach. Horizontal axis shows data samples S1 to S21. A blue-outlined box groups data into six intervals i1 to i6. Red dashed boxes indicate interval duration. Red ovals highlight intervals with exceptions at data points S5, S6, S13, S14, and S15.

Time series analysis visualization with a sliding window approach. Horizontal axis shows data samples S1 to S21. A blue-outlined box groups data into six intervals i1 to i6. Red dashed boxes indicate interval duration. Red ovals highlight intervals with exceptions at data points S5, S6, S13, S14, and S15.

図 1 は、スライディングウィンドウが Interval Count パラメーターで指定された 6 つの隣接する測定間隔 (i1 から i6) で構成されている例を示しています。測定間隔i1では、サンプルS1、S2、S3の平均がS_平均として計算されます。アラームのタイプ(静的または動的)に応じて、S_avgは、上または下などのユーザー指定の比較関数を使用して、設定された静的しきい値または動的に学習されたベースラインと比較されます。比較の出力によって、特定の測定間隔が例外のある間隔としてマークされるかどうかが決まります。この評価は、スライディングウィンドウ内の各測定間隔(例えば、i1からi6)に対して繰り返されます。

図 1 の例では、エージェントは、アラームの種類に応じて、測定間隔の集計値を静的しきい値または動的ベースラインと比較することにより、i2 と i5 の 2 つの間隔が例外の間隔であると判断します。間隔 i1 がアラームが設定された最初の間隔であると仮定すると、Contrail Insights エージェントが直近の 6 つの測定間隔のうち少なくとも 2 つが例外としてマークされていると判断したとき、アラームはインターバル i6 の終わりにアクティブになります。ダッシュボードを使用してアラームを設定した場合、インターバルカウントと例外のあるインターバルはデフォルトで1に設定されます。その結果、エージェントは、1つの測定間隔にわたってデータを処理した後にアラームを生成できます。

静的アラーム

静的アラームしきい値は、アラーム定義時に提供されます。図2 は、静的アラーム定義の例と、アラームのAPI設定に使用する同等のJSONを示しています。この例で定義された条件は、60秒間の測定間隔にわたって host.cpu.usage サンプルの平均を評価することです。測定値は、80%の静的しきい値と比較され、特定の測定間隔がアラームルールに一致するかどうかを判断します。図2 は、静的アラーム定義のコンポーネントを識別します。

図2:静的アラームの定義

Labeled diagram of a monitoring alert rule for CPU usage. Explains conditions for generating a host alert: average CPU usage above 80 percent in 60-second intervals, met in 2 of last 6 intervals. Key components: EventRuleScope Host, EventRuleType Alert, MetricType host.cpu.usage, AggregationFunction Average, IntervalDuration 60 seconds, ComparisonFunction Above, Threshold 80 percent, IntervalsWithException 2, IntervalCount 6, Mode operational.

ダイナミックアラーム

動的アラームしきい値は、アラームが設定されている一連のエンティティの履歴データを使用して、Contrail Insightsによって学習されます。図3 は、動的アラーム定義の例を示し、動的アラーム定義のコンポーネントを識別します。

図3:ダイナミックアラーム定義 Diagram of rule for generating alerts on CPU usage: Host alert triggers when average host CPU usage over 60 seconds is above dynamic threshold set by k-means algorithm with medium sensitivity. Condition must occur in 2 of last 6 intervals.

Diagram of rule for generating alerts on CPU usage: Host alert triggers when average host CPU usage over 60 seconds is above dynamic threshold set by k-means algorithm with medium sensitivity. Condition must occur in 2 of last 6 intervals.

動的しきい値を使用する場合、静的しきい値は設定しません。代わりに、学習の実行方法を制御する 3 つのパラメーターを指定します。学習アルゴリズムは、エンティティ全体のベースラインを生成します。ベースラインは、平均値と標準偏差で構成されます。ベースラインは、追加のメトリックデータが収集されると継続的に更新されます。

以下は、3つの学習パラメーターのリストと、それらがどのように機能するかに関する情報です。

BaselineAnalysisAlgorithm

動的しきい値の決定に使用される機械学習アルゴリズムを選択します。以下のアルゴリズムが利用可能です。

k-means

Contrail Insights は、k 平均アルゴリズムを採用して、毎日の各時間(最大 1 週間)の粒度で一連のエンティティの予想動作範囲を生成します。学習されたベースラインは、設定可能な学習期間のデータを使用して計算されます。ベースラインは、最新のデータに基づき、時間の経過とともに継続的に更新されます。k-means ベースライン分析アルゴリズムは、特定の時間帯に予期しないパフォーマンスを観察するのに役立ちます。

たとえば、k 平均アルゴリズムは、午後 1:00 から午後 2:00 までの動的ベースラインを学習する可能性があり、80% +/- 10% になる可能性がありますが、午前 3:00 から午前 4:00 までのベースラインは 20% +/- 5% である可能性があります。午前3時から午前4時までの間に測定されたメトリックが値の75%であるが、午後1時から午後2時までの時間帯には同じ測定値が許容される場合は、アラームが発生します。

ewma

指数加重移動平均(EWMA)アルゴリズムは、1時間ごとに更新される単一のベースラインを生成します。設定可能な学習期間により、最近のデータと古いデータに割り当てられた相対的な重みを制御できます。このアルゴリズムは、メトリックの急な変化を検出できるアラームを作成するのに役立ちます。

たとえば、EWMA アルゴリズムは、過去 24 時間のデータから 60% +/- 10% の動的ベースラインを学習できます。このベースラインは、リアルタイムデータが通常の動作地域から逸脱しているかどうかを判断するために、次の1時間間隔で使用されます。1時間間隔ごとにEWMAベースラインが更新され、新たに更新されたベースラインが将来のアラーム生成に使用されます。

LearningPeriodDuration

動的ベースラインは、履歴データを使用して決定されます。このパラメーターは、動的ベースラインの計算に最新の履歴データが使用される期間の長さを決定します。例えば、1時間、1日、1週間などです。ルールの設定時点では、Contrail Insights に特定のエンティティに対して十分な履歴データがまだない可能性があります。この場合、データが利用可能になると学習が実行されます。アラーム評価は、データの学習期間が1回使用可能になり、ベースラインが生成された後に開始されます。

Sensitivity

動的アラームの感度は、学習された平均からの偏差の許容大きさを制御します。感度パラメータは、学習された標準偏差の乗数を制御します。感度として、低、中、 または高 を選択できます。Contrail Insights Agentは、リアルタイムの測定値を以下で定義された範囲と比較します。

mean - sensitivity * std_dev < x < mean + sensitivity * std_dev

アラーム定義

図2は、静的アラーム定義の例を示しています。すべてのアラーム定義には、表1に示す以下のコンポーネントがあります。

表1:アラーム定義コンポーネント
項目	オプション	説明
モジュール	アラーム、サービスアラーム	アラームを選択すると、ホスト、インスタンス、ネットワークデバイスなどのエンティティのアラームを設定できます。サービスアラームを選択すると、RabbitMQ、MySQL、ScaleIO、OpenStackサービスなどのサービスに対してアラームを設定できます。
アラームルールタイプ	静的、動的	これにより、アラームを生成するかどうかを判断するためにアラームが使用するしきい値のタイプが決まります。サポートされている 2 つのタイプを次に示します。静的—アラームが静的として定義されている場合、ルール定義には事前定義された静的しきい値を含める必要があります。例えば、静的しきい `cpu.usage` を80%にすることができます。動的—アラームが動的として定義されている場合、履歴データを使用してベースラインが学習されます。ベースライン分析アルゴリズム、学習期間、感度などの追加のパラメーターが必要です。
名前	アラーム名	名前でアラームを識別します。名前はダッシュボードに表示され、外部通知システムのユーザー向けの識別子です。
スコープ	ホスト、インスタンス、ネットワークデバイス、仮想ネットワーク	アラームが適用されるホスト、インスタンス、ネットワークデバイスなどのエンティティのタイプ。たとえば、スコープがインスタンスとして選択されている場合、インフラストラクチャに存在するすべてのインスタンス、または特定のプロジェクトまたはアグリゲートに存在するインスタンスにルールを設定するように選択できます。
サービス	RabbitMQ、MySQL、Ceph、OpenStack、Cassandra、Contrail、ScaleIO	選択すると、RabbitMQ、MySQL、Ceph、OpenStack、Cassandra、Contrail、ScaleIO サービスのアラームを設定できます。
メトリックスコープ	クラスター、ノード、キュー	監視するもののメトリックスコープ(クラスター、ノード、キューなど)を選択し、次に監視するメトリックを選択します。
オブジェクト	オプションは、メトリックスコープの選択に依存します。	監視対象のオブジェクト。
生成する	イベント、アラーム	アラームの条件が満たされたら、イベントまたはアラームを生成します。
メトリックの場合	cpu.usage、memory.usage	監視するメトリック。たとえば、host.cpu.usage や instance.cpu.usage などです。
いつ	値	—
間隔(秒)	秒単位の値	1つの測定間隔の期間(秒単位)。監視対象のメトリックのサンプリング頻度によっては、間隔期間内に 1 つ以上の生サンプルを受信する場合があります。間隔期間内に受信したすべての未加工サンプルは、平均、合計、最大、最小、標準開発などの集計関数を使用して処理されます。
は	値	例:値がしきい値-8を超える場合。例では、斜体は変数を表します。
しきい値	しきい値	測定値を比較する数値。Contrail Insights は、静的または動的の 2 種類のしきい値をサポートしています。静的しきい値—アラームが設定されているときに指定される固定値。たとえば、 host.cpu.usage が 90% を超えている場合、90% が静的しきい値です。動的閾値—しきい値はシステムによって動的に学習されます。教師なし学習は、動的しきい値を決定するための過去の傾向について学習するために使用されます。例えば、ホスト集計に対してイベントルールが定義されている場合、集計のすべてのメンバーホストから受信したデータにベースライン分析アルゴリズムを適用することによって、集計の動的ベースラインが決定されます。図 6 は、履歴データの直近の 24 時間枠と k 平均値クラスタリングアルゴリズムを使用して決定された動的ベースラインを示しています。このベースラインは、その時間帯とそれに対応するベースライン平均および標準偏差を考慮しながら、アラーム生成のために次の24時間使用されます。例えば、火曜日の午前 8:00 から午前 9:00 まで、月曜日の午前 8:00 から午前 9:00 に計算されたベースラインが、アラーム生成の基準しきい値として使用されます。動的しきい値に必要なパラメータは次のとおりです。ベースライン分析アルゴリズム学習期間感度表2は、動的アラームに必要なパラメーターとサポートされているオプションを示しています。
ベースライン分析アルゴリズム	K-Means、EWMA	表2に、これらのオプションを示します。ベースライン分析の例については、図6および図7を参照してください。
学習期間	1週間、1ヶ月	表2に、これらのオプションを示します。
感度	低、中、高	表2に、これらのオプションを示します。
重大度	なし、情報、警告、エラー、重大	アラームの重大度を示します。 Criticalは、メジャーアラームを示します。情報はマイナーアラームを示しています。
高度	選択すると、例外を含むインターバル、インターバルカウント、およびステータスが含まれます。	—
アグリゲート/プロジェクト	すべてのホスト、すべてのインスタンス。AggregateId、ProjectId	アラームが監視するエンティティのセットを選択します。スコープがインスタンスの場合、インフラストラクチャ内の特定のプロジェクト、アグリゲート、またはすべてのインスタンスに存在するインスタンスのセットに対してアラームを設定できます。スコープがホストの場合、特定のアグリゲートに存在するホストのセットまたはインフラストラクチャ内のすべてのホストに対してアラームを設定できます。
アラームモード	アラート、イベント	モードは、アラートまたはイベントとして設定できます。
集約機能	平均、最大、最小、合計、標準偏差	1つの測定間隔で受信したデータサンプルがどのように処理され、比較用の集計値を生成するかを決定します。エージェントは、測定間隔中にメトリックの複数のサンプルを収集します。エージェントは、測定間隔内の閾値(静的または動的)と比較するための単一の値を決定するために、集約関数に従ってサンプルを結合します。表5は、アラーム処理のアグリゲーション機能の一覧と説明です。
比較関数	上、下、等しい、最小レートで増加、最小レートで減少	集約関数の出力を静的または動的しきい値と比較する方法を決定します。表 6 は、Contrail Insights アラームでサポートされているさまざまな比較関数を示しています。図4 と図5 は、比較関数の例を示し、最小レートでの増加と減少の両方を示しています。
静的しきい値	アラームルールタイプが「静的」の場合	—
アラームの重大度	なし、情報、警告、エラー、重大	アラームの重大度を示します。 Criticalは、メジャーアラームを示します。情報はマイナーアラームを示しています。
通知	なし, PagerDuty, カスタムサービス, Service Now, Slack	動作状況を警告する通知方法。
例外ありの間隔	例えば、「2」とします。	これは、アラームを発生させるためにアラームの条件を満たす必要があるスライディングウィンドウ内の測定間隔の最小数です。図 3 には、例外を除く i2 と i5 の 2 つの間隔があります。ダッシュボードでアラームを設定する場合、例外のある間隔はデフォルトで1に設定されています。例外ありの間隔は、ダッシュボードで監視 >アラーム>ルールを追加を選択して指定できます。例外のある間隔は、間隔カウントより大きくすることはできません。
インターバルカウント	例えば、「3」と入力します。	アラームが生成されるかどうかを判断する前に統計分析が実行される隣接測定間隔の最大数。図3では、スライディングウィンドウには6つの測定間隔(i1からi6)があります。各測定間隔には、[間隔期間] パラメーターで指定された期間があります。ダッシュボードでアラームを設定する場合、インターバルカウントはデフォルトで1に設定されています。間隔カウントは、ダッシュボードで監視 >アラーム>新しいルールを追加を選択して指定できます。
ステータス	有効、無効	アラームルールの設定とステータスの検証に使用します。ステータスを有効または無効に設定します。

動的アラームに必要なパラメータ
アラームモードの状態
アラーム処理のための集約機能
アラーム処理の比較機能
動的ベースラインの例

動的アラームに必要なパラメータ

表2は、動的アラームに必要なパラメーターとサポートされているオプションを示しています。

表2:ダイナミックアラームに必要なパラメーター
動的しきい値に必要なパラメータ	説明	サポートされているオプション
ベースライン分析アルゴリズム	ベースライン分析アルゴリズムは、履歴データに対して教師なし学習を実行するために使用されます。ベースライン分析は、新しいデータを受信すると継続的に実行されます。	K-Meansクラスタリング指数加重平均平均(EWMA)
学習期間	学習期間期間は、ベースラインを決定するためにベースライン分析アルゴリズムが使用する履歴データの量を指定します。動的ベースラインは、最新の学習期間のデータを使用して継続的に更新されます。動的アラームが設定されている場合、最新の学習期間のデータ(利用可能な場合)を使用してベースライン分析が実行されます。利用可能なデータが十分ない場合、Contrail Insights Agent は、最初のベースラインセットを学習するのに十分なデータが存在するとすぐにメトリックを評価します。例: 学習期間が 1 日の場合、エージェントはメトリックを過去 24 時間の時間ごとのベースラインと比較します。例: 学習期間が 1 週間の場合、エージェントはメトリックを過去 7 x 24 時間の時間ごとのベースラインと比較します。	1週間—ベースラインは、過去1週間のデータにおける各時間について決定されます。次の 1 週間のベースラインは、先週のデータに基づいて決定されます。 1か月—ベースラインは、過去4週間のデータに基づいて決定されます。ベースラインは、曜日ごとに毎時間学習されます(7 x 24ベースライン)。次の 1 週間のベースラインは、過去 4 週間のデータに基づいて決定されます。たとえば、月曜日の午後 2:00 から午後 3:00 までのベースラインは、過去 4 つの月曜日の午後 2:00 から午後 3:00 までのメトリックデータを使用して学習されます。
感度	動的ベースラインは、特定のスコープについて、特定のメトリックの通常の運用領域を提供します。図 6 に示すように、動的ベースラインは、1 日の特定の時間帯に適用可能な mean と std-dev を持つタプルです。感度係数は、許容動作帯域を決定します。動作帯域外の測定では、例外のある間隔が発生します。たとえば、ベースライン平均が 20 で、std-dev が 2 の場合、通常の動作領域は 18 から 22 の間です。感度が低い場合、通常の動作領域は 10(平均 - 5std-dev)および 30(平均 + 5std-dev)として扱われます。この場合、メトリックの測定された平均が10から30の間である場合、アラームは発生しません。対照的に、平均が5または35の場合は、アラームが発生します。	低—ベースライン平均から `5 * std-dev` を超えるデータポイントは外れ値です。中—ベースライン平均から `3 * std-dev` を超えるデータポイントは外れ値です。高—ベースライン平均から `2 * std-dev` を超えるデータポイントは外れ値です。

アラームモードの状態

表3は、モードをalertとして設定した場合のアラームで考えられるすべての状態を示しています。

表3:アラートとして定義されたアラームモードの状態
状態	説明
学習内容	これは、各アラームの初期状態です。この状態では、アラームはリアルタイムデータを処理しており、アラームを生成するかどうかを決定するのに十分なデータが処理されるまで、アラームはこの状態を維持します。学習期間の期間は、スライディングウィンドウパラメーターによって異なります。
アクティブ	アラームで指定された条件が満たされています。アラーム条件が満たされている限り、アラームはこの状態を維持します。
非アクティブ	アラームで指定された条件が満たされていません。たとえば、学習状態の後、CPU使用率が設定されたしきい値を下回ったため、アラームがアクティブ状態から非アクティブ状態に遷移します。
無効化済み	エージェントは、このアラームのデータをアクティブに分析していません。アラームがユーザーによって削除されるか、一時的に無効化されます。

表4は、モードがイベントとして設定されたアラームで考えられるすべての状態を示しています。

表4:イベントとして定義されたアラームモードの状態
状態	説明
有効	これは、ルールが設定されたときのモードがイベントに設定されたアラームの初期状態です。アラームを生成する条件が満たされるまで、この状態が維持されます。
トリガー	アラーム生成の条件が満たされると、トリガーされた状態のアラームが生成されます。アラーム生成は、アラームの条件が満たされ続ける限り、各測定間隔の終了時にログに記録されます。
無効化済み	エージェントは、このアラームのデータをアクティブに分析していません。アラームが削除されているか、ユーザーによって一時的に無効になっています。

アラーム処理のための集約機能

表5は、アラーム処理のアグリゲーション機能の一覧と説明です。

表5:アラーム処理のための集約関数
集約機能	説明
平均	1つの測定間隔内に受信したすべてのデータサンプルの統計平均。例:60秒間隔のCPU使用率平均が、最後の3つの測定間隔のうち2つの測定間隔の80%を超えた場合にホストアラートを生成します。この例では、測定間隔は60秒です。CPU 使用率サンプルの平均が、隣接する 3 つの測定間隔のうち任意の 2 つの測定間隔で 80% を超えると、アラームが生成されます。
合計	1つの測定間隔内に受信したすべてのデータサンプルの合計。例:60秒間隔のCPU使用率の合計が、最後の3つの測定間隔のうち2つの測定間隔の250%を超えた場合、ホストアラートを生成します。この例では、隣接する3つの測定間隔のうち任意の2つの測定間隔でCPU使用率の合計が250%を超え、各測定間隔の継続時間が60秒の場合にアラームが生成されます。
最大	1つの測定間隔内に観測された最大サンプル値。例:60秒間隔のCpu-Usage Maxが、最後の3つの測定間隔のうち2つの測定間隔の95%を超えた場合、ホストアラートを生成します。この例では、隣接する3つの測定間隔のうち任意の2つの測定間隔で最大CPU使用率が95%を超え、各測定間隔の長さが60秒の場合にアラームが生成されます。
分	1つの測定間隔内に観測された最小サンプル値。例:60秒間隔のCPU使用率が、過去3つの測定間隔のうち2つの測定間隔の5%を下回った場合、ホストアラートを生成します。この例では、隣接する3つの測定間隔のうち任意の2つの測定間隔で最小CPU使用率が5%を下回り、各測定間隔の長さが60秒の場合にアラームが生成されます。
標準設計	時系列データの標準偏差は、現在の測定間隔までに受信したサンプルに基づいて決定されます。例:60秒間隔のCpu-Usage std-devが、最後の3つの測定間隔のうち2つの測定間隔のうち2シグマを超えた場合、ホストアラートを生成します。この例では、生の時系列サンプルが、最後の3つの測定間隔のうち少なくとも2つの測定間隔で `mean + 2*sigma` を超えた場合にアラームが生成されます(各測定間隔の期間は60秒です)。

アラーム処理の比較機能

図4と図5は、比較関数の例を示し、最小レートでの増加と減少の両方を示しています。

表 6 は、Contrail Insights アラームでサポートされているさまざまな比較関数を示しています。

表6:アラーム処理の比較関数
比較演算子	説明
上記	特定の測定間隔内の集約関数の結果がしきい値を上回っているかどうかを判断します。注: 上記の動的しきい値の場合、Contrail Insightsは、集約関数の結果が通常の動作領域(平均+/-シグマ*感度)の範囲外であるかどうかを比較します。
以下	特定の測定間隔に対して決定された集約関数の結果がしきい値を下回っているかどうかを判断します。注: 動的閾値については、以下では、集約関数の結果が通常の動作領域内にあるかどうかを比較します(平均+/-シグマ*感度)。
等しい	集約関数の結果がしきい値と等しいかどうかを判断します。
最小限の割合で増加	この比較関数は、絶対値ではなく、特定のメトリックの値の急激な増加を追跡したい場合に便利です。例えば、イングレスまたはエグレスのネットワーク帯域幅が短い間隔で増加し始めた場合、アラームを発生させることができます。図4 は、測定間隔i1とi2の間のメトリック平均の急激な増加を示しています。同様に、測定間隔i4からi5の間のメトリック平均に急激な増加が観察されます。例:60秒間隔のhost.network.ingress.bit_rate平均が、最後の3つの測定間隔のうち2つの最小レートで25%増加している場合、ホストアラートを生成します。この例では、平均イングレスビットレートが3つの測定間隔のうち2つの測定間隔で少なくとも25%増加した場合、アラームが発生します。
最小限の割合で減少	この比較関数は、絶対値ではなく、特定のメトリックの値の急激な減少を追跡する場合に便利です。例えば、エグレスネットワークの帯域幅が短時間で減少し始めた場合、根本原因を調査するためにアラームを発生させることができます。図5 は、測定間隔i1とi2の間のメトリック平均の急激な減少を示しています。同様に、測定間隔 i3 と i4 の間のメトリック平均にも急激な減少が観察されます。例:60秒間隔のhost.network.egress.bit_rate平均が、最後の3つの測定間隔のうち2つの最小レートの25%で減少している場合、ホストアラートを生成します。この例では、平均エグレスビットレートが3つの測定間隔のうち2つの測定間隔で少なくとも25%減少した場合、アラームが発生します。

図4:

Visualization of time series data analysis using a sliding window. Highlights include raw data, sliding window, measurement intervals, and detected anomalies.

の最小レートで増加を示す比較関数

図5:

Conceptual diagram of analyzing time series data using a sliding window. Shows intervals with exceptions and regions decreasing at a minimum rate.

の最小レートでの減少を示す比較関数

動的ベースラインの例

図6は、24時間のデータとk平均クラスタリングアルゴリズムによって計算された動的ベースラインを示しています。特定の時間において、青い点がmean、緑のバーがmean + std-dev、紫色のバーがmean - std-devです。

図6:過去24時間のデータとK平均スタリングアルゴリズム Dashboard for CPU usage monitoring with alarm details and graph. Alarm triggers if CPU usage exceeds dynamic threshold over 60-second intervals. Graph shows low usage with a rise at day's end.

Dashboard for CPU usage monitoring with alarm details and graph. Alarm triggers if CPU usage exceeds dynamic threshold over 60-second intervals. Graph shows low usage with a rise at day's end.

によって決定された動的ベースライン

図7は、EWMAアルゴリズムを使用して24時間の履歴データによって計算された動的ベースラインを示しています。このベースラインは、直近の24時間のデータを使用して再度更新されるまで、アラーム生成のために次の1時間使用されます。

図7:EWMA

Monitoring interface showing an alert triggered for disk.io.write above threshold. Includes alarm details, configuration table, and graph with MB/s data point.

を使用した過去24時間の履歴データによって決定された動的ベースライン

アラームルールの設定

アラームを設定するには:

監視 >アラームを選択します。
アラームルールパネルで、ルールを追加をクリックして、ネットワーク内の選択したエンティティの1つでユーザー定義の条件が満たされた場合にアラームをトリガーする新しいルールを作成します。

図8:Contrailコマンドのアラームアクティブアラートとアラームルールパネル

モジュールで、以下のオプションの1つを選択します。選択内容に応じて、フィールドは異なります。

Alarms	アラームを選択すると、ホスト、インスタンス、ネットワークデバイスなどのエンティティのアラームを設定できます。
Service Alarms	サービスアラームを選択すると、RabbitMQ、MySQL、ScaleIO、OpenStackサービスなど、環境内のサービスに対してアラームを設定できます。

図9:Contrailコマンド Create Alarm page in Contrail Command interface for setting system metric alerts. Monitoring category expanded. Alarm named Test-CPU. Static rule for host.cpu.per_core.usage, 60-second interval, above threshold, critical severity.

Create Alarm page in Contrail Command interface for setting system metric alerts. Monitoring category expanded. Alarm named Test-CPU. Static rule for host.cpu.per_core.usage, 60-second interval, above threshold, critical severity.

でアラームを作成および設定する

[アラームルールタイプ]を選択します。
- 静的—アラームが静的として定義されている場合、ルール定義には、ユーザーが決定する定義済みの静的しきい値を含める必要があります。
- 動的—アラームが動的として定義されている場合、しきい値はベースラインアルゴリズムによって動的に決定されます。ベースラインアルゴリズムは、k-meansまたはewmaのいずれかです。
ルールのメトリックを選択し、ルールがアラームを トリガー する間隔を指定します。その他のパラメータについては、表1 および「アラーム定義」セクションの説明を参照してください。
作成をクリックしてアラームを保存します。