Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

センサーの概要

Paragon Insightsは、ジュニパー、サードパーティデバイス、およびシステムログやSNMPなどの従来のネットワーク管理プロトコルを含む、さまざまなタイプのテレメトリセンサーからのデータを受け入れます。Paragon Insightsは、データ収集のプッシュモデルとプルモデルをサポートします。プッシュモデルでは、たとえば、トラップ通知を介してデバイスがテレメトリデータをParagon Insightsにプッシュします。プルモードでは、Paragon Insightsは定期的にデバイスをポーリングしてデータを探します。このガイドでは、サポートされている各取り込み方法について、プッシュモデルまたはプルモデルのどちらに該当するかでソートされた例を挙げて説明します。それぞれの説明とともに、特定の取り込みタイプを有効にするために必要なJunos OSバージョンとデバイス設定が記載されています。

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

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

Paragon Insightsは現在、5つのプッシュモデルセンサーをサポートしています。

「プッシュ」モデルは効率性と拡張性の点で好ましいアプローチですが、「プル」データ収集モデルが適切なケースもあります。2つの例としては、デバイスがJunosテレメトリインターフェイス(JTI)をサポートしていない場合や、サードパーティ製デバイスを管理している場合が挙げられます。プルモデルでは、Paragon Insightsはユーザー定義の間隔で定期的にネットワークデバイスにデータをリクエストします。

Paragon Insightsは現在、以下のプルモデルセンサーをサポートしています。

ネイティブGPB

ネイティブセンサーは、Googleプロトコルバッファ(GPB)を利用したジュニパー独自のデータモデルを使用します。デバイスは、UDPを介してテレメトリデータ(設定されている場合)をプッシュします。

デバイスは、パケット転送エンジンから、つまりラインカードから直接データをプッシュします。つまり、テレメトリデータは転送プレーンを介して送信されるため、コレクターはデバイスへの帯域内接続が必要です。

ネイティブフォーマットを使用するには、テレメトリデータの送信先などの設定でデバイスを構成します。データの収集を開始するように Paragon Insights を設定すると、ストリームはすでにサーバーに向かって流れています。

ネイティブセンサーの詳細については、 収集データのJunosテレメトリインターフェイスのエクスポート形式についてを参照してください

ネットフロー

Paragon Insightsは、他のParagon Insights取り込みメカニズムと連携したデータモデルを使用して、NetFlowの取り込み方法としてNetFlow v9およびNetFlow v10(IPFIX)をネイティブにサポートします。NetFlowは、IPトラフィック統計を収集するネットワークプロトコルであり、それをツールにエクスポートして分析することができます。NetFlow v9のデータエクスポート形式は 、RFC 3954で説明されています。NetFlow v10は正式にはIPFIXとして知られ、 RFC 7011で標準化されています。

Junosデバイスは、これらのプロトコルを使用してフロー監視とアグリゲーションをサポートします。Junos OSは、トラフィックをサンプリングし、フローテーブルを構築し、設定されたUDPポートを介してフローテーブルの詳細をコレクター(この場合はParagon Insights)に送信します。Paragon Insightsは受信したNetflowデータを受信し、v9またはv10として自動検出し、さらに処理します。

上記のように、ネットワークデバイスはパケット転送エンジンから、つまりラインカードから直接データをプッシュします。つまり、フロー データは転送プレーンを介して送信されるため、コレクターはデバイスへの帯域内接続が必要です。フローセンサーオプションを使用するには、フローデータの送信先などの設定でデバイスを構成します。データの収集を開始するようにParagon Insightsを設定すると、フローデータはすでにサーバーに向かって流れています。

Paragon Insightsは、フローテンプレートをメカニズムとして使用し、受信したフローデータを識別してデコードしてから、さらに処理するために送信します。Paragon Insightsには、NetFlow v9およびv10(IPFIX)用に事前定義されたフローテンプレートが用意されていますが、独自のテンプレートを定義することもできます。定義済みのテンプレートは、Junos OSが現在サポートしているテンプレートと一致します。たとえば、Junos OSテンプレートの ipv4-templateは、Paragon Insightsテンプレートの hb-ipfix-ipv4-templateに合わせて調整されます。Junos OSテンプレートで使用されるフィールドを表示するには、 インラインアクティブフロー監視についてを参照してください。

注:

NetFlowの現在の取り込み実装では、以下のフィールドタイプはサポートされていません。

  • エンタープライズ固有の要素のフィールド

  • 可変長フィールド

警告:

NetFlow取り込みでは、デバイスとParagon Insightsの間のネットワークパスにソースNATがないことを確認します。ネットワークパスに送信元NATが含まれている場合、受信したデバイス情報は正確ではありません。

一般的なワークフローには、Paragon InsightsへのNetFlow設定デバイスの追加、NetFlowテンプレートの設定、フローセンサーによるルールの設定、デバイスグループへのルールを含むプレイブックの展開が含まれます。

プレイブックを適用したら、デバイスの監視を開始できます。

  1. 左側のナビゲーション バー > [ネットワーク健全性の監視 ] をクリックし、[ デバイス グループ ] タブをクリックします。

  2. デバイスグループプルダウンメニューから、プレイブックを適用したデバイスグループを選択します。

  3. 監視するデバイスを1つ以上選択します。

  4. タイルビューの外部タイルには、前に設定したルールのパラメーターが含まれています。

sフロー

Paragon Insightsは、別のフローベースの取り込み方法としてsFlow(v5)をネイティブでサポートしています。

sFlowは、高速スイッチネットワークまたはルーティングネットワーク向けの統計サンプリングベースのテクノロジーです。必要に応じて、すべてのインターフェイスで同時にワイヤスピードでトラフィックを継続的に監視するようにsFlowを設定できます。

sFlowは以下を提供または支援します。

  • ギガビット速度での詳細で定量的なトラフィック測定

  • 転送の決定に関するインサイト

  • ネットワーク問題のトラブルシューティング

  • 混雑制御

  • セキュリティと監査証跡の分析

  • ルートプロファイリング

sFlowが上記で行うことはすべて、転送やネットワークパフォーマンスに影響を与えることなく実行します。sFlow の詳細については、以下を参照してください: RFC 3176、InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks.

統計サンプリングプロトコルとして、ジュニパーのsFlowエージェントは、ネットワークインターフェイス上のトラフィックとカウンターをサンプリングし、sFlowデータグラムを作成して、外部のsFlowコレクターに転送します。Paragon Insights はそのようなコレクターの 1 つです。

Paragon InsightsでsFlowパケットを設定する方法については、「 sFlow設定を設定する」を参照してください。

OpenConfig

OpenConfig形式を使用するには、デバイスをgRPCサーバーとして設定します。Paragon Insights がクライアントとして機能し、サブスクライブするセンサーを定義し、デバイスに向けてサブスクリプション リクエストを送信します。

gRPCを介してストリーミングされるデータは、プロトコルバッファ(GPB)エンコードメッセージ内のOpenConfigキーと値のペアでフォーマットされます。キーは、監視対象のデバイスのOpenConfigスキーマ内のシステムリソースのパスに対応する文字列です。値は、インターフェイスカウンターなどのシステムリソースの動作状態を識別する整数または文字列に対応します。OpenConfig RPCメッセージは、1つのメッセージに複数のインターフェイスカウンターを提供するなど、一括で転送できるため、メッセージ転送の効率が向上します。

OpenConfigセンサーの詳細については、 Junosテレメトリインターフェイス上のOpenConfigとgRPCについてを参照してください。

gNMIでエンコードされたOpenConfig RPC

gNMIでエンコードされたOpenConfigは、ネットワークデバイスをParagon Insightsがサブスクリプションリクエストを行うOpenConfigサーバーとして設定する必要があるという点で、OpenConfig RPCとよく似ています。ただし、gNMIは、Paragon Insightsが現在サポートしているよりも多くのサブスクリプションタイプをサポートしています。現在、Paragon Insightsは、SAMPLEモードでのgNMI STREAMサブスクリプションのみをサポートします。STREAM サブスクリプションは、サブスクリプション内で設定されたパスのセットに関連する更新を送信するために無期限に継続される、有効期間の長いサブスクリプションです。サンプル モード ストリームサブスクリプションには、 sample_intervalが含まれている必要があります。

gNMIを介してクライアントに返されるメッセージは、デバイスによってprotobuf、JSON、またはJSON-IETF形式でエンコードされ、一括で送信することはできません。このため、部分的には、gNMIでエンコードされたメッセージングは、gRPCでエンコードされたメッセージングよりも効率が低下します。

警告:
  • JSONまたはJSON-IETFの場合、デバイスは、階層全体またはサブ階層をJSONオブジェクトとして返すのではなく、JSONでエンコードされたリーフ値のみとしてgNMI更新を返すことを前提としています。

  • JSONまたはJSON-IETFでエンコードされた数値は、 RFC 7159 および RFC 7951に従って、Paragon Insightsによってfloat64、int64、またはstringのいずれかとしてデコードされます。OpenConfigルールに異なるタイプのフィールドが含まれている場合は、それに応じてフィールドタイプを変更することをお勧めします。

Junos OSとCiscoのデバイスは、gNMIでエンコードされたOpenConfigを使用して、Paragon Automationで管理できます。デバイスが一般的にgNMIをサポートしていない場合、またはSAMPLEモードのSTREAMサブスクリプションをサポートしていない場合、またはOpenConfigリクエストをサポートしていない場合、以下のエラーのいずれかが返されます。

  • 未実装

  • 利用不可

  • InvalidArgument

Junos OSまたはCiscoデバイスの場合、このエラーにより接続はOpenConfig RPCにフォールバックします。サードパーティ製デバイスの場合、エラーにより単に接続に失敗します。

gNMIでエンコードされたOpenConfigは、デバイスレベルまたはデバイスグループレベルで有効にできます。デバイスグループレベルで有効にすると、グループに追加されたすべてのデバイスがデフォルトでgNMIを使用します。デバイスレベルで有効(または有効になっていない場合)の場合、デバイスレベルの設定がデバイスグループレベルの設定よりも優先されます。

注:

初期接続中、gNMIデバイスはクライアントとの初期同期を実行しようとします。デバイスは、デバイスとコレクター(Paragon Insights)が同期するまで、データの連続ストリームを送信します。初期同期後、デバイスは設定されたレポートレートに基づいて通常のストリーミング操作を開始します。これにより処理負荷が大きくなるため、Paragon Insightsではこの機能はデフォルトで無効になっています。必要に応じて、デバイスグループまたはデバイスレベルで有効にできます。

gNMIの詳細については、 gRPCネットワーク管理インターフェイス(gNMI)を参照してください。

OpenConfigのデバイス設定

OpenConfigには以下が必要です。

  • Junos OSバージョン:16.1以降

    • OpenConfigセンサーには、JunosデバイスにOpenConfigパッケージとネットワークエージェントパッケージがインストールされている必要があります。これらのパッケージは、Junos OSリリース18.2X75、18.3以降に組み込まれています。16.1から18.2X75または18.2の間のリリースでは、OpenConfigパッケージとネットワークエージェントパッケージをインストールする必要があります。

      ネットワークエージェントパッケージをインストールする前に:

      • Junos OSリリース16.1R3以降をインストールします。

      • OpenConfig for Junos OS モジュールをインストールします。Webブラウザを使用して、ジュニパーネットワークスWebページにあるAll Junos PlatformソフトウェアダウンロードURLに移動します:https://www.juniper.net/support/downloads/。ネットワーク管理タブから、下にスクロールしてOpenConfigを選択します。ソフトウェアタブを選択します。OpenConfigパッケージ(FreeBSDがアップグレードされたJunos)を選択します。詳細については、「OpenConfig パッケージのインストール」を参照してください。

      • ジュニパーネットワークスデバイスにセキュアソケットレイヤー(SSL)認証証明書をインストールします。

        注:

        サーバーベースのSSL認証のみサポートされます。クライアントベースの認証はサポートされていません。

      有効なネットワークエージェントパッケージ名の例は次のとおりです。

      network-agent-x86-32-16.1R4.12-C1.1.tgz

      注:

      ネットワークエージェントパッケージの各バージョンは、Junos OSの1つのリリースでのみサポートされています。サポートされているJunos OSのバージョンは、ネットワークエージェントのパッケージ名に含まれるJunos OSリリース番号によって識別されます。

      32ビットバージョンと64ビットバージョンの両方のJunos OSまたはJunos OS Evolvedに、32ビットネットワークエージェントパッケージを使用します。

      ネットワークエージェントパッケージをダウンロードしてインストールするには、次の手順に従います。

      1. ジュニパーネットワークス Web ページ(https://www.juniper.net/support/downloads/)で、All Junos Platforms ソフトウェア ダウンロード URL に移動します

      2. ダウンロードするソフトウェアのJunos OSプラットフォームの名前を選択します。

      3. ソフトウェアのダウンロードページの右側にある リリース ドロップダウンリストから、リリース番号(ダウンロードするソフトウェアバージョンの番号)を選択します。

      4. ソフトウェアタブを選択します。

      5. ソフトウェアタブのツールセクションに移動し、リリース用のJunosネットワークエージェントパッケージを選択します。

      6. ジュニパーネットワークスの担当者から提供されたユーザー名(通常は電子メールアドレス)とパスワードを使用して、ジュニパーネットワークス認証スシステムにログインします。

      7. ソフトウェアをローカルホストにダウンロードします。

      8. ソフトウェアをジュニパーネットワークスデバイスまたは社内のソフトウェア配布サイトにコピーします。

      9. 動作モードからrequest system software add package-nameを発行して、新しいnetwork-agentパッケージをデバイスにインストールします。

        例えば:

        注:

        コマンドはデフォルトで validate オプションを使用します。このオプションは、デバイスが正常に再起動するようにソフトウェア パッケージを追加するための前提条件として、現在の設定に対してソフトウェア パッケージを検証します。これは、追加されるソフトウェアパッケージが別のリリースである場合のデフォルトの動作です。

      OpenConfigパッケージとネットワークエージェントパッケージがインストールされているかどうかを確認するには、次のコマンドを入力します。

      詳細については、「 Junosテレメトリインターフェイス上のOpenConfigとgRPCについて 」を参照してください。

    • ネットワークエージェントは、PPCプラットフォーム(MX104、MX80など)ではサポートされていません。

Device Configuration

以下のコマンドを入力してデバイスを設定します。

Paragon Automation GUIのデバイス設定でOpenConfigポートを設定するには、 デバイスの編集のデバイス編集ページテーブルにある編集可能なフィールドを参照してください。

Syslog

上記のJTI関連オプションに加えて、Paragon Insightsは、他の取り込みメカニズムと連携したデータモデルを使用して、データ収集方法としてシステムログもサポートしています。

デバイスは、UDPを介してsyslogメッセージ(設定されている場合)をParagon Insightsサーバーに、ルーターの管理インターフェイスを使用したルーティングエンジン(RE)を介してアウトオブバンドで、またはパケット転送エンジンを介してインバンド(つまりラインカードから直接)プッシュできます。

syslog形式を使用するには、syslogメッセージの送信先などの設定でデバイスを構成します。データの収集を開始するようにParagon Insightsを設定すると、すでにメッセージがサーバーに向かって流れています。

ジュニパーデバイスで使用されるsyslogの詳細については、 Junos OSシステムログの概要を参照してください。

syslogメッセージは、ヘッダー、角括弧内にKey-Value形式の構造化データ、およびログメッセージで構成されます。ヘッダーは、以下の情報で構成されています。

  • ログの優先度

  • ヘッダー形式上のSyslogプロトコル仕様のバージョン番号。

    現在、この数字は1です。

  • メッセージが生成されたときのタイムスタンプ(「Mmm dd hh:mm:ss」の形式)。

  • ホスト名は、syslogメッセージを送信したデバイスを識別します。

  • アプリケーション名

  • アプリケーションプロセスID

  • メッセージID

Paragon InsightsでSyslogを設定するための要件

Syslogの取り込みは、ルールのセンサーとして使用する前に、いくつかの設定が必要です。

  • パターン - パターンはsyslogイベントを識別します。監視するイベントごとにパターンを作成します。構造化イベントと非構造化イベントの両方にパターンを設定できます。

  • パターンセット - パターンを設定したら、パターンセットにグループ化します。ルール内でsyslogセンサー設定を定義する際に参照します。

Syslogの取り込みにパターンとパターンセットを設定する前に、syslogメッセージで共通のフィールドに注意してください。Paragon Insightsはこれらのフィールドを抽出し、自動的に生のテーブルに含めるため、ルール作成時に直接使用でき、パターンを設定する必要がなくなります。

これらの値の使用を説明するために、以下の syslog メッセージの例を考えてみましょう。

構造化 - <30>1 2019-11-22T03:17:53.605-08:00 R1 mib2d 28633 SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

同等の非構造化 - <30>Nov 22 03:17:53 R1 mib2d[28633]: SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

システム生成フィールド:

  • 「__log_priority__」 - syslogメッセージの優先度

    • 例では、 <30> は優先度を示します

  • "__log_timestamp__" - syslogメッセージ内のepcohのタイムスタンプ

    • 構造化された例では、 2019-11-22T03:17:53.605-08:00 は、タイムゾーンを示す -08:00 のエポックに変換されます

    • 非構造化の例では、設定のタイムゾーンを使用してエポックを計算します

  • "__log_host__" - syslogメッセージ内のホスト名

    • 例では、 R1 はホスト名を示します

  • 「__log_application_name__」 - syslogメッセージ内のアプリケーション名

    • この例では、アプリケーション名が mib2d です

  • "__log_application_process_id__" - syslogメッセージ内のアプリケーションプロセスID

    • この例では、 28633 がIDです

  • 「__log_message_payload__」 - メッセージ内のペイロード

    • 構造化された例 - “SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

    • 非構造化の例 - “SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

  • "Event-id" - パターンで構成されたイベントIDを示します

    • この例では、イベントIDSNMP_TRAP_LINK_DOWN

注:

上記で定義済みの名前を使用して新しいフィールドを定義しないようにしてください。

Syslogの取り込みの設定方法については、「 システムログの取り込みの設定」を参照してください。

サーバー監視センサー

Paragon Automationでは、サーバー監視センサーが、Paragonアプリケーションをホストしているサーバーと仮想マシンからデータを収集します。センサーは、サードパーティのプラグインであるNode Exporterを使用します。Node Exporterプラグインは、Paragon Automationのすべてのサーバークラスターにプリインストールされています。GUIでは、Paragon Automationクラスターにデプロイされたデフォルトのサーバーと仮想マシンは、 Paragon-Cluster デバイスグループに自動的に追加されるデバイスとして表されます。センサーは、サーバーと仮想マシンからデータを収集して、CPU、メモリ、ネットワーク、トラフィック、ディスク、ファイルシステムのメトリックを追跡します。出力を時系列データベースに書き込みます。

注:

ユーザーは、デフォルトの Paragon-Cluster デバイスグループを削除してはなりません。

Paragon Automationには、サーバーデータを監視するための以下のプレイブックが事前設定されています。

  • CPU使用率
  • ディスクの読み取りと書き込み
  • ファイルシステムのエラー、使用可能なバイト、使用バイト数
  • メモリ内の使用バイト数と使用可能なバイト数
  • ネットワーク内の受信および送信パケットの合計サイズ、受信および送信パケットのエラー、受信および送信されたマルチキャスト パケットの合計

Server Monitoring の取り込みを使用してルールを構成する場合、 表 1 に示したセンサーパスの一部を使用できます。

表1:サーバーメトリック
センサーパス の説明
/node/boot/time/seconds 各サーバーノードでの起動時間。
/node/cpu/seconds/total CPU がアイドルモード、システムモード、ユーザーモード、およびニースモードにとどまる合計時間 (秒単位)。
/node/disk/read/bytes/total 正常に読み取られたバイトの合計数。
/node/disk/read/errors/total ノード内の読み取りエラーの合計数。
/ノード/ディスク/読み取り/再試行/合計 失敗が発生した場合に、インジェストがディスクからの読み取りを試みた回数。
/node/disk/read/sectors/total 正常に読み取られたセクターの総数。
/node/disk/read/time/seconds/total ノードごとの読み取りを正常に完了するのにかかった合計時間。
/node/disk/reads/completed/total 正常に完了した読み取りの合計数。
/node/disk/write/errors/total 書き込みエラーの合計数
/ノード/ディスク/書き込み/再試行/合計 失敗が発生した場合に、インジェストがディスクへの書き込みを試みる回数。
/node/disk/write/time/seconds/total すべての書き込みを完了するのにかかった合計時間。
/node/disk/writes/completed/total ノードごとに完了した書き込みの合計数。
/ノード/ディスク/書き込み/バイト/合計 正常に書き込まれたバイトの合計数。
/node/disk/written/sectors/total 正常に書き込まれたセクターの総数。
/node/exporter/build/info 値「1」を持ち、ノードエクスポーターが構築されるバージョン、リビジョン、goバージョン、およびブランチを持つメトリック。
/node/filesystem/avail/bytes root以外のユーザーが使用できるファイルシステムのサイズ。
/node/filesystem/device/error ファイルシステムからデータを収集するときに発生する I/O エラーの数。
/ノード/ファイルシステム/ファイル ノードで許可されるインデックスノードの合計数。
/node/filesystem/files/free ノードで自由に使用できるインデックスノードの数。
/node/filesystem/free/bytes 予約済みブロックを除く、ユーザーが利用可能な空き領域(バイト単位)。
/node/filesystem/readonly ノード内のファイルシステムが読み取り専用としてマウントされているかどうかを示すデータ。
/node/filesystem/size/bytes すべてのファイルのサイズ(バイト単位)。
/ノード/ロード1 1 分ごとにキャプチャされる各サーバー/ホスト ノードの負荷。
/ノード/ロード15 15分ごとにキャプチャされる各サーバー/ホストノードの負荷。
/ノード/ロード5 5分ごとにキャプチャされる各サーバー/ホストノードの負荷。
/ノード/メモリ/アクティブ/バイト プロセスによってアクティブに使用されるメモリバイト。
/node/memory/compressed/bytes 圧縮メモリの合計サイズ。
/ノード/メモリ/空き/バイト ノードで自由に使用できるメモリの合計(単位:バイト)。
/node/memory/inactive/bytes プロセスによってアクティブに使用されていないメモリバイト。
/node/memory/swap/total/bytes ノードでスワップされたメモリの合計数。
/node/memory/swap/used/bytes ノードで使用されるスワップされたメモリの量。
/node/memory/swapped/in/bytes/total ノードのメモリにスワップされた合計数。
/node/memory/swapped/out/bytes/total ノード内のスワップアウトされたメモリの合計数。
/ノード/メモリ/合計/バイト ノード内のメモリの合計バイト数。
/ノード/メモリ/有線/バイト スワップアウトできないメモリ。
/ノード/ネットワーク/受信/バイト/合計 デバイスが受信したパケットの合計サイズ。
/node/network/receive/errs/total パケット受信時にデバイスで発生したエラーの合計数。
/ノード/ネットワーク/受信/マルチキャスト/合計 デバイスが受信したマルチキャストパケットの合計数。
/node/network/receive/packets/total デバイスが受信したパケットの合計数。
/ノード/ネットワーク/送信/バイト/合計 デバイスから送信されたパケットの合計サイズ。
/node/network/transmit/errs/total パケットの送信中にデバイスで発生したエラーの合計数。
/ノード/ネットワーク/送信/マルチキャスト/合計 デバイスによって送信されたマルチキャストパケットの合計数。
/node/network/transmit/packets/total デバイスから送信されたパケットの合計数。
/node/scrape/collector/duration/seconds 各コレクターがメトリックをスクレイピングするのにかかる時間。
/node/scrape/collector/success Node Exporterコレクターがターゲットをスクレイピングに成功した回数。
/node/textfile/scrape/error テキストファイルスクリプトを使用してターゲットをスクレイピングするときにノードエクスポーターで発生したエラー。
/ノード/時間/秒 エポック(1970年)以降のノード内のシステム時間を秒単位で表示します。
/node/uname/info Node Exporterがメトリックを収集するノードの名前。

モード、デバイスなどのタグは、メインメトリック(/node/cpu または /node/network)の下にリストされているすべてのメトリックに適用できるキーフィールドとして使用できます。

ルールでキーフィールドを設定する場合、 パス フィールドにキーフィールド名のみを記載できます。

  • /ノード/cpu/
    • cpu: CPUで使用可能なコア数。
    • mode: ノードのCPU使用率のタイプ(アイドル、システム、ユーザー、niceなど)。
  • /ノード/ディスク/
    • device: disk0、disk1、sda、sdb、sdc などのディスクの名前。
  • /ノード/ファイルシステム/
    • device: /dev/sda1、/dev/sda2、/dev/sdb1 などのディスクパス
    • fstype:ext4、NTFS(New Technology File System)、APFS(Apple File System)などのパーティションフォーマットの種類。
    • mountpoint:デバイス内のパスをマウントします。
  • /ノード/ネットワーク/
    • device: デバイスのインターフェイス名(wlan0、en0、docker0など)。

Server Monitoring の取り込みを使用してルールの例を設定するには、「Server Monitoring Sensor を使用したルールの設定」を参照してください

iAgent(CLI/NETCONF)

「プッシュ」データ収集方法のすべての利点の中、一部の操作情報と状態情報は CLI/VTY コマンドによってのみ利用できます。iAgentは、NETCONF/SSH機能を活用してデバイスへの接続、コマンドの実行、出力のキャプチャを行う機能をParagon Automationに提供することで、このギャップを埋めます。

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

iAgentを使用すると、Paragon Automationサーバーは、帯域内か帯域外かにかかわらず、利用可能なあらゆるネットワークインターフェイスを介してインバウンドSSHリクエストを開始します。そして、デバイスは要求されたデータで応答します(適切に設定されている場合)。

Paragon Automation Platformでは、iAgentの取り込みは、Arista Networks、Palo Alto Networks、Ciscoの他ベンダーデバイスに拡張されています。

iAgentセンサーまたはNETCONF接続を使用してテレメトリデータを送信するには、Junosデバイスを設定する必要があります。

iAgent(NETCONF)には少なくとも次のものが必要です。

  • Junos OSバージョン:11.4以降

  • 最小限必要なデバイス構成:

Paragon Automation GUIでインバウンド接続用のiAgentまたはNETCONFポートを設定するには、 表1を参照してください。

Paragon Automationは、Netmikoを使用して、選択したポートを介してサードパーティデバイスへのインバウンドSSH接続を確立します。デバイス情報を収集するために、Paragon AutomationはSSH経由でCLIコマンドを送信し、文字列BLOBを出力として受信します。次に、文字列 BLOB は TextFSM を介して解析され、NTC テンプレートを使用して JSON 形式に変換され、データベースに格納されます。デフォルトのテンプレートは 、/srv/salt/_textfsmにあります。ネットワークデバイス用 NTCテンプレート のGitHubリポジトリにアクセスできます。

存在しないテンプレートを必要とする上級ユーザーは、独自のテンプレートを作成し、設定>ルールページのルールファイルのアップロードボタンを使用してParagon Insightsにアップロードできます。ユーザー定義のテンプレートは、/jfit/_textfsmに保存されます。ファイルの末尾には .textfsm サフィックスが付いている必要があります。Paragon Automation Platformで定義済みルールをアップロードする方法については、「定義済みルールを追加する」を参照してください。

TextFSM は、iAgent の不可欠な部分である PyEZ のテーブル/ビュー機能に統合されています。

Example: PaloAlto Panos– Show Running Security Policy

Panos デバイスで実行中のセキュリティ ポリシーを確認するには、次のことを行う必要があります。

PyEZテーブル/ビューの定義

Panos デバイスに割り当てられた iAgent ルールで使用される PyEZ テーブルを定義する必要があります。以下の表定義にはビュー定義がありません。このため、 show running security-policy からの出力全体は、処理後にデータベースに保存されることになります。

(オプション)受信したデータの一部のみをParagon Automationに保存するには、同じファイル内にビューを定義します。このビューは、どのフィールドに注意すべきかをParagon Automationに指示します。

デバイスから出力を収集する

上記で定義したPyEZテーブル(またはテーブル/ビュー)を参照するiAgentルールを使用して、Paragon Automationコマンドをデバイスに show running security-policy 送信すると、次の出力が生成されます。

Paragon Automationデータベースで使用するJSONを生成する

デバイス構成では、ベンダーとして Palo Alto Networks が指定され、オペレーティング システムとして Panos OS が指定されているため、この例で使用する TextFSM テンプレートは次のようになります。

上記のテンプレートを Paragon Automation が使用して前に示した出力を解析すると、結果の JSON は次のようになります。

アウトバウンドSSH(デバイス開始)

Paragon Automationは、アウトバウンドSSHを使用してデバイスが開始するiAgent(NETCONF)接続もサポートしています。この設定により、Paragon Automationは接続を行うデバイスに対するクライアントとして機能します。このタイプの接続は、リモートデバイスが着信接続を受け入れることができない環境で有効です。JunosデバイスでアウトバウンドSSHが設定されている場合、既存のすべてのiAgentルールを使用できます。

注:

SSH接続を介したNETCONFは、Junosデバイスでのみサポートされています。

アウトバウンドSSHはデフォルトで無効になっています。アウトバウンドSSH接続を設定できます。

  • 単一のポートを設定して取り込みます。このポートは、すべてのデバイスグループで使用されます。

  • ポートを設定してデバイスグループにします。この設定は、取り込み設定よりも優先されます。

デバイスグループでアウトバウンドSSHを設定する場合、すべてのメンバーデバイスがParagon AutomationへのNETCONF接続を開始するTCPポート番号を入力する必要があります。管理CLIを介してデバイスでアウトバウンドSSHを無効にできます。デバイスグループでアウトバウンドSSHポートを設定するには、 デバイスグループを追加するのデバイスグループ設定のポートセクションを参照してください。

Paragon Automationは、すべてのデバイスグループからのiAgent(NETCONF)アウトバウンドSSH接続用に単一のTCPポートをサポートします。このポートは、取り込みレベルで設定できます。異なるデバイスグループで複数のTCPポートを開く必要がなくなり、単一のポートでネットワーク管理を簡略化できます。取り込み時にiAgentポートを設定するには、「 iAgentのアウトバウンドSSHポートを設定する」を参照してください。

異なるデバイスグループで管理されているデバイスを、複数のクライアントを設定して各クライアントが同じポートを持つことで、アウトバウンドSSHを介して接続できます。この場合、デバイスグループの数と同じ数のデバイスのコピーを作成する必要があります。各デバイスには同じポート番号が必要です。

例として、デバイスグループ dg1dg2 に設定されたデバイス r0(10.1.1.1)について考えてみましょう。同じアウトバウンド SSH ポートを介して 10.1.1.1 を両方のデバイス グループに接続するには、同じ IP でデバイス r1(10.1.1.1)をもう 1 つ作成し、dg2 に展開します。

また、それぞれのデバイスグループでこれらのポートに対してもParagon Automationを設定する必要があります。 図1 は、デバイスグループの構成例です。

図1:デバイスグループの設定Edit Device Group Configurationを編集する

以下のクライアント設定例を使用すると、デバイス10.1.1.1は、同じポートを持つ2つのアウトバウンドSSHクライアントを使用して、2つのデバイスグループに接続できます。

注:

この例の10.1.1.1は、Paragon Automation(ホスト)IPアドレスを示しています。

SNMP

SNMPは、ジュニパーネットワークスを含む多くのネットワークデバイスメーカーが自社のデバイスで使用するために提供している、広く知られ受け入れられているネットワーク管理プロトコルです。これはポーリングタイプのプロトコルで、SNMPを使用するように設定されたネットワークデバイスが、設定、診断、イベント情報をコレクターが利用できるようにします。これらの情報も適切に設定し、認証する必要があります。コレクターは、データを取得するために、get リクエストと呼ばれる特別に構造化されたリクエストを送信することでデバイスをポーリングします。

Paragon Automationは、標準のGETリクエストを使用してデバイスから統計情報を収集するセンサータイプとしてSNMPをサポートしています。Paragon Automationは、帯域内か帯域外かにかかわらず、利用可能なあらゆるインターフェイスを介してリクエストを行い、デバイスは要求されたデータを(設定されている場合)応答します。

Junos OSデバイスで使用されるSNMPについては、 Junos OSでのSNMP実装についてを参照してください。

また、Paragon Insightsは、SNMPの表形式オブジェクトとともにスカラーオブジェクトインスタンスもサポートしています。

  • SNMP オブジェクトは、ルール内でスカラー、テーブル、またはその両方の組み合わせにすることができます。SNMP取り込みを使用してルールを作成するときに、以下を追加できます。

    • スカラーフィールドのみ。

    • 表形式フィールドとスカラー フィールドの組み合わせ。

    • スカラーオブジェクトとしてクエリされたインデックスを含むテーブル形式の列。

      スカラーとしてクエリされる表形式の列には、ルールで表形式フィールドを設定する場合、インデックス番号がすべてのデバイスで同じオブジェクトを参照しないという制限があります。例えば、 IF-MIB::ifAdminStatus.16です。ifAdminStatus は、 IF MIB テーブルの列です。 IF-MIB::ifAdminStatus.16 は、インデックス16のテーブル列を参照します。

    • 表形式のフィールドのみ。
  • スカラーオブジェクトは、そのMIB名(例: JUNIPER-MIB::scalarObjectName)またはOIDとして識別されます。

  • Paragon Insights は、MIB定義の MAX-ACCESS プロパティをチェックして、特定のスカラーを検証します。

    MIB定義で読み取り専用、読み取り作成、または読み取り書き込みに設定されている MAX-ACCESS が見つかった場合、そのオブジェクトをスカラーとして照会できます。

スカラーオブジェクトを照会するための完全なパスは MIB-Name::table column name:index numberです。

例えば、 IF-MIB::ifInOctets:16 です。