New Relicのネットワーク監視(NPM)環境構築時の注意点

この記事は約8分で読めます。

みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。

New Relicでネットワーク監視もできるのですが、かゆい所に手が届かなかったりどう使ったらいいんだっけ？というのもあって、記事を公開されている人が少ない印象です。今回はNew Relicを使ったネットワーク監視の環境構築時の注意点について、解説していきたいと思います。

過去にNew Relicを使ったネットワーク監視（ICMP）の方法について記事にまとめていますので、よければこちらの記事もご一読ください。

blog.serverworks.co.jp

想定読者

New Relicを使ってネットワーク監視を行いたい方
Ktranslateの設定方法が分からない方
実際の運用シーンを見据えた設定方法を知りたい方

概要

New Relicはフルスタックオブザーバビリティを提供するプラットフォームとして有名ですが、オブザーバビリティを実現するにはシステムの外部出力から内部状態を推測できるようにする必要があります。New Relicは、アプリケーションだけでなく、インフラ、ネットワーク、ユーザー体験まで、システム全体を可視化します。今回はその中のネットワーク機能の設定方法についてフォーカスしてみました。

New Relicのネットワーク監視について

ネットワーク監視の種類と方法

New Relicのネットワーク監視（network monitoring）機能では、下記の図に記載されている通り、SNMPやネットワークフローデータ以外に、ICMPやSyslogのデータなどを扱うことができます。基本的にはひとつのKtranslateというサーバにて収集したデータをNew Relicに送信する流れとなりますが、設定方法や内部挙動の観点から基本的にはいくつかの機能に分けた別々のサーバとして構築していただく方がよい認識です。

※New Relic社のページより引用

その背景として、基本的な設定と設定後の挙動について見ていきましょう。

基本的な設定と設定後の挙動

New Relicのネットワーク監視ではKtranslateというNetwork observerbilityの仕組みを使用してデータ取得をおこないます。標準ガイドライン設定で構築する場合、Ktranslateサーバで使用する snmp-base.yamlの設定は下記のような内容となり、デバイスセクション（devices: {}）には何も記載がない状態のコンフィグとなっています。

また、discovery セクションに設定時に記載したSNMP機器を自動検知したいセグメントのCIDRを記載する項目があり、ここに記載したセグメントに対してディスカバリーをおこなうことで対象機器を自動的に探すような挙動を示します。その時に見つかったデバイスに関しては自動的にdevicesセクションに追加されるような挙動となります。

devices: {}
trap:
  listen: '0.0.0.0:1620'
discovery:
  cidrs:
    - 10.0.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

監視パターンの整理

ここで、ネットワーク機器の監視パターンを振り返ってみましょう。想定される監視パターンは下記の通りかと思います。

SNMP Polling
SNMP Trap
ICMP
Syslog
ネットワークフローデータ

この中で、ネットワークトラフィックの観点でパターン分類をしてみるとこうなります。

監視サーバ（Ktranslate） → ネットワーク機器
- SNMP Polling
  - 監視サーバがネットワーク機器に対して定期的に情報を取得
- ICMP
  - 監視サーバがネットワーク機器の応答を確認するためにpingなどのICMPパケットを送信
ネットワーク機器 → 監視サーバ（Ktranslate）
- SNMP Trap
  - ネットワーク機器が異常やイベント発生時に自発的に情報を送信
- Syslog
  - ネットワーク機器がログ情報を送信
- ネットワークフローデータ
  - ネットワーク機器がネットワークのトラフィック情報を送信

監視サーバ（Ktranslate）からネットワーク機器へ通信するパターンの注意点

ネットワークトラフィックの観点でのパターン分類を見ると、監視サーバ（Ktranslate）側からネットワーク機器側への通信が発生する監視内容として、SNMP Polling監視とICMP監視があります。SNMP Pollingの場合は標準機能で提供されている機器のディスカバリー機能を利用することができますが、ICMP監視の場合はdevices に監視内容を記載することで監視を行うことができる項目となります。

つまり、標準でデバイスのディスカバリー機能を有効にしている状況で監視対象の機器が多く、SNMP Polling監視とICMP監視の設定が混在している場合、ディスカバリー機能により自動登録された機器の情報と手動登録したICMP監視の設定が混在することになります。また、下記SNMP v3の参考設定を見て頂くとわかる通り、ひとつのデバイスの設定に数十行のコンフィグ設定が必要となります。

大半の設定については自動的に生成されるものか、テンプレートのように使いまわすことができるものとなりますが、デバイスが数十単位または100台単位となった場合、ひとつのコンフィグファイルが膨大になってしまうことが想定されるため、そのファイルのメンテナンス工数を考慮するなら最初から自動追加前提で運用する監視サーバ（Ktranslate）と手動追加で運用する監視サーバ（Ktranslate）は分けて管理する方が運用しやすいのではないかと推測しております。

※参考例（SNMP v3の設定）

devices:
  router_snmpv3__10.10.0.202:
    device_name: router_snmpv3
    device_ip: 10.10.0.202
    snmp_v3:
      user_name: $YOUR_USER_NAME
      authentication_protocol: $YOUR_AUTH_PROTOCOL
      authentication_passphrase: $YOUR_AUTH_PASSPHRASE
      privacy_protocol: $YOUR_PRIVACY_PROTOCOL
      privacy_passphrase: $YOUR_PRIVACY_PASSPHRASE
    oid: .1.3.6.1.4.1.9.1.544
    description: ""
    last_checked: 2021-11-09T18:14:59.907821489Z
    mib_profile: cisco-asr.yml
    provider: kentik-router
    user_tags:
      owning_team: core-networking
    discovered_mibs:
    - BGP4-MIB
    - CISCO-MEMORY-POOL-MIB
    - CISCO-PROCESS-MIB
    - IF-MIB
    - OSPF-MIB
    engine_id: "80:00:01:01:0a:14:1e:28"
    match_attributes:
      if_interface_name: "^Ten.*|^Gig.*"
      "!if_Alias": "[Uu]plink"

ネットワーク機器から監視サーバ（Ktranslate）へ通信するパターンの注意点

ネットワーク機器から監視サーバ（Ktranslate）へ通信する場合、監視対象のネットワーク機器側に監視サーバ（Ktranslate）のIPなどを登録する必要があります。ネットワーク機器が送信先にDNS名などを使えるような拡張がある場合はその名称を使用するとおもいますが、大半の機器はIPアドレスで指定することが想定されます。

参考までに、スモールビジネスなどの現場で使用されている CISCO Catalyst 1000 スイッチのサンプル設定をみても、コレクターはIPアドレスで定義されています。

Device#configure terminal
Device(config)#sflow agent ip 10.1.1.1
Device(config)#sflow collector id 1 ip 10.1.1.2 port 6343 datagram-size 1024
Device(config)#sflow collector id 2 ip 10.1.1.3 port 6343 datagram-size 1024

※設定情報の参照元サイト

www.cisco.com

この場合の注意点として、フローデータの送信先IPアドレスは変更があるとネットワーク機器側の設定修正が大変になるため、なるべく送信先は固定して運用することが望ましいということです。もともとNew Relicのネットワーク監視サーバ（Ktranslate）自体がECS FargateやEC2 on ECSなどの環境での動作がサポートされていませんが、仮に動作したからと言ってこうした環境でネットワークフローを受信するためのサーバやSyslogサーバなどを構築してしまった場合、コンテナ通信先のIPが固定できない不安定な環境に対して送信先を設定することになるため、コンテナが入れ替わった後にネットワーク機器を再設定しなければいけないというのは運用上問題が生じる可能性が高いということになります。

※固定IPが使用できない話は、ECS FargateのAmazon ECS タスクに静的 IP アドレスまたは Elastic IP アドレスを使用するにはに詳細が記載されています。

Fargate の Amazon ECS タスクに対する静的 IP アドレスまたは Elastic IP アドレスの使用 | AWS re:Post

New Relicのネットワーク監視(NPM)のベストプラクティス

ここまでは挙動の面からみた監視サーバ（Ktranslate）の管理単位となりますが、New Relicのベストプラクティスがどうなっているかを見てみましょう。展開に関する考慮事項として定義されているものは前項に記載したSNMP PollingやSNMP Trap、ICMP監視に加えて、Syslog監視とネットワークフローログ監視の内容になります。アーキテクチャ上の考慮事項としては下記のポイントがあります。

SNMP Polling、ICMP監視、SNMP Trapは一緒に動作可能
Syslog監視用サーバはSNMPやICMP監視、ネットワークフローログ監視のサーバとは別にする必要がある
ネットワークフローログ監視のサーバは収集されるフローテンプレート（NetFlow v5、NetFlow v9、IPFIX、および sFlow プロトコル）の種類によって分ける必要がある

基本的にネットワーク監視サーバ（Ktranslate）自体はコンテナ環境で提供されているため、例えばAWS環境の場合EC2上にインストールしたDocker環境で複数動作させることは可能です。ただし、ポート被りするようなSyslogサーバを複数同じEC2インスタンス上に構築するのは運用上望ましい構成ではありませんので、システム負荷などを加味しながら複数のEC2インスタンスに分けることが望ましいでしょう。

また、監視対象のネットワーク機器などが監視サーバ（Ktranslate）に内包しているMIB設定に対応しているかどうかもポイントになります。CISCOなどの大手ベンダーの場合は標準でMIBが対応しているため、SNMPディスカバリーのみで詳細に設定ファイルを作りこむ必要はありませんが、Yamahaなどの国内ベンダーの場合は標準で内包されているMIB情報が対応していないため、機器情報や監視対象のOIDを記載したプロファイル用のファイルを作成する必要があります。どのプロファイルが対応しているかは、下記レポジトリのプロファイル情報を参考に確認してください。

github.com