Zabbix Conference Japan 2023レポート

1、監視からオブザーバビリティへ、そしてより幅広い領域への展開を目指すZabbix

ITシステムはもちろん、インターネットにつながるありとあらゆるものが協調し、私たちの日常生活やビジネス、社会そのものを支えるようになっている。これらが安定したサービスを実現するには、確実で包括的な監視が欠かせない。

そんな中、オープンソースの監視ソリューションとして確実な地位を築いてきたZabbixはどんな役割を果たしていくのだろうか。2023年11月16日、17日の2日間にわたって開催されたZabbix Conference Japan 2023では、あらためてこれまでのZabbixの歩みを振り返るとともに、今後の方向性が紹介された。

「究極の監視およびオブザーバビリティツール」を目指し、機能強化を継続

Zabbixの産みの親にして、Zabbix LLCの創設者兼CEOを務めるAlexei Vladishev（アレクセイ・ウラジシェフ）氏は、会場に自ら姿を見せオープニングスピーチを行った。そして、「Zabbixはエンタープライズ向けのオープンソースの監視ソリューションですが、我々のゴールは、Zabbixを究極の監視およびオブザーバビリティツールにしていくことです」と述べ、さらに進化を続ける方針を示した。

Zabbixが生まれて20年以上が経った。これまで監視を通して、さまざまな障害や問題に早期に気付き、修正できるよう支援することにより、さまざまな企業が多様なサービスを提供し、よりよい世界を実現し、最終的には人々の幸福に貢献することをミッションに取り組んできた。

Vladishev氏はこのミッションを引き続き追求し、またクローズドではなく、フリーでオープンソースであることにこだわる点もこの先変わらないとした。「急激な成長の代わりに、毎年少しずつ、着実な方法で成長したいと考えています」（Vladishev氏）

一方で、規模の大小はもちろん、ITインフラだけでなく、サービスやクラウドのモニタリング、OTのモニタリング、あるいはセキュリティやコンプライアンスのモニタリングなど、領域を問わず、Zabbixを多くの異なるユースケースに適合できるものにしていきたいと意気込みを語った。

特に力を入れていくポイントとして挙げたのは、あらゆるデータを収集し、分析して異常や問題を検知して対処し、状況をより高い解像度で可視化していく側面だ。「データを収集し、高い解像度で可視化し、パートナーやユーザーにとって低いTCOで利用できるデータ収集・処理プラットフォームにしていきたいと考えています」（Vladishev氏）

その手段の一つとして、「Single pane of Glass」、つまり単一の画面を見るだけですべてを把握できるようにしていく計画だという。「一つの画面を見るだけで、インフラで何が起こっているかがすぐわかるような監視およびオブザーバビリティプラットフォームを提供し、全体の可視性と高いレベルの透明性を実現していきます」（Vladishev氏）

すでにZabbix 7.0のアルファリリースでは新たなウィジェットが追加され、Single pane of Glassに向けた一歩が踏み出されている。また、気になる項目があればドリルダウンして詳細情報を掘り下げるのはもちろん、監視対象を切り替えながら確認したり、ハニカム型ナビゲーションやサービスツリーナビゲーション、トポロジベースのナビゲーションといった新たなビューを追加するほか、レポート機能の強化も図っていく。さらに、可視化機能を自らの手で拡張、カスタマイズできるよう、開発者向けフレームワークも強化していく。

もちろん、大元となるデータの対象も広げていく。同氏はZabbix 6.0から7.0、8.0への進化の中で、「メトリックデータだけでなく、トレーシングデータ、オープンテレメトリデータ、トポロジデータ、ストリーミングデータ、トレーシング、イベント、ログ、バイナリデータなど、ありとあらゆるタイプのデータ処理を行えるようにしていく計画です」と述べ、可視化とデータ処理の両面で強化を続けていくとした。

もう一つ力を入れていく領域が、パフォーマンスの強化や自動化だ。これは、ZabbixのトータルなTCOを下げていくという観点でも重要なポイントだとVladishev氏は説明した。

「コストを考える際には、Zabbixが稼働するハードウェアのコストだけでなく、Zabbixのインストールや運用に必要な知識の習得、設定変更に要する時間といった側面も考慮しなければなりません。Zabbixのさらなる高速化と、多くの自動化機能を組み入れ、より直感的に使いやすくするという2つの面でZabbixの運用コストを下げていきます」（Vladishev氏）

またZabbix 7.0では、プロキシ間での負荷分散・HA機能がサポートされる予定で、すでに開発が進んでいる。これをAWSなどのパブリッククラウドと組み合わせて活用することで、負荷の増減に合わせて自動的にプロキシをスケールアウトさせ、逆に負荷が減ったときには動的に減らすといったことが可能になり、低コストかつより信頼性の高い運用が可能になる予定だ。

そして、前述の通りZabbixで処理できるデータの種類を拡張するほか、ニーズに合わせてさまざまな環境の監視が行えるよう、Zabbixプラグインやスクリプト、Webhookといった既存の機能に続き、柔軟にダッシュボードのカスタマイズを行えるような機能も追加し、さまざまな領域におけるモニタリングのニーズに応えていきたいとした。

「オープンテレメトリおよびテレメトリデータ、トレーシングデータをサポートし、バージョン8.0のころには、Zabbixを単なる監視ソリューションにとどまらず、究極の監視ならびにオブザーバビリティソリューションとして認識されるようにしていきます」（Vladishev氏）

「オープンソースはしっかりビジネスになる」、ポイントは収益との絶妙なバランス

2日目のセッションには、Zabbix Japan LLCの代表を務める寺島広大氏が登場し、Zabbixも含めたオープンソースとビジネスの関係について掘り下げた。

2012年10月、Vladishev氏らとともに法務局に足を運び、Zabbix LLCにとって初の支社であるZabbix Japanを設立してから10年。それだけの年月が経っても、「日本時間で、日本人による、日本語の日本人向けのサポートを提供し、パートナー企業向けの営業支援を行い、マーケットのニーズにマッチしたサービスを提供していくところは今も変わらず、会社のポリシーとして大切にしながら運営を続けています」（寺島氏）

地道に、着実に活動を続けてきた結果、今やパートナーは67社にまで拡大した。また、Zabbixというソフトウェア単体だけでなく、サポートサービスやパートナー各社が提供するサービスを導入するユーザーも増えており、日本市場のビジネスは安定している。

しかし、Zabbix Japanの立ち上げから今に至るまで、寺島氏はたびたび「本当にオープンソースでビジネスになるんですか？　どうやって儲けるんですか？」という問いを投げかけられてきたそうだ。

今でこそ、オープンソースソフトウェア、特にメジャーなソフトウェアの多くは、さまざまなテクノロジー企業の有形・無形の支援を得て、企業主体となって開発・提供されるようになった。ソフトウェア本体はフリーで提供されつつ、周辺のサポートやトレーニング、インストールや運用支援といった技術的なサービスの部分でさまざまな企業がビジネスを展開し、幅広いエコシステムを構築している。しかし10年前は、こうした形式に懐疑的な声も多かったそうだ。

そもそもビジネスとは何だろうか。商用ソフトウェアの場合、まず製品を作り、その製品を知ってもらうために、それなりの予算を投じて宣伝・マーケティング活動を展開していく。そして、製品を購入したユーザーからのフィードバックを元にまた新たな開発につなげる——というサイクルが展開されるが、その中では、収益を最大化するために営業やマーケティング活動にある程度重きが置かれることになる。

一方、Zabbixも含めたオープンソースソフトウェアの場合はちょっと順番が異なる。すでに個人の趣味などの結果として製品はできあがっており、あとはどこかで公開すればいい。このため、商用ソフトウェアと異なり、予算を投じてのマーケティング活動はそれほど行われない。よいソフトウェアであればいろいろな人が使い、広がるにつれて自然とコミュニティが生まれ、困ったところを解決する技術情報が公開されたり、バグ報告をはじめとするフィードバックが返ってくる。

「オープンソースコミュニティというと、世界中のエンジニアがコードを書き、開発しているイメージを持つ方も多いと思いますが、実際にはそれだけではありません。フォーラムで他の人をヘルプしたり、この製品はいいよと他の人に広めたりといった、ユーザー同士の助け合いや情報発信が非常に大事なところです。Zabbixはそういった方々をできるだけ支援していきたいと思っています」（寺島氏）

Zabbixはこうやって広まってきたが、ユーザーが増えれば増えるほどさまざまな要望が寄せられる。それらの声に応えていくには、Vladishev氏自身が100％コミットするのはもちろん、技術支援やトレーニング、サポートのためのメンバーが必要だ。そういった経緯からZabbix LLCは設立された。Zabbixそのものの開発は、基本的にZabbix LLCに雇われた社員が行っており、そこは、一般のIT企業が、有償のソフトウェア製品を作る場合と大きくは変わらない。

ただ、何らかの形で開発を継続していくための資金は必要だ。Zabbixでは本体による技術支援、あるいはパートナーによる企業としてのサポート体制を展開し、そこから得られた収益を、プロダクトを改善し、開発を継続していく原資になっている。同時に、コミュニティ活動を通して、ユーザーから得られるフィードバックも重要な位置付けにあるという。

寺島氏はこういった全体像を説明した上で、ロジックこそ違うが、「オープンソースでビジネスはしっかりできる」と結論付けた。

そして「押し売りではなく、ユーザーに選んでいただけるものを作るためにも、エンジニアの視点や技術力を大切にしています。一方で収益が必要なのも事実です。ビジネス色はあまり強くない方がいいのですが、でもビジネスもしなければいけません。その真ん中でうまくバランスを取っていく感覚を持ちながら、10年間、会社としてやってきました」と述べた。

商用ソフトウェアの場合、どうしても収益が先になる。しかしZabbixはまずユーザーを広げることを重視しており、そのためにエンジニア主導で製品を開発し、情報をオープンに公開し、より広く知ってもらうことに力を注いできた。「その上で収益も必要ではありますが、得すぎないという微妙なバランスを保っているのが、私たちの活動だと思っています」（寺島氏）

そして、もし困ることがあればパートナー経由で価値あるサービスを提供してもらうことで、全体の収益につながるビジネスモデルを展開している、というのが今の構図であり、このあり方を今後も継続していくとした。

こうしたこれまでの活動を通して、情報システムの分野ではZabbixの認知度が非常に高まってきた。プロキシの活用やクラウド環境の監視など、監視の対象はより広がっていく方向にある。

ただ海外の事例を見ると、IT関連の機器やリソースだけでなく、太陽光発電システムなどIoTデバイスの監視に活用するケースも生まれている。

「サーバーやネットワーク機器だけでなく、データセンターのファシリティや工場設備、建築、医療、運輸など、これまでに聞いたことのない業界でもZabbixを活用いただける分野はたくさんあると思っています」（寺島氏）。今後はそんな新たな分野での監視に向け、ISVやIHVとの連携を広げ、新たな事例を作っていく方針だ。

2、単なるモニタリングを超え、さまざまな可能性を示すZabbixの活用例(事例編)

安定したサービスや通信環境の提供には、監視が欠かすことができない。Zabbixはすでにさまざまなサービスの裏側でその監視業務を担っている。それも、単なるモニタリングだけでなく、企業それぞれの環境に応じて、標準化・自動化といった工夫を組み合わせ、工数やコストを減らしているケースがほとんどだ。

Zabbix Conference Japan 2023の事例セッションでは、自社の課題に合わせてどのようにZabbixを使いこなしているのかを担当者自らが紹介した。さらに、毎年幕張メッセで開催されるInterop TokyoのShowNetの安定運用をいかにZabbixが支えたかの紹介や、広域でのデータ同期・負荷分散にZabbixを活用しようとしているトヨタ自動車の挑戦も披露された。

「KDDI版Zabbix」による標準化に加え「布教活動」を展開し、監視品質の向上を進めるKDDI

KDDIは固定回線やモバイル、クラウドなど幅広い通信サービスを提供している。安定したサービスの提供には、「監視」が不可欠だ。同社のインフラエンジニア、神谷太郎氏は「KDDI版Zabbix導入による監視標準化に向けた取り組み」というタイトルで、独自の工夫を重ねながらZabbixをどのように活用し、監視に取り組んでいるかを説明した。

神谷氏らの部署では、KDDIが運用する80から100ほどの設備の監視を行っている。ただ、以前は過去の経験や実績をもとに各担当がバラバラに監視設定を定義し、開発パートナーなどに発注していた。このため、同じ「DBの応答遅延を監視する」という要求でも、ある設備では遅延を、別の設備では応答時間を監視するといった具合に、実際の監視設定が全く異なることもあったという。

こうした課題を踏まえ、KDDIではZabbix 5.0をベースに監視の標準化に取り組んだ。

具体的には、「なぜ監視するのか」という目的を定めた上で、「何を監視するのか」という監視ポリシーを明確に定義し、標準化した。さらに実際の監視設定例も用意することで、経験の少ないエンジニアでも抜け漏れなく、同一品質で監視が行える環境を整えていった。また、システムは生き物であり、どんどん変化する。一度標準化した監視も、時間が経てば陳腐化する恐れがあることから更新は不可欠だが、その更新フローも明確化した。

次に神谷氏が取り組んだのは、監視のプロダクトおよび構成の標準化だ。「以前は、監視対象ごとに監視ソフトが乱立していました。このため、担当設備が変わるたびにやり方が変わり、学習コストが発生していました」（神谷氏）。せっかく標準化した実装ポリシーがあっても、結局は監視ソフトごとにやり方が変わって工数がかさむ上に、コストも下がらないという状況だった。

そこで神谷氏は、Zabbixを用いて実装レベルも標準化することにした。まず、実装ポリシーに基づいたテンプレートを、主な監視対象ごとに約30種類作成した。さらに、Zabbix本体とデータベース、フロントエンドと可視化の仕組みに加え、前述のテンプレートをVMDK形式でイメージ化した「KDDI版Zabbix」を作成し、これを入れるだけですぐに標準的な監視が始められる仕組みを整えた。

もっとすごいのはここからだ。単に仕組みを整えるだけでなく、それを使ってもらうための布教活動も展開した。

「せっかく監視プロダクトをZabbixを使って標準化し、監視設定も標準化しましたが、これが普及、浸透しなければ課題はいつまでたっても解決できません。ですが、ただ『作ったから使ってください』では、誰も使ってくれません」（神谷氏）

そこで神谷氏らは、いかにZabbixを使うと監視が楽になり、便利になるかを伝えるだけでなく、何か不明なことがあった場合の質問受付窓口をTeams上に設けて速やかに回答したり、Zabbix認定スペシャリストや認定プロフェッショナルといった資格を取得し、社内のメンバーが安心して利用できる支援体制を整えた。さらに、「猫でもわかるZabbix」という名前の教育用資料を内製し、それを用いた社内勉強会も実施し、Zabbixによる標準化された監視の敷居を下げる取り組みを進めていった。

加えて仕組みの面でも、Zabbixエージェントの展開・インストールから設定までの作業を自動化する「構成管理サーバー自動化基盤」を内製し、手順を大幅に簡素化。その上で、標準テンプレートの自動適用を行う仕組みも構築し、監視対象の構成を把握した上で適切なテンプレートを適用できるようにした。

こうして、Zabbixでで標準化するだけでなく、それを「使ってもらえる」環境を整えていったKDDI。今後は、せっかく標準化したこの監視の仕組みを、日本全国の他の設備にも拡大していく計画だ。同時に、より大規模な環境での監視をどう実現するかにはじまり、Zabbix 6.0系で実装されたベースライン監視の活用、マシンラーニングを用いた異常の早期検知などにも取り組んでいきたいという。

神谷氏は「これにより、監視をするKDDI側の人間が楽になるだけでなく、実際にサービスを使っていただくお客様の利便性も高まるのではないかと考えています」とし、これからも時代の変化に合わせて監視の仕組みを進歩させていきたいと述べ、講演を終えた。

JP1とZabbixのいいところどりで、要件を満たしつつコストの大幅削減を実現したオプテージ

オプテージは関西電力の情報通信事業の中核会社として、通信サービスや「mineo」というMVNO事業、法人向けのソリューション事業を展開している。同社は、それまでJP1で行ってきた監視の大部分をZabbixに移行することで、より効率的に管理する体制を実現しており、その経緯を「サーバー1,000台の高度な監視を、JP1とZabbixのいいとこ取りで実現！」で紹介した。

コーポレートITシステム部は、オプテージの各事業を支える基幹システムやMVNO管理、工事系管理や法人向けの業務システムの開発、運用を担っている。同社の妙中徹平氏は「社内システムが停止してしまえば業務が止まってしまいます。システムによっては、複数のサービスに影響があります」と説明した。

そうした事態を招かないために欠かせないのが監視だ。そこで同社はJP1を用い、約1000台に上る社内システムのサーバーを監視し、異常を早期に検知して対応する体制で運用してきた。

だが、中核となるJP1 Managerは、2024年3月31日に標準サポートが終了する予定になっていた。加えて、JP1での運用には幾つかの課題があった。一つはJP1エージェントのコストだ。監視対象単位でのライセンス体系となっていることから年間1000万円以上のコストがかかっており、今後も増加することが見込まれた。また、監視対象サーバーが新規に加わるたびにメディアからエージェントをインストールする必要があり、その負荷も課題だった。また、全体としてサーバーリソースを最適化したいと考えても、JP1ではリソース情報の収集・確認方法がバラバラで、共通の仕組みでの可視化が困難だった。

こういった背景からオプテージでは、新たな監視システムを検討することにした。三つの課題を解決するだけでなく、生死監視やログ監視、プロセス監視、リソース監視、そしてSNMP Trap監視といった必要な監視項目を網羅すること、既存のメール通知やオペレータ画面への連携処理を改修することなくそのまま利用できることの二つも必要な要件だった。

解決策として浮上したのがZabbixだ。「社内の他部署で採用実績があり、システムの監視、アラート通知、パフォーマンス可視化などにおいて、高度な監視を実現することが可能でした」（同社、平山勇氏）

加えてオープンソースソフトウェアであり、サポート費用も監視対象台数に依存しないため、監視コストの大幅な削減が可能なこと、OSテンプレートへの組み込みによってエージェントの配布が容易に行え、導入工数を抑えられること、そしてブラウザ上でリソース情報を可視化できることも利点だった。

ただ、「Zabbixは、SMNP Trap監視について不得手です。また、既存通知連携処理を継続することが難しく、改修やテストなどが高コストとなってしまいます」（平山氏）

それでも魅力的な選択肢だったため、何とかいい方法がないかと模索。結果として、SNMP Trap監視についてはJP1/NNMiを継続して利用することにし、またZabbixで検知したイベントをJP1/IMへ連携することによって既存通知連携処理を継続させることで、必要な要件をすべて満たす形に落ち着いた。「ZabbixとJP1を組み合わせることで、高度な課題と要件を解決しました」（平山氏）

Zabbixの導入にあたっては、標準的な監視項目をテンプレート化し、ホスト登録時に自動的にリンクする仕組みを整えた。「各システムの監視設定を一から作成するのではなく、監視テンプレートを自動リンクさせることで監視設定作業に要する時間を短縮し、運用面の効率化を実現しました」（平山氏）

他にも、Zabbixのパートナーであるアシストの支援を得ながら、ZabbixのAPIを利用して監視抑止・抑止解除機能を実装したり、システム担当者の意見を反映しながらマニュアルを作成したり、Ansibleを用いて効率的にZabbixエージェントを展開するなど、さまざまな工夫を凝らして導入した。

ZabbixとJP1を組み合わせた新たな監視の仕組みでは、以前の課題であったエージェントのコストを、2024年度には1000万円以上と大幅に削減できる見込みで、「十分なコスト削減効果を得られていると判断しています」と妙中氏は述べる。

また、OSテンプレートへの組み込みによって、監視対象サーバーを新規構築した時点でZabbixエージェントがすでに導入された状態を整えることができた。以前は2時間程度かかっていたインストール作業の時間も、ほぼゼロになったという。また、リソース情報に関しても、ブラウザ上から一元的にリソースグラフを確認できるようになった。

「Zabbixの製品の長所を活かしつつJP1と組み合わせることで、製品を適材適所で使い、課題、要件に対応できました」（妙中氏）。今後はZabbixの活用範囲をさらに広げ、監視項目を増やしていくほか、Zabbixによって可視化できたリソース情報を分析し、社内のサーバーリソースの最適化を促進するなど、引き続きさまざまな取り組みを進めていくという。

コントリビュータとして、さまざまな側面からShowNetの安定運用を支えるZabbix

日本最大級のネットワーク関連の展示会である「Interop Tokyo」の最大の特徴が、「ShowNet」だ。ShowNetは会場ネットワークとして出展者や来場者に接続環境を提供すると同時に、先進的な、チャレンジングな技術を駆使して近未来のネットワークの姿を示す「ライブデモンストレーション」ともなっているが、そのShowNetでもZabbixが活用されている。「ShowNet2023における取り組みとZabbixの活用について」では、主に三つの側面から、Zabbixを使ってどのようなモニタリングが行われたかが紹介された。

ShowNetは、産学の垣根を越えて集まったトップエンジニア集団「NOCチーム」が核となって設計・構築・運用されるが、それだけでなく、製品・サービスを提供する多くのコントリビューターの支援と、一般公募で集まった「STMメンバー」によって作られている。Zabbix Japanもコントリビューターの一員として、この数年、ShowNetに携わってきた。

2023年6月に行われたInterop Tokyo 2023のShowNetには、3台の物理アプライアンスのZabbix Serverと、クラウド上にデプロイした仮想アプライアンスの計4台を提供し、ShowNetのネットワーク全体を監視した。

「Interopという展示会の特性上、ネットワーク機器の監視が非常に多かったのですが、それ以外にもサーバーや仮想基盤、さらに我々が持ち込んだセンサーの監視も行いました」（Zabbix Japanの水谷和弘氏）。イベントを検知するとSlackやWebEX、パトライトに通知を行うという、一般的な構成で監視を実施した。

ちなみに今回のShowNetは、ホスト数は約800、アイテム数は約27万、会期中の運用時のNVPS（一秒あたりのデータ数）は1400で、ホットステージと呼ばれる構築時には約3000NVPSに上るいう、比較的大規模な環境になる。わずか5〜6日程度でこの規模のネットワークを構築し、監視設定を投入していることも特徴だ。「自動化やネットワークディスカバリを活用し、さらに認定パートナーにもご協力いただいてなんとか構築しています」（水谷氏）

今回Zabbixは、ネットワーク全体の監視に加え、ファシリティの監視、そして放送局に見立てたMedia over IPという三つの領域でShowNetを支えた。それぞれの領域を担当するNOCチームメンバーが、各分野でどんなチャレンジに取り組み、それをZabbixがどのように支えたかを紹介した。

監視・モニタリングを担当した神山卓哲氏は、改めて「ShowNetは実験網でありつつ、幕張メッセという会場内の出展者や来場者へのインターネットサービスの提供も担っており、安定運用が必須です。そのため、監視が必要不可欠になっています」と述べた。

その監視を、Zabbixも含めた16社のコントリビュータが支援した。特にZabbixは、ICMPやSNMP、syslogなどを用いたネットワーク全体の監視・異常検知を行う統合監視を行った。

ShowNetにはまた、限られた期間で急ピッチで構築し、利用者も変動していくといった特殊性もある。「毎日のように監視要件・監視対象が変わり、その都度監視設計をしていくことが求められる環境になっています」（神山氏）。限られた期間内で監視条件をチューニングしきるのはなかなか難しい。「静観で問題ないアラートはその都度抑制していきますが、それでも、最終日までひたすらチューニングを続けていました」と同氏は振り返り、そうした知見を次のShowNetにも生かしていきたいとした。

また、ファシリティを担当した山﨑俊彦氏は、会場に設置したラックにさまざまなセンサーを設置し、収集したデータをZabbix上で一元管理したことを紹介した。

ShowNetの機器は幕張メッセの会場内に設置される。データセンターとは異なる過酷な環境で安定的に機器を動作させるため、ファシリティでは物理的なラックの設営や通電に始まり、設備を可視化して管理する「DCIM」（Data Center Infrastructure Management）に取り組んでいる。そのDCIMのソフトウェアツールとして、Zabbixが活用された。

幕張メッセのShowNetブースには、全部で18本のラックが設置される。そのラックに、温度や湿度、気圧、CO2などを計測するセンサーを60から80個設置し、情報をリアルタイムにZabbixに、それも波形やマップ形式でグラフィカルに表示させることで、状況を一目でわかるようにした。

「ラックの温度が35度を超えると、排気を上の機械が吸い込んでしまい温度がどんどん上がっていく悪循環に陥ります。そうした場合には、専用のフィルタでエアーフローを適切に作ってあげなければなりません。適切なラック運用を意識して、こういった波形をZabbix上で取り、構築・運用を行いました」（山﨑氏）

また今回ならではのユニークな試みとして、接点センサーをラックの扉に取り付け、活用した。SNMPのリクエストで一分感覚で情報を取得し、ラックの扉の開閉状況を遠隔から確認できる仕組みを構築し、作業時に間違って別のラックを開け閉めしていないかを確認できるようにした。さらにドアハンドルを組み合わせ、「ZabbixのGUIの画面からラック解錠のボタンを押すと、SNMPリクエストが飛んで、遠隔でラックを開けられるような仕組みも実現しました」（山﨑氏）

なお、CO2センサーを介して二酸化炭素の濃度を測定し、人流解析にもチャレンジしたが、来場者が押し寄せすぎてどのラックも似た波形になるという、痛し痒しの結果になったそうだ。

ShowNetのもう一つのチャレンジが「Media over IP」だ。拠点間における映像制作を模した環境を構築し、4Kの非圧縮映像を伝送するといったデモンストレーションを行った。

ここにどうZabbixが関わってくるかというと、PTPの監視だ。「映像制作においては、低遅延であること、そして非圧縮、もしくは圧縮率の低いコーデックで映像を伝送すること、そして高い耐障害性を備えていることが要求事項となります。フレームレベルの欠けもあってはなりません。そのためには正確なタイムスタンプを記録し、データの整合性をとることが必要不可欠です。そのためにPTPの監視をZabbixで行いました」（岩佐一樹氏）

Zabbixでは、PTPのグランドマスターやバウンダリクロックのマスター/スレーブの状況が一目でわかるように可視化。さらに、もし時刻同期のずれが閾値を超えた場合にはアラートを通知し、すぐに問題を検知できる形で監視を実施し、ずれを100ns程度に抑えつつ運用したという。

Zabbix JapanはShowNet 2024にもコントリビュータとして参加する方針だ。今回の経験も踏まえつつ、よりさまざまな監視方法を提案しながら取り組んでいければと考えている。「2024年6月であればZabbix 7.0がリリースされているはずです。次回はZabbix 7.0の新機能なども使ってShowNetを構築できればと考えています」（水谷氏）

広域でのデータ分散にZabbixを活用し、効率的でグリーンな処理に取り組むトヨタ自動車

毎年ラトビアで開催される「Zabbix Summit」には、世界各地からZabbixのユーザーやパートナーが集まり、最新動向やZabbixの活用方法についての情報交換が行われる。2023年10月に行われたZabbix Summit 2023では、日本から2人のスピーカーが発表を行った。

その一人が、トヨタ自動車の情報システム本部　情報通信企画部　InfoTech-IS　E2Eコンピューティンググループグループ長の阿部博氏だ。

阿部氏はInterop TokyoのZabbix社ブースでプレゼンテーションを行ったところ、Zabbix Japanの寺島氏から「Summitでも発表してみませんか」と声をかけられたことをきっかけに応募。リガに赴き、「Monitoring Green Power and Distributed Edge Computing Infrastructure with Zabbix」というタイトルで、トヨタ自動車がどのようにエッジ基盤でのデータ分散処理にZabbixを活用しようとしているかについて発表を行った。なお、ラトビアへの訪問は初めてだったそうだが、「素晴らしい国なので、ぜひ行ってみるといいのではないかと思います」という。

同氏は、現地での発表内容の抜粋も紹介した。

「トヨタ自動車というと、すぐ、自動車にZabbixを積んだのかと思う方がいるのですが、そういう話ではありません」（阿部氏）

現在、トヨタも含め自動車業界ではコネクティッドカーが一つのキーワードになっている。近年出荷される車にはDCMという通信モジュールが搭載され、車両の状態に関するデータはもちろん、プローブデータやセンサーの情報などが転送される仕組みだ。「コネクテッドカーの総台数と転送データの掛け算でデータはどんどん大きくなっていき、遅かれ早かれ、エクサバイトを軽く超えるような容量になるであろうというのが現状の予測となっています」（阿部氏）

このようにデータの転送量、処理量が増えれば、それを処理するコンピュータやネットワーク機器、データセンターはより多くの電力を消費することになる。これはそのままコストに跳ね返るだけでなく、自動車業界全体にとって大きな課題であるグリーンエネルギーの活用という観点でも問題だ。

そこでトヨタ自動車では、広域の複数のデータセンターにデータを配置し、夜間、あるいは太陽光発電で余剰電力が生まれている時間帯のデータセンターに処理を寄せることで、効率的に処理を行う仕組みを研究しているという。

具体的には、大手町と、さくらインターネットの石狩データセンターの間で、Apache Kafkaを用いてクラスターを構築して広域のデータ同期を行い、データがどこにあるかを意識することなく処理ができるようにした。その際、データの処理量や負荷、レスポンスタイムや電力消費を踏まえ、最適な負荷分散を行うために活用したのがZabbixだ。センターにメインとなるZabbixを置き、各拠点にZabbixのProxyを置いてエッジの基盤を監視することにより、各拠点の負荷を見ながら、ProducerとConsumerを効率的に調整し、負荷分散を行っていく、というコンセプトだ。

どこで制御するかについてはいくつかの選択肢があり、Zabbixでの監視で行う方法もあれば、監視のトリガーをコントローラーとして実装するなど、柔軟にシステムデザインができるのではないかと期待している。さらには、AI/ML基盤や天気予報の情報と連動するといった可能性も考えられるという。

さらに、今回PoCで試した日本国内での負荷分散だけでなく、世界規模での分散システムも視野に入れており、「ZabbixプラスZabbix Proxyを使って、スケーラビリティを考慮した分散設計を行えると考えています」とした。

こうした仕組みが実現できれば、文字通り「Follow the sun」で、よく晴れた場所を選び、太陽光発電の余剰電力がある場所に処理を動かしてグリーンエネルギーを積極的に活用したり、逆に、安い夜間電力が利用できる場所に「Follow the moon」へ処理を寄せることもできる。ひいては「処理をうまく効率化し、かつコストも安くして、グリーン電力を積極的に使うというアプローチが実現できるのではないかと、研究課題の一つとして取り組んでいます」（阿部氏）

3、進化を続けるZabbix、最新機能を活用してより効率的な監視を実現するポイントとは？(パートナー編)

Zabbix Japan LLCの寺島広大氏が述べている通り、Zabbixの価値は、Zabbixという会社単体で実現しているものではなく、関連サービスやソリューション、サポートを提供する多くのパートナー企業あってこそだ。

Zabbix Conference Japan 2023には、日本国内で長年にわたってZabbixの構築や運用支援、サポートサービスを展開しているパートナー企業各社も壇上に登場した。それぞれの知見やZabbixの最新機能を踏まえ、より効率的・安定的に運用するためのポイントや、AIや自動化ツールと組み合わせて可能性について紹介した。

ネイティブ機能を使いこなし、ノイズを排除した効率的な運用を

「監視運用者にとって、毎日は『通知との戦い』です。日々監視対象から大量の通知が届く中から優先度、重要度を判断し、順繰りに対応していかなければなりません」ーーSRA OSSのプリンシパルエンジニア、赤松俊弘氏は「運用の効率化に向けた通知の課題とZabbixでの対処法」と題するセッションでこのように述べ、Zabbixの運用・通知をどのように効率化していくべきか、ポイントを紹介した。

Zabbixで監視を行っていると大量の通知が送られてくる。その中には「ノイズ」も少なくなく、重要な通知が埋もれて見逃してしまう恐れもある。

そんなノイズを避けるためのTipsとして、赤松氏は、「トリガーの依存関係」、maxやmin、countといった「トリガー関数」の活用、「復旧条件式」の活用といったいくつかの方法を紹介した。例えばmax関数を利用すれば、障害を検知する感度は高いですけれども、復旧の感度は少し低くなる。また短期間の閾値またぎは抑制できるがスパイクは検知してしまう、といった具合だ。

こうした特性を踏まえ、検知したい障害やアラートを抑止したい状況に応じて使い分け、組み合わせることで、ノイズを減らして運用をより効率的にすることができる。

さらに、トリガーではなくアクション設定を活用し、エスカレーション機能を組み合わせて通知を抑制したり、出力されたログの件数をカウントする「log.countキー」やイベント相関関係を組み合わせることでも、ログやSNMPトラップで多発する通知を改善できるという。

同じくオープンソースソフトウェアの「AlertManager」を組み合わせることで、大量の通知を集約したり、アクティブ-アクティブ構成での通知をまとめることも可能だとした。

「Zabbixのネイティブ機能をうまく使うことで、通知の効率化はある程度可能です。しかし、すべての状況に当てはまる、すべてをうまく解決できるような解決策はなく、状況に応じて使い分けた必要になってきます」（赤松氏）。そして、もし「こんな機能があればいいな」と感じることがあれば、ZABBIX FEATURE REQUESTSにリクエストを投げてみてほしいと呼びかけた。

Zabbixとの組み合わせでPostgreSQLの安定稼働を支援

2012年からZabbixの取り扱いを開始し、2021年にからプレミアムパートナーとなった日本電気（NEC）の小塚妃那子氏は、「ZabbixでPostgreSQL監視の課題をサクッと解決！DB Monitor for PostgreSQLのご紹介」と題するセッションにおいて、あらためめてPostgreSQLをはじめとするデータベースの監視の重要性を説いた。

「監視をしなければ、データベースシステムの稼働に大きく影響し、性能劣化や異常といった障害が発生するとサービスの応答速度が低下したり、システムそのものが停止しまいます。結果として、お客様満足度の低下や収益の損失にまでつながってしまう可能性があります」（小塚氏）

もちろん、Zabbixは監視を通してそうした事態を避けるためのソリューションで、PostgreSQLの運用に活用しているケースも多いだろう。ただ、監視をしていく中では、データベース単位だけでなく、テーブルやユーザーといったもっと詳しい単位で状況を把握したいといったニーズも生まれる。

NECの「DB Monitor for PostgreSQL」はそうした課題を解決するツールだ。Zabbixと連携してPostgreSQLの監視を強化できる製品で、きめ細かな監視設定が可能なこと、スロークエリ監視やVACUUM監視といったPostgreSQLの運用で重要な項目をサポートしている点が特徴となる。

NECでは、24時間365日体制で技術的な問い合わせに答えるサービスや、コミュニティサポートが終了したバージョンのPostgreSQLに対し、個別にパッチを作成して提供するPostgreSQLパッチサービスといったさまざまな保守サポートサービスを提供し、PostgreSQLの安定運用を支援。合わせて、Zabbixの保守サポートも提供し、データベースそのものの運用と監視の両方をサポートしていくとした。

「Zabbixは難しそう」は勘違い、アイデア次第で広がる可能性

プレミアムパートナーであるアシストのZabbix技術担当、小野田純平氏は、「Zabbix機能のよくある勘違い3選～手ごわい機能の活用イメージを解説！～」と題するセッションで、Zabbixに関してよく勘違いが起こる「自動登録機能」「ローレベルディスカバリ機能」「マップ機能」の三つに関して、誤解を解きつつ活用イメージを紹介した。

自動登録に関しては、「ホストを登録して、テンプレートをリンクするだけでしょ」とよく言われるというが、それは勘違いだ。「他にも色々自動化できる部分があり、Zabbixにおける自動化の対象は、実は無限大と言えると考えています」（小野寺氏）。同社の中村静巴氏によると、Zabbixの設定のつながりを意識することにより、事前の設計次第で、インベントリ設定の自動化やマップ表示をはじめ、より多くの設定を自動化することが可能という。

またローレベルディスカバリ機能（LLD）については、ノイズが増える場合もあり、調整が難しく、使うのがちょっと怖いといった声も聞かれるというが、これも機能をよく理解し、フィルター機能やオーバーライド機能を組み合わせることで、不要なノイズを抑止したり、個別の調整を加えた形で設定することができる。「LLDを活用することで、不確定な情報や変化しやすい情報に対しても、柔軟に、工数を上げずに監視を実現できます。特に、クラウド系の監視に活用いただけると思います」（中村氏）

マップ機能に対しても、「参照するだけで、他に使い道はあるのか。そもそも手動で作らなければいけないので更新が大変だ」という声があるという。しかし実はコマンド実行機能を活用することで、マップ上のボタンを押すだけで障害発生時の初動切り分けに必要な情報を収集したり、設定情報を管理するといったことが可能だ。また、マップの自動作成・自動配置機能を用いれば、ホストの追加・削除に自動的に追随する形でZabbixのマップが作成される。

「Zabbixはできることが多い分、難しそうといった話をよくお聞きしますが、そんなことはありません。アイデア次第で、Zabbixの可能性はさらに広がっていくんじゃないかと考えています」（小野寺氏）

イベント駆動型Ansibleとの連携で、イベント通知後の一連の対処まで自動化を

一般的なシステム監視においては、対象のシステムを監視し、さまざまなアラートが上がってくるとそれを受けて人が内容を確認し、切り分けを行って然るべき担当に振り分けし、何らかの作業を行うことで対応が完了する。

このフローの中でZabbixは監視部分を自動化してくれるが、レッドハットのシニアソリューションアーキテクト、中島倫明氏は、「Zabbix x Ansible で実現する障害対応の自動化」において、さらにAnsibleを組み合わせることで、アラートが上がった後の一連のアクションを自動化できることを説明した。

Ansibleは、サーバーやネットワーク機器、クラウドなど幅広いインフラに対応した、IT基盤の構築・運用で発生するさまざまな作業を、「プレイブック」の記述に従って自動化するソフトウェアだ。「Zabbixが監視を自動化するものであるのに対し、Ansibleは、現場で発生する、人間が手を動かしている部分を自動化してくれるソフトウェアになっています」（中島氏）。そして、Zabbixが挙げてくるアラートなどをトリガーにして、動的にAnsibleを動かす、Event-Driven Ansible（EDA、イベント駆動型Ansible）を組み合わせることによって、一段と高度な自動化が可能になるという。

これまでのAnsibleでも、確かに、仮想マシンの起動やポートの開閉、ログの取得といった最後の作業そのものは自動化できていた。しかし自動化された処理を実施する・しないの判断や調整、連携はこれまで通り人間が行っていた。これに対し、Ansibleでは、エンジニアが何らかのアクションをとらなくても、APIを介して、自動的に作業を回したり、セルフサービス化できるような仕組み作りを進めている。

「システムから上がってくるイベントをベースに、条件に応じてAPIを叩くことができれば、自律的にイベントに対応し、いろんな作業を自動化し、より効率的な運用スタイルを築き上げていけるでしょう」（中島氏）

そのコアとなるのがEDAだ。このEDAとZabbixのイベントを連携させることによって、「そのイベントがソースとなり、あらかじめ定義したルールに従って、どんな自動化操作を行うかを判断し、AnsibleやAPI化された部品を通してアクションを起こしていきます」（中島氏）

たとえば、「ホストAのプロセス1が落ち、しかも重大な事態です」とアラートが上がってくれば、EDAを介してAnsibleがホストAのプロセス1を再起動する、といった処理を行うことも、あるいはチケットシステムと連動することも可能だ。しかも処理内容は固定的なものではなく、自由度高く設定できることが、この仕組みの強力なポイントだとした。さらに、「監視する人と対処する人が別々の組織でも、従来の責任体制を保ったままこういった自律的な仕組みを作っていけます」

ZabbixとEDAは、互いに認定済みのソリューションとなっており、現在、Zabbix 6.0と6.4向けにEDAを連携させるためのテンプレートが用意されている。「EDAを使って自動化すると、Ansibleが持つ強力な自動化機構を、イベント対応に使えるようになっていきます。サーバー、ネットワーク、クラウド、セキュリティ、エッジ、アプリケーションに関連するオペレーションまで、人間がコマンドを打って実行したり、APIを叩いて実行するものであればほぼ自動化できるため、多岐にわたる用途で使っていただけると思います」（中島氏）

Zabbixの安定稼働に不可欠なバックアップ、実施時に抑えるべきポイントは？

NTTコム エンジニアリングのZABICOMチームは、組織が同社に移管する前の2008年からZabbixに関連する構築事業などを手掛けてきた。同チームに所属する岩島琉偉氏は、「Zabbixにおけるデータ保全と安全な運用管理の考え方」と題し、可用性と保守性を備えたZabbixのシステム構築における留意点について紹介した。

「Zabbixでは、可用性を高めるために冗長構成を取ることができます。また、保守性においてはシステム更新をしっかり行うといった要素があります、そして、保守性と可用性、両方を担保するものとしてバックアップがあります。どれもシステムの安定運用には重要な要素です」（岩島氏）

その上で、保守性と可用性の両方を担保する仕組みとしてバックアップ、中でもミドルウェア層でDBMSの機能を用いたバックアップについて言及した。

一度にデータベース全体を取得する「完全バックアップ」はデータ構造を意識する必要がなく、完全なデータ復旧が可能といったメリットがある反面、データのサイズが大きくなるため負荷が高くなりやすく、データの取り回しが悪いといった課題がある。

一方、監視設定情報のみをバックアップする部分バックアップでは、負荷がかからずより多くの世代を保持できるが、バックアップ・リストア時にはデータベースのリレーショナルを考慮する必要がある。特に、監視設定の部分バックアップは安易に行うと予期せぬ動作を起こしかねず、監視データの除外や中間データの削除を行って、整合性を保つことが重要だとした。

さらに、部分バックアップを応用したZabbixのアクティブ-アクティブ構成では、監視設定を同期する際、障害情報に関連したテーブルやID管理情報のテーブルを単純に同期させるわけにはいかず、整合性に配慮する必要があるという。そして、NTTコム エンジニアリングでは、それぞれアクティブ-スタンバイ構成やアクティブ-アクティブ構成の同期に対応した「SyncConfig」「ReserveConfig」をはじめ、Zabbix運用を支援するさまざまなツールを提供していることも紹介した。

クラウドMSPサービスも支えるZabbix、人的ミスも排除しつつ24時間365日体制で監視

スカイ365のクラウドエンジニア、小藏風陽氏は、「クラウドMSP事業におけるZabbix活用の運用業務高度化～ミス改善の紹介、高度化したデモなどを紹介します～」と題するセッションで、同社がどのようにクラウドシステムの監視業務にZabbixを活用しているかを紹介した。

スカイ365は、資格保有者がクラウドシステムを24時間365日体制で監視するMSPサービスを提供している。その監視業務で活用しているのがZabbixで、「創業以来約10年間使い続けており、案件単位では1600件以上、台数では7500台以上を常時監視しています」（小藏氏）

自動化やサービスレベルの維持の重要性はオンプレミスもクラウドも変わらないが、クラウドの場合は、日々新たな機能のアップデートやサービスの追加があり、それに応じて顧客からの監視要望も変化していく。このため、開発風の運用が必要になることが特徴だ。

この特徴を踏まえスカイ365では、AWS環境にZabbixサーバーを配置し、チケット管理ツールなどとAPI経由で連携して監視を行っている。「クラウドであれば、一台のZabbixサーバーで何百案件の監視対象を同時に監視できます」（小藏氏）

同社のサービスでは日々、監視対象の追加や監視設定変更に関する依頼が多々ある。その際、人間が手作業で実施していては、「静観解除漏れ」などの設定ミスが生じる恐れがある。そこで同社では、スクリプトを定期的に回して設定間違いが疑われる状況を検知し、チケットを自動的に起票し、オペレーションルームのエンジニアが気付ける体制を整えている。「オペレーション品質向上のために、人間のミスはZabbix設定のチェックの自動化でカバーするように工夫しています」（小藏氏）

小藏氏は、今後のクラウドMSP業務は多様化と大量化に直面し、それをどう捌くかが問われていくだろうとした。同社では、「SkyCoodle」と名付けた運用監視システムの機能を追加し、オーダーマネジメントシステムによるセルフMSP化や、オブザーバビリティの実現、フィルタリングによる情報収集の最適化によって対応し、Zabbixをさらに活用していくとした。

非公式トレーニングプログラムで理解する、知られざる「メンテナンス機能」のツボ

SCSKに所属し、Zabbix認定トレーナーとして活動する片井隆元氏は、「マニュアルを読んでもわからなかった機能や、運用者側で管理が必要な機能について、包括的に知ることができてよかった」といった受講者からの感想・意見を踏まえながらトレーニングに携わっている。「研修の合間には、講師の経験に基づいた事例紹介などもやっており、それらが非常に参考になった」といった意見が寄せられたこともあるそうだ。

そうした経験を踏まえて片井氏は、「Zabbix 非公式トレーニングプログラム/メンテナンス機能」と題したセッションを実施。Zabbixのメンテナンス機能にフォーカスし、スペシャリストのトレーニングに模した形で6つの試験問題を用意。四問以上正解した来場者は「MAINTENANCE CERTIFICATE」として認定するという趣向で、機能を紹介した。

メンテナンス機能は、トリガーやアイテムに比べ、サポートサイトにある情報も、トレーニングカリキュラムの中で言及される内容もそれほど多くない。にもかかわらず、緊急の問い合わせは結構あるという。

ただでさえスケジュールがタイトな運用者にとっては、Zabbixだけに注力することは難しく、検証する工数もなかなか確保できない。この結果、仕様を知らないままメンテナンス機能を運用するパターンも少なくないという。だがその結果「設定に漏れが出てしまい、設定ミスによる障害アラートが誤発報してしまう事象がしばしばあります」（片井氏）。たとえ誤発報でも、クリティカルなシステムの運用では、別部隊への引き継ぎなどさまざまなオペレーションが発生するため、顧客が気にするケースは非常に多い。

片井氏は「メンテナンスモードが『データ収集あり』の場合は、アクション実行を抑止するために追加の設定をする必要がない。○か×か」といった問題を通して、意外と知られていないメンテナンス機能の仕様や設定に関する知識を説明し、「メンテナンス機能は、きちんと使用や機能を理解していれば面倒な事態は発生しません。ぜひ普段からメンテナンス機能のことを気遣って、設定運用をしていただければと思います」と呼びかけた。

EOLの到来で避けられないZabbixのバージョンアップ作業を確実に支援

SRA OSSのプリンシパルエンジニア、北川健司氏は、同社が提供する「Zabbix バージョンアップサービス」について紹介した。

SRA OSSは、Zabbix Japanができる前からパートナーシップを締結し、 Zabbixの設計・導入・構築支援を行うほか、PostgreSQLを組み合わせて付加価値をつけた形のZabbixのサポートサービスを提供してきた。最近では英語でのサポートも開始しており、2023年には「10th Annversary 2022 ベストテクニカルアワード」を受賞するに至った。

Zabbix関連サービスの一つが、 Zabbixバージョンアップサービスだ。Zabbixそのもの、あるいは Zabbixを動かすOSやハードウェアのEOLが到来したり、監視対象の拡大に伴ってハードウェアのパフォーマンスが足りなくなる、といったことをトリガーにアップデートを検討する企業も多いが、そうしたニーズに応えるサービスとなる。なお、 Zabbix 4.0 LTSに関しては、標準サポート期間が2023年11月で終了し、深刻度の高いバグの修正やセキュリティフィックスを含むアップデートは行われないため、注意が必要だという。

「現状を調査して、弊社のフォーマットによる設計、パラメータシートの作成、そしてバージョンアップ作業を行った上で、最後に調整作業を行います。そして監視試験を行い、正常稼働を担保した上でお客様にお渡しします」と北川氏は述べ、機器移行やミドルウェアの変更など、かゆいところに手の届くオプションも準備しているとした。

実運用への搭載を視野に入れて検証した、Zabbix×生成AIの可能性

世の中にはChatGPTに代表される生成AIの登場によってAIブームが到来し、IT業務の自動化・運用化を図る「AIOps」といった概念も登場している。SCSKの坂木翼氏は「このエラーコード何だっけ？」 Zabbix x GenerativeAIが疑問解消！監視運用自動化の新方式」というセッションで、Zabbixと生成AIとのシナジーでどのような新たな価値が創出できるかを検証した結果を紹介した。

坂木氏らはまず、Zabbixの機能のうち、メディアタイプとスクリプトという二つの機能について、AIの組み合わせが可能ではないかと考えたそうだ。

メディアタイプでは、障害が発生するとAPIを用いて障害の内容をAIに問い合わせ、障害画面のコメント欄に回答を書き込ませる。一方スクリプトの場合は、障害が発生したら手動でグローバルスクリプトを実行し、AIに発生した障害のトレンドデータを連携させ、問い合わせを行い、Zabbix APIを用いて応答を表示する。二つの方法を比較し、処理に時間はかかるが、実行のタイミングを制御でき、コストの増加を抑えることができることから、スクリプトを用いる方がいいという結論に至った。

その上で坂木氏らは、トレンドデータをAIに送付して未来の値を予測してもらう「未来値予測」と、あらかじめ対応方法を学習させておいたAIを用いて、検知したログ内容をもとに対応方法を案内させる「ナレッジ参照」という二つのユースケースを想定し、ZabbixとAzure OpenAIを組み合わせて検証を行った。

未来値予測の検証では、文字列入力時に送信できるデータのサイズに限界はあるが、「AIに判断させることで、オペレータによる判断の説得力が増すのではないかと考えられます」（坂木氏）。またナレッジ参照の検証では、学習データの作成にはコツがいるものの、「スクリプトでナレッジを参照できるため、Excelのデータの中をわざわざ探す必要がなく、初動対応時間の短縮につながると考えられます」（坂木氏）という。

今回の検証を通して、学習させた内容をうまく引き出すのは難しいと感じたものの、「今後は、回答制度を上げるための調査を引き続き行いつつ、実運用に載せたいと考えています」（坂木氏）。もちろん、セキュリティ面での配慮は必要だが、「その先では、障害発生後の動作確認やログ取得といった初動対応を自動化していきたいと考えています。夢は、完全なオートメーション化です」と述べ、さらに取り組みを続けていくとした。

バージョンアップに合わせ、監視設定もぜひ楽しみながら見直しを

NTTコム エンジニアリング主任で、2023年8月からはZabbix認定トレーナーを務め、ユーザートレーニングを担当している吉田剛太氏は、「今日から使える！Zabbix監視設定ノウハウの共有 ～ 進化に合わせた監視設定 ～」の中で、日々バージョンアップが重ねられているZabbixに合わせ、監視設定も折りに触れて見直し、進化させていってほしいと呼びかけた。

基調講演でも触れられている通りZabbixは日々進化している。テンプレートの数だけ見ても、3.0と6.0を比較すると約8倍に増加している。しかも「ただ数が増えているだけでなく、テンプレートの中に使われている技術もより進化したものになっており、新しい機能を使って監視設定をしているテンプレートが数多く作られています」（吉田氏）

だが現実の監視を見ると、安定稼働が求められることもあり、2.2や3.0といった時代に作られた監視テンプレートがそのまま引き継がれ、使われているケースが多い。「ですが、やはりこれはもったいない話です」（吉田氏）

同氏は、複数データの集計、そしてSNMPトラップ監視の汎用的な監視設定を例に挙げ、Zabbix 3.0以降のバージョンで逐次追加されていった保存前処理、マクロ関数、SNMP Discovery、集計関数といった機能を活用することで、同じ結果を得るのでも、より活用しやすく、メンテナンスしやすく、すっきりした方法が考えられることを説明した。

「複数データの集計をする場合、バージョン6.0ではforeach関数を用いるのがいいでしょうが、4.0や5.0にはこの関数がないため、discoveryキーと保存前処理を活用するのがいいと思います。ただ、Zabbixは進化するにつれて新たな機能が追加され、試してみるといろんな処理方法があることがわかります。面白いと思うのでぜひチャレンジしてみてください」

吉田氏自身、こうした課題があると、ある方法を試していったんは解決しても、また脳内会議を開いては別の方法、より良い監視設定を考え、試すということを楽しみながら繰り返してきた。「これが監視設定で一番楽しいところであり、Zabbixの醍醐味だと思いますので、ぜひみなさんにもチャレンジしてもらいたいと思っています。ぜひ一緒に、Zabbixの監視設定を楽しみましょう」

ITシステムだけじゃないZabbixの活用法、HEMS連携で家庭の節電意識向上も

Zabbixというと、いわゆるシステム監視に活用するものというイメージが強いかもしれない。しかし、アークシステムの小羽根陸氏によると、用途は決してIT関連だけとは限らない。現に同社は、引越し先の部屋を見つけたり、大気汚染量を監視してジオマップにまとめたり、河川状況を監視するといった幅広い用途にZabbixを活用し、その方法をZabbix Conferenceやブログで紹介してきた。「普段はシステム監視を行うZabbixですが、こんなに面白い使い方もできます」（小羽根氏）

今回は、家庭の電気設備に繋いでエネルギーの使用量を見える化し、各機器を制御してエネルギーの自動制御を行う「HEMS」（Home Energy Management System）とZabbixを連携させ、家庭の電気料を見える化することにチャレンジした。

実装は簡単だ。APIが利用できるHEMS機器を自宅に設置し、HTTPエージェントを使用して情報を取得するよう設定し、保存前処理を活用して必要な値を取得することで、リアルタイムの消費電力や月の積算電気料などが取得できた。実際に、自宅でリモートワークで仕事をしていた一日の電力測定値を可視化してみると、エアコンや電子レンジなどを利用したタイミングで消費電力が一気に上昇する様子までがわかったという。

さらに、計算アイテムを使用して毎月の電気料金グラフを取得したり、予測関数を使用して電気代が一カ月前に比べ1000円以上上回る場合は障害として検知させ、通知するなど、さまざまな活用方法を試してみた。Zabbix 6.0で追加されたベースライン関数を活用し、一年前など長期トレンドでの比較にもチャレンジしてみた。「障害を通知した際には、Webhookを使ってLINEで通知するように設定しました。家族全員に通知を飛ばすことで、電気節約意識が上がるはずと思っています」（小羽根氏）