【2026年】Prometheus + Alertmanager 設定ガイド｜監視アラート基盤構築

Prometheus + Alertmanager 設定ガイド｜監視アラート基盤構築

現代のインフラストラクチャにおいて、サーバー障害が発生した際の影響は甚大です。2026 年時点のクラウドネイティブ環境では、マイクロサービスアーキテクチャが主流となっており、単一のコンポーネントの故障が連鎖的にシステム全体をダウンさせるリスクが高まっています。このような複雑な環境で、インフラの状態を可視化し、障害を早期に検知するために不可欠なツールセットが Prometheus、Alertmanager、そして Grafana です。本ガイドでは、これらを組み合わせた監視アラート基盤の構築方法を、最新バージョン情報に基づき詳細に解説します。

読者は自作 PC 初心者から中級者向けの技術者層を想定していますが、サーバー運用の基礎知識を持つ方向けです。専門用語は初出時に簡潔な補足説明を加え、実務で役立つ具体的な設定値やパラメータを提供します。例えば、Prometheus のデータ保存期間（retention）や、アラート閾値の設定、Exporter の選定基準など、判断材料となる具体的な指針を網羅的に提示します。

本記事では、単なるコマンドの羅列ではなく、アーキテクチャの背後にある設計思想にまで踏み込みます。メトリクス収集のプロセス（Pull 型）、時系列データベース（TSDB）の仕組み、PromQL による高度なクエリ構築、そして Alertmanager を介した通知先の柔軟な制御までを包括的に扱います。これにより、読者は特定のツールの使い方だけでなく、監視基盤全体を設計・運用する能力を獲得できます。

Prometheus アーキテクチャの核心：Pull 型と TSDB の仕組み

Prometheus は 2016 年に CNCF（Cloud Native Computing Foundation）へ参加し、2018 年に graduated（卒業）プロジェクトとなりました。現在では Kubernetes やクラウド環境における標準的な監視システムとして確立されています。その最大の特徴は「Pull 型」メトリクス収集方式を採用している点です。これは、監視サーバー側からターゲットとなる対象サーバーへ定期的に接続し、データを取得する仕組みを指します。このアーキテクチャが選ばれる理由として、ファイアウォールの設定が容易であることや、スケールアウトに適していることが挙げられます。大規模クラスターでは、Prometheus の分散構成（Thanos や Cortex との連携）によって対応が可能ですが、ここでは基礎となる単一インスタンスの動作原理を解説します。

Pull 型のアプローチは、エージェントを各ターゲットに常駐させる必要がないため、管理コストが低減されます。代わりに、Exporter という軽量なバイナリやサイドカーコンテナをメトリクス取得対象に配置し、HTTP エンドポイント（通常は /metrics）を公開する形をとります。例えば、Linux サーバーの CPU やメモリ使用率を取得するには「Node Exporter」を使用し、Docker コンテナの場合は「cAdvisor」が標準的に利用されます。このように、目的に応じて適切な Exporter を組み合わせることで、システム全体のカバレッジを広げることができます。

データの保存においては、TSDB（Time Series Database）という独自のデータストレージを採用しています。これは時系列データを効率的に格納・圧縮するために設計されたデータベースであり、ディスクへの書き込みを抑えつつ、高速な読み出しを可能にします。バージョンアップを重ねるごとに TSDB のストレージ構造は改良され、高負荷時のパフォーマンスが向上してきました。メトリクスはラベル（Key-Value ペア）によって識別されるため、同一のメトリック名でも異なるサーバーや環境から収集されたデータを柔軟に区分けして検索できます。

• Pull 型アーキテクチャ：監視サーバーからターゲットへ接続する方式
• TSDB（Time Series Database）：時系列データ専用データベース
• Exporter：メトリクスを取得するための外部インターフェース
• ラベル（Labels）：メトリクスを識別・分類するためのキーバリューペア

インストール環境構築：Docker Compose を活用したセットアップ

監視基盤の構築において、効率的な方法の一つが Docker コンテナ化です。サーバーへの直接インストールよりもコンテナベースのデプロイが扱いやすく、再現性も高くなります。本セクションでは、Prometheus、Alertmanager、Grafana の 3 つを Docker Compose で構成し、少ないリソースで運用可能な環境を構築する方法を解説します。具体的には、Ubuntu 24.04 LTS または CentOS Stream 9 を OS ベースとし、新しめの Docker Engine を使用することを前提としています。

まず、各コンテナに必要なリソース割り当てを明確に定義する必要があります。Prometheus の TSDB はメトリクス数が増加するとディスク容量とメモリを圧迫します。本番環境では、最低でも 4GB 程度のメモリと十分な SSD ディスク領域を確保することを推奨します。初期段階や学習用であれば 2GB メモリで動作可能ですが、データ保持期間（retention）を短く設定する必要があります。Alertmanager は軽量なサービスであるため、512MB 程度のメモリでも稼働しますが、大量のアラートが集中した場合は CPU リソースの確保が必要です。

Docker Compose を使用することで、各サービスの依存関係を定義し、ワンコマンドで起動・停止を管理できます。設定ファイルには、ネットワークの分離やボリュームマウント（データ永続化）を含め、運用上の堅牢性を高めます。例えば、Prometheus の設定ファイルをコンテナ内部ではなく、ホスト側からマウントすることで、設定変更時にコンテナを再ビルドせずに反映させやすくなります。また、ログ出力は stdout/stderr に統一し、Docker の Log Driver を使用して外部のログ集約システムへ転送する構成も一般的です。

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/usr/share/prometheus/console_libraries'
      - '--storage.tsdb.retention.time=15d'

  alertmanager:
    image: prom/alertmanager:latest
    container_name: alertmanager
    ports:
      - "9093:9093"
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml

volumes:
  prometheus_data:

本番運用では latest ではなく、検証済みの特定バージョンタグを固定することを推奨します。Prometheus は 2024 年 11 月に 7 年ぶりのメジャーバージョンとなる 3.0 が GA となり、UTF-8 文字サポートや OpenTelemetry 互換性、新 UI などが追加されました。利用する際は、3.0 系の最新パッチや、Alertmanager・Grafana との互換性を確認したうえでバージョンを選定してください。

• CPU 要件：Prometheus は最小 1 コア、推奨 2 コア程度
• メモリ要件：Prometheus 4GB 以上、Alertmanager 512MB 以上が目安
• ポート割り当て：9090（Prometheus）、9093（Alertmanager）
• データ永続化：Docker Volume を使用し、コンテナ削除後もメトリクスを保持

prometheus.yml 設定詳解：scrape_configs と relabel_configs の制御

prometheus.yml は Prometheus の中枢となる設定ファイルです。ここでの設定ミスは、監視対象の漏れやパフォーマンス低下に直結するため、慎重な設計が求められます。PromQL の構文は洗練されており複雑な条件分岐も可能ですが、その前提としてメトリクスの収集ルール（scrape_configs）を正確に定義する必要があります。

基本となる global セクションでは、すべてのスクレイプジョブに適用されるデフォルト値を設定します。例えば、scrape_interval はターゲットからデータを取得する頻度です。標準的な設定は 15 秒ですが、リソース制約がある環境や、データ量を抑えたい場合は 30 秒〜60 秒へ延長できます。逆に、極めて短い時間スケールでの異常検知が必要な場合（例：バッチ処理の遅延監視）には、より短い間隔に設定することも可能です。ただし、インターバルを短くしすぎると、Prometheus サーバー自体がネットワーク I/O とディスク書き込みで負荷を受け、メトリクス収集そのものが不安定になるリスクがあります。

scrape_configs セクションでは、実際に監視する対象（ターゲット）を定義します。静的な IP アドレスやホスト名をリストにする static_configs の他、Kubernetes などの動的環境向けの Service Discovery も使用可能です。また、relabel_configs を活用して、取得したメトリクスに対してラベルの追加、削除、置き換えを行うことができます。例えば、ターゲットが多くのサーバーからなる場合、すべてのデータに environment: production というラベルを付与することで、Grafana でのフィルタリングを容易にします。逆に、機密情報や不要な高カーディナリティなラベル（例：ユーザー ID など）が含まれるメトリクスは、取得前に除外する設定が必須となります。

global:
  scrape_interval: 15s
  evaluation_interval: 30s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node-exporter'
    file_sd_configs:
      - files:
          - '/etc/prometheus/targets/node_targets.json'
    relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):(\d+)'
        target_label: port
        replacement: '$2'

• scrape_interval：メトリクス収集頻度（例：15s, 30s）
• evaluation_interval：アラートルール評価頻度
• static_configs：静的なターゲットリスト定義
• relabel_configs：取得データに対するラベル操作

PromQL 基礎と実践クエリ集

PromQL（Prometheus Query Language）は、時系列データをクエリするための言語です。SQL に似ていますが、時系列データの特性に特化しており、rate() や increase() といった関数が重要な役割を果たします。リソース枯渇の予測には predict_linear() を用い、将来的な傾向を把握できます。

最も基本的かつ頻繁に使用される関数として rate() があります。これは、指定された時間範囲内のカウンター（Counter）メトリクスの増加分を、秒あたりの平均レートに変換します。例えば、ネットワークインターフェースの受信バイト数を監視する場合、単純な値を取得するだけでは「過去の値との差分」がわからないため、rate(node_network_receive_bytes_total[5m]) のように [5m] というウィンドウ指定が必要です。この時間範囲は、データのノイズを平滑化するために重要です。また、ヒストグラム（Histogram）メトリクスを使用する際には histogram_quantile() を使用し、P90 や P99 などのパーセンタイル値を取得できます。

実践的なクエリとして、CPU 負荷の監視やディスク容量の残量を把握するための例を挙げます。「CPU 使用率が一定の閾値を超える状態が継続している」ようなアラート条件を作成する際、単純な閾値判定だけでなく、avg_over_time() を使用して直近の平均負荷を取得し、急激な変動を検知する手法があります。さらに、ディスク容量の減少傾向を予測するには predict_linear(node_filesystem_avail_bytes[1h], 3600 * 24) のように、現在から未来（秒数指定）の値を予測するクエリを使用します。これにより、空き容量が枯渇する前に警告を発信することが可能になります。

ヒストグラムからパーセンタイルを算出する際は、対象メトリクスの _bucket サフィックスと rate() を組み合わせる点に注意してください。例えば HTTP リクエストの P95 レイテンシは、次のように記述します。

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

le（less than or equal）ラベルでバケットごとの累積カウントを集約し、その増加レートに対して分位点を求めるのが正しい形です。_bucket を付けない、あるいは rate() を省いた記述は意図した値を返しません。

• rate(): 1 秒あたりの平均増加分（Counter 用）
• increase(): 指定時間の総増加量（Counter 用）
• histogram_quantile(): レイテンシなどの分布解析に使用（_bucket + rate() 必須）
• predict_linear(): リソース枯渇予測に有用

アラートルール定義のベストプラクティス：抑止と通知の設計

アラートルールの設定は、監視システムが最も重要な役割を果たす部分です。不適切なルール設定は「アラート疲れ」を招き、実際の障害を見逃す原因となります。Prometheus のアラートルールは YAML 形式で定義され、groups、rules、alert、expr、for、labels、annotations などの要素から構成されます。

alert セクションにはアラートの名前を定義します。これは人間が読みやすい名前にするだけでなく、システム内で一意となるように命名することが推奨されます（例：HighCPUUsage）。expr には前述の PromQL クエリを記述し、このクエリが結果を返す時にアラートが発火します。特に重要なのが for パラメータです。これは、アラート条件が満たされた状態が継続する時間を指定するもので、一瞬のスパイクによる誤作動を防ぐために必須です。例えば、CPU 使用率が一時的に高騰したとしても、5 分間続かない場合は通知しない設定にすることで、ノイズを減らせます。

labels と annotations は、アラートのメタデータと表示情報を定義します。labels には severity（Critical, Warning, Info）を設定し、Alertmanager で優先度に応じた処理分岐を行えるようにします。また、annotations にはアラートが発生した際の人間向けの説明や、対応手順が記載された URL を含めます。これにより、通知を受け取ったオペレーターは、即座に「何が起きているのか」「何をすべきか」を把握できます。対応手順をまとめた Runbook へのリンクを含めておくと、運用時の初動が速くなります。

なお、expr の論理と annotations の説明文は必ず一致させてください。下記の例では、node_cpu_seconds_total{mode="idle"} の増加レート（= アイドル率）が 0.2 を下回る、すなわち CPU 使用率がおおむね 80% を超えた状態を検知しています。description もこの意味に揃えています。

groups:
- name: cpu-alerts
  rules:
  - alert: HighCPUUsage
    expr: avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) < 0.2
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "CPU usage is high"
      description: "{{ $labels.instance }} CPU usage is above 80%"

• for: アラート発火までの持続時間（例：5m）
• severity: 重要度のラベル分類（Critical, Warning）
• annotations: 通知本文や対応マニュアルへのリンク（expr の論理と一致させる）
• labels: グループ分けやフィルタリング用タグ

Alertmanager 設定詳解：ルーティングと抑制ロジック

Alertmanager は、Prometheus から受信したアラートを処理し、適切な通知先へ配信するサービスです。単に通知を送るだけでなく、冗長性の排除（Suppress）、グループ化（Grouping）、および優先度による分岐（Routing）を行う役割を持ちます。

設定ファイル alertmanager.yml の核心となるのは route セクションです。ここでは、アラートの配送先（receiver）やグループ化のルールを定義します。例えば、「障害の種別」ごとに通知先を分けることができます。「Critical」レベルのアラートは Slack へ即座に送信し、「Warning」レベルは Email で報告するといった設定が一般的です。また、group_by パラメータにより、同じグループ化キーを持つアラートをまとめて通知できます。これにより、同一のサーバーで複数のアラートが発火した場合でも、1 通のメッセージとしてまとめられ、通知頻度を抑制できます。

さらに高度な機能として「抑制ルール（Inhibit Rules）」があります。これは、ある条件のアラートが発生している場合、他の関連するアラートを抑制するためのロジックです。例えば、「Disk Failed」という重大障害が発生した場合、それによって生じる「Disk Low Space」や「IO High Latency」などの派生アラートは意味がないため、抑制して通知しないように設定します。これにより、オペレーターは根本原因（Disk Failed）に集中し、二次的な問題への対応を省略できます。

抑制ルールでは source_matchers（抑制元の条件）と target_matchers（抑制対象の条件）をリスト形式で指定します。加えて equal で「両者で一致していなければならないラベル」を指定する点が重要です。equal を省略すると、1 つの Critical アラートがインフラ全体の Warning アラートを無差別に抑制してしまう恐れがあります。下記の例では、同一 instance 上で発生した Critical と Warning に限って抑制が適用されます。

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  receiver: 'default-receiver'
  routes:
    - matchers:
        - severity="critical"
      receiver: 'slack-critical'
inhibit_rules:
  - source_matchers:
      - severity="critical"
    target_matchers:
      - severity="warning"
    equal: ['instance']

• route: アラート配送先のルーティング定義
• group_by: アラートをグループ化するためのキー（例：alertname）
• inhibit_rules: 上位アラートの発生時に下位アラートを抑制（source_matchers / target_matchers はリスト）
• receiver: 通知アクションの定義名

Slack/Discord 連携実装：Webhook を活用したリアルタイム通知

チームコミュニケーションでは、Slack や Discord が標準的なチャネルとして定着しています。Alertmanager とこれらのサービスを連携させることで、アラート情報を即座に通知することが可能になります。設定には Alertmanager の receivers セクション内で Webhook URL を指定するだけで済みますが、メッセージの内容をカスタマイズして見やすくすることも重要です。

Slack への通知では、通知先として Webhook URL を設定します。Alertmanager は、アラート情報を Slack 用のフォーマットに変換して送信します。ただし、デフォルトの設定では非常に簡素なテキストのみが送られるため、Markdown やブロック表示を使用した装飾を施すことが推奨されます。具体的には、slack の text フィールドや blocks オプションを使用し、色分けされたメッセージカードを作成できます。例えば、Critical 時は赤色のバーを表示し、Warning 時は黄色を表示することで、視覚的な区別をつけられます。

Discord への通知も同様に Webhook を使用します。Discord はボット連携が容易で、通知をきっかけに後続のアクションを自動化することも可能です。Alertmanager のテンプレート機能を使用し、{{ .GroupLabels }} や {{ range .Alerts }} といった変数を使用して、動的なメッセージ内容を生成します。これにより、発火したアラートのインスタンス名や説明を含む詳細情報を、チャット上で読みやすく整形して送信できます。

• Webhook URL: 通知先エンドポイントへの接続パス
• Markdown 表示: Slack のブロック表示への対応
• テンプレート変数: {{ .Labels }} による動的テキスト置換
• 絵文字の活用: 視認性向上のための絵文字付与

Grafana ダッシュボード作成：Prometheus データソース接続と可視化

収集したメトリクスデータを人間が理解しやすい形に可視化するのが Grafana の役割です。新しめの Grafana では UI のレスポンス性が向上し、ダッシュボードのレンダリング速度も改善されています。Prometheus をデータソースとして追加し、その中からクエリを記述することで、リアルタイムのサーバー状態を確認できます。

まず、Grafana 上で「Data Sources」の設定を行い、Prometheus の接続情報を入力します。URL は通常 http://localhost:9090 となりますが、外部からアクセスする場合は適切な認証やネットワーク設定が必要です。データソースが追加されたら、「New Dashboard」を選択し、新しいパネルを作成します。各パネルには、先ほど学んだ PromQL クエリを記述し、グラフのタイプ（時系列グラフ、ゲージ、単一値など）を選択して表示形式を調整できます。

Grafana の強力な機能として「Variable」があります。これは、ダッシュボード上で動的にパラメータを変更できる機能です。例えば、「サーバー名」や「環境（prod/dev）」をプルダウンリストで選択可能にし、それに応じてクエリが書き換わるように設定します。これにより、1 つのダッシュボードテンプレートで全サーバーの状態を監視することが可能になり、運用効率を大幅に向上させます。基本的な可視化は手動クエリによる設定が中心ですが、必要に応じてプラグインで機能を拡張できます。

• Variable: ダッシュボードのパラメータ動的指定機能
• Panel Types: グラフ、ステータス、ヒートマップなど多様な表示
• Time Range: 過去 1 時間、7 日間などの表示範囲指定
• Refresh Rate: データの自動更新間隔（例：30s）

エクスポーター比較：Node Exporter, cAdvisor, Blackbox の役割分担

監視対象に応じて適切な Exporter を選択することは、コストと効果のバランスにおいて重要です。ここでは主要な 3 つの Exporter を比較し、それぞれがカバーする範囲や設定上の注意点を解説します。各ツールは特定の環境や用途に最適化されており、組み合わせることでインフラ全体を網羅できます。

Node Exporter は Linux サーバーの OS レベルでのメトリクス取得に最も広く使用されます。CPU 使用率、メモリ使用量、ディスク IO、ネットワークトラフィックなど、システムリソースの状態を包括的に取得可能です。設定はシンプルで、デフォルトポート（9100）上で /metrics エンドポイントを公開するだけで動作します。ただし、コンテナ内部の詳細なメトリクスまでは取得できないため、Docker 環境では cAdvisor と併用する必要があります。

cAdvisor（Container Advisor）は Docker コンテナ向けの Exporter です。コンテナごとの CPU・メモリ使用率やブロック IO などを監視できます。Kubernetes の Pod やデプロイメント単位でのメトリクス収集に適しており、特にマイクロサービスアーキテクチャでは重要なツールです。ただし、ホストレベルのリソース（物理ディスクなど）は取得できないため、Node Exporter との併用が推奨されます。

Blackbox Exporter は「外形監視」に特化しています。HTTP/HTTPS プロトコルや TCP ポートへの到達性（Reachability）をテストします。つまり、「サーバーは動いているか」「Web サイトは開けるか」という可用性のチェックを行います。これは、メトリクス収集とは異なる意味での監視であり、ネットワーク障害や DNS 解決エラーを検知する際に有効です。特に、外部からアクセス可能な Web サービスの監視には欠かせません。

• Node Exporter: OS リソース監視用、ポート 9100 標準使用
• cAdvisor: コンテナ内リソース監視用、K8s と相性良好
• Blackbox: 可用性テスト（Ping/HTTP）、SSL 証明書期限も取得可
• Exporter の選定: インフラ構成に応じて単一または複合で採用

パフォーマンスチューニングと運用上の注意点

監視環境では、データ量の増加に伴うパフォーマンス課題が重要なテーマです。Prometheus の TSDB は効率的ですが、高頻度なスクレイプや大量のメトリクスラベルを保持すると、ディスク I/O やメモリ使用量が増加します。これらを管理するために、データ保持期間（retention）の適切な設定と、高負荷時の最適化が必要です。

storage.tsdb.retention.time パラメータにより、データを保存する期間を指定できます。一般的な運用では 15 日〜30 日を目安としますが、コスト削減や長期分析が必要な場合は外部ストレージ（S3 や GCS）との連携を検討します。また、ベストプラクティスとして、高カーディナリティなラベル（例：ユーザー ID をそのままラベルにするなど）を避けることが重要です。これにより、メトリクス数の爆発的な増加を防ぎ、TSDB の負荷を抑制できます。

運用上の注意点として、時刻の同期が挙げられます。Prometheus はサーバー側のシステム時刻に基づいてタイムスタンプを付与するため、ターゲットとなるサーバーとの時刻差分（NTP 設定）が大きいと、データ解析に不具合が生じます。特に rate() 関数を使用する際、時刻のズレは計算結果に誤差をもたらすため、全サーバーで NTP サーバーへの同期が望ましい構成です。また、ネットワークの分断や Prometheus サーバー自体の再起動時にデータが欠落しないよう、WAL（Write-Ahead Log）の挙動を理解しておくことも重要です。

• Retention Policy: データ保存期間（例：15d, 30d）
• Cardinality Control: ラベル数を制限して TSDB 負荷軽減
• NTP Sync: サーバー間時刻同期の重要性（誤差防止）
• WAL の理解: 再起動・障害時のデータ整合性に関わる

よくある質問（FAQ）

Q1: Prometheus のメトリクス保存期間はどのように設定しますか？ A1: --storage.tsdb.retention.time コマンドライン引数で設定します。例えば 30 日間保存する場合は、'--storage.tsdb.retention.time=30d' と指定します。容量上限で管理したい場合は --storage.tsdb.retention.size を併用することもできます。

Q2: アラートが発火しない場合、どのように確認すべきですか？ A2: まず Prometheus の Web UI から「Rule Status（Alerts）」を確認し、アラートルールが正しく評価されているか確認します。次に、該当する PromQL クエリを直接実行して結果が空でないか検証します。また、Alertmanager に正しくメッセージが届いているか、Alertmanager の Web UI で確認することも重要です。

Q3: 大量のアラートが集中して「アラート疲れ」になるのを防ぐには？ A3: Alertmanager の inhibit_rules（抑制ルール）を設定し、根本原因となるアラートの発生時に派生アラートを抑止します。また、アラートルールの for パラメータを適切に設定し、一瞬のスパイクによる通知を防ぐ設定が有効です。group_by による集約も併用すると効果的です。

Q4: Grafana で Prometheus データソースを追加できないエラーが出ます。 A4: 主にネットワーク接続または認証の問題です。Prometheus サーバーと Grafana が相互に到達可能なネットワークにあり、かつ Prometheus の Web UI（通常 9090 ポート）へアクセスできるか確認してください。コンテナ間通信の場合は、Docker ネットワーク上のサービス名で解決できているかも確認します。

Q5: Docker コンテナ内で Node Exporter を使用する場合の注意点は何ですか？ A5: Node Exporter はホストの状態を計測するため、ホストのファイルシステムやプロセス・ネットワークの名前空間を参照できるようにする必要があります。具体的には、/proc・/sys・ルートファイルシステムをコンテナにマウントし、--path.rootfs 等で参照先を指定したうえで、ホストの PID／ネットワーク名前空間を共有する構成が一般的です。コンテナ内部だけを見ていると、ホスト全体のメトリクスが取得できない点に注意してください。

Q6: Prometheus のメモリ使用量が急激に増加しました。どう対処しますか？ A6: メトリクスのカーディナリティ（ラベルの組合せ数）が異常に高くなっていないか確認してください。不要なラベルが含まれていないか prometheus.yml の relabel_configs でフィルタリングする必要があります。また、データ保持期間を短縮するか、ストレージ・メモリ容量を見直します。

Q7: cAdvisor を使用してコンテナの CPU 使用率を取得できない場合の原因は？ A7: cAdvisor が Docker のソケットやコンテナ情報にアクセスできていない可能性があります。Docker のアクセス権限を確認し、cAdvisor に必要なボリューム（Docker ソケットや /sys、コンテナのルートディレクトリ等）がマウントされているか確認してください。また、Kubernetes 環境では DaemonSet としての設定ミスも考えられます。

Q8: Slack 通知のメッセージ形式をカスタマイズする方法はありますか？ A8: Alertmanager のテンプレートファイルを編集することで可能です。slack セクション内の text や blocks フィールドに対して Go テンプレート言語を使用して動的なテキスト生成が可能です。例：{{ .GroupLabels.alertname }} を使用してアラート名を表示できます。

Q9: Prometheus のバージョンは新しいものに更新すべきですか？ A9: 基本的に推奨されます。各バージョンで TSDB のパフォーマンス改善やセキュリティパッチが含まれます。特に 2024 年 11 月に GA となった 3.0 系では、UTF-8 サポート・OpenTelemetry 互換性・新 UI などが追加されました。更新時は Alertmanager や Grafana との互換性、および破壊的変更の有無を確認したうえで、検証環境で動作確認してから本番へ適用してください。

Q10: 監視システム自体に障害が発生した場合、どうやって検知しますか？ A10: 「自己監視」が必要です。例えば、別のサーバーや外部サービスから Prometheus の Web UI や API エンドポイントを定期的にチェックする Blackbox Exporter を設定します。これにより、監視システム自体のダウンを検知し、冗長化を確保できます。

まとめ

本記事では、Prometheus と Alertmanager を組み合わせた監視アラート基盤の構築方法を詳細に解説しました。以下が主要なポイントのまとめです。

• アーキテクチャ: Pull 型と TSDB の仕組みを理解し、用途に合った構成を把握する
• インストール: [Docker Compose を活用してリソース効率よく環境構築を行う（CPU 1-2 コア、RAM 4GB+ が目安）
• 設定: prometheus.yml におけるスクレイプ間隔と relabel 機能の制御を徹底する
• PromQL: rate() や histogram_quantile()、predict_linear() を使いこなして実用的なクエリを記述する
• アラートルール: for と severity を設定し、expr と annotations の論理を一致させる
• Alertmanager: ルーティングと抑制ルール（source_matchers / target_matchers / equal）でアラートノイズを削減し、Slack/Discord と連携する
• Grafana: データソース接続と可視化パネルの作成により、状況把握を容易にする
• Exporter 選定: Node, cAdvisor, Blackbox の特性を適切に使い分けて監視範囲を広げる

これらを正しく適用することで、堅牢かつ効率的な監視基盤を構築できます。本ガイドが、サーバー運用やインフラ設計の参考になれば幸いです。