GitLab Runnerのモニタリング

GitLab RunnerはPrometheusを使って監視することができます。

Prometheusの組み込みメトリクス

GitLabRunner1.8.0では、Prometheusメトリクスの組み込みHTTP Statistics Serverが導入されました。

GitLab RunnerはネイティブのPrometheusメトリクスで計装されており、/metrics パス上の組み込みHTTPサーバを通して公開することができます。このサーバーは、Prometheusモニタリングシステムによってスクレイピングされたり、他のHTTPクライアントからアクセスすることができます。

公開される情報は以下の通りです：

  • Runnerビジネス・ロジックのメトリクス（現在実行中のジョブ数など）
  • Go固有のプロセス・メトリクス（ガベージ・コレクション統計、ゴルーチン、memstatsなど）
  • 一般的なプロセス・メトリクス（メモリ使用量、CPU使用量、ファイル記述子使用量など）
  • ビルド・バージョン情報

メトリクスのフォーマットはPrometheusのExposition formatsspecificationに記載されています。

これらのメトリクスは、オペレーション担当者がランナーを監視してインサイトを得るためのものです。例えば、Runnerホストの平均負荷の増加が処理されたジョブの増加に関連しているかどうかを知りたいと思うかもしれません。あるいは、マシンのクラスターを実行しており、ビルドの傾向を追跡してインフラストラクチャを変更できるようにしたい場合もあるでしょう。

Prometheus についてもっと知る

このHTTPエンドポイントをスクレイピングし、収集されたメトリクスを利用するためのPrometheusサーバーのセットアップ方法については、Prometheusの入門ガイドを参照してください。また、Prometheusの設定方法の詳細については、設定セクション、アラートルールのセクション、アラート通知を送信するためのアラートマネージャの設定セクションを参照してください。

利用可能なメトリクス

利用可能なすべてのメトリクスの完全なリストを表示するには、curl メトリクスのエンドポイントを設定し、有効にします。例えば、リスニング・ポート9252 で構成された内部 Runner の場合：

$ curl -s "http://localhost:9252/metrics" | grep -E "# HELP"

# HELP gitlab_runner_api_request_statuses_total The total number of api requests, partitioned by runner, endpoint and status.
# HELP gitlab_runner_autoscaling_machine_creation_duration_seconds Histogram of machine creation time.
# HELP gitlab_runner_autoscaling_machine_states The current number of machines per state in this provider.
# HELP gitlab_runner_concurrent The current value of concurrent setting
# HELP gitlab_runner_errors_total The number of caught errors.
# HELP gitlab_runner_limit The current value of limit setting
# HELP gitlab_runner_request_concurrency The current number of concurrent requests for a new job
# HELP gitlab_runner_request_concurrency_exceeded_total Count of excess requests above the configured request_concurrency limit
# HELP gitlab_runner_version_info A metric with a constant '1' value labeled by different build stats fields.
...

利用可能なメトリクスの完全なリストについては、ランナーの監視を参照してください。

pprof HTTPエンドポイント

pprof インテグレーションは GitLab Runner 1.9.0 で導入されました。

GitLab Runner プロセスの内部状態に関するメトリクスを持つことは有用ですが、Running プロセスの内部で何が起こっているかをリアルタイムで確認した方が良いケースもあることがわかりました。そこで、pprof HTTPエンドポイントを導入しました。

pprof エンドポイントは/debug/pprof/ パスの組み込み HTTP サーバから利用できます。

pprof の使い方については、そのドキュメントを参照してください。

メトリクス HTTP サーバーの設定

note
メトリクスサーバーは、GitLab Runnerプロセスの内部状態に関するデータをエクスポートし、公開すべきではありません！

メトリクスHTTPサーバーは以下の方法で設定できます：

  • config.toml ファイルのlisten_address グローバル設定オプションを使用します、
  • run コマンドの--listen-address コマンドラインオプション、
  • values.yaml のmetrics とservice の設定オプションを設定することで、Helm Chart を使用する Runner 用になります。

アドレスをconfig.toml ファイルに追加した場合、メトリクス HTTP サーバーを起動するには、Runner プロセスを再起動する必要があります。

どちらの場合も、このオプションは[host]:<port> という形式の文字列を受け付けます：

  • host は IP アドレスまたはホスト名です、
  • port は有効なTCPポートまたはシンボリックサービス名（http など）です。Prometheusで既に割り当てられているポート9252 を使用することをお勧めします。

リッスンアドレスにポートが含まれていない場合、デフォルトは9252 になります。

アドレスの例：

  • :9252 - は、ポート9252
  • localhost:9252 - のループバックインターフェイスだけをリッスンします。9252
  • [2001:db8::1]:http - は IPv6 アドレス[2001:db8::1] で HTTP ポートを待ちます。80

1024 以下のポートをリッスンするには、少なくとも Linux/Unix システムでは root/ 管理者権限が必要です。

HTTP サーバは、作成者なしで選択されたhost:port で開かれます。もし、メトリクス・サーバーを公開インターフェースにバインドする予定であれば、ファイアウォールを使用してこのサーバーへのアクセスを制限するか、HTTPプロキシを追加して、作成者とアクセス制御レイヤーを追加することを検討する必要があります。