HertzBeatで100以上のサービスをエージェントレス監視：高速・軽量・シンプル – ITFROMZERO

Table of Contents

課題：エージェントのインストールという悪夢

キャリアの浅い頃、上司から30台の仮想マシンとあちこちに分散したデータベースの監視を任され、苦労したことがあります。最初に思いついたのはPrometheusやZabbixでした。しかし、現実はそう甘くありません。MySQLを監視するには、そのサーバーにSSHでログインしてMySQL Exporterをインストールしなければなりませんでした。RAMやCPUの数値を見るには、さらにNode Exporterも追加で入れる必要がありました。

結局、インストールコマンドのコピペとファイアウォールのポート開放だけで5日間も費やしてしまいました。さらに、サーバーのOSが更新されるたびに、これらのエージェントがエラーで動かなくなることも。その時、私はエージェントレス（Agentless）システムの価値を痛感しました。ターゲットサーバーに侵入せず、何もインストールせず、サーバーを汚さない監視方法です。

なぜ従来のツールは時に「オーバースペック」なのか？

ZabbixやPrometheusがDevOps界の金字塔であることは間違いありません。しかし、それらには大きな2つの壁があります：

設定が複雑すぎる： 長大なYAMLファイルと格闘し、数十もの Exporterのポートを管理し、接続ごとにファイアウォールを設定するのは非常に骨が折れます。
メンテナンスの負担： あらゆる環境（Linux、Windows、クラウド）で数百ものエージェントを維持することは、システムリソースと技術者の時間を大幅に消費します。
Webサイト（HTTP）、データベース（JDBC）、サーバー（SSH）を、内部に深く干渉することなく一元管理できる直感的なダッシュボードが必要なら、よりスマートなアプローチが必要です。

エージェント vs エージェントレス：どちらを選ぶべきか？

現在、主に2つのアプローチがあります：

エージェント型： 対象サーバーにソフトウェアをインストールします。メリットは非常に詳細なデータが得られることですが、インストールと定期的なメンテナンスが大きな負担となります。
エージェントレス型： 監視システムが外部からSSH、SNMP、JDBCなどの標準プロトコルを使用してサーバーの状態を「伺い」に行きます。

多くのツールを試した結果、私はHertzBeatに辿り着きました。これは非常に軽量なオープンソースプロジェクトで、対象に複雑な設定を強いることなく多層監視をサポートしています。

HertzBeatの導入：オールインワン監視

HertzBeatはWebサイト、データベース、OSからミドルウェアまで幅広くサポートしています。最大の魅力は、ユーザーフレンドリーなインターフェースです。特に、Dockerを使えばわずか5分でシステムを稼働させることができます。

ステップ1：環境の準備

Dockerがインストールされた Linuxサーバー（Ubuntu/CentOS）が必要です。まだ準備ができていない場合は、以下のコマンドを実行してください：

sudo apt update && sudo apt install docker-compose -y

ステップ2：Docker Composeによるインストール

Docker Composeを使うとコンテナ管理が非常にスッキリします。まず、作業ディレクトリを作成します：

mkdir hertzbeat && cd hertzbeat
nano docker-compose.yml

以下の設定内容をファイルに貼り付けます：

version: '3.8'
services:
  hertzbeat:
    image: tancloud/hertzbeat:latest
    container_name: hertzbeat
    restart: always
    ports:
      - "1157:1157"
    volumes:
      - ./data:/opt/hertzbeat/data
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

コマンド docker-compose up -d でシステムを起動します。その後、http://あなたのIP:1157 にアクセスし、デフォルトのアカウント **admin/hertzbeat** でログインしてください。

ステップ3：Webサイトの監視（アップタイムとレイテンシ）

Monitor -> Website メニューから Add Website を選択します。URL（例：https://itfromzero.com）を入力し、Interval（実行間隔）を60秒に設定します。数秒後には、レイテンシのグラフとWebサイトの死活状態が明確に表示されます。

ステップ4：ExporterなしでMySQLを監視

複雑な設定の代わりに、HertzBeatはJDBCを使用して直接接続します。基本的なアクセス権を持つMySQLユーザーを作成するだけで準備完了です：

-- HertzBeat用のユーザーを作成
CREATE USER 'hertzbeat'@'%' IDENTIFIED BY 'あなたのパスワード';
-- 権限を付与
GRANT SELECT ON *.* TO 'hertzbeat'@'%';
-- 設定を反映
FLUSH PRIVILEGES;

HertzBeatの管理画面で、作成したIPとユーザー情報を入力します。クエリレート、キャッシュヒット率、接続数などのパラメータが自動的にダッシュボードへ流れ込みます。

ステップ5：SSH経由でLinuxサーバーを管理

CPUやRAMを監視するには、SSH情報を提供するだけです。HertzBeatが自動的にログインし、top や free -m などのコマンドを実行してデータを取得した後、ログアウトします。この方法は非常に安全で、サーバーに余計なソフトウェアの「痕跡」を残しません。

実践的な経験：「アラート疲れ」の罠を避ける

アラート疲れ（Alert fatigue）は、監視を始めたばかりの時に最も陥りやすいミスです。以前、私はCPU使用率が80%を超えたらすぐにTelegramへ通知が飛ぶように設定していました。その結果、夜中の2時にサーバーの定期バックアップが走り、CPUが数分間跳ね上がるたびにスマホが激しく震えることになりました。

私の解決策：

Trigger Times（トリガー回数）の活用： 3回連続のチェック（約3〜5分間）で閾値を超えた場合のみアラートを出すように設定。
優先順位の階層化： サービスが完全にダウンした場合はTelegram/SMSで即時通知。Webサイトが少し重い程度であれば、翌朝対応できるようにメール送信に留める。

終わりに

HertzBeatは、迅速かつ軽量に導入したいけれど機能も妥協したくないという場合に最適な選択肢です。Uptime Kumaの手軽さとZabbixの重厚さの間にある空白を埋めてくれます. 中規模のシステムにおいて、HertzBeatは運用コストをかけずにインフラを管理できる強力な「武器」となるでしょう。