• English日本語한국어
  • ログイン今すぐ開始

ネットワークモニタリングのベストプラクティス

ネットワークモニタリングでは、New Relicはコンテナを使用してネットワークテレメトリーデータを収集します。このデータは、ネットワークパフォーマンスの監視、ボトルネックの特定、問題のトラブルシューティングに使用できます。システムアーキテクチャーとデプロイメントに基づいて、ネットワークコンテナを監視するためのベストプラクティスをご覧ください。

デプロイメントに関する考慮事項

このガイドでは、以下の要件を満たす一般的なネットワークアーキテクチャーについて説明します。

  • SNMPポーリングとSNMPトラップ収集
  • ネットワークデバイスからのSyslog収集
  • NetFlow v5、NetFlow v9、IPFIX、sFlowプロトコルでのネットワークフローの収集
  • 地理的に離れた複数のサイトのサポート

アーキテクチャーに関する考慮事項

コンテナのタスク

個々のコンテナのタスクに応じて、ネットワークデプロイメントの設計が決まります。従うべき基本ルールを以下に紹介します。

  • SNMPデータを収集するコンテナは、デフォルトでSNMPトラップを受信することもできます。
  • Syslogデータを受信するコンテナは、独自に実行する必要があります。
  • ネットワークフローデータを受信するコンテナは、収集されるフローテンプレートのタイプに基づいて分離する必要があります。

ネットワークフローとSyslogコンテナ

ネットワークフローとSyslogコンテナを使用する場合、カスタム設定ファイルは必要ありません。すべてのコンテナ設定は実行時にフラグを介して渡されるため、コンテナイメージのデフォルト設定は問題なく機能します。

ただし、設定ファイルにデバイスセクションのエントリを指定しない場合、New Relic APIに送信される結果には、各パケット内のIPアドレスからDNS経由で解決されたdevice_nameが使用されます。実行時にカスタムDNSサーバーの場所を指定できますが、タグ付けによる完全な制御のためには、flow_only設定をtrueに設定して、デバイスセクションに独自のエントリを指定する必要があります。これは、New Relic APIに送信される名前が、同じデバイスをポーリングするSNMPから送信される名前と一致するように、管理者が通常行います。

地理

最新のネットワークでは、SNMPおよびICMP(ping)プロトコルの優先順位が下がっているため、往復時間で遅延が長くなる可能性があります。タイムアウトによるポーリングシナリオの失敗を防ぐため、コンテナをターゲットデバイスの近くに作成する必要があります。

スケールの計算

個々のコンテナは通常、非常に小さなホストでホストされていますが、KTranslateコンテナ要件で概説されている最小限の要件があります。ただし、大規模なポーリングシナリオでは、ホストのCPUを拡張する必要がある場合があります。コンテナのCPUフットプリントを大きく拡張する主な理由は、タスクに提示される負荷の量です。このような状況では、通常、コストがかかるDockerホストの合計サイズを増やすよりも、複数のコンテナを実行して負荷分散する方が賢明です。

一般的なアーキテクチャーの例

この図は、次のようなネットワーキングアーキテクチャーの例を示しています。

  • 各地理的ロケーションには、データを収集してNew Relicへの転送に使用される独自のローカルコンテナがあります。

    • DC_01 (AMER)

      • ニューヨーク市のDC_01ロケーションに、サービスを提供する1つのホスト上の3つのコンテナ。
      • コンテナはSNMPポーリング、NetFlow v5収集、Syslog収集を処理します
      • 考慮事項:このホストにはクラスBのプライベートサブネット(/16)が含まれています。ジョブを完了するための時間を確保するには、検出ターゲットを管理可能なサブネットサイズに分割する必要があります。
    • OFFICE_01 (APJ)

      • オーストラリア、シドニーのOFFICE_01ロケーションに、サービスを提供する1つのホスト上の1つのコンテナ。
      • コンテナは、/24サブネットに対する検出を使用して、SNMPポーリングとSNMPトラップ収集を処理します。
    • DC_02 (EMEA)

      • アイルランド、ダブリンのDC_02ロケーションに、サービスを提供する1つのホスト上の3つのコンテナ。
      • コンテナはNetFlow v9、IPFIX、sFlow収集を処理します
      • 考慮事項:このホストにはさらに大きなクラスAプライベートサブネット(/8)がありますが、この場所では検出の必要がないため、ジョブを拡張する必要はありません。1秒あたりのフロー数によっては、将来的に追加のコンテナにスケールアウトする必要が生じる可能性があります。その場合は、Dockerホスト上の異なるポートをターゲットにするようにネットワークフローエクスポーターを設定するだけで済みます。

デプロイメントの維持

初期インストール後、ネットワーク監視オブザーバビリティフットプリントは、さまざまな技術を使用して維持できます。これには、設定ファイルの変更をAnsibleなどのツールと統合することや、バージョン管理をサポートするためのアーキテクチャーを中心としたGitOpsパイプラインの構築や、外部チームがレビューのために変更を送信できる「ゲスト」オプションが含まれます。

継続的なメンテナンスでの最も一般的なニーズは、ターゲットデバイスのリストを正確に保つことです。3つの主要な検出方法を使用して、これを実行できます。

自動検出は、KTranslateコンテナがIPアドレスや範囲のターゲットリストをスキャンし、活性プローブを実行し、MIB-2システムMIBの基本的なSNMPウォークを実行して、デバイスと既知のSNMPプロファイルの照合を試みるために使用されるプロセスです。

コンテナにはコンテナランタイムフラグ(-snmp_discovery_minおよび-snmp_discovery_on_start)が埋め込まれており、定期的なSNMP検出イベントのスケジュールを作成できます。これにより、設定ファイルのdiscoveryセクションのターゲットに対する検出ジョブが自動化され、新しいデバイスでファイルが自動更新され、変更を受け入れるためにサービスが更新されます。

利点

  • 既知のIP範囲とSNMPコミュニティ文字列のハンズオフ検出。

  • 各デバイスの適切なSNMPプロファイルへの自動相関。

  • 設定ファイルを破壊する可能性のある不適切な設定を防ぐための安全メカニズムが設けられている。

    欠点

  • 設定ファイルのdiscoveryセクションに、IPアドレスとSNMPコミュニティ文字列/V3認証の既存のターゲットリストが必要。

  • 大規模なサブネットはタイムアウトのリスクがある(/16以下を推奨)。

  • 設定ファイルでデバイス固有のuser_tagsを使用するチームは、新しいデバイスのタグが更新されるように追加作業が必要。

    これは、New Relic UIを通じてガイド付きインストールを実行する場合に見られる、ネイティブ設定パターンです。

    devices: {}
    trap:
    listen: '0.0.0.0:1620'
    discovery:
    cidrs:
    - 192.168.0.0/24
    ignore_list: []
    debug: false
    ports:
    - 161
    default_communities:
    - public
    default_v3: null
    add_devices: true
    add_mibs: true
    threads: 4
    replace_devices: true
    check_all_ips: true
    use_snmp_v1: false
    global:
    poll_time_sec: 300
    mib_profile_dir: /etc/ktranslate/profiles
    mibs_enabled:
    - IF-MIB
    timeout_ms: 3000
    retries: 0

    関連付けられたDocker実行コマンドは次のようになり、$CONTAINER_SERVICE_NAME$NR_LICENSE_KEY、および$NR_ACCOUNT_IDが置き換えられます。

    bash
    $
    docker run -d --name ktranslate-$CONTAINER_SERVICE_NAME --restart unless-stopped --pull=always -p 162:1620/udp \
    >
    -v `pwd`/snmp-base.yaml:/snmp-base.yaml \
    >
    -e NEW_RELIC_API_KEY=$NR_LICENSE_KEY \
    >
    kentik/ktranslate:v2 \
    >
    -snmp /snmp-base.yaml \
    >
    -nr_account_id=$NR_ACCOUNT_ID \
    >
    -metrics=jchf \
    >
    -tee_logs=true \
    >
    -service_name=$CONTAINER_SERVICE_NAME \
    >
    -snmp_discovery_on_start=true \
    >
    -snmp_discovery_min=180 \
    >
    nr1.snmp

手動検出では自動検出と同じメカニズムを使用しますが、より詳細な制御が可能になります。手動検出を使用すると、カスタムコンテナを個別に実行できます。つまり、いつでも実行でき、必要に応じて結果を確認して操作できます。これは、タグ付けが普及している環境や、ネットワークに新しいデバイスを追加する集中型チームからの制御が十分に行われている環境に推奨される方法です。これにより、時間がかかり、中断を伴う完全なサブネットスキャンの必要性が軽減されます。

利点

  • タグの装飾を含め、ターゲットと結果を完全に制御。

  • 監視対象フットプリントの範囲に含まれない可能性のあるデバイスを除外する。

  • 各デバイスの適切なSNMPプロファイルへの自動相関。

  • 設定ファイルを破壊する可能性のある不適切な設定を防ぐための安全メカニズムが設けられている。

    欠点

  • ネットワーク/SNMP接続が適切にテストされていることを確認するため、管理者は実稼働コンテナが実行されているのと同じDockerホストから、コンテナをオンデマンドで実行する必要がある。

  • 手動プロセス検出結果を実稼働設定ファイルに移動し、新しい設定をロードするために実稼働コンテナを再起動する必要がある。

    この検出方法は、KTranslateコンテナの元のデプロイメントオプションに従います。大まかに言えば、検出プロセスは次のとおりです。

  1. 最新バージョンのDockerイメージをローカルマシンにプルする。

  2. サンプルのsnmp-base.yaml設定ファイルをイメージからローカルマシンにコピーする。

  3. 設定ファイルを編集して、cidrsdefault_communitiesに必要な設定を使用してdiscovery検出セクションを更新する。

  4. アドホック検出ジョブを実行する短期間のコンテナを起動する。

  5. 設定ファイルで、結果として得られるデバイスに必要な変更を編集する。

  6. 検出設定ファイルからの新しいデバイスを実稼働コンテナ設定ファイルにコピーする。

  7. 実稼働コンテナを再起動して、新しい設定をロードする。

    この方法を使用するには、手動コンテナ設定の手順に従ってください。

最後のオプションは、検出プロセス全体をスキップし、手動でデバイスを実稼働設定ファイルに直接追加することです。標準の検出オプションによりデバイスがそのプロファイルに自動的に照合され、設定ファイルが正しくフォーマットされていることを確認するため、このパターンが実際に使用されていることはほとんどありません。

利点

  • デバイスの設定とタグの装飾を完全に制御する。

    欠点

  • 設定での設定ミスのリスクは中程度。この方法では、デバイスのシステムオブジェクト識別子(SysOID)を把握し、有効にするMIBを特定できるように、デバイスがターゲットにするプロファイルを理解している必要がある(すべて検出で自動化)。

  • 新しい設定をロードするには、同様に実稼働コンテナの再起動が必要。

    以下に、APC UPSを正常に監視するために必要なデバイス設定の例を示します。

    devices:
    ups_snmpv2c__10.10.0.201:
    device_name: ups_snmpv2c
    device_ip: 10.10.0.201
    snmp_comm: public
    oid: .1.3.6.1.4.1.318.1.3.27
    mib_profile: apc_ups.yml
    provider: kentik-ups
    user_tags:
    owning_team: dc_ops
    ...
    global:
    ...
    mibs_enabled:
    - ARISTA-BGP4V2-MIB
    - ARISTA-QUEUE-MIB
    - BGP4-MIB
    - CISCO-MEMORY-POOL-MIB
    - CISCO-PROCESS-MIB
    - HOST-RESOURCES-MIB
    - IF-MIB
    - OSPF-MIB
    - PowerNet-MIB_UPS

    重要

    global.mibs_enabled MIBのポーリングを開始するには、更新する必要があります。デバイスを追加する際は、関連するSNMPプロファイル全体で見つかった個別のMIB名のリストを使用して、この設定が更新されていることを確認する必要があります。

    必要な設定については、デバイスおよびグローバルブロックに関するドキュメントに詳しく説明されています。

Copyright © 2023 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.