ルールの概要

準則

ルール は、ハードコーディングから解放されることを意図しています。閾値について考えてみましょう。しきい値がハードコードされている場合、異なる要件を持つ別の顧客やデバイスに合わせて閾値をカスタマイズする簡単な方法はありません。そのため、ルールはパラメーター化を使用して定義され、既定値が設定されます。これにより、パラメータをデフォルトのままにしておくことも、展開時にオペレーターがカスタマイズすることもできます。カスタマイズは、個々のルールが含まれているプレイブックを適用しながら、デバイスグループまたは個々のデバイスレベルで実行できます。

デバイス中心のルールは、デバイスルールと呼ばれます。シャーシ、システム、ラインカード、インターフェイスなどのデバイスコンポーネントは、すべてルール定義のトピックとして扱われます。通常、デバイスルールでは、デバイス上のセンサーが使用されます。

複数のデバイスにまたがるルールは、ネットワーク ルールと呼ばれます。ネットワークルール:

• ルール頻度を設定する必要があります

• センサーを含まないこと

• プレイブックでデバイスルールと混在させることはできません

いずれかの種類のルールをデプロイするには、プレイブックにルールを含め、プレイブックをデバイス グループまたはネットワーク グループに適用します。

ルールを構成するすべてのブロックがすべてのルールに必要なわけではありません。ルール定義で特定のブロックが必要かどうかは、取得しようとしている情報の種類によって異なります。また、一部のルール コンポーネントはネットワーク ルールに対して無効です。 表 1 は、ルールのコンポーネントの一覧と、各コンポーネントの簡単な説明を示しています。

センサー

センサーを定義するときは、センサー名、センサー タイプ、データ収集頻度などの情報を指定する必要があります。 表 1 に示すように、センサーは次のいずれかです。

• OpenConfig

  OpenConfig JTI センサーについては、 Junos Telemetry Interface User Guide を参照してください。

• Native GPB

  ネイティブ GPB JTI センサーについては、 Junos Telemetry Interface ユーザー ガイドを参照してください。

• iAgent

  iAgentセンサーは、NETCONFおよびYAMLベースのPyEZテーブルとビューを使用して、必要なデータを取得します。構造化データ(XML)と非構造化データ(VTYコマンドおよびCLI出力)の両方がサポートされています。Junos PyEZの情報については、 Junos PyEZのドキュメントを参照してください。

• SNMP	簡易ネットワーク管理プロトコル。

• syslog

  システムログ

• BYOI	Bring your own ingest – 独自のインジェストタイプを定義できます。

• Flow	NetFlow トラフィック フロー分析プロトコル

• sFlow

  sFlow パケット サンプリング プロトコル

異なるルールに同じセンサーが定義されている場合、センサーごとに 1 つのサブスクリプションのみが行われます。OpenConfig およびネイティブ GPB センサーの sensor-path と、iAgent センサーの file と table のタプルで構成されるキーを使用して、関連するルールを識別します。

同じ センサー パス キーを持つ複数のセンサーに異なる周波数が定義されている場合、センサー サブスクリプションには最も低い周波数が選択されます。

田畑

フィールド・ソースには、 表 1 にリストされているように、4 つのタイプがあります。 表 2 では、4 つのフィールド取り込みタイプについて詳しく説明しています。

/device-group[device-group-name=<device-group>]\
/device[device-name=<device>]/topic[topic-name=<topic>]\
/rule[rule-name=<rule>]/field[<field-name>=<field-value>\
 AND|OR ...]/<field-name>
 

/device-group[device-group-name={{pe-device-group}}]
/device[device-id={{pe-device-name}}]/
topic[topic-name='protocol.l3vpn']
/rule[rule-name=get-interface-details]
/field[sub-interface-index='{{pe-ifl-number}}' 
and interface-name='{{pe-interface-name}}']
/link-state

ベクトル

ベクトル は、複数の要素を 1 つのルールにまとめるのに役立ちます。たとえば、ベクトルを使用すると、すべてのインターフェイス エラー フィールドを収集できます。Vector の構文は次のとおりです。

$field-n は、参照型のフィールドにすることができます。

ベクトルの定義に使用されるフィールドは、他のルールで定義されたフィールドへの直接参照にすることができます。

この構文では、コンストラクトの <field-name>=<field-value> 部分を使用したオプションのフィルター処理が可能になります。ベクトルは、指定された時間範囲から値を選択する時間範囲オプションを取ることもできます。指定された時間範囲で複数の値が返された場合、それらはすべて配列として選択されます。

ベクトルでは、次の定義式がサポートされています。

• unique @vector1–vector1 から一意の要素セットを返します。

• @vector1 and @vector2–vector1 と vector2 の一意の要素の共通部分を返します。

• @vector1 or @vector2–2 つのベクトル内の一意の要素の合計セットを返します。

• @vector1 unless @vector2–ベクトル 1 の一意の要素セットを返しますが、ベクトル 2 の要素は返しません

変数

変数は、ルール作成時に [変数 ] ページで定義します。変数定義のこの部分では、デプロイ中にデバイス グループまたはデバイスに特定の値が設定されていない場合に使用される既定値が作成されます。たとえば、 check-interface-status ルールには interface_name という変数が 1 つあります。 [変数 ] ページで設定される値は、正規表現 (regex)、 .*、つまりすべてのインターフェイスです。

check-interface-statusルールをそのまま適用すると、デバイスグループ内のすべてのデバイスのすべてのインターフェイスに関するインターフェイスステータス情報が提供されます。このルールを含むプレイブックを適用するときに、デバイスグループまたはデバイスレベルでデフォルト値を上書きできます。これにより、ルールを柔軟に適用できます。優先順位は、デバイス値がデバイス・グループ値を上書きし、デバイス・グループの値がルールで設定されたデフォルト値を上書きします。

関数

関数は、ルール作成時に [関数] タブで定義します。ここで関数を定義すると、フィールドに関連付けられた数式や、トリガーの [When] セクションと [Then] セクションで使用できます。トリガーの when 句で使用される関数は、ユーザー定義関数と呼ばれます。これらは true または false を返す必要があります。トリガーの then 句で使用される関数は、ユーザー定義アクションと呼ばれます。

Paragon Automationでは、Pythonユーザー定義関数を使用して複数の値を返すことができます。

たとえば、3 つの戻り値を持つ関数 example_function.py があるとします。ルールで example_function.py を呼び出すと、ユーザー定義関数 (UDF) の最初の戻り値が、関数を呼び出すルール フィールド ([フィールド] タブ) に格納されます。 r2 や r3などの戻り値フィールドを構成する必要があるのは、[関数] タブの [戻り値リスト] の残りの 2 つの戻り値だけです。

時系列データベースでは、リターン リスト フィールドの名前の前には、UDF を使用するルール フィールドの名前が付きます。たとえば、 rule_field_name-r2。

図 2 は、 Functions ブロックの構成例を示しています。フィールドの詳細については、以下で説明します。

図 2: Functions ブロックの

トリガー

トリガーは、Paragon Insightsのルール定義において極めて重要な役割を果たします。これらは、使用可能なセンサー データの変更に基づいてアクションを実行するかどうか、およびいつ実行するかを決定するルールの一部です。トリガーは、when-this、then-that の方法で構築されます。前述したように、トリガーアクションは 条件に基づいています。 用語 は、フィールド値の更新を監視する when 句と、変更内容に基づいてアクションを開始する then 句で構成されます。1 つのトリガー内で複数の 用語 を作成できます。

本規約の when 句の評価は、用語リストの一番上から始まり、一番下に向かって行われます。項が評価され、一致しない場合は、次の項が評価されます。既定では、一致するか、一致なしでリストの一番下に到達するまで、この方法で評価が続行されます。

when 句で使用できる定義済みの演算子には、次のものがあります。

• より大きい - ある値が別の値よりも大きいかどうかをチェックするために使用されます。

  • 戻り値: True または False

  • 構文: greater-than <LHS> <RHS> [time-range <range>]

  • 例： //Memory > 3000 MB in the last 5 minutes

    when greater-than $memory 3000 time-range 5m;

• greater-than-or-equal-to- より大きい ものと同じですが、より大きいか等しいかをチェックします(>=)

• より小さい

  • 戻り値: True または False

  • 構文: less-than <LHS> <RHS> [time-range <range>]

  • 例： //Memory < 6000 MB in the last 5 minutes

    when less-than $memory 6000 time-range 5m;

• より小さいか等しい - より小さい のと同じですが、より小さいか等しいかどうかをチェックします(<=)

• equal-to- ある値が別の値と等しいことを確認するために使用されます。

  • 戻り値: True または False

  • 構文: equal-to <LHS> <RHS> [time-range <range>]

  • 例： //Queue’s buffer utilization % == 0 

    when equal-to $buffer-utilization 0;

• not-equal-to: equal-to と同じですが、負の条件(!=)をチェックします。

• exists - 値自体を気にせずに、ある値が存在するかどうかを確認するために使用します。つまり、デバイスから何らかの値が送信されているはずです。

  • 戻り値: True または False

  • 構文: exists <$var> [time-range <range>]

  • 例： //Has the device configuration changed? 

    when exists $netconf-data-change

• matches-with(文字列と正規表現用)- Python の正規表現操作を使用して文字列の一致をチェックするために使用します。詳細については、「 Python 正規表現」 を参照してください。

  手記：

  LHS、または左側は、検索している文字列です。RHS(右辺)は一致式です。正規表現は RHS でのみ使用できます。

  • 戻り値: True または False

  • 構文: matches-with <LHS> <RHS> [time-range <range>]

  • 例： //Checks that ospf-neighbor-state has been UP for the past 10 minutes

    when matches-with $ospf-neighbor-state “^UP$” time-range 10m;

• does-not-match-with(文字列と正規表現の場合)– matches-with と同じですが、否定的な条件をチェックします

• 範囲 - 値 X が、最小や最大(最小 <= X <= 最大)などの特定の範囲内にあるかどうかを確認します。

  • 戻り値: True または False

  • 構文: 範囲 <$var> 最小 <最小値>最大値<最大値> [time-range <範囲>]

  • 例： //Checks whether memory usage has been between 3000 MB and 6000 MB in the last 5 minutes

    when range $mem min 3000 max 6000 time-range 5m;

• Increaseing-at-least-by-value:以前の値と比較して、値が少なくとも最小許容率だけ増加しているかどうかを確認するために使用します。許容可能な最小増加率を定義する省略可能なパラメーターを指定できます。最小許容増加率は、指定しない場合、デフォルトで 1 になります。

  • 戻り値: True または False

  • 構文：

    値ごとに最小で増加する<$var> [増分<連続するポイント間の最小値>]

    increase-at-least-by-value <$var> [increment <連続するポイント間の最小値>] time-range <範囲>

  • 例： Checks that the ospf-tx-hello has been increasing steadily over the past 5 minutes.

    when increasing-at-least-by-value $ospf-tx-hello increment 10 time-range 5m;

• increaseing-at-most-by-value - 以前の値と比較して、値が最大許容レートを超えていないかどうかを確認するために使用します。許容可能な最大増加率を定義する省略可能なパラメーターを指定できます。指定しない場合、最大許容増加率はデフォルトで 1 になります。

  • 戻り値: True または False

  • 構文：

    increaseing-at-most-by-value <$var> [increment <連続するポイント間の最大値>]

    値ごとに最大で増加する<$var> [増分<連続するポイント間の最大値>] 時間範囲<範囲>

  • 例： Checks that the error rate has not increased by more than 5 in the past 5 minutes.

    when increasing-at-most-by-value $error-count increment 5 time-range 5m;

• inging-at-least-by-rate - 連続する値の増加率が少なくとも特定の率であることを確認するために使用されます。必須パラメータには、値と時間単位が含まれ、これらが合わせて最小許容増加率を示します。

  • 戻り値: True または False

  • 構文：

    この構文は、現在の値を以前の値と比較し、少なくとも値レートだけ増加するようにします。

    <秒|分|時間|日|週|月|年> [時間範囲<範囲>><<$var>

    この構文は、現在の値を以前の値と比較し、少なくともパーセント率で増加するようにします

    <秒|分|時間|日|週|月|年> [時間範囲 <範囲>><<$var>

  • 例： Checks that the ospf-tx-hello has been increasing strictly over the past five minutes.

    when increasing-at-least-by-rate $ospf-tx-hello value 1 per second time-range 5m;

• 最大レートで増加 - レートごとに増加する場合と似ていますが、レートの減少を確認する点が異なります。

when 句で これらの演算子を使用すると、ユーザー定義条件と呼ばれる関数が作成されます。これらの関数は、常に true または false を返す必要があります。

用語の評価の結果が一致した場合、Then 句で指定されたアクションが実行されます。デフォルトでは、用語の処理はこの時点で停止します。このフローを変更するには、Then 句の下部にある [次の用語の評価] ボタンを有効にします。これにより、Paragon Insightsは項処理を続行し、when-this、this、then thatなどのより複雑な意思決定機能を作成します。

次に、[ Then ] セクションで使用できる事前定義済みのアクションの一覧を示します。

• 次に

• 地位

タグ 付け

タグ付けを使用すると、特定の条件が満たされたときに、フィールド、値、およびキーをParagon Insightsルールに挿入できます。詳細については、「 Paragon Insightsのタグ付けの概要 」を参照してください。

ルールのプロパティ

[ルールのプロパティ]ブロックでは、ハードウェアの依存関係、ソフトウェアの依存関係、バージョン履歴など、Paragon Insightsルールのメタデータを指定できます。このデータは、情報提供や、デバイスがParagon Insightsルールと互換性があるかどうかを確認するために使用できます。