Zabbix Conference Japan 2021レポート

1、リリース20周年の節目を超え、さらに先へーー「Zabbix Conference Japan 2021」レポート

2001年4月に「Zabbix 1.0」がリリースされてからちょうど20年という節目の年、「Zabbix Conference Japan 2021」が、11月18日、19日の2日間にわたって開催されました。昨年に続き、新型コロナに配慮してオンラインと組み合わせてのハイブリッド開催という形ですが、今回は初の試みとして、カンファレンス前の3日間にわたってWebセミナーやオンライントレーニングも行い、さながら「Zabbix Week」となりました。

クラウド時代、コンテナ時代も「ユニバーサルな監視ツール」であり続けるZabbix

カンファレンスの冒頭には、恒例ですが、Zabbixの創設者兼CEOであるAlexei Vladishev氏が「Universal Monitoring for the Future」と題して基調講演を行い、Zabbixは文字通り「ユニバーサルな監視ツールである」ことをたびたび強調しました。

ITシステムの役割が広がるにつれ、Zabbixによるモニタリングの対象も広がっています。「さまざまなITインフラの監視に加え、IoTの監視、可用性やパフォーマンスの監視、そして将来的にはセキュリティの監視も可能なユニバーサルなソリューションを目指しています」（Vladishev氏）

オープンソースソフトウェアであり続けてきたことも特徴の一つです。「Zabbixはすべての機能をオープンソースで実装しており、より高度なセキュリティ機能や監視データの保存といったエンタープライズ向けの機能も無償で利用できます」（Vladishev氏）。何より、ソースコードが公開されているため、誰もが情報に自由にアクセスし、Zabbixがどのように動作しているかを理解できるようになっています。この結果、さまざまな拡張用プラグインやモジュール、監視テンプレートなどが用意されているのです。

Zabbixが登場した当初、ITシステムはオンプレミス環境やデータセンターで動作するものでしたが、今やクラウドや仮想マシン、コンテナなど新たな環境の活用が広がっています。こうした変化に伴ってZabbixは、デプロイ先も、また監視対象も広げてきました。「近年はハイブリッドクラウドが普及し、KubernetesやOpenShiftといったプラットフォームの活用が広がってきましたが、すでにZabbixからこれらの環境を監視できるようになっています」とVladishev氏は述べています。

また、単純なしきい値に基づく障害検知だけでなく、よりビジネス視点に沿ったアラートを生成できるような機能も追加されています。具体的には、Zabbix 6.0に実装される「アノマリー検知」や「ベースライン監視」で、機械学習技術を活用することで、これまで以上にスマートな監視を実現できる見込みです。また、日本のユーザーに歓迎されそうなものとして、PDF形式でのレポート生成機能があり、今後もさまざまなウィジェットを追加して拡張する計画だそうです。

ただ、Zabbixをもっとユニバーサルな監視ツールとして発展させていくには、いくつかの課題もあるとVladishev氏は述べ、より多くのプロトコルをサポートするほか、可用性やパフォーマンスの監視、ログの監視といった項目を挙げました。さらに、「より大規模な企業で活用されるにつれ、セキュリティもトッププライオリティの1つになっています。Zabbix自体のセキュリティに加え、モニタリングにおけるセキュリティも重要なトピックです」とし、やりとりするデータの暗号化やユーザー権限のきめ細かな制御、シークレット情報の保存先などで改善を加えてきたことを紹介しました。

Vladishev氏はさらに、Zabbix 7.0 LTSの方向性にも触れました。基本的には、「誰もがZabbixをより簡単に利用できるようにユーザビリティを高め、Webインターフェイスの設定を簡素化していきます」という計画です。利便性を高めるために可視化やレポート機能を強化するほか、監視対象もいっそう拡大していく方針といいます。合わせて、スケーラビリティと高可用性の向上も進めていく予定です。具体的には、Zabbix公式サイトのロードマップのページに紹介されているため、興味のある方はぜひ確認してみてください。

2つの新機能で、「いつもと違う状態」の検知を可能にするZabbix 6.0

実は当初の予定では、Zabbix Conference Japan 2021までに、最新のLTSである「Zabbix 6.0」がリリースされるはずでしたが、残念ながら今回は間に合いませんでした。ただ、「まもなくリリース予定」であることに変わりはありません。

Zabbix 6.0における大きな目玉機能が、アノマリー検知とベースライン監視です。Zabbix Japan代表の寺島広大氏は、「これまでの障害検知には、しきい値を決めなければいけないという問題点がありました。低く設定すると頻繁に検知してしまうかもしれないし、高い値だと大事なところで障害を検知してくれないかもしれません。そこをどう考えるかが必要でした」と振り返りました。

この問題を解決するためZabbixは、基本的なトリガー条件式や文字列一致といった方式に加え、バージョンアップのたびごとに、「タイムシフト」や「予測検知」「トレンド分析」といった機能を順次追加し、単純に閾値を超えたかどうかだけでなく、「先週と比べてどうか」「先月と比べてどうか」を検知できるようにしてきました。

そして、Zabbix 6.0で加わる二つの機能では、「過去データを分析して算出したものに基づいて、いつもと大きく異なる状態を検知させる」ことが可能になります。

アノマリー検知では、STL分解を用いて規則性、季節性のあるデータを見いだし、通常とは異なる「アノマリー」（異常値）を検知できるようになります。またベースライン監視では、「過去のデータのうち、指定期間の繰り返しの平均値から得られる値」を分析し、比較が可能です。以前のトレンド分析では、一つ前の周期、たとえば一週間前の値としか比較できなかったものが、ベースライン監視ではさらに長期にわたる過去のデータと比較が可能になり、より正確に精度を高めていくことができるでしょう。

まもなく10周年を迎えるZabbix Japanが考える、「次の10年」

Zabbixそのものがリリースから20年を迎えた一方、日本法人であるZabbix Japanは設立から9年目を迎えました。2022年には10周年という節目を迎えることになります。「最初の頃は、オープンソースソフトウェアで本当に会社って成り立つんですか、と聞かれることもありましたが、今ではパートナー数は60社近くを数え、売り上げも順調に伸びています」（寺島氏）

近年、ラトビア本社では開発ペースはさらにスピードアップしており、スピード感ある形でさまざまな新機能の追加や機能強化が行われています。加えて、QAのプロセス改善やテンプレート作成を専門にするチームもできており、よりパワフルなツールを目指している形です。ただ、最初からの開発ポリシーはぶれることなく、「オープンソースでの開発を継続し、バグ報告やユーザーからのフィードバックを取り込んでいきます」と寺島氏は述べました。

Zabbixというソフトウェアそのものは無償で提供する一方、Zabbixという会社は、Zabbixに関する技術支援やトレーニングを提供することで成長してきました。そしてパートナー各社には、導入支援などそれぞれの得意分野を生かしてもらう形となっています。

「Zabbixでは、問題を解決するサポートを提供したいと思っています。技術力のあるエンジニア、全員がお客様と直接会話をし、何かあったとき『それはサポート範囲外です』と返すのではなく、できる限り調査、解析して回答し、お客様の問題解決までお手伝いするようにしています」（寺島氏）。この姿勢は顧客のためだけでなく、エンジニアの技術力向上という面でも有用だとしました。

もちろん、課題もないわけではありません。特に近年は、オープンソースソフトウェアの進化が著しく、次々に新たなバージョンや機能が登場する上に、クラウドサービスがめざましい勢いで普及しています。そうした変化に追いつくために常に学び続ける必要がありますし、クラウドという環境でいかにZabbixを安定して稼働させていくかという部分に難しさを感じることもあるそうです。

そんな中でも、「私の感覚では、サポートとは何か問題が起きたものを改修することではなく、問題解決のための技術支援を提供するサービスだととらえています。既存のものにパッチを当て、修繕しながら使い続けていくというよりも、バージョンアップにともなって、修正と新機能をともに取り込んでいって進化していくものだと思っています」と寺島氏は述べました。そして、そのための技術力や姿勢を重視し、システムとしても「独自の作り込みをやり過ぎず、バージョンアップに追随しやすいよう柔軟な構成にしていく、そんな作り方が重要になってくると思います」としました。

そんな思いからZabbix Japanでは、より顧客にとって有用なサポートメニューを考え、サポートメニューの中に、日本独自のトレーニングコースを組み合わせることを検討しています。これまで日本独自で実施してきた入門トレーニングやショートトレーニングをサポートの中に組み入れ、「何か問題があったら支援するというサポートだけでなく、ユーザーさんの理解や技術力向上の手助けができないかというところに取り組んでいきたいと思っています」（寺島氏）ということです。

「来年は10年目を迎え、その次の10年をどうするか考えていかなければいけません。単純にサポートを提供するだけではなく、ユーザーさんの『わからない』や『困った』を具体的に支援できるサービスを総合的に提供できる10年にしていきたいなと思っています」（寺島氏）

2、日々の運用監視の現場で生じるあんな悩みをどう解決？　事例セッションから探るヒント

2021年11月18日、19日の2日間にわたって開催された「Zabbix Conference Japan 2021」では、Zabbix 6.0で追加された新機能の紹介やインストール方法、アップグレード方法に関する技術的なセッションに加え、パートナー各社によってさまざまな導入事例が紹介されました。日々の運用監視の中ではさまざまな課題が浮上しますが、それらをどのように解決していけるか、大いにヒントを得ることができるでしょう。

「作り込みをしすぎない」ことがコツ、西川ゴム工業でのダウンタイム縮小に貢献したZabbix

OFFICE-HAYASHIの林聡氏は、広島に拠点を置きながら、全国さまざまな企業の情報システム部門にコンサルティングやアドバイスを提供してきました。3年前からZabbixに触れ始め、今ではZabbix Japanとリセラー契約を結ぶに至っています。同氏はその道のりを「民間企業の情シスが本当に欲しいZabbix 〜西川ゴム工業株式会社の導入事例〜」と題するセッションで紹介しました。

林氏がZabbixを活用することになったきっかけは、西川ゴム工業でのシステム監視のためでした。システム運用に関する契約を結び、常駐する立場にあったものの、「当時は監視システムが導入されていなかったため、『ネットワークがつながらないんだけど』『サーバにつながらないんだけど』といったユーザーからの入電によってはじめて情報システムが障害を把握し、当たりを付けながら調査を進め、障害対応を行うという流れでした」と同氏は振り返りました。

しかし、今やITシステムは業務を支える存在であり、システムのダウンタイムが長引けば長引くほど損害額も膨らんでしまいます。ましてや製造業の場合、製造ラインが停止してしまうと損害に直結することから、「システムの安定稼働を守ることが情報システム部の使命となります」（林氏）

こうした背景から林氏は、西川ゴム工業でのシステム監視にZabbixを採用しました。当初は死活監視からのスタートでしたが、それでも障害を情報システム部側が把握し、「今、つながらない状況です」とアウトバンドでエンドユーザーに伝える体制が整ったことで、安心感を提供できるようになったそうです。さらに、どの拠点のサーバルームのどの機器で障害が発生しているかの特定を容易にするために、独自に「ロケーションマップ」を作成し、誰が見ても障害の有無が一目でわかり、ドリルダウンでその場所を特定できるようにしました。

林氏は「障害箇所と影響範囲の特定が非常にスピーディにできるようになり、初動対応も迅速になりました。結果として、ダウンタイムの縮小に大きく貢献できたと思っています」と述べ、Zabbixによる監視がなくてはならない存在になっていると振り返りました。

もちろん、最初からすべてがスムーズだったわけではありません。林氏はZabbixの導入に当たって、「なるべく標準機能で作成し、作り込みをしすぎない」「情報システム担当者が直感的にわかるようにする」「使い勝手と見栄えに留意する」という三点に留意したそうです。必ずしも専門家とは限らない情報システム担当者でも少ない負荷で運用でき、属人化を避け、異動があったとしても引き継げるようにという意図からです。

こうしてZabbixを用いた監視を三年間続ける中で、林氏は顧客からの要望を受け、Microsoft 365のレスポンスタイム監視や、各拠点を接続しているWAN回線の疎通確認とトラフィック監視などへと適用範囲を広げてきました。また、リアルタイムに更新できるサーバ／ネットワーク機器の管理台帳としてもZabbixを利用しており「現実に即した管理台帳として使うことができ、運用負荷が非常に軽減できています」（林氏）

今後は、無線LANのヒートマップ情報を取り入れ、アクセスポイントで障害が発生した際に影響範囲を特定しやすくするなど、引き続き改良を進めていく予定です。

多数のアラートをフィルタリングし、障害発生から電話通報までの時間を大幅短縮するWebSAM AMC

日本電気（NEC）では統合運用管理ソフトウェア「WebSAM」の製品の一つとして「WebSAM Automatic Message Call（AMC）」を提供しています。実はこのAMCはZabbixとも相性がよく、うまく連携させることで、システム監視でしばしば生じる悩みを解決できます。NECの野中澪氏はその特徴を、実際の事例とともに「Zabbix電話通報自動化で運用をカイゼン!～事例に学ぶ8割の不要なアラートの削減方法～」で紹介しました。

AMCは、システムから発生されるさまざまなアラートメールを受け取り、フィルタリングを行った上で、必要な情報だけを電話やメールでエスカレーションするクラウド型のサービスです。既存の環境に新たにソフトウェアをインストールしたり、サーバを構築することなく、すぐに利用できることも特徴となっています。

野中氏によると、AMCユーザーの利用実績から、2つの興味深い数字が得られているそうです。1つは、AMCで受信したアラートメールのうち、エスカレーションを行わず静観処理にとどめたものの割合が「84％」に上るというもの。つまり、100件アラートメールを受信しても、対処が必要となったのは16件だけにとどまったというわけです。また、一ヶ月で電話通報を実施した平均回数は「46件」に上っており、仮に電話1件あたり5分程度の時間だとしても、のべ230分、4時間分が単なる架電作業に費やされる計算となります。

野中氏はZabbixとAMCの連携によって大量のアラートメールを削減し、かつ電話通報を自動化することで、これらの数字を大幅に改善できることを、事例を交えて説明しました。

とあるシステムインテグレーターでは、AWSで運用しているシステムの監視をZabbixで行い、障害発生から顧客へのエスカレーションまでを30分で行うSLAを設定していたそうです。しかし、毎月3万件に及ぶアラートメールが届き、判別に時間がかかってしまうことから、なかなかSLAを達成できずにいたといいます。

ここにAMCを導入することで、3万件ものアラートメールの中からエスカレーションの対象になるものを判別し、保守担当に電話通報を行うまでを自動化しました。この結果、アラートメールのうち95％以上を削減するとともに、人手に頼っていた電話通報を自動化することで迅速化し、SLAの目標を実現できたそうです。

AMCでは、たとえば「このサーバ名とステータスが本文に含まれている場合には通報を行う」といった具合に、いくつかの条件を設定してフィルタリングを行えます。それも、単純な条件式だけでなく、一定時間内に似たようなアラートメールが複数届いた場合に集約して重複を省いたり、メンテナンス時間を例外に指定するといった具合に、きめ細かなフィルタ機能を備えていることが特徴です。

また、電話通報の自動化においても、曜日や時間帯に応じて電話をかける先を柔軟に変更したり、つながらなかった場合には別の担当者にかけ、それでもつながらなければ再び最初の担当者にかけ直すといった具合に、つながるまでかけ直す処理も設定できるようになっています。

野中氏はこうした説明を踏まえ、NECでは、人々がより豊かで、快適に、安全安心に生活できる社会の実現のためにITを活用するデジタルトランスフォーメーションを実現するソリューションの1つとして、運用監視の観点からWebSAMを提供し、運用現場の改善を支援していくと述べました。

Amazon Connectを組み合わせて電話通報を自動化、コスト削減と人的ミスの抑制を測ったSCSK

Zabbixのプレミアムパートナーとして導入構築から保守運用まで幅広くサービスを提供しているSCSKの中野祐輔氏も、「運用自動化、エンタープライズ環境の活用方法」と題し、Zabbixを利用したシステム監視における電話通報の自動化と、監視設定の自動化について紹介しました。

中野氏によると、最近は「時間・コストを低減させたい」「大規模・複雑でも迅速にリリースを行いたい」「24時間365日落ちないサービスを実現したい」という3つの観点からの相談が増えているそうです。これに対しSCSKでは、Zabbixの導入や運用一部を自動化することで、こうした悩みの解決を図っています。

ある顧客では、Zabbix Serverで検知した障害を受け付け、監視オペレーターを通して各拠点の管理者に電話通報を行う24時間365日体制のコールセンターを利用してきました。このコストを削減したいという相談を受けてSCSKが提案したのが、クラウドサービスのAmazon ConnectとZabbix Serverの連携による電話通報の自動化でした。

ただ、電話通報は障害に対する初動対応の要です。このため「障害イベントが急増したときの電話通報を抑止したい」「カレンダーベースで通報先や通知方式を切り替えたい」「事前に定義した連絡先に順番で通報処理を行うための通報フロー処理を実現したい」といったさまざまな要望が盛り込まれていたといいます。

SCSKでは、まずZabbixアクションを用いて時間帯や深刻度に基づく分岐処理を行い、重度の障害以上の場合は独自スクリプトを実行して「アラート情報ファイル」と「連絡先ファイル」を作成し、それをAmazon Connectへ連携する、という流れで電話通報の自動化を実現しました。さらに、Zabbixアクションを用いて大量検知時のアクション処理の負荷を軽減するスクリプトを実行して電話通報のバーストを回避したり、パラメータ設定によってコール時間やループ数を制御するといった工夫を加え、顧客の要望に合わせた通報の仕組みを実現しています。

「各処理について、Zabbix側で制御するか、Amazon Connect側で制御するかの分担を最初に確定しておき、事前に運用設計をきちんと固めておくことで、運用に入った後は大きな問題なく自動化できています」（中野氏）。この結果、コスト削減はもちろん、見落としや電話のかけ間違いといった人為的ミスも抑制できる効果が得られました。

もう1つの事例は、ホスト約7000台、約100万アイテムという大規模環境において、監視設定の作業コストを削減したいという要望に応えたケースです。SCSKでは、Zabbixのネットワークディスカバリ機能を利用してホストの自動登録と設定の自動登録を実現し、作業の効率化と期間の短縮に加え、設定ミスの抑制につなげました。

このケースでも、事前の準備がものをいったそうです。「ネットワークディスカバリを使用した運用自動化を実現するには、運用前の仕込みと、例外に対する運用が必要となります。このため、事前に影響をしっかり調査しつつ、出てきた課題を抽出し、対策を検討しました」（中野氏）

具体的には、機器が故障した場合や新たな機器を追加した場合、どのような流れで監視設定を追加するかを想定して落とし込むのはもちろん、「監視テンプレートが存在しない機器を発見した場合にどうするか」「複数のIPアドレスを持つ機器を重複して登録しないようにするためにはどうするか」といった例外的な事態も洗い出し、それぞれ対策を用意したそうです。

「実際にこの構成を構築してみて、既存の運用をすべて自動化することは難しいと感じました。ただし、影響の大きなホスト登録や監視設定の登録作業を自動化する一方で、頻度が低く、影響が小さい業務に関しては手動で運用することで、大部分の作業を自動化できました。それが可能だったのも、事前のディスカバリ設計、特に運用設計をしっかり行ったからだと感じています」（中野氏）

この経験やノウハウを踏まえ、今後も、業務運用目線、システム運用目線に立って、自動化への落とし込みを支援していくそうです。

既存機能を使い倒せばこんな無茶ぶりにも対応可能？　NTT Comが実践してきたユニークな事例

NTTコミュニケーションズ（NTT Com）は2008年からZabbixのプレミアムパートナーとして、監視サービス「ZABICOM」をはじめとするさまざまなサービスを提供してきました。田中武信氏も2011年からZabbixに関する業務に携わり、さまざまなZabbix実装案件を手がけており、その経験の中から5つの興味深い実装事例を、「Zabbix 応用事例集の紹介～Zabbixの既存機能を使い倒す！～」と題して紹介しました。

1つ目は「トリガーの依存関係をテンプレート化する」というものです。Zabbixを使って監視をしているとさまざまなアラートが飛び交い、特にネットワーク機器の監視の場合、上位の機器が故障すると、下位の機器も含めて多数のアラートが飛んできます。これを解決するには「トリガーの依存関係を使う」のが定石ですが、「このトリガーの依存関係は非常に複雑で、設定はできても維持管理は大変だというのが大きな問題です」（田中氏）

そこで同社では、依存先を親IP、依存元を子IPと定義し、その両方を監視するPingを設定して、子IP側のホストが落ちた場合にトリガーを仕掛ける構造を取ることで問題を解決しました。「子のIPが二回NGで、かつ親のIPが正常の場合のみ障害として検知すると設定します。これにより、親が生きているときはきちんと子の方でアラームが上がるし、逆に親が死んでいる場合にはアラームは上がらないような制御を作ることができました」（田中氏）

この結果、設定に要するクリック数を減らして作業工数を抑えつつ、「過去二回連続してNGだった場合に障害検知とする」と条件を付けることで、ポーリングのタイミングのずれによる誤検知を避けることができました。

2つ目の取り組みは、「LLD（Low-Level Discovery）を用いて任意のアイテムを作る」というものです。「監視項目がまだない状態だけれど、監視項目を自動で作りたい」という顧客からの要望に応えるために工夫したケースです。

ここでは、標準ではPoller方式で記述されているLLDテンプレートを、待ち受けを行うTrapper方式に変えました。その上で、zabbix_senderコマンドを用いてZabbixトラッパーに向けて入力データを送信し、その入力データを取り込むことで、アイテム・トリガーを自動生成する流れを実現しました。

「使い道としては、まず、監視対象がなくてもLLDを動かしてアイテムを自動的に作るのが1つです。また構成管理システムがあれば、その元データからCSV形式で入力データを作り、システムに送信することで自動生成が実現できます」（田中氏）

3つ目の取り組みは、「ZabbixダッシュボードをWebアプリケーションのユーザーインターフェイスとして使う」というものです。これもきっかけは、「Zabbixの情報をCSV形式のファイルで扱いたい」というある顧客からの要望でした。

そこで、ZabbixからまずXML形式でデータを出力し、それを「URLオブジェクト」機能でZabbixダッシュボードに貼り付けたWebインターフェイス経由でCSVに変換し、取り出してくる——という形でクリアすることにしました。

なおURLオブジェクトには、セキュリティのためのサンドボックスによる制限や、プロトコルの差異があると表示できないといった制約があります。それらをきちんと理解した上で使いこなせば、たとえば、Wikiを張り込んで社内共有メモを記したり、気象庁のページにリンクを張って気象情報を取得する、といったアイデアも実現可能です。

「今回のように機能の導線がはっきりしていれば、個別の単発機能を組み合わせ、ダッシュボードに貼り付けることで、あたかも一つの機能のように動かせる仕組みを作れます。Zabbix側は何一ついじらずに、あたかもZabbixを拡張したように見える点がいいと思います」（田中氏）

田中氏はほかにも、「GPS情報の取得と利用」、そして非推奨ではありますが「スマホの監視」についても、既存の機能を組み合わせて実現する方法を紹介しました。

そして最後に「今回のConferenceでもZabbix 6.0に関する話題が多くあり、これからも新しい機能がどんどん入っていくでしょう。一方で既存の機能の中にも使えるものは非常にたくさんあり、アイデア次第でいろいろな使い方ができます」と述べました。

3、DockerやAnsibleとの組み合わせも、広がるZabbixの活用方法

2021年11月18日、19日の2日間にわたって開催された「Zabbix Conference Japan 2021」では、Zabbixそのものの新機能はもちろん、他のオープンソースソフトウェアやDockerなどの新しい基盤、あるいはパートナー各社が提供するツールと組み合わせることで、より効率的に、より便利に活用していくための工夫が紹介されました。さらに、「監視」以外の領域への適用という新しい可能性を感じさせる提案まで飛び出しました。そんなユニークな内容がそろったセッションの模様を紹介します。

より堅牢に、よりセキュアに——6.0alpha6をベースに確認するZabbixの最新機能

長年にわたりさまざまなオープンソースソフトウェアの導入支援、運用支援を行い、Zabbixのパートナーとしても活動しているSRA OSSの赤松俊弘氏は、「Zabbix最新LTSバージョン 6.0の新機能解説」と題し、Zabbix 6.0alpha6をベースに、「ビジネスサービス監視」「HAとスケーラビリティ」「高度な障害検知」「監視の簡易化と制限解除」「セキュリティ向上」という5つの観点から新機能について解説しました。

まずビジネスサービス監視についてですが、Zabbixでは、データベースやサーバ、ネットワーク機器など複数の要素で構成される1つの「サービス」の状態をハイレベルで監視し、サービス自体の可用性やSLAを把握できる「サービス監視」機能が提供されてきました。6.0ではこのサービス監視機能が改良され、タグによる障害のひも付けや柔軟なステータス計算および伝播、根本原因の表示、サービスのステータス変化によるアラート通知、サービスへの権限付与といったさまざまな機能が追加されています。

2つめのHAとスケーラビリティでは、アクティブ/スタンバイ形式のHAクラスタをネイティブで構築できることが大きなポイントです。「アクティブのZabbix Serverに何らかの障害発生して監視ができなくなった場合には、残りのスタンバイの1つがアクティブとして立ち上がり、監視を継続できます」（赤松氏）

さらに、このHAクラスタの状態確認・監視も行えるようになり、各ノードの状態やフェイルオーバー時の遅延といった情報を把握できます。ITシステムの重要性が高まり、それにともなって監視の比重も高まっていることを踏まえると重要なポイントと言えそうです。

3つ目の高度な障害検知では、単調変化の検知機能が追加されたほか、変化回数を検知する「changecount関数」の追加、Prometheusパターンの保存前処理の演算子追加・histgram対応の関数追加などがポイントだと赤松氏は説明しました。

4つ目の監視の簡易化と制限解除では、agent.hostmetadataやkernel.openfilesといった新たなアイテムキーが追加されています。またcount()、item_count()、exists_foreachといった新たな関数が追加され、たとえば、

count(max_foreach(/*/proc.num[*], 1h))

と記述すれば、「過去一時間のうちにデータ収集が行われたproc.numアイテム数を取得する」といった処理が行えるようになりました。「こうしたcount系の関数と履歴系のforeach関数を併用すると性能に影響が出る可能性があります。exists_foreach関数を、履歴ではなく設定情報を見て情報を取得するため、性能に影響が出ない利点があります」と赤松氏は説明しています。

他に、複雑なトリガー条件式や復旧条件式を作ってしまい、思ったように動かない時にデバッグを支援する「トリガー関数のデバッグ用マクロ」が追加されています。またアクションに関しては、webhookにgithubメディアタイプが追加され、Zabbixで障害が起こった場合に、webhookでGithubに情報を送ってissueを登録する、といった処理が行えます。

制限解除に関しては、Zabbix getとZabbix senderにタイムアウトを指定できるパラメータが追加されました。

最後のセキュリティ強化では、Zabbixユーザーのパスワードポリシーを設定し、最小パスワード超や必須項目を指定できます。たとえば、「password」のような推測されやすいパスワードの利用を禁止する設定も可能です。合わせて監査ログ機能も強化され、これまで監査ログに出力されなかったディスカバリルールやアクション、スクリプトの実行も含め、すべての処理が記録されるようになりました。

これら5つの分野以外にも追加された機能があります。その一つが、データベースのバージョンチェック機能です。Zabbixではバージョンごとにサポートするデータベースがあります。そこで、サポート範囲に合致していないデータベースを使っていないかをチェックし、対応バージョン外であれば起動しない仕組みが設けられました。他にフロントエンド側でも、アイテム選択時にデータ型が自動選択される機能が加わるなど、挙げていけばきりがない状態です。

赤松氏はこれらを一通り紹介し、「まだまだ他にも、ベースライン監視と異常値監視をはじめとして今後6.0に実装予定の機能があります。Kubernetesクラスタ監視もそうですし、私にとってはEscalation cancelledメッセージの抑制という機能がありがたいです」と述べています。そして、Zabbix公式サイトの他、SRA OSSが公開しているテックブログの情報も参照しながらキャッチアップしてほしいと呼びかけました。

ZabbixをDockerコンテナ化し、持ち運びのしやすさというメリットを享受

2008年からZabbixと提携し、「ZABICOMソリューション」をはじめ各種サービスを提供しているNTTコミュニケーションズ（NTT Com）の名倉堂心氏は、「コンテナでの監視機能の実装とproblemテーブル肥大化問題の事例紹介」と題してセッションを行いました。

現在、デジタルトランスフォーメーション（DX）をにらんだ新たなアーキテクチャとして、Dockerコンテナが注目を集めています。名倉氏が考えたのは、このようなアプリケーションの基盤としてだけでなく、システム監視の基盤としてもコンテナを活用できないかというアイデアです。

「基本的にZabbixは物理サーバや仮想サーバに導入するケースがほとんどですが、検証環境と同じものを本番環境にも適用したいという要件があり、移植・適用のしやすさを考えるとコンテナが圧倒的にスピーディでやりやすいと考え、コンテナを採用しました」（名倉氏）

ただ今回は、機能ごとに切り出してマイクロサービス化したコンテナを連携させるのではなく、サービスを一つのコンテナにまとめるオールインワンコンテナを採用したそうです。

「マイクロサービス化した時の保守や運用に関する実績があまりなかったことを考え、オールインワンコンテナを採用しました。物理マシン・仮想マシンでの運用実績の多さと、コンテナによる持ち運びのしやすさのいいところ取りをしました」（名倉氏）。オンプレミス環境の物理マシン・仮想マシンとほぼ同等の構築手順を取るため、過去の実績ある手法に近い形で構築、保守、運用が担保できる、より確実な手段だと判断したということです。

続けて名倉氏は、problemテーブルの肥大化問題に関する事例と対応について紹介しました。

problemテーブル肥大化はZabbix Conference 2020でも紹介された問題で、ご存じの方も多いでしょう。Zabbixでは、障害中のイベントデータはproblemテーブルに格納されます。復旧しない限り、それら障害イベントのデータは蓄積されて肥大化していき、たとえフロントエンドから見えなくなっても残り続けます。この結果、Zabbixのダッシュボード表示が遅くなったり、ひどいときには表示ができなくなる事態が起こっていました。

これを解消するには、手動クローズを許可して実施するという運用面での対策の他、復旧イベントを正しく生成することが重要になります。

名倉氏が直面したケースでは、problemテーブル内に200万件以上のデータがたまってしまい、Web画面からの削除作業すら行えず、結局データベースを作り直すことになったそうです。その後、新たな監視設定を投入する際、アイテムトリガーに、自動で復旧するnodata関数を使用した復旧条件式を設定することで問題の発生を防ぎ、現在は正常に運用ができているといいます。このとき、きちんとアイテムキーの第二引数を指定することも、望まぬ誤検知を防ぐ上でのポイントだそうです。

なおNTT Comでは、大量にログやトラップが発生した際の確認作業を支援するオプションツールとして「GatherAlert」を開発、提供しています。障害内容を一定期間ごとにまとめ、メールやSlack、Teams、LINEなどに通知するシンプルな仕組みですが、多数のアラートに紛れて重要な障害を見落とさないようにする上で有効です。また、カレンダーに応じて通知設定をカスタマイズすることも可能となっています。

さらに「通知した障害については、自動でクローズ処理を走らせる仕組みもあります。ログやトラップが大量に発生したとき一気に消し込むのは大変ですが、GatherAlertでは通知するとともに自動クローズでき、そこでも力を発揮します」と名倉氏は述べました。

Ansibleを活用し、200時間見込まれた400台へのエージェント導入作業をわずか半日で完了

ビジネスのITシステムへの依存度が高まれば高まるほど、監視の重要性は高まり、監視対象も増えていきます。となると、監視に必要なZabbixエージェントをどのように配布していくかという新たな問題も生じます。

アシストの塩澤正寛氏は、「Ansibleで自動化してみた！400台のZabbixエージェントを半日で導入」と題するセッションの中で、「皆さんは、複数台のZabbixエージェントの導入にどのように対応していますか？」と問いかけました。

10台や20台ならば手作業で頑張ることもできるでしょうが、100台規模になってくると非現実的です。塩澤氏はそういった場合の参考にと、構成管理ツール「Ansible」を用いてZabbixエージェントを導入した事例を紹介しました。

通常のZabbixエージェント展開手順では、インストーラーを配布して実行し、confファイルで各種パラメータの設定を行ってエージェントを起動する流れになります。「通常、ツールを使わずにエージェントをインストールする場合、確認作業まで含めるとざっくり言って30分程度かかります。単純計算すると100台ならば50時間、今回お話しする400台規模ですと200時間程度かかる計算です。仮にこの作業を1人でやるとしたら、1カ月以上、エージェントのインストールだけをし続けるようなボリュームになります」（塩澤氏）

この作業を効率化するために着目したのが、ソフトウェアの導入や構成管理を自動化するAnsibleでした。AnsibleはYAML形式で記述された「プレイブック」に従って自動的に処理を行います。可読性が高く、自動化処理の記述がしやすいことに加え、何度操作を繰り返しても同じ結果が得られる「べき等性」の担保、Zabbixも含めた多種多様な環境への対応といった特徴を備えているツールです。

アシストではこうしたAnsibleの特徴に着目し、とあるサービス業の顧客でのZabbixエージェント展開に活用してみました。

この環境には、Windows環境が100台、Linux環境が300台あり、Windowsは2012と2016、LinuxはRedHat 6と7という具合に、異なるバージョンが稼働していました。そんな環境でエージェントを展開するため、接続要件を確認してプレイブックを作成し、自動化処理を流してみたそうです。

「結果から申し上げると、400台への展開を、準備も含めて約20時間で行うことができました。WindowsとLinux、それぞれの環境向けのプレイブックの作成と動作検証に2人日、エージェントの展開は0.5日で、実際には1台あたり1分以下で展開しています。当初の試算から考えると、大幅な時間削減と効率化につながったと考えています」（塩澤氏）

この事例を通して得られた知見も多くありました。まず、ターゲットとなる環境にはいくつか前提条件が必要になります。そして、べき等性が適用できるところとできないところを見分けた上で、適宜スキップ処理を組み込みながらパターン分岐を行うことで、べき等性の利点を十分に得られ、効率化が図れました。結果として、インストール時に問題が発生するような事態は生じなかったといいます。

「今回はエージェントのインストールにAnsibleを組み合わせましたが、他にもたとえば、エージェントのバージョンアップのほか、監視設定の自動化、監視の静観対応といったところにも、Ansibleによる自動化が期待できると思います」（塩澤氏）

アシストでは、IT運用リューション「ENISHI」のほか、今回の実績を踏まえ「Zabbix Agent構築自動化パック」を用意し、提供しています。今後もさまざまな分野で自動化を検証し、そのノウハウをソリューションに組み込みながら提供していくそうです。

複数台のZabbix Serverにまたがり障害状況を一元化し、運用監視をより快適に

SRA OSSの村中拓磨氏は、「Zabbixの運用監視機能をより快適にするWebアプリケーション『Premija Viewer for Zabbix』のご紹介」と題し、同社が開発した「Premija Viewer for Zabbix」（PVZ）について紹介しました。

PVZは、複数のZabbix Serverで監視している障害状況やイベントを一画面にまとめて表示するWebアプリケーションです。複数のZabbix Serverに対してZabbix APIを実行してデータを取得し、一画面で統合的な監視が行えるようにします。既存のZabbix Server環境に設定や変更を加えることなく利用できることもポイントです。

「複数台のZabbix Serverで監視・運用をしている方の中には、障害内容を確認するたびにZabbixフロントエンドを切り替える必要があり、手間だと感じていらっしゃる方もいるのではないでしょうか。PVZであれば、そうした悩みをワンストップで解消できます」（村中氏）

PVZでは、各Zabbix Serverごとにノードツリーとツリーマップが用意されており、障害発生状況を深刻度別に色分けして表示し、直感的に把握できます。また、すべてのイベント情報をマージして発生日時順に表示する「イベントテーブル」を用意し、統合的な管理を支援するようになっています。多数のフィルタ項目も用意されており、特定のZabbix Serverに対してはもちろん、複数のZabbix Serverをまたいでのイベントフィルタリングも可能です。

またノードツリー、ツリーマップ、イベントテーブルが連動しており、1つのペインでの操作が他のペインにも伝搬し、関連するイベントが自動的にフィルタリングされて表示されることも特徴といいます。障害を確認して対応状況を確認した場合、一括して更新することも可能です。

障害対応においては迅速な状況把握が欠かせません。PVZは複数のZabbix Serverにまたがって、監視運用に必要な機能を一画面で提供することで、それを支援してくれるものといえそうです。

Zabbixの用途はシステム監視だけじゃない？　目からうろこの意外な活用法

Zabbixはシステム監視のためのもの——多くの人がそう考えているでしょう。ですが、さまざまなZabbix環境の構築に携わってきたアークシステムの渋谷正晃氏は、「高い性能と柔軟なカスタマイズを可能とする拡張性を兼ね備えたZabbixの使い道は、システム監視だけではもったいないのではないか」と述べ、「システム監視だけではもったいない。Zabbixがあなたにピッタリのお部屋を探します！」という目からうろこの発表を行いました。

新型コロナウイルスの影響でテレワークが広がり、快適にオンライン会議を行うため、新たな物件を探そうと考えた人は少なくないでしょう。ただ「家を探すのはけっこうな手間です。なので、それをZabbixに探してもらいましょうというのが今日のテーマです」（渋谷氏）

Zabbixでは監視対象をホストとして登録し、その監視対象の持つさまざまなリソース、たとえばCPU使用率やディスク容量、ネットワーク通信の量などをアイテムとして紐付け、監視を行います。この仕組みはシステム監視に限らず幅広い用途に応用可能で、「家探し」も効率的に行えるというのです。

渋谷氏は実際に、Zabbixを用いて物件情報を収集し、家探しに役立てるための仕組みを作ってみました。不動産情報サイトをスクレイピングするスクリプトを作成し、そこから得られた物件情報一覧をZabbix APIを利用してホストとして登録します。このときにテンプレートも指定し、テンプレートに含まれるアイテムも紐付けていく形です。

次に詳細ページをスクレイピングするスクリプトを作成し、外部チェックアイテムとして、詳細情報に家賃や最寄り駅からの距離、部屋のタイプ・間取りや築年数といったさまざまな情報を取得し、依存アイテムとして登録していきました。これらに加え、ホスト情報の更新を行ったり、逆に契約が決まってしまった物件を無効化する処理なども追加し、物件を探せる仕組みを作り上げました。

「後はアクションで、物件が登録されたタイミングでメールやSlack、LINEなど好きなものに通知をするといった実装ができます」（渋谷氏）

このように、充実した機能や高いカスタマイズ性を備えたZabbixの特徴を生かし、さらにZabbix APIを活用することで、活用範囲はさまざまなシーンへ広がる可能性があります。ちなみにアークシステムには、Zabbixを用いて大気汚染情報や神奈川県の雨量水位状況の監視などを行っているメンバーもいるとのことです。

渋谷氏は最後に「こうしてみるとZabbixの新しい可能性を感じませんか。Zabbixでシステム監視ばかりさせてきましたが、それ以外の使い方もあるのではないかと共感してもらえればうれしいです」と呼びかけてセッションを終えました。