Zabbix 5.0はKubernetes監視やZabbix Agent 2など――Zabbixでデータ収集ゲートウェイを構築した事例が登場したZabbix Conference Japan 2019：7年間で運用トラブル一切なし――医療施設約900拠点のシステムを集中監視する事例も

Zabbixのユーザーやパートナーが集う毎年恒例のイベント「Zabbix Conference Japan 2019」が11月15日に開催された。本稿では、当日の模様をレポートする。

[PR／＠IT]

　2019年11月15日、国内最大のZabbix社主催イベント「Zabbix Conference Japan 2019」が都内で開催された。2017年、2018年に続き、Zabbix社創設者兼CEOのAlexei Vladishev氏による基調講演の他、Zabbixを使っているユーザーの生の声、検証事例、Zabbixを利用したシステム運用を便利にする関連ソリューションの紹介などが行われた。幾つかのセッションをピックアップしてお届けする。

講演一覧（クリックで各講演に移動）

• 5.0ではKubernetes監視やコードコントリビューター制度も――CEO基調講演
• NEC、富士通ソーシアルサイエンスラボラトリ、NTTコム ソリューションズが自社ソリューションを紹介
• Zabbix Proxyを使ってデータ収集ゲートウェイを構築したNTTコム ソリューションズ
• 7年間で運用トラブル一切なし――医療施設約900拠点に配備されたPACSシステム端末をZabbixで集中監視するNOBORI
• Zabbix 5.0で正式サポートされる「Zabbix Agent 2」を解説

5.0ではKubernetes監視やコードコントリビューター制度も――CEO基調講演

　基調講演には、Zabbix 創設者兼CEO Alexei Vladishev氏が登壇。「Welcome to Zabbix Conference Japan 2019! 〜Road to Zabbix 5.0に向けて〜」と題し、最新版のZabbix 4.4と、次期LTS（Long-Term Support）であるZabbix 5.0の動向を解説した。

Zabbix 創設者兼CEO Alexei Vladishev氏

　Vladishev氏は、オープンソースソフトウェア（OSS）の動向について振り返りながら「クラウドプロバイダーに対抗するために、OSSが制約のある独自のソリューションに舵を切るケースが出てきています。しかし私はOSSがもたらす自由の理念を信じています。Zabbixはこれからも“ユニバーサル”な真のOSSを追求していきます」と強調した。

　ユニバーサルとは、一部の監視機能だけではなく、開発（Dev）から運用（Ops）にわたる、あらゆるユースケースに対応するという意味だ。Vladishev氏は、「組織の規模を問わずエンタープライズレベルの監視ができるソリューションとして提供していきます」とした。

　Vladishev氏は2019年の振り返りとして、4月にリリースしたZabbix 4.2では、データ破棄による高度な監視、データ収集のためのHTTPエージェントとPrometheus対応、保存前処理でのバリデーションとJavaScript対応、タグ機能の拡張などの機能強化を挙げた。また、10月にリリースされたZabbix 4.4でも、30以上の新しい機能追加と改善が行われた。

　「4.4では、Go言語を使った新しいエージェント『Zabbix Agent 2』の開発や、Webhookを使ったアラート／通知、テンプレートの標準化が行われています。プラグインよる拡張が可能で、Webhookベースの実装により、さまざまなベンダーとのコネクティビティーを確保できます。よりクオリティーの高い監視プラットフォームを構築できます」（Vladishev氏）

　2020年3月にリリースを予定しているZabbix 5.0については、大きな方向性として「さらなる監視方法とアラートの改善」「クラウドとKubernetesの監視」「ベースラインモニタリング」「セキュリティモニタリング」「可視化とレポート」「パフォーマンスと高可用性」というテーマで開発に取り組んでいることを紹介した。

　具体的には、「新しいZabbix AgentのWindows版の提供」「セキュリティ監視における安全ではない設定パラメーターやコネクションの監視」「全ての障害を可用性、パフォーマンス、セキュリティでタグ付けする」「ホストとテンプレートの障害のタグ設定を必須にする」などだ。

　またVladishev氏は、開発者向けの新しいプログラムとして「コードコントリビューター」を開始することも明かした。これは、Zabbixとのコードコントリビューター契約の下、プラグインやメディアタイプの開発を行い、Zabbixチームのレビューとフィードバックを受けた後、成果物を公式ソフトウェアに取り込んでいくというものだ。

　Vladishev氏は「コントリビューターの貢献により、Zabbixはより良い製品になっていきます。Zabbix 4.4とともに、5.0のロードマップも公開されます」と、“真のOSS”としての開発を加速させることを強調し、講演を締めくくった。

NEC、富士通ソーシアルサイエンスラボラトリ、NTTコム ソリューションズが自社ソリューションを紹介

　スポンサーセッションでは、NEC、富士通ソーシアルサイエンスラボラトリ、NTTコム ソリューションズが、Zabbixに対する自社の取り組みや、Zabbixを用いたソリューションを紹介した。

NEC 中村桂一氏

　NECでは2004年から提供する保守サービス「OSSミドルウェアサポートサービス」の中でZabbixを対象にしたサポートを展開している。講演した同社の中村桂一氏は「Zabbixを活用するプロジェクトは確実に増加していて、業種に依存せずさまざまなユーザーに利用されています。NECは年間300件前後のインシデントに対応し、迅速なサポートを提供しています」と話した。この他にも、OSS構成管理ツール「Ansible」を用いたZabbixの標準構築の自動化サービスや、Zabbixを活用した運用監視ソリューションを展開していることを紹介した。

富士通ソーシアルサイエンスラボラトリ 矢澤祐也氏

　富士通ソーシアルサイエンスラボラトリのセッションでは同社の矢澤祐也氏が、同社が展開するZabbixエキスパートによる設計構築支援、設計構築代行を行う「Zabbixプロフェッショナルサービス」と保守サポートを行う「OSSサポートサービス」の事例を基に、Zabbixの運用の注意ポイントを紹介した。矢澤氏によると、富士通ソーシアルサイエンスラボラトリでは「設定したはずの回復メッセージが送信されない」「マップのアイコンを更新するとエラーが発生する」という2つのトラブルに直面したという。その解決方法を示しながら「原因を素早く突き止め、正しく対処することで課題を解決することができます」と同社のサービスの優位性を紹介した。

NTTコム ソリューションズ 鈴木貴大氏

　NTTコム ソリューションズのセッションでは同社の鈴木貴大氏が、ネットワークトポロジー図を自動描画する「T-View for Zabbix」を紹介した。ネットワークトポロジー図を用いると、現場に行かなくても配線状況を知ることができるが、手作業で更新すると情報が古くなりやすいという課題がある。そこで同社では、トポロジーデータと3D描画エンジンを利用して、ネットワーク図の自動描画とネットワークの可視化ができるようにした。鈴木氏は「T-View for Zabbixを用いることでトポロジー図が自動更新され、現場に行かなくても配線状況が分かります」と同サービスのメリットを紹介した。

Zabbix Proxyを使ってデータ収集ゲートウェイを構築したNTTコム ソリューションズ

　イベントの目玉になったのが2つの事例講演だ。1つ目では「Zabbixの可能性を広げる！ 〜データ収集ゲートウェイの事例紹介〜」と題して、NTTコム ソリューションズの田中武信氏が、GPSや3G、LTEを使って非IT機器を含めながら汎用（はんよう）的に利用できるデータ収集基盤を構築した事例を紹介した。

NTTコム ソリューションズ 田中武信氏

　田中氏はまず、Zabbixの監視対象について「ITを構成する要素を監視対象としていますが、近年は、センサーやアナログ信号、物理デバイスといった非IT機器からの情報収集が求められるようになりました。また、機械学習システムや分析システムなど他システムとの連携を求められるケースも出てきています」と説明した。

　Zabbixは「データを集める仕組み」として「Zabbix Proxy」「Zabbix Agent」、「データをためる仕組み」としての「Zabbix Server」、「データを渡す仕組み」としての「Zabbix API」や「Action」機能、JSONなどがある。そこで、これらの仕組みを利用して、非IT機器も含めて汎用的に使用できるデータ収集基盤を作ることを検討したという。

Zabbixは新領域に対応できるか？

　「想定したのは、全国のさまざまなエリアの拠点にまたがって存在する機器や環境の監視です。この場合、データを集めるためには、IT機器からのデータ収集、環境情報の収集、複数拠点の監視が要件となります。この要件を満たすため、各監視拠点にZabbix Proxyを設置する方針としました」（田中氏）

　Zabbix Proxyは、それがない場合と比較して、通信セッション数の最小化、パッシブ監視／コマンド実行、通信圧縮、通信暗号化、オフラインバッファーなどを利用できる点がメリットだ。一方で、Zabbix Proxyは仮想化環境やサーバ機などが必要になり、拠点ごとのサーバ機設置の難しさが課題となった。

　「可搬式のZabbix ProxyとしてZabbix社からアプライアンス製品『Zabbix Enterprise Appliance ZP-1400』などが提供されています。ただ、Linux OSのカスタマイズができないこと、無線ネットワークやストレージが未搭載であることが課題でした。要件を充足させるため、新たに『データ収集ゲートウェイ』を作ることにしました」（田中氏）

　新たに開発したデータ収集ゲートウェイは、Intel Atom系列のプロセッサを搭載した産業用のコンパクトサーバだ。GbE NICを2ポート、USB 2.0を4ポート、HDMI、RS232Cを3ポートなどインタフェースが多数搭載され、ファンレス設計、ACアダプター駆動という特徴を持つ。

　「OSにUbuntu 18を搭載し、Zabbix Proxy 4.0とZabbix Appliance準拠の専用UIを備えています。拡張用オプションで機能追加が可能で、スタンドアロン型GPSレシーバーや、SIM、Wi-Fi、SSDなどを搭載できます」（田中氏）

　位置情報については、シリアル接続でデータの取得を行う常駐型プログラムを開発し、Zabbix Serverに対してデータを送信する方式（zabbix_proxy.confで指定された送信先を使用）とした。また、Zabbix Serverに受信用のトラッパーアイテムを作成した。

　「Zabbixにデータを格納することを前提としたシンプルな構造です。構造を単純にすることで、不具合発生のリスクを低減できます」（田中氏）

　通信機能（3G、LTE、Wi-Fi）については、設定はLinuxにおける一般的なAPN設定、インタフェース設定、Wi-Fi設定と同じように設定できる。データ保持は、mini PCIe接続のSSDを使い、再起動時のオフラインバッファーが消える問題に対処した。温度、湿度、気圧のデータを取得するセンサーは、Zabbixでの使用実績がある「Feelers」の製品を使用した。

　「集めた情報は、データ肥大化、データ保持、I/O性能といった要件が求められ、オンプレミスでは厳しかったことからクラウドサービスを利用しました。データベースにマネージドSQLのサービスを利用し、Zabbix Serverは小リソースのインスタンス（1vCPU、1.7GBメモリ）を使用してコスト削減を図っています」（田中氏）

　田中氏は現状の課題として、時刻が打刻されていないデータをZabbixが受け取らないことや時刻情報を保持していない機器への対処、ホストインベントリに格納された値の収集時間が分からないことなどを挙げた。

　最後に「Zabbixを用いることで監視要件を充足できるデータ収集ゲートウェイを作成できました」とし、Zabbixの新しい可能性をあらためて示した。

7年間で運用トラブル一切なし――医療施設約900拠点に配備されたPACSシステム端末をZabbixで集中監視するNOBORI

NOBORI 山根健志氏

　2つ目の注目事例は、NOBORIの山根健志氏が行った「クラウド型医用画像システムにおけるZabbixを利用した分散監視」の事例講演だ。同社は医療用画像管理システム（PACS）を自社開発し、提供している企業だ。PACSは、従来はフィルムなどで管理されていた画像情報を、電子的に保存、管理、利用できるようにするシステムだ。

　NOBORIは、1998年にテクマトリックスの医療関連事業部門としてオンプレミス型PACSシステムの提供を開始し、2012年からは、クラウド型PACSサービス「NOBORI」の提供を開始。2018年に医療関連事業部門がNOBORIとして独立した。

　「クラウドPACSサービスのNOBORIは、CRやCT、MRI、内視鏡、超音波、マンモグラフィ、歯科画像、病理画像、眼科画像、脳波、心電図といったさまざまな画像情報をクラウドサーバで管理します。2019年3月現在で、全国約900施設で利用されており、NOBORIに保管している患者の延べ人数は2612万人、保管している検査総件数は1億4597万件に達します」（山根氏）

　山根氏は医療用画像システムの開発、保守、運用に従事するエンジニアで、サーバサイドのモジュール開発から、ハードウェア、ネットワーク、OS周りのトラブル解消に至るまで、幅広い業務に携わっている。Zabbixは1.6.xのころから業務で愛用してきたという。

　「NOBORIは、各施設側に専用の小型アプライアンス（NOBORI-CUBE）を設置し、施設側で直近に必要となる画像データのみをキャッシュとして保持することで高速な動作を実現しています。原本となる画像データは、セキュリティを確保した上で、インターネット経由でクラウド側データセンターへ保管されます」（山根氏）

　NOBORI-CUBEは、Linux系OSで構成され、クラウド側で集中管理された施設ごとの設定情報を受信するモジュールを使って定期的に通信を行う。画像サーバ、データベース、参照用アプリケーションなど、利用するソフトウェアは全てコンテナ化され、施設ごとの要件や構成に応じて配信される仕組みだ。

　「CUBEに故障や障害が発生したときはCUBEを交換することで迅速に復旧します。その際には個々のシステム障害を素早く検知することが重要で、そこでZabbixを用いて集中監視を実現しています」（山根氏）

　Zabbixによる監視／運用の規模は、2019年11月現在で、ホスト数は2700ホスト、アイテム数は約45万項目、トリガー数は約36万項目、1秒当たりの監視項目数は約591件という規模となる。

システム構成・分散拠点への対応

　「監視対象システムの障害検出やパフォーマンス管理に必要な情報を見極めて、効率の良い監視、収集が行えるように計画、導入を行っています。ポイントは、アイテムの収集間隔は必要以上に短くし過ぎないこと、ユーザー定義アイテムなどにおいて数値形式で収集できる情報は可能な限り文字列よりも数値形式のデータとして収集することなどです」（山根氏）

　その上で山根氏は、運用において具体的にどのような点に注意しているかについて「Zabbix Server／Proxyの負荷対策」「データベースのパフォーマンスチューニング」「データベース周りの負荷対策」「監視対象となる施設／ホスト情報登録の自動化」「監視対象ごとに固有の監視項目登録の自動化」などを説明した。

　例えば、監視対象となる施設／ホスト情報登録の自動化では「CUBEの設置情報の変更は日常的には発生しません。日常的ではないからこそ自動化、スクリプト化することでミスを防止することがポイントです。設定情報を基にして、Zabbix APIで登録、更新を行っています。一方で、個々のお客さまに固有の設定や、コンテナ配置の構成、連携させる外部システムの構成など細かな変化は日常的に発生します。そうした変更はLow Level Discovery（LLD）で検知し、コンテナの配置状況やファン回転数、温度などのハードウェア、NASやUPSの周辺機器についても、独自スクリプトでLLDに対応させています」（山根氏）

　現在は、Zabbix Proxyを含むZabbixシステムのバージョンアップに取り組もうとしているところだ。Zabbix Server／Proxyは同じメジャーバージョンで稼働している必要があるため、新しいZabbix Serverを別に用意し、1拠点ずつ順番に移行させる作業の検討を開始している。

　最後に山根氏はZabbix採用のメリットとして対応の迅速化と顧客満足度の向上を挙げ、次のように強調した。

　「障害発生をいち早く検知することにより、お客さまからの障害問い合わせに先立って保守スタッフからお客さまへ連絡しての対応が可能になりました。これまで7年間にわたって運用してきた中でメンテナンスを除くシステム障害は発生しておらず、非常に安定しています。これはZabbixの大きなメリットです」（山根氏）

Zabbix 5.0で正式サポートされる「Zabbix Agent 2」を解説

　Zabbix 4.4以降の注目機能の一つに、Zabbix Agentの機能強化がある。Zabbix サポートエンジニア兼トレーナー Alexey Pustovalov氏のセッション「Magic of the new Zabbix Agent」では、そのポイントが紹介された。

Zabbix サポートエンジニア兼トレーナー Alexey Pustovalov氏

　Pustovalov氏はまず、Zabbix Agentの特徴として、CPUやメモリ、ディスク使用率、ホスト名、ポート監視といったOSに関連するあらゆる情報を監視できること、それ以外にもログ監視やファイル、Windowsイベントログ、Zabbix Server／Proxyのパフォーマンス情報なども監視できることを紹介。さらに、「エージェント監視機能は大きく3つの観点から拡張が可能です」とし、カスタムモジュール、ユーザーパラメーター、system.runの3つを挙げた。

　「カスタムモジュールは、C言語で開発するモジュールで、コーディングには“ジェダイマスター”のような卓越した技術が求められます。ユーザーパラメーターは“忍者”のように素早くコマンドとして実行できます。system.runはシンプルですがパワフルです。リモートから何でもできてしまうため、責任とリスクを伴います」（Pustovalov氏）

　ただ、これまでのZabbixエージェントには課題もあった。他のソフトウェアからのデータの受け取りに制約があること、アクティブチェックは監視間隔のカスタマイズに未対応であること、1つのアクティブチェックのプロセスが1つのZabbix Server／Proxyを担当すること、モジュール開発にはC言語の学習が必要なことなどだ。

　「そこで取り組んだのがZabbix Agent 2の開発です。CではなくGo言語を採用したことで、コンパイルして単一バイナリで実行できるようになり、C言語より簡単に開発できるようになりました」（Pustovalov氏）

　Zabbix Agent 2では、アクティブチェックでも監視間隔をカスタマイズ可能だ。現行の.confファイルをサポートし、ログファイル読み取りも並列で実施できる。また新たにネイティブでsystemdの監視にも対応した。プラグイン単位でタイムアウトを実装することもできる。

アクティブチェック

　Pustovalov氏は、Zabbix Agent 2のアーキテクチャやプラグイン開発のモデルを詳しく解説。その上で「Zabbix Agent 2は、Zabbix 4.4では実装テスト段階で、5.0から正式サポートを開始します。現時点ではLinux OSのみに対応していますが、Windows向けエージェントも開発中です。近日中にドキュメントもGit上に公開されるので、ぜひチェックみてください」と、アピールした。

Zabbix Conference Japan 2019の様子