Zabbix Conference Japan 2022レポート

1、より広く、より深いモニタリングを——これまでもこれからもぶれないZabbixのコアーー「Zabbix Conference Japan 2022」レポート

デジタルトランスフォーメーション（DX）やハイブリッドワークなど、今、さまざまな企業や組織が進めるあらゆる取り組みは、IT技術の上に成り立っていると言ってもいいだろう。これらIT技術が安定的に期待された役割を果たし続けるには、適切なモニタリングに基づく運用が欠かせない。

それを支えてきたオープンソースの監視ソリューション、「Zabbix」の年次カンファレンス「Zabbix Conference Japan 2022」が11月17日、18日に渡って開催された。

2022年は、Zabbixとして初の海外法人であるZabbix Japanの設立から10年目となる節目の年だ。久しぶりに来日したZabbixの創設者兼CEOのAlexei Vladishev氏は、「（日本法人代表の）寺島さんをはじめとするチームメンバー、そして日本のZabbixユーザーやコミュニティ、パートナーの方々に対し、これまでの支援に心からお礼を申し上げます」と述べ、ともに10周年を祝った。

進むDXの中、レガシーからクラウド、コンテナまで幅広い環境をサポート

Vladishev氏は講演の中で、あらためて「Zabbixは無償で、ユニバーサルで、かつエンタープライズレベルのオープンソースの監視ソリューションです」と強調した。

ITシステムはもちろん、ハイパフォーマンスコンピューティング（HPC）や組み込み、あるいはクラウドなど幅広い領域で活用されるほどユニバーサルであり、しかも、さまざまな既存のITインフラと統合可能だ。そして、データ収集とそれに基づく分析、トレンド予測やアラート、問題対応に至るまで、エンタープライズクラスのモニタリングソリューションに必要なすべての機能がオールインワンで提供される。

一方で、オープンソースソフトウェア（OSS）であり基本的には無償で利用できる。ライセンスの自由度も高く、監視対象のデバイスやサービスが増えても制限はない。それゆえにユーザーベースも広く、Zabbixに関するノウハウを持った認定エンジニアを探すのも容易だ。

Vladishev氏はこうした特徴を踏まえ、「Zabbixは、フリーかつ自由度が高いオープンソースで、Zabbix社やパートナーが提供するサポートサービスによる手厚い支援が受けられる商用ソリューションです。二つの世界のいいところ取りをしたソリューションと言えます」と述べた。

こうしたメリットが受け入れられ、Zabbixのユーザーはグローバルに広がっている。確実に把握しているだけでもFortune 500社のうち100社以上で使われている上に、米国のあるグローバル企業のように、1台のZabbix Serverで数十万台ものデバイスを監視するほど大規模に活用している事例も珍しくない。こうしたユーザーのニーズに応えるため、Zabbix社では日々、パフォーマンスの改善に尽力しているとした。

もう1つ、特に強化しているのが多様なプラットフォームへの対応だ。Vladishev氏は「ユーザーに選択の自由を提供することが重要だと考えています」とし、幅広いLinuxディストリビューションへの対応はもちろん、Dokcerイメージ形式で活用できるほか、Kubernetes環境、さらにAWSやAzure、GCPといった主要なクラウド環境にインストールし、モニタリングを行えることを説明し、次のように述べた。

「今、多くの企業はレガシーなシステムから新しいテクノロジへと移行するDXに取り組んでいます。Zabbixの利点は、旧来のテクノロジ、レガシーなシステムやアプリケーションだけでなく、クラウドやハイブリッドクラウド、Kubernetesといった新たなテクノロジ、両方をサポートすることです」（Vladishev氏）

そして今後も、インテグレーションチームを中心に、さまざまなサービスやアプリケーション、ネットワーク機器との統合・対応を進めていくとした。

すでにZabbix 6.2ではVMwareプラットフォームへの対応を強化し、より深くモニタリングが行えるようになったほか、Cisco MerakiやHPEのネットワークプラットフォームの監視、VeloCloudやKubernetes監視用のテンプレート強化を図っている。また、Amazon CloudWatchをはじめ、各種クラウドサービスが提供しているサービスのモニタリングや、ServiceNow、Jiraといったチケット管理製品、あるいはSlackやMicrosoft Teamsなどのコミュニケーションツールとの連携も進めているという。

Vladishev氏は合わせて、Zabbixのセキュリティ面での取り組みについても紹介した。「今やセキュリティは非常に重要な課題です。Zabbixでは専門のセキュリティチームを立ち上げ、高度なセキュリティ標準に沿ってZabbixを開発するとともに、Zabbixインフラの保護に努めています」という。

具体的には、最小権限の原則に基づき、Zabbixエージェントはroot権限がなくてもインストールできるようになっている。Zabbixのコンポーネント間の通信はTLSやHTTPSによって暗号化され、管理インターフェイスを利用するには二要素認証が必要だ。そして、パスワードやAPIキー、トークンといったZabbixに関連するセンシティブな情報は、外部のシークレット管理ソリューションと連携し、安全に保管する仕組みを整えている。

近年では、OSSに存在する脆弱性を狙った不正アクセスも増えている。Zabbixでは、HackerOnetと連携してバグバウンティプログラム（脆弱性報奨金制度）を開始したほか、脆弱性情報をセキュリティアドバイザリーの形でWeb上で公開し、Zabbix本体はもちろん、依存するソフトウェアで発見された脆弱性情報も把握できる体制を整えた。

さらに「高いセキュリティスタンダードに沿ってZabbixを開発していくことも重要で、年内にISO 27001認証を取得する見込みです」（Vladishev氏）とし、引き続きセキュリティの確保に取り組んでいくとした。

ユーザー視点での監視やプロキシの無停止アップグレードなども——多数の新機能を盛り込む6.4

続けてVladishev氏は、今後のロードマップについて紹介した。Zabbixにこれからどのような機能を搭載していくかについては、基本的に同氏が責任を負っている。ただ、ユーザーやパートナーが「Feature Request」というチケットを作成し、「こんな機能が欲しい」と思ったチケットに投票する仕組みが用意されており、これが優先順位を決定する要素の一つとなっているという。

毎回そうだが、Zabbixはバージョンアップのたびに多くの新機能を追加し、機能改善を施してきた。バージョン6.4では、

• スクリプト機能の追加：複数のステップによって構成される複雑なモニタリングシナリオを定義し、それに沿ってデータの収集・監視が可能になる
• ブラウザエミュレーション：WebアプリケーションやWebサービスをエンドユーザーの視点でモニタリングできるようになる
• イベント分類の追加：単純に「問題」として通知するのではなく、根本原因を示す「cause」と、それによって引き起こされる「symptom」に分けて把握できるようになる

といった機能が追加されるほか、相関分析エンジンの強化、可視化機能の強化など、盛りだくさんの機能強化が図られる予定だ。

中でも、運用を担う現場の担当者にとって歓迎されそうな機能が、「Zabbixプロキシの無停止アップグレード」や「監視設定の即時同期」だ。

「現時点では、Zabbix ServerとProxyは同時にアップグレードしなくてはなりませんが、6.4ではそれを非同期で行えるようになります。まずServerをアップグレードしてから、順次、複数のProxyをアップデートすることが可能です。しかもその間、プロキシは継続してデータ収集・処理が行えます」（Vladishev氏）

また、構成変更に応じて監視対象に新しいデバイスやアイテム、トリガーを追加した際には、すぐにその情報がプッシュされ、スピーディに構成変更が反映される。「数時間ではなく数分でデータ収集が行えるようになります」（Vladishev氏）

さらに、7.0での実装が予定されていたテンプレートのバージョン管理も繰り上げて搭載される。「テンプレート管理がより簡素化され、どの種類の、どのバージョンのテンプレートを使っているかを把握し、どれをアップグレードすべきかがわかりやすくなります」とVladishev氏は述べた。

その先の7.0でも、クラウドやKubernetesの監視および可視化の強化に加え、イベント相関分析エンジンの強化など、多くの機能が搭載される予定だ。そしてその先では、「Zabbixでセキュリティやコンプライアンスのモニタリングも行えるようにしていく計画です。また、APMやトレーシング、オープンテレメトリスタンダードとの統合なども計画しています」とし、引き続きたゆまぬ強化を進めていくとした。

10年を経て、単なる「サポート」のイメージを越えた包括的な支援を提供するZabbix Japan

Zabbix Japan代表の寺島 広大氏がZabbixと出会い、大きな可能性を感じてラトビアに足を運んだ後、日本法人を立ち上げたのは2012年のことだ。これはZabbix LLCにとっても初めての海外法人だった。それから10年、サポートとトレーニングという2つのサービスを中心にZabbix Japanは順調に成長を遂げている。

「これまで、Zabbix Japanに寄せられた問い合わせ件数はトータルで1万4000件に上ります。実際にはパートナー様で解決した問い合わせもあり、相当な数のお問い合わせをいただいています。また、Zabbixのトレーニングは約4000人に実施してきました」（寺島氏）

寺島氏がZabbix Japanを立ち上げてから今に至るまで、たびたび尋ねられたのが「果たしてOSSを扱っていて、ビジネスとして、会社として成り立つのか」という質問だったそうだ。だが寺島氏は、この話題は今年でもう終わりにしたいという。「パートナーも売り上げも順調に伸びており、会社として十分安定し、成り立っています」という。

Zabbix Japanの事業の大きな柱がサポートだ。設立時には「シルバー」「ゴールド」「プラチナ」という3つのプランを用意してスタートしたが、その後、さまざまなニーズに応えながらサポートメニューを拡張してきた。

その1つが「ベーシック」プランだ。提供の契機となったのは、2013年に日本で独自に販売を開始したZabbixアプライアンスの存在だ。「ハードウェアおよびファームウェアのサポートに、Zabbixを知らない人に向け、3時間で『どこから設定すればいいか』がわかる入門トレーニングを付けました」（寺島氏）。同時に、ファームウェアなどのダウンロードが可能なカスタマーポータルも構築した。

サポートメニュー自体も拡張していった。problemテーブルのレコード肥大化問題を解消する機能なども盛り込まれている「Zabbix-enterprise-utils」や「設定バックアップツール」など、Zabbix運用においてかゆいところに手の届くツール群も提供している。

さらに2022年5月には、元々はパートナー向けに実施していた「勉強会」を、「ショートトレーニング」という形でゴールド・プラチナサポート向けに提供を開始した。

寺島氏は、「サポートに入っている方向けに、さまざまなツールやトレーニングを拡充する取り組みを進めてきた10年間でした。これからの10年間もこれまで地道にやってきたことを続け、サービスや支援を強化していきます」と述べ、Zabbix Japanでは補えない部分はパートナーの力を借りつつ、引き続きメニューを拡充していく方針を示した。

一般にサポートというと、トラブルが発生した時の技術的な問い合わせ対応、というイメージが強い。だが寺島氏はそのイメージを変えていきたいという。

具体的には、ツールやトレーニングなども合わせて提供するさまざまなサポートの集合体として、「サポート＆サブスクリプション」という名称に変更し、今後も高い顧客満足度を維持していきたいとした。合わせて、日本の顧客から寄せられたさまざまな要望を本社に橋渡しする役割も強化し、コミュニケーションを図っていく。こうした取り組みを通して、引き続きZabbixの顧客を支援していくと宣言した。

2、環境が変化しても基盤を支え続けるZabbix、その最新動向を一挙紹介

Zabbix 1.0α1がリリースされてから20年以上、そして日本法人であるZabbix Japanの設立からちょうど10年という節目の年を迎え、「Zabbix Conference Japan 2022」が2022年11月17日、18日に開催された。クラウドサービスが浸透し、モバイルやリモートワークを含む新しい働き型が広がるなど、この間にはIT環境も社会環境も大きく変化したが、Zabbixは少しずつ進化し、パートナーを増やしながら新たなニーズに応えてきた。セッションではそうした最新動向・ソリューションや活用事例が紹介された。

Zabbix 4.2からデータベースとしてサポートされた「TimescaleDB」、その実力は？

Zabbixをはじめとするオープンソースソフトウェアの構築・サポートを提供しているSRA OSS LLCでマネージャを務める赤松俊弘氏は、「ZabbixにおけるTimescaleDBの利用方法とパフォーマンス」と題し、Zabbix 4.2以降で新たにバックエンドデータベースとしてサポートされたTimescaleDBを採用した場合、パフォーマンスはどの程度向上するか、実際に試してみた結果を紹介した。

TimescaleDBは、PostgreSQLの拡張モジュールとして開発された「時系列データベース」だ。名前の通り時系列データを扱うことに特化しており、使いやすさとスケーラビリティ、信頼性の高さが特徴だ。

TimescaleDBは、全体の時系列データを管理する「ハイパーテーブル」と一定期間のデータのみを保持する子テーブルである「チャンク」というアーキテクチャで構成されている。このため、Zabbixのバックエンドデータベースとして活用する際には、保存期間を過ぎたデータベースを定期的に削除する「Housekeeper」処理時の負荷を抑えられる他、圧縮機能を用いてストレージ容量を節約できることなどが利点だ。ただ利用に当たっては、ZabbixとPostgreSQL、TimescaleDBそれぞれについて、どのバージョンが対応しているか確認する必要がある。

赤松氏は、Zabbix 6.0.9でホスト数500、アイテム数3万5000という検証環境を用意し、TimescaleDBを利用した場合にどのくらいパフォーマンスが改善するかを検証。PostgreSQLでは一回のHousekeeperに約20時間かかっていたのが、わずか約6.9秒で、ほとんど負荷がかからずに処理できることが確認できた。history Syncerプロセスでのデータベース書き込み負荷やCPU負荷も抑えられることが明らかになった。

「PostgreSQLとパフォーマンスを比較した結果、履歴データについては削除処理は大幅に、データ更新・挿入の処理も比較的負荷を軽減できることが観測できました。TimescaleDBをZabbixのデータベースとして利用することにメリットを感じていただけるのではないでしょうか」（赤松氏）

「担当者が限られる」「設定が複雑、面倒」という声を解決するEnterpriseサポート

Zabbix日本法人の設立以前から認定パートナーとなり、Zabbixパートナー会の幹事会社でもあるインフォコムの上級主任、吉田和也氏は、「Zabbixの分からないを解決。Zabbix Enterpriseサポートのご紹介」と題し、実際にユーザーから寄せられた声を元に、監視システムにどのような課題がつきまとっているかを説明した。

同社がカンファレンスで行ったアンケートによると、2018年も、また3年後の2021年でも、「分かる担当者が限られてしまう」「設定が複雑、面倒」といった声が多く寄せられていた。「Zabbixの設定が複雑・面倒だったり、担当者が限られてしまうという課題がなかなか解決できず、ずっと残っている状況が伺えます」

この状況に対してインフォコムでは、オフィシャルサポートの1つである「Zabbix Enterpriseサポート」の活用を推奨している。サポートを導入することで、技術的な問い合わせへの対応が得られるだけでなく、Zabbix社が公開しているナレッジベースや各種ツールが活用できる。特に、監視設定のバックアップ・リストアができ、履歴を残しておける「Zabbix設定バックアップツール」の利用は非常に多いという。

インフォコムではさらに10年にわたるサポート経験をベースにした知見、ノウハウを生かし、顧客が目的を達成するための支援を提供していくとした。

枯れたバージョンよりも最新版を——顧客が抱く、素朴な悩みへズバリ回答

長年システム監視設計業務に携わってきたアシスト主任の塩澤正寛氏は、「Zabbixを使う時にはココを検討！実際に頂いたリアルなお悩みポイントを解説」と題し、実際に寄せられた声に基づいて、「環境構築」「機能」「運用」という3つの観点で顧客が悩みがちなポイントへのアドバイスを紹介した。

まず環境構築に関しては、「どのバージョンを採用すればいいか」という声が多いという。しばしばITの世界では「枯れた」1つ前のバージョンが好まれるが、Zabbixに関しては「今後のバージョンアップ対応やその頻度を考えると、新しいバージョンの方がいいとご案内しています」（塩澤氏）。また、他の監視ツールから移行する場合には、監視項目や通報・通知方式の机上検討にはじまり、エージェントの同居の可否や並行稼働期間のタイミング、配布方法など、さまざまな事柄を事前に確認、検討しておくことが重要だとした。

機能面でもさまざまな質問が寄せられるという。中でも「テンプレートはどのように使えばいいか」という声が多いそうだ。Zabbixでは柔軟にテンプレートを活用できるがゆえの疑問だろう。塩澤氏は、デフォルトテンプレートに加え、一部にカスタマイズを加えた「カスタムテンプレート」、自作する「個別テンプレート」と、OS種別ごとのテンプレートを、監視項目別に割り当てることがポイントであり、将来的に監視対象を追加する際の展開も容易になるとした。

最後は運用面だ。ここでよくある疑問が「監視抑止の恒久対応、一次対応はどのように行うか」だという。監視の抑止は、Zabbixの管理インターフェイス上で手動で行えるほか、スケジュール設定やトリガーの内容に手を加えることでも対応できる。ただ、塩澤氏は「ユーザー目線では、緊急対応や夜間対応時の監視の抑止は確実に対応していく必要があります。ですので、どうやってミスなく抑止し、また抑止したものを解除できるかがポイントになるでしょう」とし、JP1のような他のツールと連携して一括管理することも1つのやり方だと紹介した。

グラフィカルなレポート作成を支援する「ExReport」など、ツボを押さえたツール群

2007年から、Zabbixを活用してのシステム・監視サービスを「ZABICOM」という名称で提供してきたNTTコミュニケーションズのインフラエンジニア、坂井佑至氏は、「痒いところに手が届く！NTTコミュニケーションズオリジナルのZabbix拡張機能のご紹介」と題し、同社が独自に開発したZabbix拡張機能を紹介した。

1つは、定期的に作成するレポートの素材となるグラフをまとめて出力できる「ExReport」だ。Webインターフェイス上で、出力したいデータと期間を指定すると、当該のグラフと元のデータがエクスポートされる。すでに官公庁や金融・製造業などで活用されているという。

2つ目は、多数の拠点にまたがり、監視対象機器の状態を3次元情報で表示する「T-View」だ。Zabbixの情報を元に現在のネットワーク構成を3次元で可視化し、さらに障害情報やトラフィック情報を重ねて描画できる。また、過去の障害発生状況を後から確認できる「リプレイ再生機能」も備えており、Interop 2022のNOCでも活用されたという。

3つ目は、大量のアラートを1つにまとめ、ホストグループ単位で障害イベントの中身と件数を確認できるようにする「GatherAlert」だ。似たようなアラートが大量に送信され、本当に重要な障害通知を見落としてしまう、といった事態を避けることができ、メール基盤への負荷も軽減できる。平日・休日の区別や時間帯に基づいて通知先を振り分けることも可能となっている。

同社ではさらに、Zabbixの設定情報や監視データのバックアップを行ったり、ネットワーク機器のポート管理表やラック搭載図を自動生成するツールなど、ニーズに合わせてさまざまな拡張ツールを作成、提供している。

Zabbixの冗長化方式は一長一短、各々の特徴を理解した上で選択を

アークシステムのシステム構築スペシャリスト、新井健志氏は、「Zabbix環境の冗長化手法 早わかり解説！ ～Native HAってどうよ？～」と題し、Zabbix環境を冗長化する複数の方法と、それぞれのメリット、デメリットを解説した。

まず最初の選択肢は、Zabbix 6.0で登場した「Native HA」だ。Zabbixの標準機能として、アクティブスタンバイ方式でのフェイルオーバーが可能になる。ただ「フロントエンドやZabbixデータベースといった部分には冗長化機能は提供されないため、AWSやAzureを初めとするクラウド環境と組み合わせるか、Zabbixデータベースに何らかの形でマネージドサービスを組み合わせるといった考慮が必要です」（新井氏）。また、重複検知の抑止についても考慮などが必要だとした。

2つ目は、RedHat High Availabilityアドオンなどのソフトウェアを使ってHADクラスタを構築する方式で、クラウド環境はもちろん、オンプレミス環境での運用にも適しているという。そして、「オンプレミス環境の場合は、データベースが単一障害点とならないように高可用性ディスクを利用したり、Zabbixデータベースの冗長性を何らかの形で担保するといった配慮が必要です」と新井氏は説明した。

3つ目は、Zabbix Japanが提供する「設定バックアップ同期ツール」を用いた、アクティブ-アクティブ方式での冗長化だ。2台のZabbixサーバが同時に動き、同時にデータを収集するため、理論上、障害発生時のダウンタイムは発生しない上に、異常検知時の重複・欠落もない。前提としてZabbix Enterpriseサポート契約が必要になり、トラフィックや監視の機器の負荷が2倍になり、発報抑止や監視設定の整合性確保といったポイントがあるものの、「現時点ではこの方式が一番やりやすいと考えています」（新井氏）

一方でNative HA方式については、データベースがマネージド環境で提供されることも含め、クラウド環境での導入に優位点がある。こういった特徴を踏まえ、冗長化方式を選択することが重要だとした。

広がるクラウド活用、Zabbixから監視を行う際のポイントは？

クラウド環境の活用が広がる中、クラウド環境でZabbixを使いたい、あるいはクラウド環境の監視をZabbixで行いたいといったニーズも高まっている。Zabbix Japanでサポートエンジニア兼トレーナーを務める渡邉隼人氏が、「クラウドで使用するZabbixの機能Tips」と題してそのポイントを紹介した。

渡邉氏によると、「オンプレミス環境にあるZabbixサーバからクラウド上のZabbixエージェントの監視はできますか」という質問がしばしば寄せられるという。答えは「イエス」だ。クラウド上の仮想マシンにZabbixエージェントをインストールすれば、さまざまなリソースやログの監視が行える。また、その通信は暗号化できるほか、Zabbixのプロキシを間に置くことで、データをいったんまとめた上でZabbixサーバに送信させる形とすれば、データロスを抑えつつ転送容量の節約が可能になるという。

また、Zabbix 6.0から実装されたZabbix HAでは、アークシステムの新井氏も説明した通り、サードパーティ製のツールなどを別途組み合わせる必要なくZabbixの冗長化が行える。ただ、Zabbixデータベースの冗長化までは行わないため、ここが単一障害点になる恐れがあった。そこを補う手段として、Amazon RDSをはじめとするクラウド事業者が提供するデータベースサービスを組み合わせる、という手がある。書き込むデータ量に見合ったスペックかどうかといった注意点はあるものの、基本的には問題なく動かせるという。

ただ、クラウドサービスにはIaaS以外に、エージェントのインストールができないSaaSや一部のPaaSも多々あり、これらの監視を行いたいといった要望も少なくない。「そういったサービスについては、サービス提供元からAPIが提供されていると思います。ZabbixではAPI連携を行ってそれらを監視できます」（渡邉氏）

そしてZabbix 6.2では、AWSとAzure向けの監視テンプレートが標準テンプレートに追加された。Zabbix社が標準で提供するため、これらを利用していれば問い合わせ対応をはじめとするサポートの対象となる。ただ、このテンプレートは、Zabbix 6.2で追加された関数を組み合わせることでクラウド監視を実現しているため、残念ながら6.0ではそのまま使うことはできない。もし利用したい場合には、ポイントリリースではあるがZabbix 6.2へのバージョンアップが必要になるという。

渡邉氏は最後に「長期的に利用したい場合には、7.0のLTSのバージョンから使っていただくことになると思いますが、そのころにはテンプレートがもっと充実し、さらに使いやすいものになってくるでしょう」とした。

先入観を持たず、運用以外の幅広い領域でZabbixを活用する三菱UFJ

Zabbixというと、運用フェーズでITシステムの監視に活用するもの、というイメージが強い。もちろんそこでも有効活用できるが、MUFGグループのITを担う三菱UFJインフォメーションテクノロジーのシニアITスペシャリスト、勝野基央氏は「運用フェーズやシステム部門以外でのZabbixの活用」と題し、意外な領域でのZabbix活用例を紹介した。

1つ目は、いわゆるATMシステムの監視業務だ。さまざまな店舗に置かれているATMは、バックグラウンドのサーバ群と連携しながら稼働している。サーバ群についてはZabbixや他の製品を用い、システムの稼働状態を監視していたが、全国に点在するATMについては、横に置かれているインターホンを介してコールセンターに連絡が行き、そこから状況を把握する形となっていた。このため、人と人を介したコミュニケーションの中で伝言ゲームのような形になってしまう課題があったという。

「トラブルが起こったときに最適な対処を行うには、サーバやハードウェアの状態だけでなく、末端の現場の状態、業務の状態を踏まえて複合的な視点で見ることが必要です」（勝野氏）。そこで、実際のATMの状況などを簡単に把握できるアプリケーションを用意すればいいのではないかという考えから、Zabbixの活用に思い至ったという。

「今、ATM端末が何台稼働し、何台止まっているか、それはどのサーバの配下で起こっているかといった情報を、Zabbixを活用して自動的に取得するようにしました。またダッシュボードを整形し、ITにあまり関わりのない業務統括部門にも受け入れやすい形を取りました」（勝野氏）

この取り組みを通じて、「Zabbixはシステム運用部門が監視に使うものというイメージが非常に強いと思いますが、業務アプリケーションライクに利用できる可能性も秘めていると感じています」と勝野氏は述べ、インフラエンジニアだからこそ提案できるソリューションがあるのではないかと呼びかけた。

2つ目の取り組みは、RPA、いわゆるロボットの動作に対する監査指摘対応だ。同社グループではさまざまなRPAを開発し、ファットクライアント、つまりパソコン上で動作させている。その数はすでに300台を超えており、さらに週に10台といったペースで増えている状態だった。これらのRPAの稼働に対し、サーバと同様に「きちんと動作しているか、リソースは正常か、また不正なログインはないか」といった事柄を見るべきだと、監査の中で指摘されたという。

そこで解決策として採用したのが、使い慣れているZabbixだ。さらにAnsibleを組み合わせ、Zabbixのエージェントのインストール、エージェントの起動、Zabbixへの登録といった一連の流れをボタンを押すだけで自動的に導入される仕組みを整え、担当者が詳細を認識しなくとも自動的に監視を開始できる体制を整備した。

今では400台を超えるRPAの監視を行っているが、「AnsibleやZabbixを組み合わせることで、1台当たり1時間以上かかるような作業を自動化でき、コスト効果も発揮できています」（勝野氏）。副次的な効果として、今まで知見を持たなかった部署がわかりやすいWeb GUIに触れることで、新たに「こういうことをやれないか」「こういったところを楽にできないか」といったアイデアが出てくるようになったという。

3つ目は開発フェーズでの活用だ。同社グループでは前述の通りRPA開発が盛んに進められており、常時50名から100名が並行して開発プロジェクトを進めている。運用フェーズに入ったシステムには監視部門があり、常時監視を行っているが、開発環境となるとそこまで目が行き届いているわけではない。このため開発環境で障害が起きてしまうと、業務影響こそ生じないもののプロジェクトには大きな影響が生じていた。また、障害に気付いた担当者が個別に問い合わせを寄せるため、「そもそも開発環境で一体何が起きているか」という全体の状況も共有できていなかったという。

そこでやはり活用したのがZabbixだ。Zabbixで障害を検知すると、API連携によってRedmineにチケットを登録し、インフラ部署とRPAの開発を行う部署の関連するメンバーに通知が行く仕組みを構築した。このチケットを参照することで、トラブル対応に着手しているのか、解消しているのかといった進捗が確認できる。これにより、関係者で状況を共有し、さらに対応に当たる担当の明確後、クローズまで着実に管理を行える仕組みが整った。

勝野氏は最後に「Zabbixというと、システムが稼働しはじめた後に運用部門が活用するものという色合いが強いものですが、多様な場面で活用できるポテンシャルを持っています。先入観を持たずに、どういった場面で使えるかを検討できるといいと思います」とした。さらに、部署の垣根を越えてフロント側にもソリューションを提案することで、より大きな効果を得ることができるとした。

誰もがぶつかるZabbix運用の最初の壁？　データベース肥大化に立ち向かったエーピーコミュニケーションズ

エーピーコミュニケーションズでサーバインフラエンジニアとしてシステムを支えている池上裕幸氏は、まだZabbixの経験自体は数ヶ月で「初心者」だという。同氏はZabbixデータベースの肥大化と、それに伴って発生した事象にどのように対処したかを「Zabbix初心者が課題対処（DB肥大化・新規構築）から学んだ・学んでいること」で紹介した。

トラブルのはじまりは「Zabbixの動作が遅い、ログインできない」という連絡を受けたことだったという。調べてみると、Zabbixデータベースを動かすサーバのディスク領域が100％使われていることが判明した。領域自体が書き込み不能となっており、ダッシュボードへのログインすらできない状況になってしまっていたそうだ。

池上氏は取り急ぎ、データベース以外のファイルを別領域に退避させ、調査に取りかかった。調べていくと、データベースのテーブルも破損し、監視機能不全の状態に陥っていることも判明した。「そもそもディスク領域が逼迫したのはなぜかを調べるため、サイズの大きいファイルを確認したらすぐに該当のものが見つかりました。history_logのテーブルのデータファイルが100GBを超える容量になっていました」（池上氏）

この状況がいつ発生したかを追ってみたところ、ネットワークの利用状況の変化にともなって監視データが増加し、それがhistory_logテーブルを大きくしていたそうだ。

池上氏は根本的な対策に向け、history_logテーブルのサイズを縮小できないかあれこれ試してみたものの、芳しい効果は得られなかった。結局、Zabbixデータベースのストレージエンジンとして採用していたmyisamの仕様上、いったん記憶領域として確保された領域を解放するにはテーブルの再構築が必要と判明。監視を止めるわけにはいかなかったため、新たにZabbix 6.0 LTSで、データベースにMariaDB、ストレージにinnoDBという組み合わせで新規環境を構築し、監視機能の移行を進めているという。

新規環境の構築に当たってはこの教訓を踏まえ、Zabbix自体のチューニングに加え、InnoDBでも定期的にData Freeの領域を解消させる処理を追加したり、ディスクの空き容量を確保した上でテーブルの再構築を行うなど、さまざまなところに気を配っている。

池上氏は「Zabbixの運用上、ディスク領域の管理や定期的なメンテナンスも重要であることを実感しました」とのべ、引き続き、新旧環境の差分を補い、本当の意味で監視ツールとして扱う知識やノウハウを身につけるべく、地道に学び続けていきたいという。

Nagios、Cactiも入り交じる30環境をZabbixに統合したNTTコミュニケーションズ

NTTコミュニケーションズではさまざまな保守運用業務を通してITインフラの安定運用を支援している。同社の今井聡氏は、Zabbixのほか、WATT、Nagios、Cactiといった複数の監視マネージャが入り交じる状態となっていた約30種類の監視環境をZabbixに統合するまでのプロセスを紹介した。

今井氏が所属する保守運用チームでは、保守センターを通して23社の環境を監視してきた。ただ、従来の監視マネージャーはシングルポイントで動いており、もし壊れてしまった場合は夜間でも駆けつけて対応していたという。また基本的には一対一の関係で監視を行っており、顧客が増えるにつれて監視サーバも、また見るべき監視マネージャーも比例して増えていく状態となっていた。結果として、それらが動くサーバの保守・サポート期間も課題となっていたという。

さらに「会社の命題として、コスト削減のために自動化したいという要請もありました。しかし個社ごとに監視マネージャーが別れているだけでなく、通知メールのフォーマットや監視項目もバラバラで自動化がしにくい状況でした」（今井氏）

そんな中でも何とか自動化しやすくし、駆けつけ対応も減らすために同氏が考えたのが、乱立していた監視マネージャのZabbixへの統合だ。当初は10案件程度の統合を提案したところ、上司からは何と全案件、30案件を統合して欲しいという返事が返ってきて「頑張って対応しました」という。

統合後の環境では、物理サーバ上にHyper-Vを搭載し、その上にZabbixを構築し、約3万8800ホスト、12万4800アイテムを監視対象にしており350VPSの性能を確保している。それまで個別に表示していた監視画面もZabbixの画面上で複数社の状況を表示できるようになった。またHAクラスタソフトの「Pacemaker」を利用して冗長化も図っている。

構築に当たっては、ストレージで採用したiSCSIをDACケーブルで利用した際のみに生じる特殊なバグに遭遇した場面もあり、メーカーと連絡を取りながら解決に当たったという。ユニークな点として、基本的にHyper-Vの基盤としてのみ使うことから、GUIを持たずCUIで構築される「Windows Server 2019 Core」を採用した。必要なリソースが少なくて済み、モジュールも少ないためセキュリティアップデートも少なくて済み、リスクも低いといったことがメリットだ。

30案件を18カ月で移行する、つまり1ヶ月に1案件以上移行するというある意味強行スケジュールだったため、移行時にもさまざまな知恵を絞った。特殊なものは除いて、極力共用利用ができるよう標準テンプレートを作成したり、同社のZABICOMチームから提供を受けたツールを活用してホストやインベントリ情報の一括登録を試みたりと、なるべく効率的に進める方法を模索した。ただ、さすがに1万ものホストのインベントリを一気に登録したところキャッシュがあふれてしまい、Zabbixサーバが停止する状態に陥ったという。「横着はだめということがよくわかりました」（今井氏）

また3万8000件を対象にpingをするとプロセスが足りなくなり、やはりエラーが生じた。「リソースだけでなく、プロセス数などそれ以外のところもきちんと見なければいけません」（今井氏）。こういった課題に直面するたびに設定を見直し、チューニングすることで対応した。また、ZabbixとNagiosとで監視間隔の設定が異なることを踏まえ、「最長検知時間」を合わせる工夫も行ったという。

今も移行作業は続き、残り4カ月で7案件というところまで来た一方で、統合後の環境の運用もスタートしている。運号フェーズでも無駄なアラート・通知を省くため、たとえば問題を手動で復旧させた場合にはSNMP Trapで回復メールが飛ばないよう通知抑止を行ったり、Zabbix Senderのコマンドを利用し、故障を通知するメールにtracerouteの結果を付け加えて送るようにするなど、運用現場で求められるさまざまな機能を追加した。こうした工夫を凝らしながら、全30案件の移行を引き続き進めていくという。

3、1997年に書き始めたコードから始まったZabbix——小さな一つのアクションがもたらした大きな変化

ITシステムというものが存在する限り、運用監視という役割もまた、なくなることはないだろう。「Zabbix Conference Japan 2022」の2日目には、その重要な任務を担うZabbixがどのようなきっかけで生まれ、世界中で使われるまでに成長してきたのかを張本人が語った特別対談に加え、大規模環境での統合事例や「伝説のトレーナー」によるミニトレーニングなど、バラエティに富むプログラムが用意された。

「こんなに大きくなるとは思っていなかった」——アレクセイ氏・寺島氏が振り返る20余年の歩み

2日目の冒頭には、Zabbix公開から21年、Zabbix Japan設立10周年という節目を記念して、Zabbix創設者兼CEOのアレクセイ・ウラジシェフ氏と、Zabbix Japan代表の寺島広大氏の特別対談セッションが行われた。

「Zabbixを作り始めたきっかけは？」という寺島氏の問いに対し、アレクセイ氏は、1990年代に金融機関のシステム管理者としてシステム運用やモニタリング業務に携わる中で、「すべてが健全に動いているかをチェックする業務を自動化するため、bashやシェルスクリプト、cronスクリプトを書き始めたことが原点です」と振り返った。

その後、別の企業に転職してシステム運用から離れた後も、趣味としてモニタリングツールの開発を続け、それが1997年からソースコードを書き始めたZabbixにつながったという。

「自分の作った成果を誰かに見せたい、共有したい」と思いつつも、クローズドなソフトウェアとして配布する選択肢もあったというが、同氏の姿勢に大きな影響を与えたのがLinuxやFreeBSDといった他のオープンソースソフトウェアプロジェクトだった。「Linuxという好例が私の背中を押してくれました。オープンソースかつフリーなLinuxやFreeBSDシステムに心から魅了され、このプロダクトもオープンソースにするという決断を下しました」（アレクセイ氏）。GPLライセンスを採用したのもLinuxの影響だったという。

公開直後はさほど反響がなかった。しかし「しばらくしてから、世界中のさまざまな人から『こんなソフトウェアを作ってくれてありがとう』と感謝を伝えるメールを受け取るようになりました。フィードバックを受け取り始めたことで、私が作っているソフトウェアが世界中の人に使われていることがわかり、Zabbixを作っていく大きなモチベーションになりました」（アレクセイ氏）

こうして同氏は2004年、それまで名前のなかったソフトウェアに「Zabbix」と名付け、初めての安定バージョンである1.0をリリースした。

ちなみにネーミングについて、アレクセイ氏は特に明確な理由は示していない。「Yahoo!やAltaVistaといったサーチエンジンでいろいろな名前を検索し、たまたまZabbixという言葉が頭に浮かんで検索してみたところ、結果は0件でした。『これはいいな』と思ってこの名前にしました」とだけ説明している。

その後も、別の仕事に携わりながら趣味としてZabbixの開発を続けていたアレクセイ氏だが、世界中から多種多様な要望が寄せられ、「すべての時間をZabbixに費やすことができれば理想ではないか」と考えるようになった。そして31歳の時ついに、たった一人でZabbix社を立ち上げたという。

寺島氏がZabbixと出会ったのはこの時期だった。最初は仕事のためにZabbixを見つけて使い始めたが、「実際に1.1を使ってみて、いいソフトウェアだし開発も進んでいることを感じたので、日本のコミュニティサイトを作ってZabbixを広めたり、フォーラムで他の人を支援できたら面白いのではないかと思い、日本Zabbixユーザー会のホームページを立ち上げました」（寺島氏）

その後寺島氏は、インターフェイス画面を日本語訳してソースコードへのマージを依頼したり、日本語による解説書籍を執筆するなど、Zabbixへのコミットを深めていった。こうしたやりとりを進める中で、2011年にZabbix本社に転職し、ラトビアで働くことになったという。

当時、ラトビアに関する日本語の情報などほとんどない中での決断だったが、「これは私自身にとっても、またZabbixにとっても大きなターニングポイントだったと思います。滞在したのは1年半だけでしたが、今思うと新しいことの連続で、もっと長くいたような気がします」（寺島氏）

このころからZabbixの開発体制も拡大し、いかに効率的に高品質なソフトウェアを開発できるかに取り組むようになった。一方日本でもユーザー数は拡大し、パートナーも増えてきたことから、きちんと日本にオフィスを作り、日本語・日本の時間帯で支援をする方がいいと判断して2012年10月にZabbix Japanを設立した。

「Zabbixは世界中で採用され、各国にコミュニティがありましたが、中でも強力なコミュニティの1つが日本でした。海外支社を立ち上げるのは新たな挑戦でしたが。ナレッジをよりユーザーの近くで提供することは大事だと考えていたため、ロジカルなステップでした」（アレクセイ氏）

寺島氏とアレクセイ氏が一緒に登記所に足を運び、日本法人を立ち上げてから10年。その後、アメリカやブラジルなどにも支社は広がっている。また日本では公式パートナーが60社を超え、多くのユーザーに導入されている。

今、Zabbix本社では80名、全社合わせて120名が働くほどに成長した。「だいぶ大きくなり、顔を知らない人も増えてきました」（寺島氏）

そんな中でアレクセイ氏が注力しているのは、品質を犠牲にせず、できる限り迅速に開発できるよう、いかに開発をスケールさせるかだそうだ。ソフトウェア開発プロセスの効率も追求し、いくつかのチームに分けて独立して動く体制を整えている。また、テンプレートなどの作成に特化した「インテグレーションチーム」も立ち上げ、さまざまなサービスやソリューションとの統合を容易にしようとしている。

「満足ということはありません。より迅速に開発を行い、監視というものをユーザーにとってもっとシンプルにし、可視化するためにさまざまなアイデアを出し、迅速にデリバリしたいと考えています」（アレクセイ氏）

さまざまな機能を追加し、バージョン6.2でとうとうソースコード行数が100万行を超えたZabbix。今は、開発の第一線でソースコードを書くことはほとんどないというアレクセイ氏だが、ぜひZabbixに対する改善要望を、遠慮することなく積極的に寄せてほしいと呼びかけた。

そして「より多くの機能を追加しつつ、ソフトウェアのシンプルさを保つことが重要です。データを集め、分析し、対応していくというZabbixの機能。それは、モニタリングの分野だけでなく、異なる使い道、異なる業界でも活用できると考えています」と今後の方向性を語った。

21年前に始まったソースコードから20年。「Zabbixのコードを書き始めたとき、オープンソースソフトウェアとしてこんなに大きくなるとは思っていませんでした」とアレクセイ氏は振り返る。小さな一つのアクションが、将来に大きな影響を及ぼした好例と言えるだろう。

「1台のZabbixサーバで何台まで監視できる？」——素朴な疑問を追求した結果は？

「1台のZabbixサーバでどのくらいのホストを監視できるのだろうか」——Zabbixを使って運用監視を行うエンジニアなら、誰しも一度は抱く疑問だろう。SCSKの大石麻奈斗氏は、そんな素朴な疑問を「エクストリーム・アイロニング」さながらに追求した結果を、「限界シリーズ　Zabbix on AWSのパフォーマンス限界に挑戦」と題するセッションで披露した。

今回の検証では、Zabbix 6.0を採用してZabbixアプライアンスに相当するシングル構成の環境をAWS上に構築し、何台まで遅延なく監視できるかを試していった。サーバ自体はAmazon EC2上に、データベースにはMySQLを採用してAmazon RDSで構築し、標準のLinux監視テンプレートを用いてCPUやメモリ、ディスクといったリソースの監視を行う仕組みでエージェントをどんどん増やしてどこまで耐えられるかを見ていったという。

まず監視対象ホストを2000台とした場合、全体にキャッシュ領域が不足し、そのままではZabbixサーバが停止してしまう結果になった。そこでZabbixServer.confに手を加え、キャッシュサイズを拡張したところ問題は大幅に改善し、アイテム数12万7844、nvpsも1580程度でキューも発生することなく処理できる状態に持っていくことができた。つまり「2000台ではまだまだ余裕があるな、という感じになりました」（大石氏）

次は倍の4000台だが、今度はプロセスが枯渇し、キューの監視遅延が発生する事象が発生した。まずunreachableのプロセスを増やしてみたが、問題は解消しない。そこでエージェント側に目を向けたところ、エージェント側のCPUが閾値を超えていることが判明した。「これは構成上の問題であるとわかったのでエージェントの構成を見直し、EC2の数を増やして1台当たり1000台のエージェントを登録する構成にしてCPUの負荷を軽減したところ、キューが改善され、プロセスのビジー率も大きく下がりました」（大石氏）

4000台でも余裕がありそうだと判断し、次に6000台の監視にチャレンジした。今度は、LLD関連のデータ収集を担うプロセスと、キャッシュからデータベースへの書き込み処理の部分でプロセスが足りなくなるエラーが発生したというが、設定ファイルに手を加え、それぞれプロセスを増やすことで改善できた。

最後は8000台だが、監視対象の登録時に早速Zabbixサーバが停止してしまったという。キャッシュを拡張して登録作業を済ませたものの、「さまざまなプロセスでビジー率が上がり、枯渇状態となってしまいました。表示も遅かったり、グラフが出たり出なかったりという状態を確認しました」（大石氏）。これまで同様にパラメータを変更し、チューニングを図ったものの残念ながら改善には至らなかった。最終的にはAmazon RDS側のインスタンスの種類を変えてリソースを増やしたところ問題は一気に解決したが、当初のスペックでの限界は8000台という結果に落ち着いた。

大石氏はこのチャレンジを通して、「収集プロセス数、キャッシュサイズ、内部プロセス数などの各パラメータの関係性を理解したチューニングが肝心です。理解しないままチューニングをしても、改善どころか余計に悪化させてしまうこともあります」と述べ、パラメータに対する理解が重要だとした。ちなみに、Zabbixアプライアンスにはデフォルトでこうした理解を踏まえた設定が入っているため、安心して使えることがポイントだという。

使い方は自分次第、拡張続く「テンプレート」と「webhook」の活用を

Zabbixには「テンプレート」という便利な機能がある。Zabbix Japanでサポートエンジニア兼トレーナーを務める渡邉隼人氏が、その歴史と使い方のポイントを「バージョンアップで進化するテンプレートとwebhook」で紹介した。

テンプレートが追加されたバージョン1.8当時、数は50あるかないか程度だった。その後、変動はありながらもテンプレート数は増加し、さらにZabbix本社側にテンプレート作成を専門に行う「インテグレーションチーム」が立ち上がったこともあって、バージョン5.0、6.0以降は飛躍的にテンプレート数が増えている。特に多いのは、外部APIとの連携に使うテンプレートだ。

「初期のバージョンでは、Zabbixエージェントを使用した監視やSNMPエージェント、ping監視のようなシンプルチェックといったZabbixの機能自体を用いるテンプレートが用意されていました。そこに、4.4から追加されたHTTPエージェントを利用した依存アイテムやメディアタイプなどが加わり、さまざまな機能が導入できるようになっています。そして5.4からはスクリプトアイテムが追加されています」（渡邉氏）

ちなみに、バージョンアップ時のテンプレートのインポートには少し注意が必要だという。バージョンアップ前のテンプレート情報がそのまま引き継がれるため、新規にインストールした場合に比べテンプレート数が少なくなってしまうのだ。こうした事態を解消するには、別途zabbix.comのサイトやGitからテンプレートをダウンロードし、手動でインポートする必要がある。

便利に活用できるのがホストテンプレートだ。HTTPエージェントやスクリプトといったアイテムを活用することで、単純な死活監視にとどまらず、たとえばAWS上に構築したサーバのステータス取得を始めとするさまざまな複雑な監視が行える。ここに保存前処理と依存アイテムを組み合わせることで、JSON形式で取得したデータを用途に応じて振り分け、それぞれ別のアイテムとして保存することでデータを軽量化するといったことも可能になる。

また、条件分岐を組み合わせることのできるスクリプトを活用すれば、「こういった条件の場合は、このようなリクエストを送る」といった事柄を設定したり、リクエストを反復して送信させることができる。渡邉氏はユニークな例として、天気予報の情報を受け取れる「OpenWeatherMap by HTTP」テンプレートを利用し、知りたいエリアの天気情報を取得するといった活用例を挙げた。

もう1つ使いこなしたい便利な機能が、メディアタイプやグローバルスクリプトで実行できる「webhook」だ。「webhookは外部システムとの連携を行う際に使います。メール通知だけでなく、よく利用されているSlackやTeamsに通知を送ったり、Redmineなどのヘルプデスクシステムに障害に関するチケット登録を行うといったことができます」（渡邉氏）。HTTP通信が可能でAPIが付いているものであれば、パトライトなどのデバイスとも連携可能だ。

たとえばZabbixの内部で障害イベントが発生したら、webhookを活用し、REST API経由でRedmineに対してスクリプトを実行してチケットを登録するといった処理が行える。さらに、RedmineからZabbixサーバ側にレスポンスを返し、チケットIDなどの情報をZabbix側でタグとして追加することで、Webインターフェイスからシームレスに情報を確認するといったことが可能になる。

しかもwebhookは、標準テンプレートのまま活用するだけでなく自作も可能だ。渡邉氏は、自らもLINEに通知するシステムを作成してみたことに触れ、「ぜひ活用してほしい」と呼びかけて講演を終えた。

「このアラートはどこから？」、物理的な場所を一目で示し対応を支援

Zabbixを利用すれば、論理的にどのホストで障害が起きているかは把握できる。だが、そのホストはどの場所にあるどのラックに格納されているのか、物理的な場所を直感的に把握するのはなかなか難しい。「Zabbixでの位置情報の活用～geomapの活用事例紹介～」と題するセッションにおいて、NTTコミュニケーションズの城間涼子氏は、こうしたもやもやを解消する手段として「geomap」と「RackMap」という2つの機能を紹介した。

「従来、障害情報と位置情報を紐付けるには、マップを手作業で作成する必要がありました。日本地図のデータを持ってきて、そこにアイコンを一つ一つ手作業で配置する必要がありました」（城間氏）

こうした手間を解消するのが、ダッシュボードウィジェットのgeomapだという。geomapのウィジェットを登録し、ホスト登録時にインベントリに緯度・経度情報を追加することで、geomap上にホストの場所が自動的にプロットされ、障害が発生したホストの場所をすぐに特定できる。「監視対象が複数の拠点に点在する場合などでは効果的ではないでしょうか」（城間氏）。ノートパソコンやスマホといった過般機器の表示も可能だ。

同氏は、geomapを利用することでホストの設置場所や障害発生箇所を地図上で把握できるだけでなく、タイルプロバイダを変更して表示形式を変更したり、障害の深刻度を表示したり、フィルタをかけたりといった便利な機能があることを紹介した。

ただ、実際に障害対応に当たるエンジニアにとっては、「どの場所か」だけでなく、「データセンターのどのラックに搭載されている、どのホストで障害が起きているか」の情報も重要だ。こうした情報を提供するために同社が開発したオプション製品がRackMapだという。

これまで、機器のラッキングからマウント位置の確認、ラック図の作成といった一連の作業は手作業に頼る部分が多かった。RackMapは、Zabbixと連携してホストインベントリに登録した搭載位置情報に基づいてラック搭載図を自動的に生成するツールだ。ラック名や表・裏両面にわたる機器の搭載位置、前後・左右の向きや電源の位置などを網羅したラック図が自動的に作成され、障害が発生している機器を一発で把握できる。Zabbixとシームレスに連携し、マップ上で障害を示す赤い表示からZabbixの障害画面に飛んで詳細を確認することが可能だ。

さらに同社は、各機器を結ぶ配線を可視化する「PortMap」も開発、提供している。配線図の作成もまた手動で作成・更新されることがほとんどで、実際の状況とずれが生じることもあったが、「PortMapはケーブルの配線を行い、タグ付けをすると、管理表や配線図を自動生成してくれます」（城間氏）。機器外観図についても、専用テンプレートを用いて取得したZabbixの監視結果を基に、自動的に生成されるという。さらに、ポートごとのリンク状況や隣接機器情報、通信量、帯域使用率なども確認できるほか、ポート管理表も生成可能だ。

城間氏は、geomapとRackMap、PortMapという3つの可視化機能を相互連携させることでさらに利便性が高まるとし、今後ぜひ、geomapと2つのツールの連携機能のサポートに期待したいとした。

カオス極まる大規模な監視環境を7つの方針に沿ってすっきり一元化

フリーランスとしてさまざまな企業のITシステム運用を支援しているインフラエンジニア、津野哲平氏は、とある製造業で運用されていた複数のZabbixによるカオスな監視環境を一元化した事例を「Zabbixのコンテナ運用管理『Zabbixをクラスター化して大規模監視に対応した話』」で説明した。

この企業では5台ほどのZabbixが動作していた。それぞれデータベースがテラバイトクラスに肥大化しており、グラフを表示するだけで10分かかるほど閲覧速度が低下していたのに加え、監視のインターバルを始めとする設定項目もばらばらで統一されたルールがなく、カオスな状況だったという。

いっそ監視環境を作り直すべきだと津野氏が提案したところ、最大監視対象ホスト数が2万、監視アイテム数は40万で、データは7年ほどさかのぼれるようにしたいといった現行システムの規模を遙かに上回る要件と、それなりのリソースを渡され、引き受けることになった。

作り直しに当たって津野氏が解決すべきだと考えた課題は、

• 監視設定の管理を一元化する
• ユーザーの管理を一元化する
• データベースの負荷を下げる
• 閲覧速度を上げる
• 通知の管理を一元化する
• 全部を少ない労力でできるようにする
• リソース計算できる監視設計にする

の7項目だった。

中でも重視したのはユーザー管理だ。Zabbixを閲覧するユーザーをコントロールしつつ登録の手間をなくす手段として、LDAPとの連携が可能な「Grafana」を採用し、Zabbixとは切り離したところでユーザーを管理することにした。

次に検討したのがデータベース肥大化の問題だ。どんな企業でも規模が拡大するにつれ直面する問題だが、この企業で以前から活用していた分散ノードシステムの「Elasticsearch」と、ログの入れ込みを行う「fluentd」を組み合わせることで、閲覧速度を大幅に向上できたという。

ここまできて、いよいよZabbixサーバ本体の構成の検討に取り組んだ。「Zabbixをクラスター化する」という大方針に沿って、各種監視設定を「監視マスター」が持ち、実際にデータの収集・アラート通知といった監視処理を行ってElasticsearchにデータを保存する「監視実行ノード」を柔軟に増減させる構成とした。これはまさにZabbix 2.4で除外された「Zabbix Node」と同様のアーキテクチャであり、PythonとPyZabbix、Zabbix APIを組み合わせて自力で作成したという。設定情報はJSONで作成し、Redisで管理することにした。

次に取り組んだのは通知管理の一元化だ。トリガーアクションで細かく通知を設定するやり方では作業が繁雑になる上に、メンテナンスも困難だ。そこで、ちょうどこの企業で採用を進めていた「ServiceNow」を利用し、そちらに全部丸投げする形にした。複数のホストから通知を集めてServiceNowに渡す「ラッパー」も独自に作成したという。

こうやって大まかに構成は固まっていったが、次の問題はこれらを動かす環境だ、「仮想マシンでやろうとすると、種類が多いため、周辺システムの整備が思いのほか大変なことになります。どのように組み合わせるか選択していくのは面倒な作業です。リソースの管理とネットワーク管理、ストレージ管理を一括で実現するならば、コンテナとKubernetesだよね、と考えて使うことにしました」（津野氏）。もしシステムに障害があって落ちても短時間で復旧できるシステムを目指し、運用することにした。

こうしてほとんどすべての課題は解決でき、最後に残ったのはリソースの計算だ。まず、監視インターバルの設定など監視設定を統一し、テンプレートを作り直すことで、必要なリソースのめどを立てられるようにした。結果、再構築から約4年が経つ今も「だいたい想定通りに動いています」と津野氏は振り返った。

現在この企業では、約83万の監視アイテム、7500前後の対象ホストを、9つの監視実行ノードで監視している。最大NVPSは4500前後で、設計に比べまだ余裕のある状態だ。それでも「10個のアイテムを表示期間7日間で指定しても、10秒ほどで表示されるほど非常に高速化されています」（津野氏）。すぐに表示されるため、あれも表示したい、これも見ようと負荷をかけてくる人が増えたほどだそうだ。

監視環境の再構築によって、当初の課題をすべて解決できただけでなく、Redisで設定情報のバージョン管理を行うことでデータベースのバージョンアップが容易になるという、想定外のメリットも生まれた。あとはZabbix社に対して、「Zabbix自体の仕様を頻繁に変えるのは、ぜひやめてほしいなと思います」というのが願いだという。

たかがログされどログ、「世界で二番目に生まれたトレーナー」がミニトレーニング

Zabbix Japanの設立前、バージョン1.8の時代からトレーナーとなり、アレクセイ氏に次ぐ「世界で二番目に生まれたトレーナー」として10年以上活動して世界で最も多くの受講者のトレーニングに当たってきたのがNTTコミュニケーションズの福島崇氏だ。今もZabbix認定トレーニングの「スペシャリスト」「プロフェッショナル」「エキスパート」といったコースを担当している同氏が、随所にネタを仕込みながら「非認定」のトレーニングを行った。

ミニトレーニングのテーマは「ログ」だ。未来永劫永遠に1つのファイルにログを書き込むことは不可能であり、どこかのタイミングで「ログローテーション」が発生する。「監視しているログファイルの状態変化に応じて、ログの読み直し、再読込が発生してしまうので職人技ではないかという意見をよく聞きますが、そんなことはありません」（福島氏）。logキーとlogrtキーに分け、抑えるべきポイントさえ理解すれば難しいことはないと説明した。

Zabbixは、inode番号とファイルのMD5、ファイルサイズ、そして5.0.2までの過去のバージョンではファイルの変更時間（mtime）といった項目をチェックし、それまでのログファイルと同じか、それとも新しいログファイルかを見分けている。従って、非常によくある話だが「ちょっとログを眺めよう」と思って、ビューワではなくviエディタなどでログファイルを開き、うっかり少しでも変更を加えるとmtimeが変わるため、再読込が発生してしまうことになる。

「logキーを使う場合、一般的なログ出力の仕組みを使う分にはあまり問題ないと思いますが、それ以外のところでinode番号とかファイルの中身、ファイルのサイズ、mtimeを触らないように気を付けてください」（福島氏）

もう1つのlogrtキーはローテーションを行う前提で監視を行うものだが、ローテートに二つの方式があることに留意が必要だ。1つは、元々のログファイルを別名に変え、かつ元々と同じ空のファイルを作成してそこにログを書き込んでいく「ファイルローテート」方式で、当然inode番号は変わる。もう一つは、元々のログファイルのファイルサイズを0に切り詰めた上で、同じファイルに書き続ける「copytrancate」方式だ。この2つの方式の違いを理解した上で、パラメータを適切に設定することが重要だとした。

福島氏はまた「logrtキー、パラメータ多過ぎ問題」と表現し、全体の流れやロジックがどうなっているかを意識しながら設定をすること、その際正規表現は厳密に記述すること、といった注意事項を挙げた。またlogキーと同様に、ログ出力機構以外でログファイルに触れたり、内容やmtimeの編集をしないことによって、ログライフの再読込を高い確率で防ぐことができるとした。

「敵を知り己を知れば百戦あやうからずで、ログ監視というものは知ってさえいれば難しくありません」（福島氏）とし、仕組みを理解した上で活用してほしいとした。

既存の環境に手を加えることなく、複数のZabbixから得られる情報を統合

SRA OSS LLCのエンジニアとして、Zabbixを中心にさまざまなオープンソースソフトウェアのテクニカルサポートや構築作業に携わってきた村中拓磨氏は、「Zabbixの運用監視機能をより快適にするWebアプリケーション『Premija Viewer for Zabbix』のご紹介」と題して講演を行った。

Premija Viewer for Zabbixは、SRA OSS LLCが開発した、運用監視画面を統合するWebアプリケーションだ。複数のコンソールを切り替えることなく、運用監視に必要な情報を1つの画面上に集約し、ノードツリーやツリーマップ、マージされたイベントテーブルを通して「どのホストグループ、どのホストで障害が発生しているか」といった事柄を把握できる。Zabbix APIを用いて、複数のZabbixサーバからデータの取得や登録処理を行うため、既存のZabbix サーバの環境に変更を加えることなく統合監視が行えることが特徴だ。

さらに、複数のZabbixサーバをまたいでのイベントフィルタリング・検索が可能なほか、Zabbixサーバごとにノードツリーやツリーマップを自動生成することで、監視対象を可視化し、障害の影響範囲、深刻度などを直感的に把握できる。また、ノードツリーとツリーマップ、イベントフィルタが相互に連動しているため、障害が発生して対処がに必要なホストの情報にすぐフォーカスできる。

村中氏は「既存のZabbixサーバ環境に変更を加えることなくインストールでき、しかも各Zabbixサーバのデータ移行は必要ない」とし、ぜひ活用してほしいとした。