こんにちは。オブザーバビリティの深淵を覗き込み、システムと対話するエンジニアの皆さん。
今日は、Prometheusという強力な武器を「ネットワークの壁」の向こう側にまで届ける、少し高度で、しかし現場では避けて通れない「多段プロキシ・セキュア監視」の極意を伝授します。
「監視したいサーバーが閉域網にある」「セキュリティ要件で直接アクセスできない」。そんな絶望的な状況でも、Prometheusの設計思想を理解していれば、スマートに解決できるのです。
—
1. なぜ「閉域網の監視」は難しいのか？
Prometheusは「プル型（Pull-based）」の監視ツールです。つまり、監視対象（Exporter）に対して、Prometheusサーバーが自ら「元気ですか？」と聞きに行くスタイルです。
しかし、Prometheusが対象に直接アクセスできないネットワーク構成（VPCの境界、DMZ、多段踏み台など）では、この「プル」が成立しません。ここで多くの初心者が「プッシュ型（Pushgateway）」に逃げがちですが、それは運用の複雑さを増やすだけ。
今日は、Prometheusの思想を崩さず、ネットワークを貫通させるプロフェッショナルな手法を紹介します。
—
2. ネットワークの壁を突破する：SSHトンネルとリバースプロキシ
最も堅実なのは、SSHポートフォワードまたはリバースプロキシを用いた経路確保です。
手法A：SSHトンネル（手軽で強力）
監視対象のネットワーク内に踏み台（Bastion）がある場合、踏み台を介したトンネルを掘るのが最も簡単です。
踏み台を経由して、閉域網内のExporter(9100)を、ローカルの9101へ転送する
-L [ローカルポート]:[監視対象IP]:[対象ポート]
ssh -f -N -L 9101:10.0.0.5:9100 user@bastion-host
これにより、Prometheus側からは `localhost:9101` を叩くだけで、閉域網のサーバーが見えるようになります。
手法B：Nginxリバースプロキシ（本番運用の定石）
踏み台でNginxを動かし、閉域網内のExporterを外部公開（認証付き）する構成です。
踏み台サーバー上のNginx設定例
server {
listen 443 ssl;
location /metrics {
# ここでBasic認証をかけるのがプロの嗜み
auth_basic “Monitoring Access”;
auth_basic_user_file /etc/nginx/.htpasswd;
# 閉域網内のExporterへ転送
proxy_pass http://10.0.0.5:9100/metrics;
}
}
ポイント: `proxy_pass` を使うことで、Prometheusは「HTTPS経由でセキュアに」かつ「正規のプロトコルで」メトリクスを収集できます。
—
3. 【実践】HelloWorld：セキュアなスクレイピング設定
では、実際にPrometheusにこの経路を認識させましょう。`prometheus.yml` はこう書きます。
scrape_configs:
- job_name: ‘closed-network-server’
scheme: https # リバースプロキシ越しなのでHTTPS推奨
basic_auth: # 認証情報を忘れずに
username: ‘admin’
password: ‘your-password’
static_configs:
- targets: [‘bastion-host.example.com’] # プロキシサーバーを指定
この設定により、Prometheusは「壁の向こう」にあるメトリクスを、あたかも隣にあるかのように収集し始めます。
—
4. Alertmanagerのフェイルオーバー：監視の「死」を防ぐ
ネットワークが分断されたとき、Alertmanagerが動かないと障害に気づけません。ここで重要なのは「監視の二重化」です。
1. Prometheusの冗長化: 2つの独立したPrometheusサーバーを立て、同じターゲットをスクレイピングさせます。
2. Alertmanagerのクラスタリング: 両方のPrometheusが同じAlertmanagerクラスタへ通知を送るようにします。
PrometheusのAlerting設定
alerting:
alertmanagers:
- static_configs:
- targets: [‘alertmanager-1:9093’, ‘alertmanager-2:9093’]
この構成なら、片方のネットワーク経路が遮断されても、もう一方が確実にアラートを届けます。これが、現場で震えるほど役立つ「落ちない監視」の鉄則です。
—
最後に：先輩からのアドバイス
「ツールを入れる」こと自体はゴールではありません。「ネットワークの境界線においても、メトリクスの流れをいかにして途絶えさせないか」を考えること。それがオブザーバビリティ・エンジニアとしての第一歩です。
最初はSSHトンネルのコマンド一つで苦労するかもしれません。でも大丈夫。エラーが出たら、まずは `curl` でその経路が本当に繋がっているかを確認してください。シンプルで論理的なトラブルシューティングこそが、あなたの技術を磨き上げます。
これをマスターすれば、どんな複雑なエンタープライズ環境でも「監視できません」と泣きつく必要はなくなりますよ。さあ、次はあなたの番です。システムの深淵を覗きに行きましょう。