はじめに

Zabbix Summit 2026 レポートの2日目では、大規模な監視環境を支える技術的な工夫から、収集したデータの活用、ビジネスサービスの信頼性管理まで、幅広いテーマの講演をいくつかピックアップして紹介します。

今回取り上げる講演では、毎秒 100 万件の新規監視値を扱うための性能面の工夫や、日々の運用を効率化する機能、製造現場の業務アプリケーションを支える監視事例が紹介されました。さらに、Zabbix が収集したデータをレポートや AI による異常検知に活用する方法や、サービス全体の状態を可視化して SLA の管理につなげる取り組みも取り上げられました。

これらの講演に共通しているのは、監視データを収集して異常を通知するだけでなく、その情報を運用の改善や業務上の判断に役立てようとしている点です。それぞれの講演から、Zabbix の機能をどのように活用し、監視の効率化やサービスの安定運用につなげているのかを見ていきます。

大規模監視と日々の運用を支える Zabbix の工夫

Aleksandrs Kalimulins 氏の講演「Achieving 1M NVPS and Other Little Things」では、毎秒 100 万件の新規監視値を扱うというテーマとともに、日常の運用に役立つ Zabbix の機能が紹介されました。エージェント設定の簡素化からプロキシの運用、マクロによる通知の改善、ブラウザー監視まで、規模の拡大と使いやすさを両立するための工夫が幅広く取り上げられました。

■ エージェントの設定を整理する

エージェントの設定では、ホスト名の取得方法や、長いアイテムキーとパラメータの扱いが話題になりました。環境ごとに異なる情報をどこで設定するかを整理することで、テンプレートの再利用と保守をしやすくできます。短い別名やユーザーパラメータの活用は、複雑な設定を扱いやすくするための手段として紹介されました。

また、単一のエージェントを複数の論理的なホストとして利用する考え方も示されました。アクティブ監視では複数のホスト名を設定する方法があり、パッシブ監視では複数のホストから同じエージェントの接続先を参照できます。同じマシン上の監視対象を分けて管理したい場合に役立ちます。ただし、監視対象をどう分けるかは、テンプレートやパラメータの管理方針と合わせて考える必要があります。

導入を支援する機能として、ホストウィザードも紹介されました。画面の案内に従って設定を進め、生成されたコマンドを実行することで、エージェントの導入を進められます。設定に不慣れな担当者でも、必要な作業を段階的に確認できることが利点です。

■ 分散監視を支えるプロキシ

プロキシについては、収集データの保存方法として、ディスク、メモリ、ハイブリッドという選択肢が説明されました。メモリを使う方式は、収集データのバッファリングに伴うデータベースへの書き込みを抑えられます。ハイブリッド方式はメモリとデータベースを組み合わせるもので、通信状況やデータ保持の要件に応じた使い分けが重要です。軽量な SQLite は、遠隔拠点での運用やデータベースの再作成の容易さという観点から取り上げられました。設定の同期頻度についても、回線帯域や接続の安定性を考慮して調整できます。必要なタイミングで手動の設定更新を行う方法も紹介され、拠点ごとの事情に合わせた運用が示されました。

さらに、対応する範囲で異なるバージョンのプロキシを利用し、サーバーとプロキシを段階的に更新する考え方が説明されました。大規模環境では、すべての拠点を一斉に更新する負担を減らせます。プロキシ側でシークレットマクロを解決する機能も取り上げられ、拠点や役割に応じた秘密情報の取り扱いが話題になりました。

■ トリガーと通知を理解しやすくする

複雑なトリガー式は、設定を読むだけでは判定の理由を把握しにくい場合があります。講演では、マクロや式の構成要素を実際の値に展開して確認し、条件を読み解くための機能が紹介されました。複数のテンプレートや条件を組み合わせた監視では、こうした確認機能が調査を助けます。

通知の内容を充実させる方法として、値や時刻を示すマクロ、式マクロ、文字列変換などのマクロ関数も説明されました。例えば、ディスク容量の問題を知らせる際、対象のファイルシステムや残り容量をメッセージに含めれば、通知を受けた時点で状況を把握しやすくなります。異常の発生だけでなく、対応に必要な情報まで伝えることがポイントです。

■ ウェブ監視と表示機能の活用

ウェブシナリオでは、応答から JSONPath や XPath で値を抽出し、後続のステップで利用する方法が紹介されました。複数のリクエストをつなぐ REST API のテストなどに活用できます。ブラウザーアイテムについては、ログイン操作だけに用途を限定せず、自動操作の仕組みをさまざまな確認に応用する考え方が示されました。Appium を利用したモバイルアプリケーションのテストや、スクリーンショットの取得も話題になりました。一方、ブラウザーポーラーは同期的に処理するため、各チェックの所要時間、実行数、タイムアウトを考慮する必要があります。操作を自動化するだけでなく、監視を継続できる処理能力を見積もることが大切です。

このほか、ダッシュボードの操作性、アイテム履歴ウィジェット、ホストやテンプレートを探すグローバル検索も紹介されました。HTTP エージェントを使った Prometheus エクスポーターからのデータ取得にも触れられ、既存の監視資産を取り込む方法が示されました。

■ 毎秒 100 万件をテーマとした性能検証

講演の終盤では、ClickHouse と連携した構成での性能検証が紹介されました。履歴同期処理やバッファー、保存先の設定を調整し、書き込み先に過剰な負荷をかけないようにする工夫が説明されました。強調されたのは、瞬間的なピークではなく、単一の Zabbix サーバーノードで継続して処理できる負荷として評価する姿勢です。実測値は安定して 毎秒 100 万件処理を続けられることが説明されました。今回の講演は、大規模な処理性能と、日常の小さな運用改善を結び付ける内容でした。データ収集、保存、通知、画面操作をそれぞれ見直すことで、扱いやすく拡張しやすい監視環境につながると実感しました。

Zabbix の監視データを活用する ― AI による異常検知と高度なレポート機能

Wolfgang Alper 氏の講演「Putting Zabbix Data to Work: AI-Based Anomaly Detection and Advanced Reporting」では、Zabbix が収集している大量の監視データを、単なる監視結果として見るだけでなく、Reporting、外部連携、AI-Based Anomaly Detection に活用する方法が紹介されました。Alper 氏は、Zabbix はデータ収集に非常に強い一方で、収集した情報をそのまま監視画面の中だけで使うのではなく、Business Insight に変換することが重要だと説明しました。

■ レポート作成と外部システム連携によるデータ活用

まず紹介されたのが、Widget ベースの Reporting Engine です。考え方は Zabbix ダッシュボードに近く、レポートを複数の Widget の組み合わせとして構成します。Availability、Problem History、Current Problem、Long Running Problem、Graph、Markdown など、用途ごとに異なる Widget を利用でき、Management 向けレポートに必要な背景説明や補足情報も追加できます。レポートの元データは Zabbix API から取得し、Trend だけでなく Alert、Problem、Audit Log など幅広い情報を利用します。

収集したデータは Render Process を通して、人が読むレポートに変換することも、外部システムが再利用できるデータに変換することもできます。人向けには PDF レポートを生成でき、Header、Logo、Title、Table of Contents、Page Number などを含む形式で出力されます。各 Widget は Card のように レポート内へ配置され、Service Availability、MTTR、Problem State、Host Graph などを視覚的に確認できます。一方、システム連携向けには JSON、XML、CSV 形式でのエクスポートに対応し、BI Tool、Spreadsheet、Database、External Dashboard、Message Bus などにデータを渡せます。

講演では、既存データから新しい KPI を作る例として、Mean Time to Interaction や Mean Time to Recovery が紹介されました。Zabbix Event API に既に存在する情報を使って、Tech Support Team が Incident に対応するまでの平均時間や、Incident が Close されるまでの時間を算出できます。つまり、新しいデータを収集しなくても、既存の監視データから Management に有用な指標を作れるという点が重要です。

また、外部システムごとに必要なデータフォーマットが異なる場合に備えて、Transformation レイヤも用意されています。JavaScript の transform Function を使い、Report Object に対してフィールドの追加、削除、値の変更、新しい KPI の生成、Flatten 処理、Schema の変更などを実行できます。例えば外部システムが Report ID を必要とする場合は新しい フィールドを追加し、SLI と SLA の条件を比較して Boolean 値を生成することもできます。さらに、レポートデータを OpenTelemetry Collector が扱える形式に変換する例も紹介されました。

こうした仕組みにより、Zabbix で収集したデータを他部門や別アプリケーションに連携し、監視システムを企業全体のデータソースとして活用できます。特に大規模組織では、監視データを Kafka などの Message Bus に流し、別 Department や Business Application が Subscriber として利用する構成も考えられます。

■ 外部 AI Model による異常検知

講演後半では AI-Based Anomaly Detection も紹介されました。考え方は、Zabbix から取得した Time Series Data を外部 AI Model に入力し、各 Value が通常の Behavior からどの程度外れているかを Score として返すものです。複数の Model を同時に利用する Ensemble 構成も可能で、例えば 5 個の Model のうち 3 個以上が Anomaly と判断した場合に、最終的に異常として扱うような Majority Vote も設定できます。利用する Model 数を増やせば判定の信頼性を高められますが、その分 AI Server の Resource も必要になります。

AI 側からは Anomaly Score や Segment Score、さらに Trigger 作成の参考になる Threshold などが Zabbix に返されます。これらの値は通常の Zabbix Item と同様に ダッシュボードで確認でき、Trigger Expression に利用できます。つまり、Zabbix 本体の Source Code を変更せず、既存の アイテム、トリガー、ダッシュボードの仕組みを活用しながら、外部 AI Model による Anomaly Detection を組み込める点が特徴です。

■ 収集したデータを新たな価値につなげる

講演の Takeaway として強調されたのは、「もっとデータを集めること」よりも「すでに集めているデータをもっと賢く使うこと」です。監視システムには Infrastructure、Application、Business Activity など大量の情報が蓄積されています。それらは単なる監視用データではなく、企業にとって価値のある Asset です。

Zabbix が収集したデータをレポートに変換し、Management が理解しやすい KPI として提示し、JSON、XML、CSV などで外部システムに渡し、必要に応じて AI Model で Anomaly Detection を行うことで、Monitoring の役割を大きく拡張できます。今回の講演は、Zabbix を「異常を通知する Tool」だけでなく、「企業データを集約し、加工し、外部へ活用するプラットフォーム」として捉える実践的な事例でした。

Zabbix のサービス監視を活用した BSM と SLA 管理

Marek Panečný 氏の講演「Improving Service Reliability With Zabbix SLA Monitoring」では、Zabbix の Service Monitoring 機能を Business Service Monitoring、いわゆる BSM の考え方で活用し、単なる障害監視からサービス全体の信頼性管理へ発展させる方法が紹介されました。Panečný 氏は Asseco CEIT で監視基盤を担当しており、長年さまざまな監視製品を扱ってきた中で、2013 年頃から Zabbix を主要な監視ソリューションとして利用していると説明しました。

■ サービス全体の状態を可視化する BSM と SLA 監視

一般的な IT 環境は、Hardware、Operating System、Network、Database など複数のレイヤで構成されています。従来の監視では、それぞれのレイヤに対して Item や Trigger を大量に設定し、「何も気付かないまま壊れる」ことを避けるようにします。この方法自体は正しいものの、監視対象が増えるほど Problem や Notification も増え、いわゆる Alert Flood が発生しやすくなります。また、個々の Component の状態は分かっても、「その障害が Business Service にどの程度影響しているか」までは分かりにくいという課題があります。

そこで BSM では、通常の監視レイヤの上に Business レイヤを追加します。その中心となるのが Service Tree です。Service Tree は、Service や Service Component を Node として表し、それらの関係性を Tree 構造として定義するものです。各 Node には Severity や Status があり、下位 Node の状態を上位 Node に伝播させることで、サービス全体への影響を可視化できます。また、この Service Tree があることで、SLA Report、Impact Analysis、Root Cause Analysis といった処理の基盤を作ることができます。

Zabbix は標準機能として、Service Tree の構築、Problem と Service Node の関連付け、伝播や相関のルール、さらに各 Service に対する SLA 設定を提供しています。Problem と Service Node の紐付けには Tag を利用できるため、特定の Problem Severity や条件を Service の状態へ反映できます。そのため、Business Service Monitoring の基本機能は標準の Zabbix だけでも構築可能です。

■ 独自の Widget と Module によるサービス監視の強化

一方で、講演では標準機能の弱点も指摘されました。最も大きな課題は Service Tree の表示方法です。Zabbix 標準では Service Tree を本当の Tree 形式ではなく Table 形式で表示するため、構造が複雑になるほど関係性を直感的に把握しづらくなります。また、Service Tree をダッシュボード上に表示する専用 Widget がなく、Service Tree 自体の自動生成機能もありません。そのため、大規模環境では構築や保守を手作業で行う必要があります。

この課題を補うため、Asseco CEIT では 2 つの Widget と 1 つの Module を独自に開発しました。

• Service Tree Widget
  これは Service Tree を実際の Tree 構造としてダッシュボード上に表示します。Node に Mouse Pointer を合わせると詳細情報を表示でき、対象 Service の Status や Severity が時間とともにどのように変化したかも確認できます。
• Service History Report Widget
  これは複数の Service Node の状態変化を時間軸で表示し、Downtime の割合や継続時間、最終状態変更時刻などを確認できます。Service の信頼性を履歴として把握できるため、SLA の評価や障害傾向の確認にも役立ちます。
• Impact Analysis Module
  これは Problem 一覧から特定の Problem を選択した際に、その Problem が Service Tree のどの Node に影響しているかを表示します。Problem から直接 Impact Analysis を開始できるため、単に「障害が発生した」という情報だけでなく、「どの Business Service に、どの範囲で影響しているか」を素早く把握できます。

これらの拡張機能を標準の Zabbix Service Monitoring と組み合わせることで、CIO、Service Owner、Manager など、技術詳細より Business Impact を重視する利用者にも分かりやすい Monitoring が可能になります。Service Tree を視覚的に確認し、Node ごとの履歴や SLA を把握し、Problem から Impact Analysis を行い、さらに Service Node の状態変化を Alert の起点として利用することもできます。

■ SLA 監視をサービスの信頼性向上につなげる

今回の講演のポイントは、Zabbix の Service Monitoring 機能は単なる補助機能ではなく、Business Service Monitoring を実現するための重要な基盤になり得るという点です。一方で、Service Tree の Visualization や自動生成にはまだ改善の余地があり、今後は Automatic Discovery や Service Tree の自動構築機能が加わることで、さらに実用性が高まることが期待されています。

ラリーカー製造を支える Teamcenter 監視―― PLM を止めないための実践

Marko Väätänen 氏の講演「Keeping PLM at Full Throttle: Teamcenter Monitoring in Rally Cars Manufacturing」では、ラリーカー製造で利用する Teamcenter を対象に、Zabbix による監視の実践が紹介されました。中心となるテーマは、サーバーの稼働状況だけでなく、アプリケーションや業務の流れまで把握し、製造を支える PLM（製品ライフサイクル管理）環境の安定運用につなげることです。講演では、本番環境のダッシュボードや通知の例を交えながら、現場で必要とされる監視の考え方が説明されました。

■ 正常な状態を定義し、監視の範囲を広げる

監視を設計する出発点は、何をもって正常と判断するのかを定義することです。Teamcenter が正常に機能しているかを判断するには、その基盤となるサーバーやデータベースに加え、関連するサービスや自動化処理にも目を向ける必要があります。講演では、一般的な基盤監視と Teamcenter 固有の監視項目を組み合わせ、必要な情報を収集する構成が紹介されました。

具体的な対象として挙げられたのは、データベースの状態、アプリケーションのプロセスごとのメモリ消費量、ファイルの欠落、Windows イベントログなどです。メモリリークの検出も監視対象に含まれており、サービスが起動しているかどうかだけでは分からない問題を捉えようとしています。メモリ使用量をグラフで確認することで、ある時点の値だけでなく、時間の経過に伴う変化を追える点も紹介されました。

■ 業務のワークフローに踏み込む

この事例で注目したいのは、Teamcenter 固有のワークフローを監視対象としている点です。基盤側の状態を確認するだけでなく、アプリケーション内部の処理が期待どおりに進んでいるかを追跡する視点が示されました。処理の連鎖の中に問題があっても、監視がなければ担当者が気付けない場合があるという説明は、業務に近い層を可視化する重要性を表しています。

一方で、ワークフローから必要な情報を取り出す作業は、簡単ではないことも語られました。どの情報を取得したいのか、どの条件で結果を抽出するのかを明確にし、Teamcenter のデータベースや処理の構造に合わせて設定する必要があります。
講演では、UserParameter を使った情報取得や、特定のイベントに対応するトリガーの設定にも触れられました。監視項目を増やすだけでなく、業務上の問題を判断できる情報に整えることが、実装上の要点として読み取れます。

■ ダッシュボードで利用状況をまとめて確認する

本番環境の監視画面では、サービスの状態とともに、ユーザー数やログインに関する情報を確認する例が示されました。複数の情報を一つの画面にまとめることで、担当者が環境全体の様子を把握しやすくしています。日常的に確認する情報を集約することは、異常が起きた際に、どこを調べるべきか判断する助けにもなります。

ライセンスも重要な可視化対象です。講演では、利用中のライセンス数や期限に関する情報を扱い、ダッシュボードで確認する仕組みが紹介されました。システムの稼働状況に加えて、利用者が実際にサービスを使うための条件まで把握している点が特徴です。監視対象となるユーザーのリストを更新する運用にも触れられ、収集対象を実態に合わせて維持する必要性がうかがえました。

■ 通知を、確認と対応につなげる

異常を迅速に知るためのアラームは欠かせませんが、通知が多くなると、その内容を確認して対応すること自体が課題になります。講演でも、多数のメール通知を受け取る状況が取り上げられました。情報を集めて通知する仕組みを整えるだけでは、運用上の負担がなくなるわけではありません。

そこで言及されたのが、事前チェックやワークフローの状態確認です。自動化を考える際にも、対象の状態を確かめる仕組みが必要であり、通知から直ちに処理を実行すればよいという単純な話ではありません。また、チームからの連絡や確認を取り入れるフィードバックの流れも紹介されました。監視で得た情報と現場で把握した状況を照らし合わせることが、問題の確認や対応を支えています。

■ 製造を支えるアプリケーション監視の価値

今回の講演が示したのは、監視対象をインフラからアプリケーション、さらに業務の流れへと広げる実践です。データベース、プロセス、ログ、ファイル、ライセンス、ワークフローをそれぞれ確認することで、単一の指標では見えない問題を捉えようとしています。その実現には、Teamcenter の内部構造と運用を理解し、必要な情報を選び取る作業が欠かせません。

ラリーカー製造という現場を支える PLM 環境において、監視は障害を知らせるだけの仕組みではありません。担当者が日々の状態を理解し、見落としやすい問題に気付き、対応へ進むための基盤です。Zabbix の収集・可視化・通知の機能を、対象アプリケーションの特性に合わせて組み合わせることの価値が伝わる事例でした。

おわりに

今回紹介した講演では、大規模なデータ収集を支える性能面の工夫から、日々の運用を効率化する機能、アプリケーションや業務サービスの状態を把握するための監視、さらには AI や外部システムとの連携まで、Zabbix の幅広い活用方法が紹介されました。

毎秒 100 万件の新規監視値を扱うための性能検証では、データの収集や保存の仕組みを適切に調整することの重要性が示されました。また、エージェントやプロキシの設定、通知メッセージの改善といった日々の運用に関わる工夫も取り上げられ、監視環境の規模を拡大することと、扱いやすさを両立するための考え方を知ることができました。

一方、Teamcenter の監視事例や SLA 監視の講演では、インフラの稼働状況だけでなく、アプリケーション内部の処理や業務サービスへの影響まで把握することの重要性が示されました。さらに、収集したデータをレポートや KPI に変換し、外部システムや AI による異常検知に活用する取り組みからは、監視データを運用改善や意思決定に役立てる可能性が見えてきます。

これらの事例から、監視環境を改善するうえでは、単に監視項目を増やしたり、より多くのデータを収集したりするだけでなく、何を把握したいのか、得られた情報を誰がどのように活用するのかを考えることが重要だと感じました。

Zabbix には、データ収集、障害検知、可視化、通知、サービス監視など、さまざまな機能が備わっています。これらを監視対象や運用上の課題に合わせて組み合わせることで、障害の早期発見にとどまらず、日々の運用の効率化やサービスの信頼性向上にもつなげることができます。

Zabbix Summit 2026 で紹介された事例や考え方を参考に、私たちもお客様の環境や課題に応じた監視のあり方を考え、より実用的な監視・運用の実現に取り組んでいきたいと思います。

はじめに

Zabbix Summit は、オープンソースの統合監視ソリューションである Zabbix に関する最新情報や活用事例、技術的な知見が共有されるイベントです。世界各国の Zabbix ユーザーやエンジニア、パートナー企業、開発者などが集まり、Zabbix の最新機能や今後の開発の方向性、実際の運用現場での取り組みについて理解を深める機会となっています。

今回開催された Zabbix Summit 2026 では、Zabbix の最新バージョンに関する情報をはじめ、監視運用の効率化や自動化、生成 AI との連携、オブザーバビリティなど、今後の監視基盤を考えるうえで興味深いテーマが取り上げられました。

本レポートでは、Zabbix Summit 2026 で発表されたセッションの中から、特に注目した内容をピックアップし、技術的なポイントや実際の Zabbix 環境への活用という観点から紹介します。

Zabbix 8.0 が切り拓く Observability の新時代 ― Alexei Vladishev 氏による基調講演

Zabbix Summit 2026 で、Zabbix の創設者である Alexei Vladishev 氏が「Zabbix 8.0: Redefining Observability」と題した講演が行われました。
講演では、Zabbix 8.0 の主要な新機能と性能改善に加え、AI、クラウド、モバイル、Marketplace を含む今後の戦略が紹介されました。
特に印象的だったのは、従来の監視ツールから、システム全体の状況と問題の背景を理解する Observability プラットフォームへ進化させようとする方向性です。

■ オープンソースと統合監視という Zabbix の強み

Alexei 氏は、Zabbix の大きな特徴として、オープンソースであること、さまざまな環境に柔軟に対応できること、監視に必要な機能を統合的に提供することを挙げました。
Zabbix は、OS やネットワーク機器の監視を中心に発展してきましたが、現在ではコンテナ、クラウド、アプリケーション、オンプレミスとクラウドが混在するハイブリッド環境まで対象を広げています。
異なるベンダーの製品を組み合わせて監視基盤を構築する方法もありますが、できるだけ多くの機能を一つの基盤で利用できることは、構成や運用の複雑さを抑えるうえで重要です。
ライセンス料金を課さない方針に加え、公開ドキュメント、公式トレーニング、各種サービスによって利用者を支援する姿勢も強調されました。
セキュリティについては、認証や製品開発・提供プロセスへの対策の組み込みに触れ、機能の豊富さだけでなく信頼性も重視していることが示されました。

■ OpenTelemetry とトレースによる可観測性の拡張

Zabbix 8.0 の重要なテーマの一つが、OpenTelemetry などを通じた新しい種類のデータの取り扱いです。
従来のインフラ監視では、CPU 使用率、メモリ、ディスク、ネットワークの状態といったメトリクスが中心でした。
しかし、複数のサービスが連携するアプリケーションでは、ある処理がどこを通り、どの部分で遅延や障害が発生したかを把握する必要があります。
そこで重要になるのが、リクエストや処理の経路を追跡するトレースデータです。
講演では、こうした情報を Zabbix で収集、保存、可視化する取り組みが説明され、AWS X-Ray にも言及されました。
メトリクス、ログ、トレースを関連付けて扱うことができれば、単に異常を検知するだけでなく、問題がインフラにあるのか、アプリケーションにあるのかを調べる手掛かりが増えます。
Zabbix をインフラ監視だけでなく、アプリケーションの動作を理解するための基盤へ広げる重要な変化と言えます。

■ MCP Server で AI と監視データを接続

もう一つの大きな進化として紹介されたのが、MCP Server への対応です。
MCP Server は Zabbix と AI の間に入る仲介役として機能し、AI から監視情報を参照・活用するための接点になります。
講演では、「今、最も重要な問題は何か」「どのホストに注目すべきか」といった問いを自然言語で投げかける利用方法が例示されました。
これまで監視担当者は、画面を切り替え、条件を指定し、複数の情報を読み解いて状況を把握する必要がありました。
AI との連携が進めば、必要な情報を対話形式で取り出し、調査の出発点を素早く見つけることが期待されます。
Alexei 氏は、特定の AI モデルに固定するのではなく、利用者が適切な AI の仕組みを選べる柔軟性も重視していました。
ただし、AI がすべての判断を自動化するという説明ではなく、監視データをより使いやすくするための新しいインターフェースとして理解することが重要です。

■ 複合イベント処理によってアラートの意味を整理

Complex Event Processing と呼ばれる複合イベント処理も、講演で強調された機能です。
大規模環境では、単一の障害が原因で多数のトリガーや問題イベントが短時間に発生することがあります。
すべてのイベントを個別に確認する運用では、本当に対処すべき問題が大量の通知に埋もれてしまいます。
新しい処理の仕組みでは、イベントの流れやパターンを扱い、関連する事象を整理して重要な情報を浮かび上がらせることを目指しています。
講演では、毎分 100 件を超えるイベントが発生する状況にも触れ、単純なイベント単位のルールを超えた複雑な処理や、プログラムによるパターンマッチングの拡張について説明されました。
監視の価値を、アラートを数多く出すことから、運用担当者が優先順位を判断しやすくすることへ変えていく機能です。

■ 毎秒数百万メトリクスを見据えた性能向上

性能面では、大量の監視データを継続的に処理する環境を想定した改善が紹介されました。
Alexei 氏は、毎秒数百万件規模のメトリクスを扱う事例を挙げ、ボトルネックの解消やストレージ処理の最適化について説明しました。
新しいストレージエンジンへの対応や、高度な圧縮技術によって、データを効率的に保持・処理する方向性が示されています。
CPU やメモリの効率についても改善が語られ、処理によっては大幅な高速化が得られることが強調されました。
ただし、講演中に示された性能値は特定の条件に基づくものと考えられるため、あらゆる環境で同じ改善率が得られると断定することはできません。
大規模な監視基盤ほど、こうした処理効率の向上はインフラコストや拡張性に直結します。

■ 使いやすさを高める UI とビューのカスタマイズ

UI の改善も、日常の運用に直接関わる重要なテーマです。
講演では、画面の一貫性やアクセシビリティの改善に加え、利用者が必要な情報を柔軟に表示するためのカスタマイズ機能が紹介されました。
表示する列の追加や並べ替え、タグやホストのインベントリ情報を利用した列の構成などにより、用途に応じた一覧画面を作成できるようになります。
例えば、データセンター名や機器に関する情報を列として表示すれば、問題の発生場所や対象機器を一覧から把握しやすくなります。
また、データのフィルタ条件と表示方法を保存し、異なる目的に応じて複数のビューを使い分ける考え方も説明されました。
監視データの量が増えるほど、情報の見せ方を利用者自身が調整できることの価値は高まります。

■ Zabbix Cloud と Mobile App による運用の変化

Zabbix Cloud については、監視基盤そのものの保守負担を減らすサービスとして紹介されました。
利用者がセキュリティパッチ、バックアップ、基盤のメンテナンスを細かく管理する必要を減らし、本来の監視業務に集中できることが狙いです。
クラウドから各拠点のインフラを監視する構成や、Zabbix のバージョン対応についても言及がありました。
一方、Mobile App では、重要な問題をプッシュ通知で素早く把握することと、外出先から問題の状態を確認することが主要な利用場面として示されました。
ユーザープロファイルとモバイル端末を関連付ける仕組みにも触れ、日常的な監視業務をデスクトップの外へ広げようとする姿勢がうかがえます。
Cloud と Mobile App は、監視の対象だけでなく、監視サービスの提供方法や利用する場所を変える取り組みです。

■ Marketplace が広げる拡張機能のエコシステム

Marketplace については、Zabbix 向けの追加機能やソリューションを見つけ、共有・入手するための場所として紹介されました。
例えば、新しいレポートや追加モジュールが必要な場合に、コミュニティやベンダーが提供する成果物を利用できるようにする構想です。
無料のものだけでなく、商用の拡張機能も想定されており、開発者が作成した機能を多くの Zabbix ユーザーへ届ける場として期待されています。
個別に作られていた便利な機能が広く流通すれば、利用者は開発の手間を減らせる一方、パートナーや開発者には新たな提供機会が生まれます。
講演では Marketplace に関する別セッションも案内され、利用者からの期待や意見を集めたいという呼びかけがありました。

■ 今後の展望 ― AI を製品と開発プロセスの両方へ

講演の最後には、Zabbix の長期的な方向性として AI のさらなる活用が語られました。
MCP Server による外部 AI との接続に加え、将来的にはテンプレート作成など、Zabbix の機能そのものに AI を組み込む方向性が示されました。
例えば、監視したいデバイスの情報を伝えることで、設定作業を支援するような使い方が考えられます。
また、AI の活用対象は製品機能に限らず、コードの作成やテスト、QA といった開発・品質保証の領域にも広がっています。
これらはすべてが Zabbix 8.0 で完成しているという意味ではなく、今後の開発に向けた戦略的な展望として説明された内容です。

Root Cause Analysis with Complex Event Processing ― CEP による根本原因分析

Kaspars Mednis 氏の講演「Root Cause Analysis with Complex Event Processing」では、Zabbix のイベント相関機能を活用し、大量の障害通知から根本原因を特定するための考え方が紹介されました。
複合イベント処理（ CEP：Complex Event Processing ）を利用した根本原因分析の目的は、単にアラート数を減らすことではなく、原因となる問題と派生的な症状を区別することです。
時間ウィンドウ、キャパシティ、グループ化、相関ルールを適切に設計すれば、複雑な依存関係の保守負担を減らし、障害対応時に注目すべき情報を絞り込めます。
一方で、設定によってイベントの扱いが変わるため、実際の監視環境に合わせて動作を検証することが重要です。

■ 従来のトリガー依存関係の課題

ひとつの障害が複数のサービスに影響すると、根本原因とは別に多数の関連アラートが発生します。

従来はトリガー間の依存関係を定義して対処できましたが、構成が複雑になるほど設定や保守が難しくなります。
講演では、既存の依存関係が機能することを認めながら、イベントの発生状況に応じて柔軟に関連付ける方法が説明されました。

■ 複合イベント処理（ CEP ）によるイベント相関

複合イベント処理（ CEP ）では、まずフィルターで対象イベントを選び、相関ルールを設定します。
ホストグループやタグなどの属性を条件にでき、関連するイベントを同じ処理の対象として扱えます。
相関ルールでは、どのイベントを照合し、一致した場合にどのような操作を行うかを定義します。
この方法により、すべての依存関係を手動で列挙することなく、一定の条件に基づいて問題同士を関連付けられます。

■ 時間ウィンドウとキャパシティ

中心となる概念が、イベントを一定期間保持して照合する時間ウィンドウです。
例えば 10 分間のウィンドウを設定すると、その期間に入ったイベントを条件に従って評価できます。
イベントがいつウィンドウに入り、いつ対象から外れるかによって相関結果が変わるため、継続時間の設定が重要です。
また、ウィンドウに保持するイベント数を制限するキャパシティも設定できます。
講演では、解決済みの問題であってもウィンドウ内に残る間はキャパシティを消費する場合があることが強調されました。
単にアラートが解決したかどうかだけでなく、ウィンドウ内の状態を理解する必要があります。

■ イベントのグループ化

タグなどを利用してイベントをグループ化すると、同じルールを複数の対象に適用しながら、ウィンドウをグループごとに分離できます。
例えばストレージごとにグループを分ければ、異なるストレージの障害を誤って関連付けずに済みます。
複数の一致条件を組み合わせることもでき、イベントの属性や発生順序に応じた処理を構成できます。
なお、相関ルールで処理対象から外すことと、元のアラートそのものを削除することは同じではありません。

■ ポートフラッピングへの適用

具体例として、ネットワークポートがダウンとアップを短時間に繰り返すポートフラッピングが紹介されました。
こうした変化をすべて独立した障害として通知すると、重要な問題が大量のアラートに埋もれてしまいます。
同じポートのイベントを時間ウィンドウで関連付ければ、繰り返し発生する変化をまとめて扱い、不要な通知を抑制できます。

■ 障害の連鎖とログイン失敗

バックアップ失敗など、ひとつの障害が後続の問題を引き起こすケースも取り上げられました。
イベントを関連付け、条件を満たした際に複数の問題をまとめて解決扱いにするなどの処理が考えられます。
また、ログイン失敗が繰り返されるケースでは、ウィンドウ内のイベント数を評価し、代表的なアラートを残して後続通知を抑制する方法が説明されました。

■ 独自ロジックによる拡張

講演では、ウィンドウ内のイベントを数える関数などを使い、条件判定の結果として true または false を返す処理にも言及がありました。
イベントのタグや数値属性を変更したり、複製や破棄などの操作を組み合わせたりすることで、用途に応じた相関ロジックを作成できます。

Zabbix の新たな APM の可能性 ― OpenTelemetry を活用した監視の進化

Zabbix の製品責任者である Martiņš Orinskis 氏は、「Unlocking New APM Power」と題した講演で、OpenTelemetry を活用したアプリケーション監視の新たな可能性を紹介しました。
クラウドネイティブ技術や分散アーキテクチャの普及により、アプリケーションの健全性を把握することは従来以上に難しくなっています。
単純な死活監視や個別の性能指標だけでなく、複数のサービスを横断して状況を理解し、問題の原因を迅速に特定する仕組みが求められています。

■ OpenTelemetry による多様なデータの活用

OpenTelemetry は、メトリクス、ログ、トレースなどのテレメトリデータを共通の仕組みで収集・転送するための技術です。
講演では、OpenTelemetry Protocol を通じて得られるデータには豊富な属性や情報が含まれる一方、そのままでは量が多く、監視に利用しにくい場合があると説明されました。
そこで重要になるのが、データを集約・計算・変換し、運用担当者にとって意味のあるメトリクスに整理することです。
例えば、特定の業務処理に対するリクエスト数や、サービス単位の応答時間などを抽出すれば、アプリケーションの状態を把握しやすくなります。

■ Zabbix Proxy を活用した収集と集約

今回の説明では、Zabbix Proxy を中心に OpenTelemetry のデータを扱う構成が紹介されました。
テレメトリデータを収集する処理と、そこから必要な値を取り出して Zabbix で監視する処理を分けることで、大量の生データをそのまま監視基盤に保存する必要を減らせます。
プロキシ側で集約やクエリを実行し、結果を Zabbix のアイテムとして扱うことで、既存の監視やアラート機能との連携が可能になります。
講演では、テレメトリストレージに対して SQL に似たクエリを実行し、その結果を JSON 形式で受け取り、Zabbix のストレージに保存する流れも説明されました。
これにより、詳細なデータの保管と、日常の監視に必要な指標の管理を役割分担できる構成が示されました。

■ 柔軟な設定と動的な情報の取得

OpenTelemetry を利用するための接続設定については、設定ファイルを使う方法に加え、ユーザーインターフェースから接続を定義する方法も紹介されました。
収集対象やリソース属性、ホストに関連する設定を組み合わせることで、環境に応じた監視を構成できます。
また、データに含まれるサービス名などの属性を利用し、動的に情報を識別することも重要なポイントです。
JSON 形式のデータから必要なフィールドを取り出す機能や、複数の値をまとめて取得する方法についても説明がありました。
こうした仕組みは、サービスや監視対象が頻繁に変化する環境で特に役立つと考えられます。

■ 集約間隔とアラートの設計

講演では、データの集約間隔とアイテムの実行間隔を適切に設定する必要性にも触れられました。
例えば、10 秒ごとにクエリを実行する場合、どの時間範囲のデータを集約するかによって、監視結果に欠落や重複が生じる可能性があります。
短時間のサンプリングで動作を確認しながら、用途に合った集約方法を選ぶことが重要です。
さらに、JSONPath を使ったフィールドの抽出や、取得したデータに基づくトリガーの設定によって、特定の状態を検出してアラートにつなげる考え方が示されました。
一方、JSON データに対する一部の高度な関数や相関処理については、今後の対応が期待される機能として言及されました。

■ APM と従来の監視をつなぐ

今回の講演で印象的だったのは、OpenTelemetry を独立した監視の仕組みとして扱うのではなく、Zabbix が持つ既存の監視機能と組み合わせようとしている点です。
データセンター全体の状態から、個々のサービスや特定のエンドポイントの応答時間まで、対象に応じて監視の粒度を変えることができます。
ログ、トレース、メトリクスを組み合わせて分析することで、単に異常を検知するだけでなく、その背景にある原因を調べるための手掛かりも得られます。
OpenTelemetry から得られる膨大な情報を、実際の運用に役立つ指標へ変換することが、今後の APM における重要なテーマだと感じました。
Zabbix の新しい取り組みは、従来のインフラ監視とアプリケーションの可観測性をつなぎ、より幅広いユースケースへの対応を目指すものといえます。

おわりに

今回の講演からは、Zabbix 8.0 が単なる機能追加版ではなく、監視基盤の役割を広げる重要な節目として位置付けられていることが伝わってきました。
OpenTelemetry やトレースによるデータの拡張、MCP Server を通じた AI 連携、複合イベント処理による情報の整理、大規模環境を支える性能改善は、いずれも現代の複雑なシステム運用に直結するテーマです。
さらに、UI の柔軟性、Cloud、Mobile App、Marketplace の取り組みは、Zabbix を利用する人や提供する企業の裾野を広げるものです。
オープンソースと柔軟性という従来の強みを維持しながら、収集したデータから問題の意味を理解し、迅速な判断につなげる Observability プラットフォームへ進化していくことが、今回の講演の中心的なメッセージだったと感じました。

脆弱性修正

• CVE-2026-49975: mod_http2 サービス運用妨害 (DoS)。Apache HTTP Server の mod_http における過大なサイズ値によるメモリ割り当ての脆弱性により、悪意のある HTTP リクエストを介してサービス運用妨害（DoS）が引き起こされる可能性があります。この問題は Apache HTTP Server 2.4.17 から 2.4.67 まで影響します。
• CVE-2026-48913: ファイルハンドル枯渇時における mod_http2 のメモリ破損。ファイルハンドルがすでに枯渇している際、Apache HTTP Server モジュール mod_http2 において使用中メモリ解放（Use After Free）の脆弱性が発生します。この問題は Apache HTTP Server 2.4.55 から 2.4.67 まで影響します。
• CVE-2026-44631: 符号付き文字のオーバーフローを介した ap_regname におけるヒープアンダーフロー。設定ファイル内の細工された正規表現により、Apache HTTP Server にバッファアンダーライト（境界未満への書き込み）の脆弱性が存在します。この問題は Apache HTTP Server 2.4.0 から 2.4.67 まで影響します。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。
• CVE-2026-44186: mod_proxy_ftp の proxy_ftp_handler における無限ループ。攻撃者が制御するバックエンド FTP サーバーを利用することで、Apache HTTP Server の mod_proxy_ftp モジュールにおいて到達不能な脱出条件（無限ループ）の脆弱性が存在します。この問題は 2.4.0 から 2.4.67 まで影響します。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。
• CVE-2026-44185: mod_ssl OCSP send_request におけるスタックバッファの過剰読み取り。攻撃者が制御する OCSP サーバーへのアウトバウンド OCSP リクエストを介して、Apache HTTP Server にバッファ過剰読み取りの脆弱性が存在します。この問題は Apache HTTP Server 2.4.0 から 2.4.67 まで影響します。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。
• CVE-2026-44119: 複数モジュールの .htaccess 内の式を介した権限昇格。Apache HTTP Server 2.4.67 以前において、不適切な権限管理の脆弱性により、ローカルの .htaccess 作成者が httpd ユーザーの権限でファイルを読み取れる可能性があります。この問題は 2.4.67 以前に影響します。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。
• CVE-2026-43951: merge_response_headers における領域外読み取り（OOB Read）によるクラッシュの可能性。mod_headers と mod_mime を使用し、複数のレスポンス言語が設定されている環境において、Apache HTTP Server に領域外読み取りの脆弱性が存在します。この問題は Apache HTTP Server 2.4.0 から 2.4.67 まで影響します。
• CVE-2026-42536: mod_xml2enc のヒープオーバーフロー。信頼されていないコンテンツ、xml2StartParse、および mod_xml2enc を使用する環境において、Apache HTTP Server にヒープベースのバッファオーバーフローの脆弱性が存在します。この問題は Apache HTTP Server 2.4.0 から 2.4.67 まで影響します。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。
• CVE-2026-42535: mod_dav_fs の保護されたディレクトリへのアクセス。Apache 2.4.67 以前の mod_dav_fs におけるパス処理の問題により、WebDAV コンテンツの作成者が信頼された DAV プロパティデータベースを直接操作し、子プロセスをクラッシュさせる可能性があります。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。
• CVE-2026-34356: ProxyPassReverseCookieMap のバッファオーバーフロー。悪意のあるバックエンドサーバーと ProxyPassReverseCookie* の組み合わせにおいて、Apache HTTP Server にヒープベースのバッファオーバーフローの脆弱性が存在します。この問題は Apache HTTP Server 2.4.0 から 2.4.67 まで影響します。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。
• CVE-2026-34355: mod_proxy_html のバッファオーバーフロー。Apache HTTP Server 2.4.67 以前の mod_proxy_html において、信頼されていないバックエンドからの攻撃を許すバッファオーバーフローの脆弱性が存在します。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。
• CVE-2026-29170: mod_proxy_ftp のクロスサイトスクリプティング（XSS）。正方向（フォワード）または逆方向（リバース）プロキシ構成で FTP ディレクトリコンテンツをリスト表示する際、Apache HTTP Server 2.4.67 以前の mod_proxy_ftp が生成する HTML ディレクトリリストにクロスサイトスクリプティングの脆弱性が存在します。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。
• CVE-2026-29167: パーディレクトリ（ディレクトリ単位）構成における mod_ldap の使用中メモリ解放（Use After Free）。ディレクトリ単位の構成で mod_ldap を使用している際、Apache HTTP Server に使用中メモリ解放の脆弱性が発生します。この問題は Apache HTTP Server 2.4.0 から 2.4.67 まで影響します。この問題を修正したバージョン 2.4.68 へのアップグレードを推奨します。

不具合修正

• mod_ssl, ab: OpenSSL 4.0 のサポートが追加されました。
• mod_ssl: SSL 識別名（DN）変数として、SerialNumber が認識可能な属性タイプとして追加されました。
• mod_ssl: クライアント証明書認証が実行された際、認証タイプ（auth type）に “ClientCert” が設定されるようになりました。
• mod_include: 条件評価がエラーを返した際、if/elsif/else のコンテンツを一切出力しないよう修正されました。
• mod_unixd: FreeBSD 11 以降において、CoreDumpDirectory の利用にトレース（tracing）の有効化が必要になりました（PR 65819）。
• mod_file_cache: スレッド化された MPM 環境下における、mmap されたファイルのクラッシュが修正されました（PR 69901）。
• core: ErrorLogFormat において、従来のマイクロ秒（%{u}t）だけでなく、ミリ秒単位で時間を記録できる %{m}t が新たに利用可能になりました。
• mod_unixd: chroot 構成において、有効ユーザー ID（EUID）がゼロであるかどうかのテスト（チェック）が削除されました（PR 69767）。
• mod_proxy_balancer: XML 出力にノンス（nonce）が含まれるよう修正されました（PR 63074）。
• mod_http2: バージョン 2.0.42 にアップデートされました。非 TLS のフロントエンド接続でファイルを送信する際、ファイル記述子（ファイルディスクリプタ）を過剰に消費する問題が修正されました。
• mod_http2: バージョン 2.0.41 にアップデートされました。LimitRequestFields に対するクッキーヘッダーのカウント処理が修正されました。
• mod_http2: バージョン 2.0.40 にアップデートされました。アップロードリクエストの処理中にサーバーのファイルハンドルが枯渇した際のエラー処理が修正されました。これにより、beam bucket のコールバックが残ってしまい、無効になった参照を呼び出す可能性があった問題が解消されました。この問題は、パイプライン処理が存在し、かつネットワークサーバーとして適切でないレベルでファイル記述子が制限されているプラットフォームにのみ適用されます。
• mod_dav_fs: リソースがすでに存在しないことが原因で削除に失敗した場合、DELETE リクエストに対して 404 を返すよう修正されました（PR 60746）。
• mod_proxy_hcheck: 更新中に子プロセスが再起動したことが原因で、ヘルスチェックが非有効化されてしまう問題が修正されました。

詳細は以下をご覧ください。

https://downloads.apache.org/httpd/CHANGES_2.4

不具合修正

• vCenter へのネットワーク接続の問題によって引き起こされる可能性のある VMware コレクターのクラッシュが修正されました。[Proxy] [Server]（ZBX-27975）
• RabbitMQ テンプレートにおける重複したディスカバリキーと JavaScript の保存前処理が修正されました。[Templates]（ZBX-21745）
• ホストウィザードで検索フィールドをクリアした後にテンプレートが誤って表示される問題が修正されました。[Frontend]（ZBX-26583）
• ディスカバリルール、ディスカバリプロトタイプ、ホストプロトタイプ、Web シナリオ、およびマップのリダイレクト機能が修正されました。[Frontend]（ZBX-26953）
• ターゲットホストがプロキシグループによって監視されている場合に、トリガーアクション操作でのリモートコマンドの実行が失敗する問題が修正されました。[Server]（ZBX-27665）
• ホストの Web 監視リストにおける一括アクションの権限チェックが修正されました。[Frontend]（ZBX-27689）
• 永続バッファの書き込みにリトライ処理が追加されました。[Agent]（ZBX-27922）
• 一部の Web サイトで証明書にアクセスできない問題が修正されました。[Agent]（ZBX-26916）
• Zabbix web service のビルドスクリプトが修正されました。[Agent]（ZBX-27724）
• Zabbix agent 2 における誤解を招くコメントが修正されました。[Agent]（ZBX-18840）
• system.run の失敗と競合状態が解決されました。[Agent]（ZBX-27024）
• GCP の DB インスタンス取得スクリプトが修正されました。[Templates]（ZBX-25578）
• MSSQL by Zabbix agent 2 テンプレートにおける PLE トリガーの命名と説明が修正されました。[Templates]（ZBX-27139）
• 値を破棄する前の冗長な保存前処理が修正されました。[Templates]（ZBX-26704）
• DBL_MAX 入力を扱う際に inf 値が生成されるのを防ぐため、平均トレンドの計算が修正されました。また、閾値に到達できずヒストリが DBL_MAX に近づいた場合に DBL_MAX を返すように timeleft() 関数が更新されました。[Server]（ZBX-27453）

機能追加・改良

• TimescaleDB の最大サポートバージョンが 2.28 に更新されました。[API] [Server]（ZBXNEXT-10669）
• Veeam Backup and Replication および Veeam Backup Enterprise Manager by HTTP テンプレートが更新されました。[Templates]（ZBXNEXT-10558）

詳細は以下をご覧ください。

https://www.zabbix.com/jp/rn/rn7.4.13

不具合修正

• vCenter へのネットワーク接続の問題によって引き起こされる可能性のある VMware コレクターのクラッシュが修正されました。[Proxy] [Server]（ZBX-27975）
• RabbitMQ テンプレートにおける重複したディスカバリキーと JavaScript の保存前処理が修正されました。[Templates]（ZBX-21745）
• ディスカバリルール、ホストプロトタイプ、グラフ、グラフプロトタイプ、Web シナリオ、およびマップのリダイレクト機能が修正されました。[Frontend]（ZBX-26953）
• DBL_MAX 入力を扱う際に inf 値が生成されるのを防ぐため、平均トレンドの計算が修正されました。また、閾値に到達できずヒストリが DBL_MAX に近づいた場合に DBL_MAX を返すように timeleft() 関数が更新されました。[Server]（ZBX-27453）
• ターゲットホストがプロキシグループによって監視されている場合に、トリガーアクション操作でのリモートコマンドの実行が失敗する問題が修正されました。[Server]（ZBX-27665）
• ホストの Web 監視リストにおける一括アクションの権限チェックが修正されました。[Frontend]（ZBX-27689）
• 永続バッファの書き込みにリトライ処理が追加されました。[Agent]（ZBX-27922）
• 一部の Web サイトで証明書にアクセスできない問題が修正されました。[Agent]（ZBX-26916）
• Zabbix web service のビルドスクリプトが修正されました。[Agent]（ZBX-27724）
• Zabbix agent 2 における誤解を招くコメントが修正されました。[Agent]（ZBX-18840）
• GCP の DB インスタンス取得スクリプトが修正されました。[Templates]（ZBX-25578）
• system.run の失敗と競合状態が解決されました。[Agent]（ZBX-27024）
• MSSQL by Zabbix agent 2 テンプレートにおける PLE トリガーの命名と説明が修正されました。[Templates]（ZBX-27139）
• 値を破棄する前の冗長な保存前処理が修正されました。[Templates]（ZBX-26704）
• スクリーンリーダーユーザー向けに、すべての機能ボタンとアイコンの aria-label テキスト、およびサイドメニュー要素の aria-expanding が改善されました。[Frontend]（ZBX-26465）

機能追加・改良

• TimescaleDB の最大サポートバージョンが 2.28 に更新されました。[API] [Server]（ZBXNEXT-10669）

詳細は以下をご覧ください。

https://www.zabbix.com/jp/rn/rn7.0.29

不具合修正

• system.run の失敗と競合状態が解決されました。[Agent]（ZBX-27024）

機能追加・改良

• TimescaleDB の最大サポートバージョンが 2.28 に更新されました。[API] [Server]（ZBXNEXT-10669）

詳細は以下をご覧ください。

https://www.zabbix.com/jp/rn/rn6.0.48

不具合修正

• 両方の Zabbix agent における過剰なヒストリのアップロード遅延が修正されました。[Agent]（ZBX-27495）
• テンプレートやホストを複製する際に、同じトリガープロトタイプに依存するプロトタイプをコピーできない問題が修正されました。[Frontend]（ZBX-27883）
• サーバーサイドのチェックを実行するインラインバリデーションを伴うスタンドアロンの編集フォームを閉じる際の JavaScript エラーが修正されました。[Frontend]（ZBX-27065）
• Zabbix agent 2 で Windows のジョブハンドルが閉じられない問題が修正されました。[Agent]（ZBX-27900）
• ディスカバリされたホストのソートが修正されました。[Frontend]（ZBX-27594）
• Web 監視におけるシナリオレベルの動的変数のための HTTP レスポンスデータのバリデーションが修正されました。[Server]（ZBX-27770）
• 並行 API リクエストでユーザーまたはホストのグループを編集する際に繰り返し発生するシステムエラーが軽減されました。[API] [Server]（ZBX-27561）
• 重複したグループセットエントリを含むホスト、テンプレート、またはユーザーグループを更新する際のコードエラーが修正されました。[API]（ZBX-26766）
• グラフプロトタイプのポップアップにおいて、ラベルクリック時のチェックボックスのトグル動作が追加されました。[Frontend]（ZBX-27355）
• タグベースのサービス権限チェックが正しくない問題が修正されました。[API]（ZBX-27382）
• ネットワークディスカバリ中にホストが複数の IP アドレスで見つかった場合の、ホストとサービスの無効なステータスが修正されました。[Proxy] [Server]（ZBX-27200）
• ダウンロードされたウィジェット画像の下部で凡例テキストが見切れる（クリッピングされる）問題が修正されました。[Frontend]（ZBX-27144）
• 最新データビューで自動更新が継続して実行されるように修正されました。[Frontend]（ZBX-27732）
• フロントエンドのモーダルウィンドウにおける長いエラータイトルの表示が修正されました。[Frontend]（ZBX-26048）
• 支援技術用の Datepicker における月と年の重複したアナウンスが修正されました。[Frontend]（ZBX-26788）
• ハイコントラストテーマにおける深刻度アイコンのコントラストの問題が修正されました。[Frontend]（ZBX-25461）
• 大量のマッピングを伴うテンプレートの複製が修正されました。[Frontend]（ZBX-24054）
• 時計ウィジェットの「サーバー時間（Server time）」がブラウザのローカル時間と同じ時間を表示する問題が修正されました。[Frontend]（ZBX-27698）
• ダークテーマにおけるアイテム値ウィジェットの誤ったラベルカラーコントラストが修正されました。[Frontend]（ZBX-27103）
• Azure SQL Managed Instance by HTTP テンプレートのダッシュボードウィジェットにおける小数が修正されました。[Templates]（ZBX-27777）
• モジュールの歪みを排除するため、ピクセルの整数アライメントを使用して QR コードの生成が修正されました。[Frontend]（ZBX-27809）
• コンテナのリサイズ時に Geomap ウィジェットのマップがリサイズされない問題が修正されました。[Frontend]（ZBX-27510）

機能追加・改良

• MariaDB の最大サポートバージョンが 12.3 に更新されました。[API] [Proxy] [Server]（ZBXNEXT-10478）
• VMware テンプレートのアラームディスカバリが更新されました。[Templates]（ZBXNEXT-10211）
• ネイティブの vmware.*.alarms.get アイテムキーに実際のホスト名が追加されました。[Proxy] [Server]（ZBXNEXT-10611）
• TimescaleDB の最大サポートバージョンが 2.27 に更新されました。[API] [Server]（ZBXNEXT-10618）
• MySQL の最大サポートバージョンが 9.7 に更新されました。[API] [Proxy] [Server]（ZBXNEXT-10592）

詳細は以下をご覧ください。

https://www.zabbix.com/jp/rn/rn7.4.12

不具合修正

• vCenter へのネットワーク接続の問題によって引き起こされる可能性のある VMware コレクターのクラッシュが修正されました。[Proxy] [Server]（ZBX-27975）
• RabbitMQ テンプレートにおける重複したディスカバリキーと JavaScript の保存前処理が修正されました。[Templates]（ZBX-21745）
• ホストウィザードで検索フィールドをクリアした後にテンプレートが誤って表示される問題が修正されました。[Frontend]（ZBX-26583）
• ディスカバリルール、ディスカバリプロトタイプ、ホストプロトタイプ、Web シナリオ、およびマップのリダイレクト機能が修正されました。[Frontend]（ZBX-26953）
• ターゲットホストがプロキシグループによって監視されている場合に、トリガーアクション操作でのリモートコマンドの実行が失敗する問題が修正されました。[Server]（ZBX-27665）
• ホストの Web 監視リストにおける一括アクションの権限チェックが修正されました。[Frontend]（ZBX-27689）
• 永続バッファの書き込みにリトライ処理が追加されました。[Agent]（ZBX-27922）
• 一部の Web サイトで証明書にアクセスできない問題が修正されました。[Agent]（ZBX-26916）
• Zabbix web service のビルドスクリプトが修正されました。[Agent]（ZBX-27724）
• Zabbix agent 2 における誤解を招くコメントが修正されました。[Agent]（ZBX-18840）
• system.run の失敗と競合状態が解決されました。[Agent]（ZBX-27024）
• GCP の DB インスタンス取得スクリプトが修正されました。[Templates]（ZBX-25578）
• MSSQL by Zabbix agent 2 テンプレートにおける PLE トリガーの命名と説明が修正されました。[Templates]（ZBX-27139）
• 値を破棄する前の冗長な保存前処理が修正されました。[Templates]（ZBX-26704）
• DBL_MAX 入力を扱う際に inf 値が生成されるのを防ぐため、平均トレンドの計算が修正されました。また、閾値に到達できずヒストリが DBL_MAX に近づいた場合に DBL_MAX を返すように timeleft() 関数が更新されました。[Server]（ZBX-27453）

機能追加・改良

• TimescaleDB の最大サポートバージョンが 2.28 に更新されました。[API] [Server]（ZBXNEXT-10669）
• Veeam Backup and Replication および Veeam Backup Enterprise Manager by HTTP テンプレートが更新されました。[Templates]（ZBXNEXT-10558）

詳細は以下をご覧ください。

https://www.zabbix.com/jp/rn/rn7.0.28

不具合修正

• Zabbix agent 2 で Windows のジョブハンドルが閉じられない問題が修正されました。[Agent]（ZBX-27900）
• 大規模なローレベルディスカバリ（LLD）を伴う LLD ワーカープロセスにおけるメモリ使用量が改善されました。[Server]（ZBX-22504）

機能追加・改良

• MariaDB の最大サポートバージョンが 12.3 に更新されました。[API] [Proxy] [Server]（ZBXNEXT-10478）
• MySQL の最大サポートバージョンが 9.7 に更新されました。[API] [Proxy] [Server]（ZBXNEXT-10592）
• TimescaleDB の最大サポートバージョンが 2.27 に更新されました。[API] [Server]（ZBXNEXT-10618）

詳細は以下をご覧ください。

https://www.zabbix.com/jp/rn/rn6.0.47

不具合修正

• 変更ログがフラッシュされない問題が修正されました。[Proxy] [Server]（ZBX-27832）
• 大規模なローレベルディスカバリ（LLD）を伴う LLD ワーカープロセスにおけるメモリ使用量が改善されました。[Server]（ZBX-22504）
• LLD ルールのオーバーライド操作における「監視間隔」「ヒストリ」「トレンド」での LLD マクロのサポートが復元されました。[API]（ZBX-27780）
• 取得不可のアイテムに対して no_data トリガーが不明（unknown）ステータスにちらつく問題が修正されました。[Server]（ZBX-27736）
• ウィジェットのオーバーレイダイアログを開いた際に、タグバッジ間の隙間がなくなる問題が修正されました。[Frontend]（ZBX-27304）
• ウィジェットの追加/編集ポップアップをドラッグした後、メインメニューの下に表示される問題が修正されました。[Frontend]（ZBX-27443）
• 最大の高さを持つグラフに対して、グラフの代わりにエラーが表示される問題が修正されました。[Frontend]（ZBX-27708）
• トップアイテムウィジェットで、「そのまま（As is）」の数値に対して閾値の色が表示されない問題が修正されました。[Frontend]（ZBX-25774）
• ディスカバリルールリスト内のネストされたタイプによるフィルタリングが修正されました。[Frontend]（ZBX-27655）
• ソート後の z-select の再レンダリングが修正されました。[Frontend]（ZBX-25509）
• すべてのステータスが未設定の場合に、アクションログウィジェットに結果が表示されない問題が修正されました。[Frontend]（ZBX-26678）
• マップナビゲーションツリーウィジェットからマップを削除した後に、ウィジェットが無限ロードになる問題が修正されました。[Frontend]（ZBX-27210）
• 既存の値のインラインバリデーション中の誤った一致を防ぐため、in_array() に厳密（strict）モードが追加されました。[Frontend]（ZBX-27740）
• Linux by Zabbix agent のアクティブおよびパッシブテンプレートにおいて、依存アイテムのキーが vm.memory.utilization から vm.memory.util に更新されました。[Templates]（ZBX-27694）
• 設定キャッシュ同期におけるデッドロックの可能性が修正されました。[Proxy]（ZBX-27399）
• 負の閾値のソートが修正されました。[API] [Frontend]（ZBX-26657）
• 設定シンカーが大量のメモリを予約しないように改善されました。[Proxy] [Server]（ZBX-27675）
• Mattermost Webhook の「fallback」フィールド名のタイプミスが修正されました。[Templates]（ZBX-27475）
• ポルトガル語のポップアップにおけるテキストの重なりが修正されました。[Frontend]（ZBX-26742）
• バリデーションエラー後にトリガーの深刻度チェックボックスがチェック済みの状態に更新される問題が修正されました。[Frontend]（ZBX-27632）
• 文字列型に対する保存前処理ステップ「変更なしで破棄」が修正されました。[Proxy] [Server]（ZBX-27022）
• 設定が不完全な状態で Gmail および Office 365 メディアタイプが一括で有効化されるのを防ぐチェックが削除されました。[Frontend]（ZBX-27688）
• 「管理」->「一般設定」->「その他」の誤ったドキュメントリンクが修正されました。[Frontend]（ZBX-27652）
• アクセス不可能なダッシュボード要素を含むテンプレートをエクスポートする際の「ページが見つかりません」という問題が修正されました。[Frontend]（ZBX-27517）
• Esc キーを押した際のエラーが修正されました。[Frontend]（ZBX-27328）
• 通知のフローティングポップアップの「閉じる」ボタンを繰り返しクリックするとエラーが発生する問題が修正されました。[Frontend]（ZBX-27121）
• アイテムおよびアイテムのプロトタイプフォームにおける「インターフェースがありません（interface missing）」エラーの表示が修正されました。[Frontend]（ZBX-27587）

詳細は以下をご覧ください。

https://www.zabbix.com/jp/rn/rn7.4.11