Prometheus + Grafana で Webサービス監視環境を構築する - クライアントライブラリ監視編 -

Posted at 2025-06-01

はじめに

これまで紹介してきたPrometheusのExporterによるメトリクス収集により、提供しているサービスが安定的に稼働しているかを確認できます。

しかし、Exporterでは以下に挙げるビジネス的な観点のメトリクス収集はできません。

ユーザーのプロファイル（年代、性別、地域といった属性）毎の機能利用率
検索 → 詳細閲覧 → カート追加 → 購入のファネル追跡
ユーザーが使用するデバイスごとの商品購入完了率

上記のようなメトリクスは、必要な項目をプログラム内部でログに出力して、週次・月次など定期的にレポーティングすることは可能です。
プレミアム会員の退会なども、退会機能を利用したユーザーのプロファイルをログに出力して、常時ログ監視しておけばアラート通知することは可能でしょう。

ただし、重要なビジネスメトリクスを迅速に収集しアラート通知したい場合、わざわざログ出力するよりも、Prometheusに直接メトリクスを収集させた方がリアルタイム性が高まります。

サービスに特化したビジネスメトリクスをプログラム内部でPrometheusに収集させるためには、Prometheusの公式クライアントライブラリを利用します。

今回は、クライアントライブラリをプログラム内部で呼び出し、Prometheusでメトリクスを収集する方法を紹介します。

前提

本記事は、以下について概要レベルの知識を有している読者を想定しています。

本記事で紹介する環境構築は、以下の環境で行いました。

Windows11 WSL2(Ubuntu 22.04.5 LTS)
Docker version 27.5.1
Docker Compose version v2.34.0

本記事では、Prometheusによるモニタリングの中でも、クライアントライブラリによるビジネスメトリクスのモニタリングに焦点を当てて紹介します。
PrometheusやGrafana自体の説明や、外形監視やスロークエリ、短命ジョブの監視、および、検証のための環境構築方法については以下を参照してください。

Prometheus + Grafana で Webサービス監視環境を構築する - 外形監視編 -

Prometheus + Grafana で Webサービス監視環境を構築する - スロークエリ・エラーレート監視編 -

Prometheus + Grafana で Webサービス監視環境を構築する - 短命ジョブ監視編 -

解説

Exporterについて

Exporterは、監視対象のサーバーやプロセスにアクセスできる環境にインストール（デプロイ）して利用します。
PrometheusからのHTTPリクエストを受け取ると、監視対象のメトリクスを収集し、TEXT形式に整形してレスポンスします。

監視対象の種類（DB、ハードウェアなど）により様々なExporterが公開されており、用途により適切なものを選んで利用します。

公式のExporterが欲しいメトリクスを収集していない場合や、そもそも公式のExporter自体が存在していない場合は、Exporterを自作して利用することも可能です。

クライアントライブラリについて

クライアントライブラリは、開発言語ごとにPrometheusが公式に用意しているものや、コミュニティが有志で用意しているものが存在するので、アプリケーションの環境に応じて選定します。

開発言語	クライアントライブラリ
Go	prometheus/client_golang
Java	prometheus/client_java
Python	prometheus/client_python
Ruby	prometheus/client_ruby
.NET	prometheus-net/prometheus-net
Node.js	siimon/prom-client

クライアントライブラリは、監視対象のアプリケーションの中に組み込みます。
アプリケーションは、ユーザーの操作など任意のタイミングでクライアントライブラリの機能を使いメトリクスを都度記録していきます。

アプリケーション側でPrometheus用のメトリクスエンドポイントを用意し、Prometheusからリクエストを受け付けた際に内部で記録しておいたメトリクスをレスポンスします。

クライアントライブラリとExporterの使い分けについて

クライアントライブラリは、アプリケーションと同一プロセスに組み込まれるため、アプリケーション自体のリソース使用率が高まります。重要な機能に絞ってメトリクスの収集を行い、処理負荷が高まりすぎないように注意が必要です。

一方で、Exporterは、アプリケーションとは別プロセスで起動するため、クライアントライブラリに比べてアプリケーションのリソース使用率を高めません。

クライアントライブラリとExporterの比較は以下の通りです。

項目	クライアントライブラリ	Exporter
取得可能なメトリクス	アプリケーション内部の詳細メトリクス（ビジネスロジック、ユーザーアクション）	システムやミドルウェアの外部メトリクス（CPU使用率、DB統計など）
リアルタイム性・精度	アプリケーション処理と同期して計測でき、ミリ秒単位での精密な監視が可能	ポーリングベースのため遅延が発生する可能性あり、精度はやや劣る
カスタマイズ性	任意のKPIや複雑な条件付きメトリクスを自由に定義可能	Exporterの仕様に依存、独自メトリクスの追加は困難または制限あり
アプリへの影響	メトリクス収集処理がアプリ本体に影響を与える可能性あり	アプリとは分離されており、Exporterの障害がアプリに影響を与えない
保守性・コード管理	ロジックと監視コードが混在し、保守性や可読性が下がる場合がある	アプリと分離されているため、役割分担が明確でコードも分離可能
障害耐性	アプリケーションがダウンするとメトリクスの取得も停止する	Exporterが別で動作していればメトリクス収集は継続可能
スケーラビリティと運用コスト	アプリ内で処理するため、高トラフィック時にリソース競合が起こり得る	Exporter側でリソースを分離・調整可能だが、運用負荷も増加

重要なビジネスメトリクスはクライアントライブラリで収集し、それ以外の技術的なメトリクスはExporterで収集させるなど、適材適所で使い分けて利用するのが良いでしょう。

監視環境の構成図（再掲）

今回構築する監視環境の構成図は以下の通りです。

環境構築手順

Grafanaのダッシュボード作成

独自メトリクスを可視化するためには、ダッシュボードを自作する必要があります。

[Home > Dashboards > New dashboard > Edit panel] からメトリクスごとのパネルを作成しましょう。

http_requests_total, http_request_duration_seconds, database_connections_active, database_query_duration_seconds, database_queries_total, user_actions_total, health_check_status, application_errors_total, slow_queries_total

平均応答速度の可視化

VisualizationにStatを選択して、以下のPromQLを入力しましょう。

rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])

応答時間分布の可視化

VisualizationにHeatmapを選択して、以下のPromQLを入力しましょう。
※データが存在しない場合はエラーが表示されます。

rate(http_request_duration_seconds_bucket[5m])

ユーザーアクションの可視化

VisualizationにTime seriesを選択して、以下のPromQLを入力しましょう。

sum(rate(user_actions_total[5m])) by (action_type)

ダッシュボードを保存しましょう。

アラート条件の設定

アラート条件の設定はprometheus/alert_rules.ymlで定義しています。
今回は、以下のアラート条件を設定しました。

prometheus/alert_rules.yml

      # === ユーザーアクション関連のアラート ===
      - alert: WebappLowUserActivity # ユーザーアクティビティが低い場合のアラート（5分間でリクエストが10未満）※監視系エンドポイントを除外
        expr: rate(user_actions_total{endpoint!~"/health|/schema|/metrics|/status"}[5m]) * 300 < 10
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Low user activity detected on webapp"
          description: "User activity is unusually low. Less than 10 requests in the past 5 minutes."

rate : 1秒あたりの平均値を算出する。×300して5分換算している。
user_actions_total : クライアントライブラリで集計しているエンドポイント毎のアクセス数。常時リクエストを送っている監視エンドポイントは除外している。

クライアントライブラリでメトリクス収集

自作のアプリケーションには、独自にメトリクスを収集する処理を埋め込みました。

app/app.js

// HTTPリクエストの応答時間を測定（ヒストグラム）
const httpRequestDuration = new clientProm.Histogram({
  name: 'http_request_duration_seconds',
  help: 'Duration of HTTP requests in seconds',
  labelNames: ['method', 'route', 'status_code'],
  buckets: [0.1, 0.3, 0.5, 0.7, 1, 3, 5, 7, 10] // レスポンス時間のバケット設定
});

// アプリケーション固有のビジネスメトリクス
const userActionsCounter = new clientProm.Counter({
  name: 'user_actions_total',
  help: 'Total number of user actions',
  labelNames: ['action_type', 'endpoint'], // ユーザーアクション種別を追跡
});