• HOME
  • blackbox_exporterでブラックボックス監視を設定する方法｜HTTP・TCP・ICMPの死活監視とSSL証明書の期限チェック

2026年10月4日

  • シェア
  • ツイート

    • 2026年10月4日

    blackbox_exporterでブラックボックス監視を設定する方法｜HTTP・TCP・ICMPの死活監視とSSL証明書の期限チェック

    blackbox_exporter を使うと、Prometheus から Web サイトやサーバーに「外から」アクセスして、応答するか・ステータスコードは正常か・SSL 証明書の期限は十分か、を定期的に確かめられます。この記事では、インストールと systemd での常駐、モジュール（検査の種類）の書き方、Prometheus 側の独特な設定（relabel）の意味、手動での動作確認、そしてサイト停止と証明書期限切れを知らせるアラートルールまでを説明します。

    ブラックボックス監視とは

    node_exporter のように監視対象の中に入って CPU やメモリを測る方法を「ホワイトボックス監視」と呼ぶのに対し、利用者と同じ立場で外からアクセスし、結果だけを見る方法を「ブラックボックス監視」と呼びます。

    サーバーの CPU やメモリが正常でも、Nginx の設定ミス、DNS の誤り、証明書の期限切れ、WordPress のデータベース接続エラーなどで、サイトが利用者から見えなくなることがあります。こうした「利用者にとっての障害」を捉えられるのがブラックボックス監視の役割です。両方を組み合わせることで、「サイトが落ちた」と「なぜ落ちたか」の両方が分かるようになります。

    blackbox_exporter は、Prometheus から「この URL をこの方法で調べて」という依頼を受けて検査を実行し、結果をメトリクスとして返します。検査の方法（HTTP、TCP、ICMP、DNS など）は、設定ファイルで「モジュール」として定義します。

    どこに置くか

    検査する側と検査される側が同じサーバーだと、そのサーバーが停止したときに検査そのものが動きません。また、同じネットワーク内からの検査では、回線障害や DNS の問題に気づけないことがあります。blackbox_exporter は、監視対象の Web サーバーとは別のサーバー（Prometheus と同じサーバーなど）に置くのが基本です。

    インストールして常駐させる

    GitHub の prometheus/blackbox_exporter のリリースページから公式のバイナリを取得します。バージョン番号は例なので、リリースページで確認した版に置き換えてください。バージョン番号は 0 系のまま更新が続いています（2026年10月現在）。

    VERSION="0.25.0"   # 例。最新の安定版に置き換える
ARCH="linux-amd64"
cd /tmp
curl -LO "https://github.com/prometheus/blackbox_exporter/releases/download/v${VERSION}/blackbox_exporter-${VERSION}.${ARCH}.tar.gz"
curl -LO "https://github.com/prometheus/blackbox_exporter/releases/download/v${VERSION}/sha256sums.txt"
grep "blackbox_exporter-${VERSION}.${ARCH}.tar.gz" sha256sums.txt | sha256sum -c -

tar xzf "blackbox_exporter-${VERSION}.${ARCH}.tar.gz"
sudo install -m 0755 "blackbox_exporter-${VERSION}.${ARCH}/blackbox_exporter" /usr/local/bin/
sudo useradd --system --no-create-home --shell /usr/sbin/nologin blackbox
sudo mkdir -p /etc/blackbox_exporter
    # /etc/systemd/system/blackbox_exporter.service
[Unit]
Description=Prometheus blackbox_exporter
Wants=network-online.target
After=network-online.target

[Service]
User=blackbox
Group=blackbox
AmbientCapabilities=CAP_NET_RAW
ExecStart=/usr/local/bin/blackbox_exporter \
  --config.file=/etc/blackbox_exporter/blackbox.yml \
  --web.listen-address=127.0.0.1:9115
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

    AmbientCapabilities=CAP_NET_RAW は、ICMP（ping）の検査に必要な権限です。root で動かさずに ping を送れるようにするための指定で、ICMP を使わないなら削ってかまいません。待ち受けを 127.0.0.1 にしているのは、同じサーバーの Prometheus からだけ使う想定だからです。blackbox_exporter を外部から使える状態にすると、第三者に任意の宛先への検査を実行させる踏み台になりかねないため、別サーバーの Prometheus から使う場合もファイアウォールで接続元を限定してください。

    モジュールを定義する

    設定ファイルには、検査の種類ごとにモジュールを書きます。WordPress サイトの監視でよく使うものを例にします。

    # /etc/blackbox_exporter/blackbox.yml
modules:
  http_2xx:
    prober: http
    timeout: 10s
    http:
      preferred_ip_protocol: ip4
      fail_if_not_ssl: true

  http_wp_content:
    prober: http
    timeout: 10s
    http:
      preferred_ip_protocol: ip4
      fail_if_body_not_matches_regexp:
        - "</html>"

  tcp_connect:
    prober: tcp
    timeout: 5s

  icmp:
    prober: icmp
    timeout: 5s
    icmp:
      preferred_ip_protocol: ip4

    http_2xx は、ステータスコードが 2xx なら成功とみなす基本の検査です。valid_status_codes を指定しなければ 2xx が成功になり、リダイレクトは既定でたどられます。fail_if_not_ssl: true を付けると、HTTPS でなかった場合（HTTPS から HTTP へ誤ってリダイレクトされた場合など）に失敗として扱います。preferred_ip_protocol を指定しないと IPv6 が優先されるため、IPv6 の経路がない環境では ip4 にしておかないと失敗し続けることがあります。

    http_wp_content は、本文に特定の文字列が含まれるかも確認する検査です。WordPress では、PHP のエラーで途中までしか出力されない、真っ白な画面になる、といった障害でもステータスコードが 200 のままになることがあります。ページの末尾にある文字列やテーマ固有の要素を条件にすると、こうした「応答はあるが中身が壊れている」状態を検知できます。正規表現が厳しすぎると、デザインの変更で誤検知になるので、変わりにくい要素を選びます。

    tcp_connect はポートに接続できるかだけを調べます。MySQL や SSH のように HTTP 以外のサービスの死活確認に使います。

    icmp は ping による到達確認です。クラウドの設定によっては ICMP を受け付けないサーバーもあるので、その場合は tcp_connect で代わりにします。

    設定を書いたら、文法を確認してから起動します。

    blackbox_exporter --config.file=/etc/blackbox_exporter/blackbox.yml --config.check
sudo systemctl daemon-reload
sudo systemctl enable --now blackbox_exporter

    手動で検査を実行してみる

    Prometheus に登録する前に、/probe に直接アクセスして検査結果を確認します。debug=true を付けると、名前解決・接続・TLS・応答の各段階のログが表示され、失敗の理由が分かります。

    curl -s "http://127.0.0.1:9115/probe?target=https://example.com/&module=http_2xx" | grep -E '^probe_(success|http_status_code|duration_seconds|ssl_earliest_cert_expiry)'
curl -s "http://127.0.0.1:9115/probe?target=https://example.com/&module=http_2xx&debug=true"

    probe_success が 1 なら成功、0 なら失敗です。失敗したときは debug の出力から、名前解決で止まっている（DNS）、接続で止まっている（ファイアウォールや経路）、TLS で止まっている（証明書）、ステータスコードが想定外（サーバー側のエラーやリダイレクト）、のどの段階かを確認します。

    Prometheus から使う：relabel の意味

    blackbox_exporter の設定で多くの人がつまずくのが、Prometheus 側の relabel_configs です。

    # prometheus.yml の scrape_configs に追加
scrape_configs:
  - job_name: "blackbox_http"
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://example.com/
          - https://example.com/wp-login.php
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

    通常のジョブでは、targets に書いたアドレスへ Prometheus が直接アクセスします。blackbox_exporter では、アクセスする先は blackbox_exporter で、検査してほしい URL は ?target= というパラメーターで渡す必要があります。3つの relabel は、次のことをしています。

    1. targets に書いた URL を、target パラメーターに移す
    2. グラフやアラートで分かりやすいよう、その URL を instance ラベルにする
    3. 実際のアクセス先を blackbox_exporter（127.0.0.1:9115）に差し替える

    この3行の順番や名前を間違えると、blackbox_exporter 自体を検査していたり、すべてのターゲットの instance が同じになったりします。設定後は Prometheus で probe_success を検索し、URL ごとに値が分かれているかを確認してください。

    モジュールを変えたい場合は、params の module を変えたジョブを別に作ります。

    アラートルールを置く

    サイトの停止、証明書の期限、応答の遅さの3つを用意しておくと、主な異常を押さえられます。

    # /etc/prometheus/rules/blackbox.yml
groups:
  - name: blackbox
    rules:
      - alert: SiteDown
        expr: probe_success{job="blackbox_http"} == 0
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} が3分以上応答していません"

      - alert: SSLCertExpiringSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 14
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} の証明書の期限まで14日を切りました"

      - alert: SiteSlow
        expr: probe_duration_seconds{job="blackbox_http"} > 3
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} の応答に3秒以上かかっています"

    for を付けているのは、一度の通信の揺れで通知が飛ばないようにするためです。probe_ssl_earliest_cert_expiry は証明書チェーンの中で最も早く期限が来るものの日時なので、中間証明書の期限も含めて確認できます。Let's Encrypt は期限切れが近いことを知らせるメールの送信を 2025 年に終了したと案内しているため、自動更新が止まったときに気づく手段として、この監視は特に役立ちます。

    ルールを追加したら promtool check rules で確認し、Prometheus を再読み込みします。通知先は Alertmanager で設定します。

    まとめ

    • blackbox_exporter は、利用者と同じく外から HTTP・TCP・ICMP などで検査し、「見えているか」を測ります。
    • 監視対象とは別のサーバーに置き、待ち受けは限定して踏み台にならないようにします。
    • モジュールで検査の種類を定義し、WordPress では本文の文字列も確認すると、200 のまま壊れている状態も検知できます。
    • 手動の /probe?...&debug=true で、失敗した段階を確認してから Prometheus に登録します。
    • Prometheus 側は3行の relabel で、URL を target パラメーターに移し、アクセス先を blackbox_exporter に差し替えます。
    • 停止・証明書期限・応答の遅さのアラートを置いておくと、主な異常に気づけます。
    Views: 52

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲