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に関する話題が多くあり、これからも新しい機能がどんどん入っていくでしょう。一方で既存の機能の中にも使えるものは非常にたくさんあり、アイデア次第でいろいろな使い方ができます」と述べました。

カンファレンスへ戻る