Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

AppFormix アラームを使用すると、インフラストラクチャで条件が満たされたときに生成されるアラームを設定できます。AppFormix は、アラームに一致するイベントを効率的かつ応答的に検出するために、収集時点でメトリックの分散分析を実行します。AppFormix には 2 種類のアラームがあります。

Static

ユーザーが指定した静的しきい値が比較に使用されます。

Dynamic

動的に学習された適応閾値が比較に使用されます。

メモ:

アラームを設定するには、AppFormix ライセンス サブスクリプションがアクティブである必要があります。

AppFormix アラームの概要

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

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

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

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

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

AppFormix アラーム動作

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

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

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

図1:アラーム生成の仕組み Alarm Generation Mechanics

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

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

静的アラーム

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

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

ダイナミックアラーム

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

図 3: 動的アラームの定義 Dynamic Alarm Definition

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

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

BaselineAnalysisAlgorithm

動的しきい値の決定に使用する機械学習アルゴリズムを選択します。次のアルゴリズムを使用できます。

k-means

AppFormix では、K-Means アルゴリズムを使用して、一連のエンティティに対して予想される動作範囲を、各 1 時間単位 (最大 1 週間) の粒度で生成します。学習されたベースラインは、設定可能な学習期間のデータを使用して計算されます。ベースラインは、最新のデータに基づいて、時間の経過とともに継続的に更新されます。K-Means ベースライン分析アルゴリズムは、特定の時刻に予期しないパフォーマンスを監視する場合に便利です。

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

ewma

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

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

LearningPeriodDuration

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

Sensitivity

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

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

アラーム定義

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

表 1: アラーム定義コンポーネント

項目

オプション

説明

モジュール

アラーム、サービスアラーム

[アラーム(Alarms)] を選択すると、ホスト、インスタンス、ネットワーク デバイスなどのエンティティにアラームを設定できます。サービスアラームを選択すると、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 を超えている場合。例の斜体は変数を表します。

しきい値

しきい値

測定値を比較する数値。AppFormix では、静的と動的の 2 種類のしきい値がサポートされています。

  • 静的しきい値—アラームが設定されたときに指定される固定値。たとえば、 host.cpu.usage が 90% を超えると、90% が静的しきい値になります。

  • 動的しきい値—しきい値はシステムによって動的に学習されます。教師なし学習は、動的なしきい値を決定するための履歴傾向について学習するために使用されます。例えば、イベント・ルールが Host アグリゲートに定義されている場合、アグリゲートのすべてのメンバー・ホストから受信したデータにベースライン分析アルゴリズムを適用することによって、アグリゲートの動的ベースラインが決定されます。 図6 は、履歴データとk-meansクラスタリングアルゴリズムの最新の24時間枠を使用して決定された動的ベースラインを示しています。このベースラインは、時刻とそれに対応するベースライン平均および標準偏差を考慮しながら、アラーム生成のために今後 24 時間使用されます。たとえば、火曜日の午前 8:00 から午前 9:00 では、月曜日の午前 8:00 から午前 9:00 に計算されたベースラインが、アラーム生成の基準しきい値として使用されます。

    動的しきい値の必須パラメーターは次のとおりです。

    • ベースライン分析アルゴリズム

    • 学習期間

    • 感度

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

ベースライン分析アルゴリズム

K平均法、EWMA

表 2 に、これらのオプションを示します。ベースライン分析の例については、図 6図7 を参照してください

学習期間

1週間、1ヶ月

表 2 に、これらのオプションを示します。

感度

低、中、高

表 2 に、これらのオプションを示します。

重大 度

なし、情報、警告、エラー、重大

アラームの重大度を示します。 [Critical] は、メジャー アラームを示します。 情報は マイナーアラームを示しています。

詳細

選択すると、[例外のある間隔]、[間隔カウント]、および [状態] が含まれます。

集計/プロジェクト

すべてのホスト、すべてのインスタンス。AggregateId、ProjectId

アラームが監視するエンティティのセットを選択します。[スコープ] が [インスタンス] の場合、インフラストラクチャ内の特定のプロジェクト、アグリゲート、またはすべてのインスタンスに存在するインスタンスのセットに対してアラームを設定できます。[スコープ(Scope)] が [ホスト(Host)] の場合、インフラストラクチャ内の特定のアグリゲートまたはすべてのホストに存在する ホストのセットに対してアラームを設定できます。

アラームモード

アラート、イベント

モードは、アラートまたはイベントとして構成できます。

集計関数

平均、最大、最小、合計、標準偏差

1 つの測定間隔で受信したデータ サンプルを処理して、比較用の集計値を生成する方法を決定します。エージェントは、測定間隔中にメトリックの複数のサンプルを収集します。エージェントは、測定間隔における閾値(静的または動的)と比較するための単一の値を決定するために、集約関数に従ってサンプルを結合する。 表 5 に、アラーム処理の集約関数をリストし、説明しています。

比較機能

上、下、等しい、最小速度での増加、最小速度での減少

集計関数の出力を静的しきい値または動的しきい値と比較する方法を決定します。 表 6 に、AppFormix アラームでサポートされているさまざまな比較関数を示します。図 4図5 は比較関数の例を示しており、最小速度での増加と減少の両方を示しています。

静的しきい値

アラームルールタイプが「静的」の場合

アラームの重大度

なし、情報、警告、エラー、重大

アラームの重大度を示します。 [Critical] は、メジャー アラームを示します。 情報は マイナーアラームを示しています。

通知

なし、PagerDuty、カスタムサービス、サービスナウ、スラック

操作条件を警告する通知方法。

例外のある間隔

たとえば、"2"

これは、アラームを発生させるためにアラームの条件が満たされる必要があるスライディングウィンドウ内の測定間隔の最小数です。 図 3 には、i2 と i5 という 2 つの例外区間があります。ダッシュボードでアラームを設定する場合、[例外のある間隔(Intervals with Exception)] はデフォルトで 1 に設定されます。例外のある間隔は、ダッシュボードで モニタリング > アラーム > ルールの追加 を選択することで指定できます。例外のある間隔は、間隔カウントを超えることはできません。

間隔カウント

たとえば、"3"

アラームを生成するかどうかを決定する前に統計分析を実行する隣接する測定間隔の最大数。 図3では、スライディングウィンドウに6つの測定間隔(i1からi6)があります。各測定間隔には、[間隔期間] パラメーターで指定された期間があります。ダッシュボードでアラームを設定する場合、[間隔カウント(Interval Count)] はデフォルトで 1 に設定されます。間隔カウントは、ダッシュボードで モニタリング > アラーム > 新しいルールの追加 を選択することで指定できます。

ステータス

有効、無効

アラームルールのステータスを設定および確認するために使用します。状態を有効または無効に設定します。

ダイナミックアラームの必須パラメータ

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

表 2: ダイナミックアラームの必須パラメータ

動的しきい値の必須パラメーター

説明

サポートされているオプション

ベースライン分析アルゴリズム

ベースライン分析アルゴリズムは、履歴データに対して教師なし学習を実行するために使用されます。ベースライン分析は、新しいデータを受信すると継続的に実行されます。

  • K 平均法クラスタリング

  • 指数加重平均(EWMA)

学習期間

学習期間期間は、ベースラインを決定するためにベースライン分析アルゴリズムによって使用される履歴データの量を指定します。動的ベースラインは、最新の学習期間のデータを使用して継続的に更新されます。

動的アラームが設定されている場合、ベースライン分析は、最新の学習期間のデータ(利用可能な場合)を使用して実行されます。使用可能なデータが十分でない場合、AppFormix エージェントは、最初のベースライン セットを学習するのに十分なデータが存在するとすぐにメトリックを評価します。

例: 学習期間が 1 日の場合、エージェントはメトリックを過去 24 時間の時間単位のベースラインと比較します。

例: 学習期間が 1 週間の場合、エージェントはメトリックを過去 7 x 24 時間の時間単位のベースラインと比較します。

  • [1 週間] - 過去 1 週間のデータの 1 時間ごとにベースラインが決定されます。ベースラインの次の 1 週間は、先週のデータに基づいて決定されます。

  • 1 か月 - ベースラインは過去 4 週間のデータに基づいて決定されます。ベースラインは、各曜日の時間ごとに学習されます (7 x 24 ベースライン)。次の1週間のベースラインは、過去4週間のデータに基づいて決定されます。たとえば、月曜日の午後 2:00 から午後 3:00 のベースラインは、過去 4 つの月曜日の午後 2:00 から午後 3:00 のメトリック データを使用して学習されます。

感度

動的ベースラインは、特定のスコープに対する特定のメトリックの通常の動作領域を提供します。 図6に示すように、動的ベースラインは、1日の特定の時間に適用可能な平均とstd-devを持つタプルです。

感度係数は、許容される動作帯域を決定します。動作帯域外での測定では、例外的に間隔が発生します。たとえば、ベースライン平均が 20 で std-dev が 2 の場合、通常の動作領域は 18 から 22 の間になります。感度 が低い 場合、通常の動作領域は 10 (平均 - 5*std-dev) および 30 (平均 + 5*std-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秒です。隣接する 3 つの測定間隔のうち、2 つの測定間隔で CPU 使用率サンプルの平均が 80% を超えると、アラームが生成されます。

合計

1つの測定間隔内に受信したすべてのデータサンプルの合計。

例: 60 秒間隔中の CPU 使用率の合計が、最後の 3 つの測定間隔の 2 つの 250% を超えた場合にホスト アラートを生成します。

この例では、隣接する 3 つの測定間隔のうち 2 つの測定間隔で CPU 使用率の合計が 250% を超え、各測定間隔が 60 秒の場合、アラームが生成されます。

最大

1回の測定間隔で観察された最大サンプル値。

例: 60 秒間隔中の CPU 使用率の最大が、最後の 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 シグマを超えた場合にホスト アラートを生成します。

この例では、生の時系列サンプルが、各測定間隔が 60 秒である最後の 3 つの測定間隔のうち少なくとも 2 つの測定間隔を上回 mean + 2*sigma った場合にアラームが生成されます。

アラーム処理の比較機能

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

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

表 6: アラーム処理の比較関数

比較演算子

説明

上記

指定された測定間隔内の集計関数の結果がしきい値 を超え ているかどうかを判断します。

メモ:

上記の 動的しきい値の場合、AppFormix は、集計関数の結果が通常の動作領域 (平均 +/- シグマ*感度) の範囲外であるかどうかを比較します。

以下に

特定の測定間隔で決定された集計関数の結果がしきい値 を下回 っているかどうかを判断します。

メモ:

動的しきい値 の場合、集計 関数の結果が通常の動作領域内にあるかどうかを比較します(平均+/-シグマ*感度)。

等しい

集計関数の結果がしきい値と 等しい かどうかを判断します。

最小増加率

この比較関数は、特定のメトリックの絶対値ではなく、値の急激な増加を追跡する場合に便利です。たとえば、イングレスまたはエグレスのネットワーク帯域幅が短い間隔で増加し始めた場合、アラームを発生させることができます。 図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: 最小増加 Comparison Function Showing Increasing-at-a-minimum-rate-of率を示す比較関数
図5: 最小での減少率 Comparison Function Showing Decreasing-at-a-minimum-rate-ofを示す比較関数

動的ベースラインの例

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

図 6: 過去 24 時間のデータと K-Means クラスタリング アルゴリズム Dynamic Baseline Determined by Last 24 Hours of Data and K-Means Clustering Algorithmによって決定される動的ベースライン

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

図 7: EWMA を使用した過去 24 時間の履歴データによって決定された動的ベースライン Dynamic Baseline Determined by Last 24 Hours of Historical Data Using EWMA

アラーム ルールの設定

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

  1. [モニタリング>アラーム] を選択します。

  2. [アラーム ルール(Alarm Rules)] パネルで、[ルール の追加(Add Rule)] をクリックして、ネットワーク内の選択したエンティティの 1 つでユーザー定義の条件が満たされたときにアラームをトリガーする新しいルールを作成します。

    図 8: Contrail コマンドの [アラームのアクティブなアラートとアラーム ルール] パネル Alarm Active Alerts and Alarm Rules Panel in Contrail Command
  3. [モジュール] で、次のいずれかのオプションを選択します。選択内容によって、フィールドは異なります。

    Alarms

    [アラーム(Alarms)] を選択すると、ホスト、インスタンス、ネットワーク デバイスなどのエンティティにアラームを設定できます。

    Service Alarms

    [サービス アラーム] を選択すると、環境内のサービス (RabbitMQ、MySQL、ScaleIO、OpenStack サービスなど) のアラームを設定できます。

    図 9: Contrail コマンド Create and Configure an Alarm in Contrail Commandでのアラームの作成と設定
  4. [アラーム ルールの種類] を選択します。

    • [静的(Static )]:アラームが静的として定義されている場合、ルール定義には、ユーザーが決定した事前定義された静的しきい値を含める必要があります。

    • 動的:アラームが動的として定義されている場合、しきい値はベースラインアルゴリズム(K平均法またはEWMAのいずれか)によって動的に決定されます。

  5. ルールのメトリクスを選択し、ルールがアラームを トリガー する間隔を指定します。その他のパラメータについては、 表 1 および「アラームの定義」セクションの説明を参照してください。

  6. [ 作成 ] をクリックしてアラームを保存します。