Apache HertzBeat を採用する前に確認すべきこと
An AI-powered next-generation open source real-time observability system.
ひと目でわかる
- これは何？
- エージェントレスでメトリクスとログを集約し、アラート配信まで一つのプラットフォームにまとめる Java 製の監視システム。YML テンプレートによる監視対象の追加と、コレクタの水平分割という設計を軸に、向く用途と向かない用途を整理する。
- 誰に向いている？
- 監視対象が多く、そのたびにエクスポータやエージェントを配る運用に疲れているチームには向く。逆に、すでに Prometheus と Alertmanager でルール資産を蓄積していて、メトリクス以外の要件がない場合は、HertzBeat を挟む理由は薄い。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に Java です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
監視対象を増やすたびにエクスポータを配る運用への回答
HertzBeat が解こうとしているのは、監視対象ごとに専用のエクスポータやエージェントを配備し、設定ファイルを書き、再起動するという反復作業である。README は「No Agent required」を掲げ、収集・分析・アラート・通知を一つのプラットフォームに統合すると説明している。想定読者は、アプリケーションサービス、プログラム、データベース、キャッシュ、OS、ビッグデータ、ミドルウェア、Web サーバ、クラウドネイティブ、ネットワークといった異種の対象を、同じ運用フローで見たい人である。
この問題設定自体は目新しくない。特徴は解決の方向にある。対象ごとの専用実装を増やすのではなく、Http, Jmx, Ssh, Snmp, Jdbc, Prometheus といった既存プロトコルを設定可能な部品として扱い、その組み合わせを YML テンプレートとして記述する。README の表現を借りれば「collect any metrics by simply configuring the template YML file online」であり、K8s や Docker への対応もオンライン設定で済ませるという主張になっている。プロトコルを固定の語彙として持つ代わりに、その上に載るメトリクス定義を外に出した設計だと言える。
収集はプロトコル、定義は YML という分離
アーキテクチャ図が README に置かれているが、本文中で説明されている範囲では、役割は manager と collector に分かれる。Docker の例では manager が 1157 と 1158 のポートを使い、collector は環境変数 MANAGER_HOST と MANAGER_PORT で manager を指す。collector 側の IDENTITY はコレクタの一意名、MODE は public か private を選び、public は通常のクラスタ、private はクラウドエッジ型の構成に対応すると README は説明している。つまり収集処理は manager に閉じておらず、collector を追加して水平に広げる前提の構成である。
データの流れとして README が明示しているのは、ログが OTLP プロトコル経由で複数のログソースから報告されるという点、アラートが内部のものと外部のソースを統合して処理されるという点である。メトリクスについては Prometheus 互換であること、プロトコル群を設定可能にすることが書かれている。ただし、manager と collector の間でどのような形式のメッセージがやり取りされるか、ストレージに何を使うかといった内部の詳細は、与えられた資料からは確認できない。ここは推測で埋めず、実際に導入を検討する際は公式ドキュメントの該当ページを読む必要がある。
起動は1コマンド、クラスタ化は環境変数3つ
単体で動かす場合、README が示すのは次の1行である。
docker run -d -p 1157:1157 -p 1158:1158 --name hertzbeat apache/hertzbeat
起動後は http://localhost:1157 にアクセスし、初期アカウント admin/hertzbeat で入る。この認証情報がデフォルトである以上、外部に公開する構成では最初に変更する前提で考えるべきで、README はそこに触れていない。
collector を追加する場合は次の形になる。
docker run -d -e IDENTITY=custom-collector-name -e MANAGER_HOST=127.0.0.1 -e MANAGER_PORT=1158 --name hertzbeat-collector apache/hertzbeat-collector
IDENTITY はコレクタの一意名、MANAGER_HOST は manager の IP、MANAGER_PORT は manager のポートで既定は 1158。MODE は public または private を指定し、public はパブリッククラスタ、private はプライベートなクラウドエッジ構成に対応する。パッケージからの導入も用意されており、apache-hertzbeat-xx-bin.tar.gz を展開し、hertzbeat/config/application.yml を必要に応じて編集したうえで ./bin/startup.sh を実行する流れが README に書かれている。設定ファイルのパスが hertzbeat/config/application.yml である点は、コンテナではなくパッケージ運用を選ぶ場合に効いてくる。
YML テンプレートを書くコストは誰が払うのか
「設定するだけで新しい監視対象に対応できる」という説明は、裏返すと、対象のメトリクス定義を誰かが書かなければならないという意味である。既存の監視ツールが対象ごとのエクスポータを同梱しているのに対し、HertzBeat はプロトコルとメトリクス定義を分離し、後者を利用者側の YML に委ねている。これは拡張性と引き換えに、初期の記述コストを利用者に移す設計だ。
README は K8s や Docker への適応を「simply by configuring online」と表現するが、この simply が指すのは配備の手軽さであって、メトリクスをどう取るかの設計が不要になるわけではない。Jmx や Jdbc のように取得項目が対象の実装に強く依存するプロトコルでは、テンプレートの質がそのまま監視の質になる。コミュニティが用意したテンプレートが対象に存在するかどうかを先に確認し、無ければ自分で書く前提で工数を見積もるのが現実的である。
Prometheus と Zabbix のどちらを置き換えるのか
比較対象として分かりやすいのは Prometheus である。Prometheus はメトリクスのスクレイプと保存に責務を絞り、アラートは Alertmanager に、可視化は Grafana に渡す。HertzBeat は逆に、収集・分析・アラート・通知を一つの製品にまとめ、通知先として Email, Discord, Slack, Telegram, DingTalk, WeChat, FeiShu, SMS, Webhook, ServerChan を README に列挙している。Prometheus 互換をうたっているため、既存の Prometheus 形式のメトリクスを捨てずに移行できる余地はある。
Zabbix との違いはより明確である。Zabbix はエージェントを前提とした構成が中心で、監視項目の定義はテンプレートとして配布される。HertzBeat はエージェントレスを前面に出し、プロトコルを跨いだ収集を一つの仕組みで扱おうとする。どちらが優れているかではなく、既に Zabbix のテンプレートとトリガーを運用している組織が乗り換える場合、その資産はそのままでは移らない。移行の判断は、テンプレートを書き直す工数と、エージェント配布をやめられる運用上の利得を天秤にかける作業になる。
アラート統合と通知はプラットフォーム側の責務になる
HertzBeat は外部のアラートソースを取り込み、内部のアラートと統合して処理すると README は説明している。しきい値ルールはリアルタイムと定期の両方が選べ、グループ化による収束、サイレンス、抑制といった制御が用意されているとされる。通知は前述の多数のチャネルに配信される。
この構成の利点は、通知経路を一箇所に集約できることである。欠点は、アラートの評価ロジックがツールの実装に依存する点だ。Prometheus の PromQL のように表現力の高いクエリ言語でルールを書き、それをコードとしてレビューしてきたチームにとって、GUI 上のしきい値設定に移ることは、ルールのバージョン管理とレビューの方法を変えることを意味する。抑制やグループ化の挙動が期待通りかは、実際にアラートを発火させて確かめる以外にない。ここは資料からは判断できない部分であり、検証項目として残る。
AI と MCP は何を変えるのか、まだ何を変えないのか
README は HertzBeat AI と組み込みの MCP Server 機能に触れ、AI による対話的な機能を備えると述べている。ただし、どのような操作が AI 経由で可能になるのか、モデルをどう接続するのか、といった具体は与えられた資料には書かれていない。リポジトリのトピックに llm が含まれ、最終 push が 2026-09-09 であることから開発が続いていることは分かるが、AI 機能の成熟度をこの情報から評価することはできない。
監視ツールにおける AI 支援は、障害時の調査を短縮する方向に効く可能性がある一方、誤った要約や推測がインシデント対応の判断を歪める危険もある。採用検討の段階では、AI 機能を導入の主理由に置かず、通常のメトリクス収集とアラートが要件を満たすかを先に評価し、AI は追加の利点として扱うのが妥当である。
Apache-2.0 とメンテナンス体制
ライセンスは Apache-2.0 で、Apache Software Foundation のプロジェクトである。派生物の配布や商用利用に関する条件はこのライセンスに従うが、具体的な解釈は利用者の法務判断に委ねられる。ここで注意すべきは、Apache プロジェクトであることが運用サポートを意味しないという点だ。README は dev-subscribe@hertzbeat.apache.org へのメーリングリスト購読と Discord を案内しており、有償サポートの記載はない。
バージョンは 1.8.0 が 2026-01-31、v1.7.3 が 2025-08-31、v1.7.2 が 2025-06-25 に公開されており、1.x 系が継続している。アップグレードのコストは、YML テンプレートの互換性と、collector と manager のバージョンを揃える必要があるかどうかに依存する。この点は資料からは確認できないため、更新前にリリースノートと移行手順を確認する必要がある。コンテナで動かす場合、apache/hertzbeat と apache/hertzbeat-collector のタグを固定し、manager 側を先に上げるのか collector 側を先に上げるのかを決めておかないと、バージョン不一致の状態が生じうる。
編集部の結論
監視対象が多く、そのたびにエクスポータやエージェントを配る運用に疲れているチームには向く。逆に、すでに Prometheus と Alertmanager でルール資産を蓄積していて、メトリクス以外の要件がない場合は、HertzBeat を挟む理由は薄い。導入前に確認すべきは、監視したい対象のプロトコルが Http, Jmx, Ssh, Snmp, Jdbc, Prometheus のどれで拾えるか、そして自分で YML テンプレートを書く前提を受け入れられるかである。README は「simply by configuring the template YML file online」と述べているが、この一文が実務でどこまで成立するかは、対象のメトリクス定義を自分で書き下ろす作業量として現れる。まず docker run -d -p 1157:1157 -p 1158:1158 --name hertzbeat apache/hertzbeat で単体を起動し、自分の環境の一つの対象を YML で記述してメトリクスが取れるかを確かめる。ここが通らなければ、コレクタを増やしても解決しない。
コミュニティノート