イノベーションセンターの安井です。普段は全社検証網の技術検証、構築、運用を担当しています。 前回 OpenROADMに準拠した光伝送網の概要・構築編― APNテストベッドで探る技術と運用手法(その2) にて、OpenROADMアーキテクチャにもとづく分離型 ROADM（Reconfigurable Optical Add/Drop Multiplexer）の物理構成と構築の勘所を紹介しました。 今回はその続編として、物理的に構築したROADMノードをソフトウェアからどのように制御・運用しているかを紹介します。 APNテストベッドでは、区間ごとに異なる伝送速度のトランスポンダーを使い分けており、構成によっては複数ベンダーのトランスポンダーが送出した光を同一のROADMに収容する、いわゆるエイリアン波長環境になることもあります。本記事ではこうした環境を前提に、論理的な制御と運用の実践を扱います。 本記事で扱う内容です。 flex-gridによる波長管理の考え方と、異なる伝送速度が混在する環境での運用の工夫（内製Webアプリによる可視化・衝突検出） 内製CLIツールを使ったNETCONFによるROADM制御の実践（設定投入、パワー調整、障害切り分け） gNMIストリーミング監視の実運用で踏んだ落とし穴と、NETCONFベースのZabbix一元監視に収束した経緯 1. OpenROADMの論理構成の概要 OpenROADM Device Model 制御の全体像 2. flex-grid波長管理 flex-gridとは flex-gridの波長管理で考慮すること APNテストベッドでの運用の工夫 3. NETCONFによるROADM制御 OpenROADMにおけるNETCONFの役割 内製CLIツールの紹介 開発の背景 アーキテクチャ 操作の概要 論理設定の構造 パワー調整の実践 リモートからの障害切り分け 4. 監視・運用ツール連携 トランスポンダーとROADMの監視手法の違い gNMI Streaming Telemetryの実運用 ZabbixへのNETCONF統合 シェルフコントローラー（ROADM）の監視 トランスポンダーの監視 一元管理で何が変わったか 内製ツール群と今後の方向性 5. まとめ 1. OpenROADMの論理構成の概要 IPルーターでは「スロット/ポート」という比較的単純な構造で装置が管理されますが、光伝送装置ではPart 2で見たように物理的な構成がより複雑です。 OpenROADM は、この複雑な物理構成を OpenROADM Device Model としてソフトウェアから操作できる形に整理しています。 OpenROADM Device Model Part 2では、Degree（方路）やSRG（Shared Risk Group）といった物理的な機能ブロックと、それらを構成するWSS（波長選択スイッチ）、増幅器、OCM（光チャネルモニタ）などの回路パックについて紹介しました。 これらの物理構成要素をソフトウェアから操作するために、OpenROADM MSAではYANGと呼ばれるデータモデリング言語で装置の構成や状態を定義しています。 IPルーターであれば、CLIやSNMP MIBで設定や状態にアクセスするのが一般的です。光伝送装置ではこれに相当する仕組みとして、YANGとNETCONFの組み合わせが使われます。 YANGはデータの構造を定義する言語、NETCONFはその構造に基づいて装置と通信するプロトコルです。 OpenROADM MSAはこのYANGモデルを標準化することで、ベンダーが異なっても共通の手順で装置を制御できるようにしています。 OpenROADM Device Modelでは、装置の内部構造を大きく3つのレイヤで表現しています。 レイヤ 内容 具体例 物理層 筐体やカード、ポートの物理構成 Shelf、Circuit-Pack(回路パック)、Port 論理層 ROADMとしての機能ブロック Degree(方路)、SRG(波長Add/Drop部) 接続層 論理的な光パスの設定 Interface、Roadm-Connection(クロスコネクト) たとえば、Part 2で紹介したDegree（方路）は、YANGモデル上では degree リストとして定義されており、そのDegreeを構成するWSS、増幅器といった回路パックや外部ファイバの接続ポートが紐づけられています。 同様にSRGは shared-risk-group リストとして、Add/Drop用のポート群を管理しています。 制御の全体像 OpenROADMネットワークの制御は、SDNコントローラーが各ノードに対してNETCONF（ネットワーク機器の設定や状態をXMLベースで操作するプロトコル）を用いたDevice Modelの操作により行われます。 SDNコントローラー ↓ NETCONF (port 830) 各ROADMノード (Device Model) ├─ 設定: クロスコネクト作成、パワー調整 └─ 状態取得: 光パワー計測値、アラーム 本記事ではこのうち、ノードレベルでNETCONFによる直接操作に焦点を当てます。コントローラーによるネットワーク全体の自動制御（パス計算や自動プロビジョニング）については範囲外とします。 まず、ROADMノードに設定する波長の割り当て管理について見ていきます。 2. flex-grid波長管理 flex-gridとは WDM（Wavelength Division Multiplexing：1本の光ファイバに複数の波長の光信号を束ねて伝送する技術）では、各波長にどれだけの周波数帯域を割り当てるかを決める必要があります。 従来のfixed-grid方式では、ITU-T G.694.1勧告に基づき50 GHzまたは100 GHz間隔で波長チャネルが等間隔に配置されていました 1 。 100Gの信号も400Gの信号も同じ幅のスロットを占有するため、低速な信号では帯域が余り、高速な信号ではスロットに収まらないという問題がありました。 flex-grid方式では、同じITU-T G.694.1勧告の拡張として、中心周波数を6.25 GHz刻みで配置し、スロット幅を12.5 GHzの整数倍で柔軟に設定できます。 信号の伝送速度や変調方式に応じて、必要十分な帯域幅を割り当てられるのが利点です。 項目 fixed-grid flex-grid スロット幅 50 GHz or 100 GHz固定 12.5 GHz x N(可変) 中心周波数の刻み 50 GHz or 100 GHz 6.25 GHz 波長配置 等間隔 信号帯域に応じて柔軟 帯域効率 低速信号で無駄が生じやすい 高い 管理の複雑さ シンプル スロット割り当て管理が必要 実際にどの程度帯域幅が異なるかを、代表的なプロファイルで整理します。 プロファイル データレート ボーレート 占有帯域の概算 実運用でのスロット幅目安 OpenROADM oFEC-31.6Gbd 100G 31.6 Gbaud 約33〜38 GHz 37.5〜50 GHz OpenROADM oFEC-63.1Gbd 400G 63.1 Gbaud 約66〜76 GHz 75〜87.5 GHz OIF 400ZR 400G 59.84 Gbaud 75/100 GHz向けを規定(※) 75〜100 GHz OpenZR+(Rev3.0) 代表 400G 60.14 Gbaud 75 GHz運用が中心 75〜100 GHz OpenZR+(Rev3.0) 拡張 400G 80.18 Gbaud 100 GHz前提 100 GHz ※ 400ZRは100 GHz DWDM、75 GHz DWDM、単波長無増幅の各アプリケーションを規定しています。 占有帯域の概算にはOpenROADM v9.0で明記されている Bandwidth = Baud rate × (1 + α) を用いています。αはロールオフ係数と呼ばれ、信号スペクトルの裾の広がり具合を示す値で、0.05〜0.2の範囲です。 100Gは37.5 GHz境界に近く、400G（63.1Gbaud）は75 GHz境界に近いため、実運用ではフィルタリングペナルティ（WSSなどの光フィルタを通過する際に生じる信号劣化）や隣接波長干渉を見込んで余裕のあるスロット幅を選ぶのが一般的です。 同じ400Gでも、プロファイルによってスロット幅が75 GHzで済む場合と100 GHz必要な場合があります。APNテストベッドでは、機器導入時にプロファイルごとのスロット幅要件を確認し、波長管理ツールのプリセットに反映しています。 flex-gridの波長管理で考慮すること 導入で触れたように、APNテストベッドでは異なる伝送速度やベンダーの機器が混在するエイリアン波長環境を扱っています。こうした環境では、flex-gridの波長管理にいくつかの考慮が必要になります。 まず、前節の表のとおり伝送速度やプロファイルが異なれば占有帯域幅も大きく変わります。同一のトランスポンダーでも伝送モードを変えれば占有帯域幅が変わるため、波長配置では実際の占有帯域幅に応じたスロット幅を個別に割り当てる必要があります。 また、隣接する波長同士の干渉を防ぐために、波長間には一定の未使用帯域（ガードバンド）を確保します。 flex-gridでは12.5 GHz単位のスロット範囲内で自然とガードバンドが生まれる場合もありますが、異なるスペクトル特性を持つ信号が隣接する場合には追加の考慮が必要です。 APNテストベッドでの運用の工夫 flex-gridでの波長管理はfixed-gridと比べて考慮事項が増えます。 APNテストベッドでは、波長の割り当てにあたって管理を単純にするためのルールを設けています。 CDC（Colorless, Directionless, Contentionless）機能により、波長やポートの制約なく任意の方路にAdd/Dropできます。 技術的には同一波長を異なる方路で重複使用することも可能ですが、波長リソースに余裕があるため全方路で波長が重複しないよう割り当てています。 また、新規波長は基本的に周波数の低い側から詰めていく方針としています。 ただし実際の運用では、PoC（実証実験）対応や経路の異なるパスの追加など、さまざまな要件で波長が追加されます。 複数の帯域に分かれて波長が配置されているのが現状です。 APNテストベッドでは機器配置やケーブリングの管理にNetBoxを活用していますが、NetBoxは波長パスの管理を想定した機能を持っていません。 flex-gridのスロット割り当てや衝突チェックは既存のインフラ管理ツールではカバーできず、当初はスプレッドシート等で補っていました。 しかし波長数が増えてくると空きスロットの把握や衝突チェックに限界が出てきます。 そこで、flex-gridの波長割り当て状況を視覚的に管理するWebアプリケーションを内製して運用しています。 画面上にはCバンドおよびLバンドの全帯域がグラフ表示され、割り当て済みの波長が色付き矩形で並びます。 グラフ上をクリックすると中心周波数がフォームに自動入力され、スロット幅は伝送速度に応じたプリセット（37.5/50/75/87.5/100 GHz等）から選ぶ形です。 新規波長が既存の波長と周波数帯域で重複する場合は追加前にエラーが出るので、手作業での見落としを防げます。 波長ごとにA/Z端のノード名、装置名、インターフェース、中継ノードも記録しており、波長割り当てとパス情報を一箇所で管理しています。 波長の配置が決まったら、ROADMノードに設定として反映します。 3. NETCONFによるROADM制御 OpenROADMにおけるNETCONFの役割 OpenROADM MSAでは管理プロトコルとしてNETCONF（RFC 6241）を採用しており、YANGモデルに基づいてクロスコネクト（波長経路）の設定、増幅器のパワー調整、OCM計測値やアラームの取得といった操作が可能です。 ベンダー提供のコントローラーを使用して管理することもできますが、パワーの確認やちょっとした設定変更といった日常的な作業では、CLIから直接操作する方が手っ取り早い場面も多くあります。 一方、コントローラーを介さずにNETCONFで直接操作する場合は、設定変更のたびにXMLファイルを作成・送信する必要があり、この運用は煩雑で難度も高いものでした。 内製CLIツールの紹介 開発の背景 APNテストベッドで採用しているROADM装置はOpenROADM準拠でNETCONFによる設定が可能ですが、手軽に操作できるCLIは用意されていません。 そこで、NETCONFの各種操作をコマンドとして抽象化し、対話的に実行できるシェルを開発しました。 アーキテクチャ 制御パスは以下のとおりです。拠点ごとにシェルフコントローラーがNETCONFのエンドポイントとなり、配下のDegree筐体やSRG筐体を制御します。 オペレータ └─ 内製CLIツール └─ NETCONF (port 830) └─ シェルフコントローラー ├─ Degree筐体 └─ SRG筐体 操作の概要 コマンド体系はネットワーク機器のCLIに馴染みのある方であれば直感的に操作できるよう設計しています。 set ~ で設定を追加、 delete ~ で設定を削除、 show ~ でステータス確認 TABでコマンド補完、 ? でコマンドヘルプ show configuration でcandidate configを表示、 show configuration running でrunning configを表示 candidate configに加えた変更は commit でrunning configに反映 commit discard でcandidate configの変更を破棄 操作例を紹介する前に、OpenROADMのインターフェース階層を整理しておきます。 本環境のROADM（MWポート側）では、光チャネルは次の順で構成され、上位インターフェースが supporting-interface-list で下位を参照します。 OTS (Optical Transport Section) │ 物理ポート/ファイバ区間 └─ OMS (Optical Multiplex Section) │ WDM多重信号の層 └─ MC-TTP (Media Channel Trail Termination Point) │ 通過可能なスペクトル帯域を定義（min-freq / max-freq） └─ NMC-CTP (Network Media Channel Connection Termination Point) 1チャネル分を定義（frequency / width） 波長の開通時は、NMC-CTPを作成して中心周波数と帯域幅を設定し、そのNMC-CTPを roadm-connection の src-if / dst-if に指定して光クロスコネクトを作成します（双方向通信では通常2本作成）。 以降の操作例に出てくるインターフェース名にはこの階層が反映されています。 なお、Add/Drop側のポート種別によっては中間レイヤを省略し、NMC-CTPがポート直下に置かれる実装もあります。 show pm current コマンドでは各ポートの光パワー計測値をリアルタイムに確認できます。 >show pm current interface: DEG-1-3-cp-mw-out-nmc-ctp-tx-191.49375 opticalPowerOutput, direction=tx 15min: -5.90 dBm 24Hour: -5.90 dBm wssAtt, direction=tx 15min: 4.70 dB 24Hour: 4.70 dB interface: DEG-1-3-cp-mw-out-nmc-ctp-tx-194.30000 opticalPowerOutput, direction=tx 15min: -4.00 dBm 24Hour: -4.00 dBm wssAtt, direction=tx 15min: 3.30 dB 24Hour: 3.30 dB (以下省略) 出力にはインターフェース名に波長の中心周波数（191.49375 THz等）が含まれており、各波長のパワーレベルやWSS減衰量を個別に確認できます。 show interfaces コマンドではNMC-CTPインターフェースの一覧と、各インターフェースに設定されたfrequencyとwidthを確認できます。 >show interfaces name: DEG-1-3-cp-mw-in-nmc-ctp-rx-191.49375 type: networkMediaChannelConnectionTerminationPoint admin: inService oper: inService frequency: 191493.75 GHz width: 75.00 GHz (以下省略) 論理設定の構造 このツールで設定する論理構成は、前章で紹介したOpenROADM Device Modelの3レイヤ（物理層・論理層・接続層）に対応しています。 上位の設定が下位に依存するため、物理層から順に積み上げていく必要があります。 たとえば新しい方路を追加する場合は、まず物理層としてShelfやCircuit-Packを登録し、次に論理層としてインターフェースを作成してポートを有効化します。 波長の開通では、接続層としてクロスコネクトを設定することで経路が確立されます。 設定の順序を誤ると依存関係でエラーになるため、この積み上げの構造を把握しておくことが運用上のポイントです。 パワー調整の実践 ROADMノード内の増幅器やVOA（可変光減衰器）を用いてパワーを調整する作業は、日常的に発生する運用の1つです。 パワー調整が必要になる場面としては、新しい波長を追加したとき、トランスポンダーを交換して出力パワーが変わったとき、ファイバ経路を変更したときなどがあります。 内製CLIツールを使った調整の基本的な流れは以下のとおりです。 show pm current でOCMの計測値を確認し、各波長の現在のパワーレベルを把握する 目標パワーとの差分を確認する set コマンドでOTSインターフェースのspan-loss値（隣接ノード間のファイバ区間損失の設定値）を変更し、 commit で反映する。span-loss-receiveが受信側、span-loss-transmitが送信側にそれぞれ対応し、ROADMはこの値に基づいて増幅器やVOAを自動調整する 再度 show pm current で計測値を確認し、目標値に収束するまで繰り返す ポイントは、一度に大きくパラメータを変えるのではなく段階的に調整することです。 EDFA 2 は全波長を同時に増幅するため、ある波長のパワーを変えると他の波長にも影響が及びます。 また、OCMの計測値が安定するまでには若干の時間を要するため、変更のたびに値が落ち着くのを待ってから次の調整に進む必要があります。 実例として、ある区間（拠点A～拠点B）のパス開通時に行ったspan-loss調整を紹介します。 開通直後、拠点B側のトランスポンダーの受光レベルが-20.76 dBmと低めでした。 まず show pm current で両端のOTSインターフェースの光パワーを確認します。 # 拠点A >show pm current interface: DEG-1-5-cp-mw-out-ots-tx # 拠点B向け送信 opticalPowerOutput, direction=tx 15min: 3.40 dBm interface: DEG-1-5-cp-mw-in-ots-rx # 拠点Bから受信 opticalPowerInput, direction=rx 15min: -13.60 dBm # 拠点B >show pm current interface: DEG-1-3-cp-mw-out-ots-tx # 拠点A向け送信 opticalPowerOutput, direction=tx 15min: 5.90 dBm interface: DEG-1-3-cp-mw-in-ots-rx # 拠点Aから受信 opticalPowerInput, direction=rx 15min: -22.70 dBm ここで着目したのは方向によるパワー差です。span-lossは対向局のOTS送信パワーと自局のOTS受信パワーの差から算出します。拠点A→Bでは送信3.40 dBmに対し受信-22.70 dBm（差は約26 dB）、逆方向の拠点B→Aでは送信5.90 dBmに対し受信-13.60 dBm（差は約19.5 dB）と、方向でずいぶん違います。2芯のファイバなので芯ごとに損失が多少異なることはありえますが、ここまでの差はROADM側のspan-loss設定が実態と合っていない可能性があります。 前述のとおりROADMの増幅器はspan-loss設定値に基づいてゲインを自動調整するため、設定値が実際の損失と乖離していると増幅が不適切になります。そこで show interfaces でOTSインターフェースのspan-loss設定値を確認したところ、拠点A側は20 dBに設定されていたのに対して拠点B側は仮の15 dBのままでした。 まずは拠点A側に合わせて、拠点B側のspan-loss-receiveを20 dBに揃えます。 >set interface DEG-1-3 ots span-loss-receive 20 >commit commit 後、トランスポンダーの受光レベルが-20.76 dBmから-16.86 dBmに改善しました。 さらに計測値から再計算した約25 dBへ設定したところ-15.83 dBmまで上がり、OSNR 3 も26.0 dBから28.2 dBに向上しました。 受信側が安定したので、対向の拠点A側でもspan-loss-transmitを同様に合わせて本対応は完了です。 パラメータを少しずつ変えながら計測値の変化を見て収束させていく、地道な作業です。 リモートからの障害切り分け show pm current はパワー調整だけでなく、障害の切り分けにも使えます。 別の区間のパス開通準備中に、拠点C側で show pm current を確認したところ、OSC（Optical Supervisory Channel：光監視チャネル）の入力パワーが検出されておらず、対向から信号が届いていない状態でした。そこで対向の拠点Dに接続して同じコマンドを実行すると、OTS-TXの送信パワーも出力されていないことがわかりました。 # 拠点C（受信側）— OSC入力に信号なし >show pm current port: DEG-1-5-cp-osc-cp-osc-in opticalPowerInput, direction=rx 15min: 0.00 dBm # 拠点D（送信側）— OTS-TXが出力していない >show pm current interface: DEG-1-5-cp-mw-out-ots-tx opticalPowerOutput, direction=tx 15min: 0.00 dBm opticalReturnLoss, direction=tx 15min: 28.00 dB なお、ここで表示されている0.00 dBmは本来1 mWを意味する値ですが、装置によっては信号未検出時にこの値を返すことがあります。 0.00 dBmがきれいに並んでいる場合は信号が来ていない可能性を考慮すべきです。 実際の判断ではアラームの有無や対向ノードのPM値と併せて確認します。 設定は正しく入っていたので物理的な問題と判断し、現地での確認へ進むことにしました。リモートから両端のPM値を見比べるだけで「どちら側の、どのポイントで光が止まっているか」を数分で絞り込めます。 拠点が遠方の場合、闇雲に現地へ行く前にこの切り分けができると助かります。 4. 監視・運用ツール連携 トランスポンダーとROADMの監視手法の違い Part 1 ではトランスポンダーの監視にgNMI + OpenConfigを活用していることを紹介しました。一方、ROADMの監視はNETCONF + OpenROADM YANGモデルが中心となります。 現在の構成を以下の表にまとめます。 項目 トランスポンダー ROADM(シェルフコントローラー) 管理プロトコル gNMI + NETCONF(2系統並行) NETCONF データモデル OpenConfig OpenROADM YANG gNMI取得方式 Streaming(ON_CHANGE) - NETCONF取得方式 ポーリング(get) ポーリング(get/get-config) 主なメトリクス 光パワー(in/out)、Pre-FEC BER 波長別光パワー(OCM)、アンプゲイン、アラーム Zabbix連携 ssh.run(port 830) + LLD ssh.run(port 830) + LLD アラート通知 Cloud Monitoring + Zabbix → Slack Zabbix → Slack 両者に共通しているのは、最終的にZabbix上でNETCONF経由の監視に収束した点です。そこに至るまでの経緯を含めて紹介します。 gNMI Streaming Telemetryの実運用 Part 1で紹介したgNMI + OpenConfigによるトランスポンダー監視を、実際にAPNテストベッドに展開しました。構成の概要は以下のとおりです。 トランスポンダー └─ gNMI (ON_CHANGE) └─ gNMIc (GKE Autopilot上) └─ Prometheus ├─ Grafana (光パワー・BERの可視化) └─ Cloud Monitoring → Slack (閾値アラート) Google Kubernetes Engine（GKE） Autopilot上にgNMIc（gNMIコレクター）をデプロイし、トランスポンダーから値が変化したときだけデータを送信するON_CHANGEモードで光パワーやPre-FEC BERなどのメトリクスをストリーミング収集しています。 収集したデータはPrometheus経由でGrafanaダッシュボードによる可視化とCloud Monitoringへ集約し、閾値超過時にSlackへアラート通知しています。 gNMI自体は動作しているのですが、実運用に載せてみると想定外の問題がいくつか出てきました。 gNMIサーバ側の実装差異やコレクター側の構成など複数の要因から一部のトランスポンダーでoptical_channelのメトリクスが取得できない GKE Autopilot上でgNMIcのPodがScaleDown対象となり、ストリーミング接続の切断を繰り返すループに陥った。 KubernetesのPod QoSクラスの調整で解消したが、マネージドKubernetes環境で常時接続型のワークロードを安定稼働させるにはそれなりのチューニングが必要だった ON_CHANGEモードでは値に変化のない間データは送信されず、Prometheusの時系列が期限切れで消失する（これについてはgNMIcのexpiration設定で対処） gNMIによるストリーミング監視はリアルタイム性に優れる一方、End-to-Endで安定稼働させるには装置側・コレクター基盤側の双方で作り込みが必要でした。 限られた工数の中で監視基盤の信頼性を優先し、NETCONFによるポーリング監視を並行して構築して2系統による補完運用に移行しています。 ZabbixへのNETCONF統合 ROADMとトランスポンダーの両方を、Zabbix標準機能のみでNETCONF監視する仕組みを構築しました。 NETCONFはSSHの netconf サブシステム上で動作するプロトコル（RFC 6242）です。Zabbixの ssh.run アイテムはSSHサブシステム指定をサポートしており、キーの第6引数に netconf を渡すと（例: ssh.run["<RPC-XML>",,830,,,netconf] ）、ZabbixがSSH接続時に自動でサブシステムをネゴシエートします。アイテムキーの第1引数にNETCONF RPCのXMLを直接記述すれば応答XMLが取得でき、外部スクリプトは不要です。 共通のアーキテクチャは以下のとおりです。 Zabbix Server └─ ssh.run (SSHエージェント, port 830, NETCONFモード) └─ 対象装置 ├─ マスターアイテム: NETCONF RPCでXMLレスポンスを一括取得 ├─ 依存アイテム: XMLから前処理で個別値を抽出 └─ LLD(ローレベルディスカバリ): 波長・ポートごとにアイテムを動的生成 シェルフコントローラー（ROADM）の監視 シェルフコントローラーは4本のマスターアイテムで監視しています。 マスターアイテム 間隔 取得内容 alarm 1h OpenROADMアクティブアラーム info 1d デバイス情報(シリアル、ソフトウェアバージョン) opticalpower 15m 光パワー(OTS/OMS/NMC-CTP) pm raw 15m Performance Monitoringデータ PM Raw DataからLLDで波長ごとのアイテムが自動生成されます。 Degree側では方路ごとの波長別input/output power、SRG側ではAdd/Drop側のパワーがそれぞれ監視対象です。 波長を追加すると、次回のLLDで新しい波長のアイテムが自動的に作られます。 トリガーはOpenROADMアラームの深刻度（Critical/Major/Warning）をZabbixの深刻度に直接マッピングしています。 トランスポンダーの監視 gNMIのoptical_channel欠損を補完するため、トランスポンダーについてもNETCONF経由の監視をZabbix上に構築しました。 トランスポンダーでは1本のマスターアイテム（ openconfig-platform:components のoptical-channel subtree filter）でNETCONF RPCを発行し、全ポートの光パワーを一括取得しています。 LLDでLine/Clientポートを動的に発見し、ポートごとにinput_power、output_power、pre_fec_ber、laser_shutdownなどのアイテムを自動生成します。 トランスポンダーにはハードウェアバージョンでポート命名規則の異なるモデルが混在しているものの、NETCONFで取得するXML構造は同一であるため、単一のZabbixテンプレートで両バージョンに対応できています。これはLLDによる動的発見の恩恵です。 一元管理で何が変わったか シェルフコントローラーとトランスポンダーが同一のZabbix基盤に載ったことで、光伝送機器も既存のサーバーやネットワーク機器と同じ運用フローで監視できるようになりました。 Slackアラートについても、Zabbix（NETCONF経由）とCloud Monitoring（gNMI経由）の2系統の通知を同一チャンネルに集約しており、監視元に関わらずチームが1箇所で状況を確認できる体制としています。 内製ツール群と今後の方向性 ここまで紹介したように、APNテストベッドでは波長管理Webアプリ、内製CLIツール、gNMI+Grafana、Zabbixと、複数のツールを組み合わせて運用しています。 現在はZabbixを監視の中核に据え、gNMIをリアルタイム補完として併用する構成に落ち着きつつあります。 波長管理Webアプリで管理している周波数情報は、ZabbixのNMC-CTP別パワー監視と中心周波数で対応づけられます。 たとえば特定の波長でパワー低下のアラートが上がった際に、波長管理ツール上でその波長のパス情報（A/Z端ノード、中継ノード）をすぐに確認できるため、影響範囲の特定が容易になります。 5. まとめ 本記事では、OpenROADMにもとづく分離型ROADMの論理構成と運用制御を、APNテストベッドでの実践をもとに紹介しました。 flex-gridでの波長管理、NETCONFによるROADM制御、gNMIの運用課題を経てZabbix一元監視に落ち着くまでの経緯を扱っています。 連載全体では、Part 1でトランスポンダー、Part 2で物理構築、本記事で論理制御と、構築から運用までをひと通りカバーしました。 光伝送機器の制御・監視はベンダー固有のツールに頼りがちな領域ですが、オープンなデータモデルとNETCONF/gNMIの組み合わせで、IPネットワークの運用と地続きのやり方が取れることをお伝えできていれば幸いです。 今後は波長管理ツールからNETCONF設定を直接投入する連動や、Zabbixの監視データをもとにした運用判断の省力化に取り組んでいきます。 本稿では業界慣用にならい "fixed-grid" / "flex-grid" と表記しています。ITU-T G.694.1原文での主表記は "fixed grid" / "flexible DWDM grid" です。また、fixed gridは12.5/25/50/100 GHzおよび100 GHzの整数倍を定義していますが、本稿では実運用で主流な50/100 GHzを中心に説明します。 ↩ Erbium-Doped Fiber Amplifier（エルビウム添加光ファイバ増幅器）。光信号を電気に変換せず光のまま増幅できる。ROADMの主要な増幅器として使用される。 ↩ Optical Signal-to-Noise Ratio（光信号対雑音比）。光増幅を繰り返すほど蓄積されたASE（自然放出光）雑音が増え、値が低下する。伝送品質の重要指標の1つ。 ↩

こんにちは！SCSKの新沼です。 VMware環境の監視において、こんな悩みを抱えていませんか？ 「膨大な数の仮想マシンを、1つずつZabbixに手動登録するのは大変…」 「すべての仮想マシンにZabbixエージェントを入れる必要があるの？」 今回は、Zabbixの標準機能（VMwareテンプレート）を利用して、VMware ESXiホストおよび、その上で稼働する仮想マシン（以下VM）を全自動で登録・監視する手順をご紹介します。 1. VMware監視の仕組みと構成 設定に入る前に、ZabbixにおけるVMware監視の仕組みを整理します。 従来の監視手法では、仮想マシン（ゲストOS）1台ずつにZabbixエージェントをインストールするのが一般的でした。しかし、この方法には以下のような課題があります。 VMの数が多すぎて、手動でのホスト登録やエージェント導入に膨大な手間がかかる。 アプライアンス製品など、そもそもOSにエージェントをインストールできない仮想マシンが存在する。 VMが作成・削除されるたびに、Zabbix側の監視設定も手動で追加・削除しなければならない。 これらを一気に解決するのが、Zabbix標準の VMwareテンプレート と ローレベルディスカバリ（LLD） の組み合わせです。   ＜メリット＞ 完全エージェントレス : Zabbixサーバーが直接ESXi（またはvCenter）のAPIと通信し、ハイパーバイザー側から見たCPUやメモリ、ストレージの利用状況を取得します。VM側には一切手を加えません。 LLDによる自動追従 : ESXiをZabbixに1つ登録するだけで、その配下にあるVMやデータストアをZabbixが自動的に見つけ出します。今後VMが増減しても、Zabbixが自動で監視対象に追加・削除してくれます。 2. 検証環境 本記事では、以下の環境を前提として設定手順を解説します。 Zabbix Server : 構築済みのZabbixサーバ (Version 7.0) 監視対象 : 1台のESXiホスト ESXi上のVM : 以下の2台を事前に作成済み Web-Server-Test DB-Server-Test この1台のESXiをZabbixに登録し、最終的に2台の仮想マシンがZabbix上に自動登録されることを目指します。 3. 事前準備①：ESXi側でのユーザー作成 ZabbixがAPI経由でESXiにアクセスするための認証情報を用意します。 セキュリティの観点から、 root ユーザーではなく Zabbix監視用の読み取り専用（Read-only）ユーザー を新規作成します。 ESXiのWeb管理画面にログインします。 左メニューの  「ホスト」  ＞  「管理」  ＞  「セキュリティとユーザー」  ＞  「ユーザー」  タブを開きます。 「ユーザーの追加」をクリックし、ユーザー（例： zabbix-monitor ）とパスワードを設定して作成します。 次に、左メニューの  「ホスト」  を右クリックし、 「権限」  をクリックします。 「ユーザーの追加」をクリックし、先ほど作成した  zabbix-monitor  に対して  「読み取り専用 (Read-only)」 ロールを割り当てて保存します。 画像の赤枠のように、読み取り専用ロールがついたアカウントがあることを確認。 4. 事前準備②：Zabbix Server側のプロセスチューニング Zabbixのデフォルト設定では、VMware環境からデータを収集するための専用プロセスが停止しています。設定ファイルを編集してプロセスを起動させます。 Zabbix ServerにSSH等でログインし、設定ファイルを開きます。 $ sudo vi /etc/zabbix/zabbix_server.conf 以下の2つのパラメータを探し、コメントアウトを外して値を設定します。  ＃ VMwareのデータを収集するプロセス数（デフォルト0、小～中規模なら3~5程度） StartVMwareCollectors=5 ＃ APIから取得したデータを保存するキャッシュサイズ（VM数が多い場合は拡張推奨） VMwareCasheSize=64M 設定を保存後、Zabbixサーバープロセスを再起動して設定を反映させます。 $ sudo systemctl restart zabbix-server 5. Zabbixフロントエンドでのホスト登録 準備が整ったら、ZabbixのWeb管理画面からESXiを登録します。 ステップ1：ホストの作成 Zabbixの管理画面にログインし、 「データ収集」  ＞  「ホスト」  を開きます。 右上の  「ホストの作成」  をクリックします。 「ホスト」タブで以下を入力します。 ホスト名 :  ESXi-Test  （任意の名前） テンプレート :  VMware  を選択 ホストグループ :  Virtual machines  等の任意のグループ 💡 ポイント：インターフェース ZabbixのVM監視は、APIによる監視を行うのでインターフェースの設定は不要です。ここでは、エージェントを選択してデフォルトのまま設定しています。 ステップ2：マクロ（認証情報）の設定 次に、上部の「マクロ」タブを開き、「継承とホストマクロ」を選択します。VMwareテンプレートで定義されている以下の3つのマクロの「値」を入力します。 {$VMWARE.URL}  :  https://<ESXiのIPアドレス>/sdk {$VMWARE.USERNAME}  :  zabbix-monitor （先ほどESXiで作ったユーザー） {$VMWARE.PASSWORD}  : （設定したパスワード） 💡 ポイント：URLの末尾に注意 URLを設定する際、単なるIPアドレスではなく、vSphere APIのエンドポイントである /sdk を必ず末尾に付与してください。これを忘れるとAPI通信に失敗します。 入力が完了したら、画面下部の「追加」ボタンをクリックしてホストを保存します。 ※画像は、作成後のものなので、「ホストマクロ」タブになっていますが、「継承したマクロとホストマクロ」のタブで入力して「追加」をクリックしてください。 6. ディスカバリ（自動登録）の確認 ホストを追加すると、Zabbixが設定した間隔（デフォルトは1時間）でESXiと通信し、仮想マシンやデータストアの情報を自動的に取得（ディスカバリ）し始めます。 →すぐに確認したい場合は、ホスト＞ディスカバリから、すべてのディスカバリルールを選択して、「監視データ取得」をクリックしてください。 💡 ポイント：初回登録時の「取得不可」エラーについて 登録直後にホストの「ディスカバリルール」画面を見ると、ルールが赤色の「取得不可」状態になることがあります。これは設定ミスではなく、 Zabbixのバックグラウンドプロセスがデータを収集し、キャッシュに保存し終わるまでの一時的な状態 です。 焦らずに5〜10分程度待つと、自動的に緑色の「有効」状態に切り替わります。 自動登録されたホストの確認 キャッシュが溜まり、ディスカバリが正常に実行された後、 「データ収集」 ＞ 「ホスト」 の一覧画面を再度確認します。 手動で登録した ESXi-Test ホストの他に、事前準備で作成しておいた Web-Server-Test や DB-Server-Test といった仮想マシンが、別々のホストとして自動的に追加されている ことが確認できます。自動登録されたホストは、名前の横にディスカバリのリンクアイコンが表示されます。   7. 【補足】本番環境（vCenter）での運用について 今回は検証のため、「1台のESXiホスト」を直接Zabbixに登録し、その上の仮想マシンを自動検出する方針で解説しました。 しかし、実際の運用現場では複数のESXiホストを「vCenter Server」で一元管理しているケースが多いと思います。その場合、 各ESXiをZabbixに1台ずつ登録する必要はありません。 Zabbix側に「vCenter」を1つだけホストとして登録し、マクロにvCenterの認証情報を設定するだけでOKです。 ZabbixがvCenterのAPIを叩き、その配下にある 「複数のESXiホスト」も「すべての仮想マシン」も芋づる式に全自動で検出・登録してくれます。 本番環境に展開する際は、ぜひこの「vCenter起点」の構成で、劇的な監視運用の自動化を体感してください。 おわりに 以上がZabbixを利用したVMware ESXiおよび仮想マシンの自動監視設定の手順です。 VMwareテンプレートを使用することで、ハイパーバイザー自体のリソース状況をエージェントレスで取得できるだけでなく、仮想マシンが新規作成・削除された際の監視設定の追加・削除作業も全自動化されます。 仮想環境の監視運用を劇的に効率化できる強力な機能ですので、ぜひご自身の環境でも活用してみてください。   　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

こんにちは、SCSKの坂木です。 ZabbixとPagerDutyを連携させると、障害発生時に電話で通知を受け取れるようになり非常に便利です。しかし、設定を間違えると「深夜にアラートが連発して、電話が鳴り止まない」という大変な事態になります。 今回は、 Zabbixから短期間に同じような障害通知が連続して発生した場合でも、PagerDuty側でそれらを「1つのインシデント」としてまとめ、電話通知を「1回」に抑える方法を解説・検証 します。   検証構成 今回の構成は以下の通りです。 [Zabbix] —-(Webhook)—-> [PagerDuty] —-(電話通知)—-> [運用担当者] ZabbixとPagerDutyの基本的な連携（Integration Keyの設定など）は完了している前提で進めます。 ZabbixとPagerDutyの基本的な連携は こちら に記載してますので、未設定の方は参考にしてください。   電話通知の設定 PagerDuty側で電話番号を登録します。 1. PagerDuty画面右上のアイコンから [My Profile] を選択。 2. [Contact Information] に電話番号を登録します。   3.  [Notification Rules] タブで以下のように、緊急度の高いインシデントのみ電話通知するよう設定します。 High Urgency（緊急度：高）: Email と 電話 Low Urgency（緊急度：低） : Emailのみ（電話は設定しない）   Service Orchestrationの設定 Zabbixから送られてきた全ての障害通知に対して電話通知すると、電話が鳴りやまないという状況になります。そのため、送られてくる障害情報に応じて緊急度を振り分け、電話通知するかしないかを判断する必要があります。 今回は 特定のホストからの通知であれば高い緊急度にして電話通知されるように設定 します。（前章で出てきた、High Urgencyに振り分けられるようにします） 1. 対象の Service を選択し、[Settings] タブを開きます。 2. [Service Orchestrations] セクションを探し、ルールを新規作成（New Rule）します。 ルールの設定内容 条件（Condition)     : event.source matches part ‘<対象のホスト名>’ 　 （今回は testhost でフィルタリング） アクション (Actions):　Set severity to error / critical  今回条件は1つですが、電話通知させたい条件を追加する場合は下の [＋] を押して複数の条件を設定できます。   それ以外（Fallback Behavior）の設定 「上記のルールに当てはまらないもの（＝重要じゃないホスト）」のアクションを以下のように設定します。 Alert Behavior: Set alert severity to warning / info   Assign and Notifyの設定 ここで対象Serviceの [Settings] タブにある [Assign and Notify] セクションを確認してください。 この設定により、ルールで判定された Severity: Critical/Error が High Urgency（電話通知） に 、 Severity: Warning/Info が Low Urgency（メール通知） に自動的に変換されます。   これで、 testhostからの障害通知は High Urgency 　 それ以外は Low Urgency 　という自動振り分けの仕組みが完成しました。   Alert Groupingの設定（Service Settings） 重要サーバの障害であっても、1分間に10回も電話がかかってきては対応できません。 そこで、 Zabbixから送られてくるアラートについて関連するものはまとめる設定 に変更します。 1. Zabbixを連携させている Service を開き、[Settings] タブをクリック。 2. [Reduce Noise] セクションにある [Automatically group alerts by similarities in alert summaries, historic alert patterns and 　　past merged alerts.] を選択し、後続の類似アラートを同一インシデントとしてまとめる期間を指定します。 (今回の検証では5分として設定しました。)   検証その１ それでは、実際に障害を発生させて挙動を確認します。 Zabbixサーバから、特定ホストの障害アラートを短期間で十数件送信します。   実行結果 ① スマホへの着信確認 携帯電話には、 1回だけ 自動音声の電話がかかってきました 。   ② PagerDuty上の表示確認 PagerDutyのインシデント一覧を確認すると、 作成されたインシデントは 1件だけ でした。   Zabbixから送った複数の障害通知をPagerDuty側でひとつに集約でき、電話回数も集約した1回のみ になることを確認しました。   Service Orchestrationの応用：アラートの「数」で緊急度を動的に変える ここでは、さらに一歩進んだ設定を行います。 特定のサーバ（testhost）からの通知は、普段はメールだけでいいけれど、短期間に大量のエラーを吐いた時だけは電話を鳴らしてほしい  という、「量」に応じた動的な通知コントロールを実現します。 これを実現するために、PagerDutyの Service Orchestration Rules を使用します。   手順①：対象ホストのSeverityを下げる（親ルール） 先ほど設定した特定のホスト（今回は testhost）からの通知を、Warning（電話を鳴らさない）設定にします。 条件（Condition)     : event.source matches part ‘<対象のホスト名>’ アクション (Actions): Set Severity to warning これで、testhost からのアラートは、通常時に「Low Urgency」として扱われ、メールのみ（電話なし）となります。   手順②：閾値を超えたらSeverityを上げる（子ルール） 次に、この親ルールの隣にある [+] ボタンを押し、子ルールを追加します。ここで「数」をカウントします。 今回は1分間で100件以上の通知があった場合に、critical（電話あり）となる設定とします。 条件（Condition)     : trigger_count over 1 minutes > 100 アクション (Actions): Set Severity to critical この設定により、 testhostからの通知であり（親ルール）、かつ、短時間で大量のアラートが来ている（子ルール）  場合のみ、強制的に緊急度が高（Critical）になり、電話が鳴るようになります。   検証その２ 実際に testhost からアラートを飛ばして挙動を確認します。   検証パターンA：電話なし まずは、testhost から障害通知を数十件送信します。 【結果】 PagerDutyの判定: Low 通知　　　　　　: メール通知のみ届きました 期待通りです。単発的なエラーや一時的な揺らぎであれば、担当者を叩き起こすことはありません。   検証パターンB：電話あり 次に、testhost から1分間以内に100件以上の障害通知を送信します。 【結果】 PagerDutyの判定: High 通知　　　　　　: 電話とメールの両方から通知が届きました   まとめ 今回の検証で、ZabbixとPagerDutyを組み合わせることで、大量のアラート通知を適切に制御できることが確認できました。 重要なポイントは以下の3点です。 Service Orchestration: ホスト名や発生頻度に応じて、電話通知の要否を自動で判断する。 Alert Grouping:  短期間に連続するアラートを1つのインシデントに集約し、電話通知回数を最小限に抑える。 Assign and Notify: SeverityとUrgencyを正しく連動させる設定を有効にする。 Zabbix側で複雑な通知条件を作り込むよりも、PagerDuty側で集約ルールを管理する方が、柔軟でメンテナンスも容易です。 担当者の負荷を軽減しつつ、重要な障害検知を確実に行う運用フローとして、ぜひ活用してみてください。   ▼ Zabbixに関するおすすめ記事 【Zabbix】UserParameterでスクリプト実行結果を監視する方法 ZabbixのUserParameter設定ガイド。独自の監視項目を追加する方法、引数を使ったコマンドの使い回し、system.runとの違いを具体例で紹介。監視業務を効率化したい方はぜひ。 blog.usize-tech.com 2025.11.06 【Zabbix】system.runでスクリプト実行結果を監視する方法 Zabbixのsystem.run設定方法をステップバイステップで解説。標準アイテムにないカスタム監視を実現するため、zabbix_agentd.confの修正、安全なAllowKeyの使い方、スクリプトの権限設定までを網羅。初心者でも安心のガイドです。 blog.usize-tech.com 2025.11.04   弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ Zabbix資料ダウンロード｜SCSK Plus サポート for Zabbix Zabbix監視構築に必要な知識と最新機能についての資料をダウンロードできるページです。世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★SCSK Zabbixチャンネル★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、最新のZabbixトレンドや実際の導入事例を動画で解説。明日から使える実践的なノウハウを提供します。 今すぐチャンネル登録して、最新情報を受け取ろう！ www.youtube.com   ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com