Paragon Insightsの概念

データ収集 - 「プッシュ」モデル

ネットワーク内のオブジェクト数とそれらが生成するメトリックが増えるにつれ、ネットワークの状態を監視するための運用統計を収集することがますます困難になっています。SNMPやCLIなどの従来の「プル」データ収集モデルは、ネットワーク要素を定期的にポーリングするために追加の処理を必要とし、スケーリングを直接制限する可能性があります。

「プッシュ」モデルは、データを非同期的に配信することでこれらの制限を克服し、ポーリングを排除します。このモデルでは、Paragon Insightsサーバーは、定期的なアップデートをストリーミングするために、ネットワークデバイスに単一のリクエストを行うことができます。その結果、「プッシュ」モデルは拡張性が高く、ネットワーク内の数千のオブジェクトの監視をサポートできます。Junosデバイスは、 Junos Telemetry Interface (JTI)という形でこのモデルをサポートしています。

Paragon Insightsは現在、5つの「プッシュ」インジェストタイプをサポートしています。

• ネイティブGPB

• Netflow

• Sflow

• OpenConfig

• Syslog

これらのプッシュモデルのデータ収集( インジェスト)方法については、 Paragon Insightsデータインジェストガイドで詳しく説明しています。

データ収集 - 「プル」モデル

「プッシュ」モデルは、その効率とスケーラビリティのために推奨されるアプローチですが、「プル」データ収集モデルが適切な場合もあります。「プル」モデルでは、Paragon Insightsは定期的にネットワークデバイスからデータを要求します。

Paragon Insightsは現在、2つの「プル」インジェストタイプをサポートしています。

• iAgent (CLI/NETCONF)

• Snmp

これらのプルモデルデータ収集( インジェスト)方法については、 Paragon Insightsデータインジェストガイドで詳しく説明しています。

ルール

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

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

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

• ルールの頻度が設定されている必要があります

• センサーを含めることはできません

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

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

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

センサー

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

• OpenConfig

  OpenConfig JTIセンサーの詳細については、を参照してください 。/../../../../../。

• Native GPB

  ネイティブGPB JTIセンサーの詳細については、を参照してください 。/../../../../../。

• iAgent

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

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

• syslog

  システムログ

• BYOI	独自のインジェストを持ち込む – 独自のインジェストタイプを定義できます。

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

• sFlow

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

異なるルールに同じセンサーが定義されている場合、センサーごとに 1 つのサブスクリプションのみが作成されます。OpenConfig センサーとネイティブ GPB センサーのセンサーパス、iAgent センサーのファイルとテーブルのタプルで構成されるキーは、関連付けられたルールを識別するために使用されます。

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

フィールド

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

ベクトル

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

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

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

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

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

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

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

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

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

変数

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

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

関数

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

トリガー

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

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

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

• より大きい - ある値が別の値より大きいかどうかを確認するために使用されます。

  • 戻り値: 真または偽

  • 構文: より大きい <LHS> <RHS> [時間範囲<範囲>]

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

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

• より大きいか等しい - より大きいか等しい - より大きい か等しいが、より大きいか等しいかをチェックする(>=)

• より小さい

  • 戻り値: 真または偽

  • 構文: より小さい <LHS> <RHS> [時間範囲<範囲>]

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

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

• より小さいまたは等しい - より小さい と同じですが、以下をチェックします(<=)

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

  • 戻り値: 真または偽

  • 構文: 等しい <LHS> <RHS> [時間範囲 <範囲>]

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

    when equal-to $buffer-utilization 0;

• 等しくない - 等しいと同じです が、負の条件(!=)をチェックします。

• exists–値自体を気にせずに、値が存在するかどうかを確認するために使用されます。デバイスから何らかの値が送信されている必要があることを意味します。

  • 戻り値: 真または偽

  • 構文: [時間範囲 <範囲>] <$var>存在します。

  • 例： //Has the device configuration changed? 

    when exists $netconf-data-change

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

  メモ：

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

  • 戻り値: 真または偽

  • 構文: <LHS> <RHS> [時間範囲<範囲>]

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

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

  例 1: 円記号 '\' をもう 1 つの円記号 '\' でエスケープする

  escape \ with one more \

  例 2: escape \ with one more \

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

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

  • 戻り値: 真または偽

  • 構文: 範囲 <$var> 最小 <最小値> 最大 <最大値> [時間範囲 <範囲>]

  • 例： //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;

• 少なくとも値による増加 - 値が前の値と比較して少なくとも最小許容率だけ増加しているかどうかを確認するために使用されます。最小許容増加率を定義するオプションのパラメーターを指定できます。指定しない場合、最小許容増加率はデフォルトで 1 に設定されます。

  • 戻り値: 真または偽

  • 構文：

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

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

  • 例： 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;

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

  • 戻り値: 真または偽

  • 構文：

    最大値による増加 <$var> [増分<連続するポイント間の増加の最大値>]

    [連続するポイント間の増加の増分<最大値<$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;

• 少なくともレートによる増加 - 連続する値間の増加率が少なくとも指定されたレートであることを確認するために使用されます。必須パラメーターには、値と時間単位が含まれ、これらは一緒になって最小許容増加率を示します。

  • 戻り値: 真または偽

  • 構文：

    この構文は、現在の値を以前の値と比較し、少なくとも値の割合で増加するようにします。

    <秒あたりの<$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 セクションで使用できる定義済みのアクションの一覧を次に示します。

• 次に

• ステータス

タグ 付け

リリース3.1.0以降、HealthBotはタグ付けをサポートしています。タグ付けにより、特定の条件が満たされたときに、フィールド、値、キーをParagon Insightsルールに挿入できます。詳細については、 Paragon Insightsのタグ付け を参照してください。

ルールのプロパティ

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

事前/事後のアクション

(オプション)Paragon Insightsリリース4.3.0以降、ルールで[アクション前]タブと[アクション後]タブを使用して、アクションエンジンワークフローで事前設定されたタスクを自動化できるようになりました。アクション エンジン ワークフローは、コマンド ライン コマンド、NETCONF コマンド、または実行可能ファイル内のコマンドとして実行できるタスクを実行するために使用されます。詳細については 、「アクションエンジンのワークフローについて 」を参照してください。

デバイスグループでプレイブックインスタンスを実行すると、Paragon Insightsはプレイブックのインスタンス化の開始時にプレアクションタスクを実行します。事前アクション タスクは、デバイス グループ内のデバイス構成を実行したり、デバイスの状態に関する通知を別のアプリケーションに発行したりする場合に便利です。複数のアクション前タスク間、およびアクション前タスクとルールの実行の間に依存関係はありません。ルールに複数のプレアクションタスクを設定すると、Paragon Insightはすべてのプレアクションタスクを同時に実行します。

Paragon Insightは、プレイブックインスタンスを停止したときにアクション後のタスクを実行します。オプションの設定であっても、アクション後タスクは、アクション前タスクを通じてデバイスに追加された追加の設定を削除するのに役立ちます。

アクション前タスクとアクション後タスクの両方に、一度だけ実行オプションがあります。デフォルトでは、一度だけ実行は無効になっています。一度だけ実行を有効にした場合、Paragon Insightはデバイスグループ内のデバイス上でタスクを1回だけ実行します。一度だけ実行は、以下の場合に適用されます。

• 同じデバイス グループでプレイブックの複数のインスタンスを実行する場合。

• 異なるプレイブックに一連のアクション前またはアクション後のタスクを含むルールを含め、同じデバイス グループでプレイブック インスタンスを実行する場合。

Paragon Insightは、アクション前タスクとアクション後タスクをデバイスグループ内のデバイスで実行する前に、重複タスクをチェックして解決します。重複は、プレイブックに含まれる多くのルールで特定のアクション前またはアクション後のタスクを構成するときに発生します。

ルールでアクション前タスクとアクション後タスクを設定するには、 Paragon Insightsのルールとプレイブックを参照してください。

デバイスごとに複数のセンサー

Paragon Insightsリリース4.0.0では、デバイスグループ内のすべてのデバイスに適用できる複数のセンサーをルールごとに追加できます。以前のリリースでは、ルールごとに 1 つのセンサーしか追加できませんでした。ルールごとの各センサーは、フィールド テーブルにデータを生成します。複数のルールに異なるセンサーを追加すると、ルールの数と同じ数のフィールド テーブルが作成されます。Paragon Insightsの1つのルールに複数のタイプのセンサー(OpenConfigやネイティブGPBなど)を追加すると、センサーからのデータは、エクスポートや視覚化が簡単な単一のフィールドテーブルに統合されます。複数のセンサー構成の GUI サポートは、今後のリリースで実装される予定です。

• ガイドライン
• Paragon Insights GUIでの複数センサーの設定
• ユースケース

センサーの優先順位

センサーからのデータ収集を効果的にするには、デバイス グループ内のデバイスが特定のセンサーを取り込み方法としてサポートする必要があります。古いバージョンのオペレーティング システムを実行しているデバイス グループ内の選択したデバイス、デバイス グループ内のさまざまなベンダーのデバイス、または同じベンダーのさまざまな製品 (ジュニパーの EX、MX、PTX ルーターなど) はすべて、デバイス グループにセンサーを適用する際の課題を引き起こす可能性があるシナリオです。このような場合は、デバイス グループ内の特定のデバイスと互換性のある別のセンサーを設定する必要があります。

Paragon Insightsリリース4.0.0では、センサーの優先順位を設定することができ、ベンダー名、オペレーティングシステム、製品名、プラットフォーム、リリースバージョンなど、ルールプロパティの各階層で異なるセンサーを設定できます。これにより、異種デバイスグループ内のマルチベンダーデバイスに適切なセンサを適用することが可能になります。リリース4.0.0では、Paragon Insights CLIを介してのみセンサーの優先順位を設定できます。Paragon Insightsリリース4.2.0以降、1つのルールに複数のセンサーを設定できます。詳細については、 Paragon Insightsのルールとプレイブックを参照してください。

図 1 は、それぞれ複数のセンサーを使用した 2 つのルールを示しています。ルールのプロパティがセンサーの優先順位に対して構成されていることを前提としています。

図 1: ルール におけるセンサーの優先順位の表現

ルール1のセンサー1がOpenConfigで、ルール2のセンサー4がiAgentで、デバイス1がJunosオペレーティングシステム(OS)を実行しているとします。ルールのプロパティでOpenConfigとiAgentがJunos OS階層のデフォルトセンサーとして設定されていた場合、デバイスグループに対してプレイブックが導入されると、デバイス1はセンサー1とセンサー4からデータを受信します。

• 始める前に
• センサーの優先順位の設定