【最前線】ベンダーAPI連携の実装｜ネットワークオブザーバビリティエンジニアへの道

この記事では、ネットワーク監視の新たな潮流であるベンダーAPI連携について、その背景と具体的な実践方法を解説します。SNMP監視だけでは見えなかった世界を、New Relicが標準で提供するCisco Merakiとの連携機能を例に、その設定と価値を見ていきます。

はじめに

皆さん、こんにちは。「ネットワークオブザーバビリティエンジニアへの道」の第8回へようこそ。

これまでの連載で、私たちはPingやSNMPによる基本的な監視から、SyslogやFlow分析といった、より深い洞察を得るための技術を学んできました。しかし、Interop Tokyo 2025のレポートが示すように、ネットワーク監視の世界は今、大きな転換点を迎えています。

それは、SNMPを中心とした監視から、ベンダーが提供するクラウドプラットフォームとAPIを主軸とした監視へのパラダイムシフトです。今回は、その最前線であるベンダーAPI連携の世界に足を踏み入れ、次世代のネットワーク監視がどのようなものかを具体的に見ていきましょう。

なぜ今、SNMPだけでは足りないのか？〜監視のパラダイムシフト〜

長年にわたりネットワーク監視のデファクトスタンダードであったSNMPですが、いくつかの構造的な課題が顕在化しています。これに加えて、従来の設定・管理手法にも限界がありました。ネットワークエンジニアは、機器一台一台にSSHやTelnetでログインしてCUIで設定変更を行い、インベントリ情報はExcelで手動管理するのが日常でした。この手法は、管理対象が増えるほど膨大な工数がかかるだけでなく、設定ミスや管理情報の陳腐化を招く温床となっていました。

こうした背景から、主要ネットワークベンダーは、自社の機器をクラウド上で統合管理するためのプラットフォーム（Cisco MerakiやJuniper Mist AIなど）へと開発の主軸を移しています。

これらのプラットフォームは、従来の管理手法を根底から覆す、以下のような強力な価値を提供しました。

脱・手動管理と集中管理: Webブラウザから国内外に点在する数百台の機器を一元管理し、Excelでのインベントリ管理から脱却します。機器のモデル名、ファームウェアバージョン、稼働状況といったデバイスインベントリは常に最新の状態に保たれます。
広帯域トラフィックの正確な可視化: SNMPでは数秒でラップしてしまう広帯域トラフィックも、ベンダー独自の仕組みで正確に収集し、これまで測ることすらできなかった膨大なトラフィック量を初めて正しく可視化できるようになりました。
豊富な可視化機能: ネットワークに接続中のクライアント情報や、拠点間VPNの接続ステータスなど、SNMPだけでは到底得られなかったリッチな情報をグラフィカルに可視化します。

このように、ベンダーのクラウドプラットフォームは、単一ベンダー環境のネットワーク管理を劇的に効率化し、その製品群に関する「最初の情報集約点」となりました。

しかし、ITシステム全体で見ると、この進化は新たな課題を生み出しました。それが「ツールのサイロ化」です。

ネットワークチームはMerakiのダッシュボードを見て、サーバーチームは別の監視ツールを見る…という状況では、結局のところ、組織全体としてのオブザーバビリティ（可観測性）は実現されていません。

ここで登場するのがAPI連携です。API連携の本当の価値は、ベンダーのクラウドプラットフォームに集約されたこれらの豊富な情報を、プログラムを通じて外部のプラットフォーム（今回の場合はNew Relic）に取り込み、他の情報と統合することにあります。

設定例：New RelicとCisco Merakiの連携

ここでは、実際にNew RelicとCisco Merakiを連携させるための設定例をご紹介します。

この連携は、これまでの連載で利用してきたktranslateエージェントを通じて行います。既存のSNMP監視の設定ファイルに、Meraki APIからどの情報を取得するかを定義する設定を追記するだけで実現できます。

準備するもの

ktranslateエージェントの稼働環境
New Relic アカウント
Cisco Meraki アカウントとAPIキー

設定手順

Meraki側: APIキーの有効化と取得
まず、MerakiのダッシュボードからAPIキーを取得します。（手順省略）
ktranslate側: 設定ファイルにMerakiの設定を追記する
次に、ktranslateエージェントの設定ファイル（snmp-base.yaml）のdevices:セクションに、Meraki APIポーリング用の設定を追記します。

# snmp-base.yaml

devices:
  # (ここから追記)
  meraki_cloud_controller:
    device_name: meraki_cloud_controller
    device_ip: snmp.meraki.com
    provider: meraki-cloud-controller
    ext:
      ext_only: true
      meraki_config:
        # --- 必須設定 ---
        api_key: "ここにMerakiダッシュボードで生成したAPIキーを貼り付け"
        organizations:
          - "ご自身のMeraki組織名"
        
        # --- この記事で解説する機能に必要な設定 ---
        monitor_devices: true      # デバイスインベントリの取得
        monitor_clients: true      # クライアント情報の取得
        monitor_vpn_status: true   # VPNステータスの取得

        # --- 推奨設定 ---
        monitor_uplinks: true      # アップリンク情報の取得 (デフォルト有効)
  # (追記はここまで)

meraki_config:配下の設定が、Meraki APIからどのような情報を取得するかを制御する重要な部分です。

補足: meraki_configには、この記事で紹介した以外にも様々な詳細オプションがあります。詳しくは公式ドキュメント（詳細オプション）をご参照ください。
また、本記事では既存のSNMP用コンテナに設定を追記する方法を解説しましたが、公式ドキュメント（インストールガイド）にはMeraki専用のコンテナを単独で起動する方法や、Podmanを利用する場合のガイドも記載されています。ご自身の環境に合わせて、こちらもご参照ください。

3. ktranslateエージェントの再起動とデータ確認

設定ファイルを保存した後、ktranslateエージェントのコンテナを再起動します。数分後、New Relicの Integrations メニューにCisco Merakiタイルが表示され、データを受信中になっていれば成功です。

【重要】データをNew Relicに統合する"本当の価値"

私たちがAPI連携によってNew Relicにデータを統合する目的は、ベンダープラットフォームの機能を単に再現することではありません。それは、分断されたツールとチームの壁を取り払い、システム全体を横断した「統一された視点」を手に入れるためです。

サイロの解消と「シングル・ソース・オブ・トゥルース」の実現 ベンダープラットフォームで得られるようになったネットワークの詳細な情報と、アプリケーション、サーバーの全てのデータを同じ場所で、同じ時間軸で確認できるようになります。これにより、例えば「アプリケーションのエラーレートが急増したタイミングで、特定のアクセスポイントのクライアント数も急増していた」といった、これまで見えなかった相関関係を発見できるのです。
高度な分析とアラート NRQL（New Relic Query Language）を使えば、Merakiから収集したデータと、サーバーのCPU使用率やアプリケーションのレスポンスタイムといった他のデータを組み合わせて、自社のビジネスに合わせた独自のダッシュボードやアラート条件を作成できます。

ベンダープラットフォームがネットワーク管理を「線」のレベルまで引き上げたのに対し、API連携はその「線」をアプリケーションやサーバーといった他の情報と結びつけ、システム全体の「面」として捉えることを可能にします。

そして何より、ベンダー独自の仕組みでしか捉えられない正確な広帯域トラフィックデータを、他のテレメトリと相関分析するためには、API連携が唯一の手段となります。

まとめ

今回は、ネットワーク監視の最前線であるベンダーAPI連携について、Cisco Merakiを例にその価値を解説しました。

SNMP/CLI/Excel管理の限界と、ベンダーのクラウド＋APIへのシフトという大きな潮流を理解する。
広帯域ネットワークにおいて、正確なトラフィックデータを収集するためには、もはやSNMPだけでは不十分であり、ベンダーAPI連携が不可欠であるという現実を理解する。
API連携の本当の価値は、ネットワークデータを単独で見るのではなく、アプリケーションやサーバーのデータと統合し、システム全体を横断的に可視化することにある。

この潮流こそ、New Relicのようなオブザーバビリティプラットフォームが、単なるSNMP監視だけでなく、主要ベンダーとのAPI連携に力を入れる理由なのです。

次回予告

いよいよ本連載も最終回となります。次回は「総括: 明日から始めるネットワークオブザーバビリティ」と題し、これまでの9回で学んだ知識と技術を総動員します。

本記事に記載されている会社名、製品名、サービス名は、各社の登録商標または商標です。

By 伊藤覚宏, LeadTechnicalSupportEngineer

New Relic株式会社　リードテクニカルサポートエンジニア OSSの運用監視ソフトウェアの日本におけるテクニカルサポート、テクニカルトレーニングの立ち上げを行い、VMwareベースのクラウドサービス開発、AWSテクニカルサポート、クラウドアーキテクトを経て現職。テクニカルサポート、テクニカルトレーニング、運用コンサルを専門領域としてお客様の運用負荷軽減を目指す。得意分野は運用設計、クラウド設計、OSSソフトウェア。

本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。

780+ インテグレーションを導入し、スタック監視を無料で開始しましょう

詳細を見る

In this article