Prometheusを使用したGitLabのモニタリング

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

Prometheusは、GitLabおよびその他のソフトウェア製品のモニタリングに柔軟なプラットフォームを提供する、強力な時系列モニタリングサービスです。

GitLabは、Prometheusを活用したモニタリング機能を標準で備えており、GitLabサービスに対する高品質な時系列モニタリングへのアクセスを提供します。

このページに記載されているPrometheusおよび各種exporterは、Linuxパッケージにバンドルされています。exporterの追加時期については、各exporterのドキュメントを参照してください。自己コンパイルによるインストール環境では、ユーザー自身がこれらをインストールする必要があります。今後のリリースでは、GitLabの追加のメトリクスがキャプチャされる予定です。

デフォルトでは、Prometheusサービスは有効になっています。

Prometheusおよびそのexporterはユーザーを認証しないため、アクセス権のあるすべてのユーザーが利用できます。

Prometheusの仕組み

Prometheusは、各種exporterを介してデータソースに定期的に接続し、パフォーマンスメトリクスを収集することで機能します。モニタリングデータを表示および操作するには、Prometheusに直接接続するか、Grafanaなどのダッシュボードツールを使用します。

Prometheusを設定する

自己コンパイルによるインストール環境では、ユーザー自身がPrometheusをインストールして設定する必要があります。

デフォルトでは、Prometheusとそのexporterは有効になっています。Prometheusはgitlab-prometheusユーザーとして実行され、http://localhost:9090でリッスンします。デフォルトでは、GitLabサーバー自身からのみPrometheusにアクセスできます。各exporterは、個別に無効にしない限り、Prometheusのモニタリング対象として自動的に設定されます。

Prometheusとそのすべてのexporter、さらに将来的に追加されるexporterを無効にするには、次の手順に従います:

/etc/gitlab/gitlab.rbを編集します。

次の行を追加するか、検索してコメントアウトを解除し、falseに設定されていることを確認します:

prometheus_monitoring['enable'] = false
sidekiq['metrics_enabled'] = false

# Already set to `false` by default, but you can explicitly disable it to be sure
puma['exporter_enabled'] = false

ファイルを保存して、GitLabを再設定し、変更を有効にします。

Prometheusがリッスンするポートとアドレスを変更する

Prometheusがリッスンするポートは変更できます。ただ、おすすめしません。変更すると、GitLabサーバーで実行されている他のサービスに影響したり、これらのサービスと競合したりする可能性があります。それでも変更する場合は、ご自身の責任において行ってください。

GitLabサーバーの外部からPrometheusにアクセスするには、Prometheusがリッスンするアドレスまたはポートを変更します:

/etc/gitlab/gitlab.rbを編集します。
次の行を追加するか、検索してコメントアウトを解除します:
```
prometheus['listen_address'] = 'localhost:9090'
```
localhost:9090を、Prometheusにリッスンさせるアドレスまたはポートに置き換えます。localhost以外のホストからPrometheusへのアクセスを許可する場合は、ホスト部分を省略するか、0.0.0.0を使用してパブリックアクセスを許可します:
```
prometheus['listen_address'] = ':9090'
# or
prometheus['listen_address'] = '0.0.0.0:9090'
```
ファイルを保存し、変更を反映させるためGitLabを再設定します。

カスタムスクレイプ設定を追加する

Prometheusのスクレイプターゲットの設定の構文を用いて、/etc/gitlab/gitlab.rb内のprometheus['scrape_configs']を編集することで、LinuxパッケージバンドルのPrometheusに追加のスクレイプターゲットを設定できます。

http://1.1.1.1:8060/probe?param_a=test&param_b=additional_testをスクレイプする設定の例を次に示します:

prometheus['scrape_configs'] = [
  {
    'job_name': 'custom-scrape',
    'metrics_path': '/probe',
    'params' => {
      'param_a' => ['test'],
      'param_b' => ['additional_test'],
    },
    'static_configs' => [
      'targets' => ['1.1.1.1:8060'],
    ],
  },
]

Linuxパッケージを使用したスタンドアロンPrometheus

Linuxパッケージを使用して、Prometheusを実行するスタンドアロンのモニタリングノードを設定できます。このモニタリングノードに接続するよう外部のGrafanaを設定し、ダッシュボードを表示できます。

複数ノードのGitLabデプロイには、スタンドアロンのモニタリングノードの使用が推奨されます。

LinuxパッケージでPrometheusを実行するモニタリングノードを設定するには、以下の手順が最低限必要です:

モニタリングノードにSSHで接続します。
GitLabのダウンロードページにあるsteps 1 and 2（手順1と2）を実行し、必要なLinuxパッケージをインストールします。ただし、それ以降の手順は実行しないでください。
次の手順で使用するため、ConsulサーバーノードのIPアドレスまたはDNSレコードを事前に確認してください。

/etc/gitlab/gitlab.rbを編集し、次の内容を追加します:

roles ['monitoring_role']

external_url 'http://gitlab.example.com'

# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false

# Enable service discovery for Prometheus
consul['enable'] = true
consul['monitoring_service_discovery'] = true
consul['configuration'] = {
   retry_join: %w(10.0.0.1 10.0.0.2 10.0.0.3), # The addresses can be IPs or FQDNs
}

# Nginx - For Grafana access
nginx['enable'] = true

sudo gitlab-ctl reconfigureを実行して設定をコンパイルします。

次に、モニタリングノードの位置を他のすべてのノードに知らせる手順を実行します:

/etc/gitlab/gitlab.rbを編集し、次の行を追加するか、検索してコメントアウトを解除します:
```
# can be FQDN or IP
gitlab_rails['prometheus_address'] = '10.0.0.1:9090'
```
ここでの10.0.0.1:9090は、PrometheusノードのIPアドレスとポートです。
ファイルを保存して、GitLabを再設定し、変更を有効にします。

consul['monitoring_service_discovery'] = trueを設定してサービスディスカバリによるモニタリングを有効にした後は、/etc/gitlab/gitlab.rbでprometheus['scrape_configs']を設定しないようにしてください。/etc/gitlab/gitlab.rbでconsul['monitoring_service_discovery'] = trueとprometheus['scrape_configs']の両方を設定すると、エラーが発生します。

外部のPrometheusサーバーを使用する

Prometheusおよびほとんどのexporterは、認証をサポートしていません。そのため、ローカルネットワークを外部に公開するのはおすすめしません。

GitLabを外部のPrometheusサーバーでモニタリングできるようにするには、いくつかの設定変更が必要です。

外部のPrometheusサーバーを使用するには、次の手順に従います:

/etc/gitlab/gitlab.rbを編集します。
バンドルされているPrometheusを無効にします:
```
prometheus['enable'] = false
```

バンドルされている各サービスのexporterがネットワークアドレスでリッスンするように設定します。次に例を示します:

node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = "0.0.0.0:9229"

# Rails nodes
gitlab_exporter['listen_address'] = '0.0.0.0'
gitlab_exporter['listen_port'] = '9168'
registry['debug_addr'] = '0.0.0.0:5001'

# Sidekiq nodes
sidekiq['listen_address'] = '0.0.0.0'

# Redis nodes
redis_exporter['listen_address'] = '0.0.0.0:9121'

# PostgreSQL nodes
postgres_exporter['listen_address'] = '0.0.0.0:9187'

# Gitaly nodes
gitaly['configuration'] = {
   # ...
   prometheus_listen_addr: '0.0.0.0:9236',
}

# Pgbouncer nodes
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'

必要に応じて、公式インストール手順に従って専用のPrometheusインスタンスをインストールしてセットアップします。
すべてのGitLab Rails（Puma、Sidekiq）サーバーで、PrometheusサーバーのIPアドレスとリッスンポートを設定します。例:
```
gitlab_rails['prometheus_address'] = '192.168.0.1:9090'
```

NGINXメトリクスをスクレイプするには、PrometheusサーバーのIPを許可するようにNGINXを設定する必要もあります。例:

nginx['status']['options'] = {
      "server_tokens" => "off",
      "access_log" => "off",
      "allow" => "192.168.0.1",
      "deny" => "all",
}

Prometheusサーバーが複数ある場合は、複数のIPアドレスを指定することも可能です:

nginx['status']['options'] = {
      "server_tokens" => "off",
      "access_log" => "off",
      "allow" => ["192.168.0.1", "192.168.0.2"],
      "deny" => "all",
}

PrometheusサーバーがGitLabメトリクスのエンドポイントをフェッチできるようにするには、モニタリング用IP許可リストにPrometheusサーバーのIPアドレスを追加します:
```
gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
```
GitLabでは、バンドルされている各サービスのexporterがネットワークアドレスでリッスンするように設定しているため、インスタンスのファイアウォールを更新し、有効になっているexporterに対してはPrometheusのIPからのトラフィックのみを許可するようにしてください。exporterサービスとそれぞれのポートをまとめた完全なリストは、こちらを参照してください。
変更を反映させるため、GitLabを再設定します。
Prometheusサーバーの設定ファイルを編集します。

各ノードのexporterを、Prometheusサーバーのスクレイプターゲット設定に追加します。たとえば、static_configsを使用したサンプルスニペットは次のとおりです:

scrape_configs:
  - job_name: nginx
    static_configs:
      - targets:
        - 1.1.1.1:8060
  - job_name: redis
    static_configs:
      - targets:
        - 1.1.1.1:9121
  - job_name: postgres
    static_configs:
      - targets:
        - 1.1.1.1:9187
  - job_name: node
    static_configs:
      - targets:
        - 1.1.1.1:9100
  - job_name: gitlab-workhorse
    static_configs:
      - targets:
        - 1.1.1.1:9229
  - job_name: gitlab-rails
    metrics_path: "/-/metrics"
    scheme: https
    static_configs:
      - targets:
        - 1.1.1.1
  - job_name: gitlab-sidekiq
    static_configs:
      - targets:
        - 1.1.1.1:8082
  - job_name: gitlab_exporter_database
    metrics_path: "/database"
    static_configs:
      - targets:
        - 1.1.1.1:9168
  - job_name: gitlab_exporter_sidekiq
    metrics_path: "/sidekiq"
    static_configs:
      - targets:
        - 1.1.1.1:9168
  - job_name: gitaly
    static_configs:
      - targets:
        - 1.1.1.1:9236
  - job_name: registry
    static_configs:
      - targets:
        - 1.1.1.1:5001

このスニペットのgitlab-railsジョブは、GitLabにHTTPS経由でアクセス可能であることを前提としています。デプロイがHTTPSを使用していない場合は、httpスキームとポート80を使用するようにジョブ設定が調整されます。

Prometheusサーバーをリロードします。

ストレージ保持サイズを設定する

Prometheusには、ローカルストレージを設定するためのカスタムフラグがいくつかあります:

storage.tsdb.retention.time: 古いデータを削除するタイミング。デフォルトは15dです。このフラグがデフォルト以外の値に設定されている場合、storage.tsdb.retentionを上書きします。
storage.tsdb.retention.size: 保持するストレージブロックの最大バイト数（実験的なフラグ）。最も古いデータから削除されます。デフォルトは0（無効）です。このフラグは実験的な機能です。今後のリリースで変更される可能性があります。サポート対象の単位はB、KB、MB、GB、TB、PB、EBです。例えば、512MBです。

ストレージ保持サイズを設定するには、次の手順に従います:

/etc/gitlab/gitlab.rbを編集します:

prometheus['flags'] = {
  'storage.tsdb.path' => "/var/opt/gitlab/prometheus/data",
  'storage.tsdb.retention.time' => "7d",
  'storage.tsdb.retention.size' => "2GB",
  'config.file' => "/var/opt/gitlab/prometheus/prometheus.yml"
}

GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

パフォーマンスメトリクスを表示する

Prometheusがデフォルトで提供するダッシュボードを確認するには、http://localhost:9090にアクセスします。

GitLabインスタンスでSSLが有効になっており、同じFQDNを使用している場合、HSTSの影響により、GitLabと同じブラウザでPrometheusにアクセスできない可能性があります。アクセスできるようにするためのGitLabテストプロジェクトが進行中ですが、それが利用可能になるまでの間は、別のFQDNを使用する、サーバーIPを使用する、Prometheus用に別のブラウザを使用する、HSTSをリセットする、NGINXでプロキシ処理を行うといった回避策があります。

Prometheusによって収集されたパフォーマンスデータは、Prometheusコンソールで直接表示するか、互換性のあるダッシュボードツールで表示できます。Prometheusインターフェースには、収集されたデータを操作するための柔軟なクエリ言語が用意されており、出力を視覚化できます。フル機能を備えたダッシュボードとしてGrafanaを使用でき、Prometheus向けの公式サポートもあります。

Prometheusクエリのサンプル

以下は、使用できるPrometheusクエリのサンプルです。

これらのサンプルはあくまでも一例です。すべてのセットアップで機能するとは限りません。さらに調整が必要になる場合があります。

% CPU utilization（CPU使用率）: 1 - avg without (mode,cpu) (rate(node_cpu_seconds_total{mode="idle"}[5m]))
% Memory available（使用可能なメモリの割合）: ((node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) or ((node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes) / node_memory_MemTotal_bytes)) * 100
Data transmitted（送信データ量）: rate(node_network_transmit_bytes_total{device!="lo"}[5m])
Data received（受信データ量）: rate(node_network_receive_bytes_total{device!="lo"}[5m])
Disk read IOPS（ディスクの読み取りIOPS）: sum by (instance) (rate(node_disk_reads_completed_total[1m]))
Disk write IOPS（ディスクの書き込みIOPS）: sum by (instance) (rate(node_disk_writes_completed_total[1m]))
RPS via GitLab transaction count（GitLabのトランザクション数に基づくRPS）: sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController'}[1m])) by (controller, action)

GrafanaデータソースとしてのPrometheus

Grafanaでは、Prometheusパフォーマンスメトリクスをデータソースとしてインポートし、そのメトリクスをグラフやダッシュボードとして表示できます。これはメトリクスの視覚化に役立ちます。

単一サーバーのGitLabセットアップにPrometheusダッシュボードを追加するには、次の手順に従います:

Grafanaで新しいデータソースを作成します。
種類で、Prometheusを選択します。
データソースに名前を付けます（例: GitLab）。
Prometheus server URL（PrometheusサーバーのURL）に、Prometheusのリッスンアドレスを入力します。
HTTP method（HTTPメソッド）をGETに設定します。
設定を保存してテストし、正しく動作することを確認します。

GitLabメトリクス

GitLabは独自の内部サービスメトリクスを監視し、/-/metricsエンドポイントで利用できるようにします。他のexporterとは異なり、このエンドポイントはユーザートラフィックと同じURLおよびポートで提供されるため、認証が必要です。

詳細については、GitLabメトリクスを参照してください。

バンドルされたソフトウェアメトリクス

LinuxパッケージにバンドルされているGitLabの依存関係の多くは、Prometheusメトリクスをエクスポートするように事前に設定されています。

ノードExporter

ノードexporterを使用すると、メモリ、ディスク、CPU使用率など、さまざまなマシンリソースを測定できます。

詳細については、ノードexporterを参照してください。

Web exporter

Web exporterは、エンドユーザーとPrometheusのトラフィックを2つの異なるアプリケーションに分離することで、パフォーマンスと可用性を向上させる専用のメトリクスサーバーです。

詳細については、Web exporterを参照してください。

Redis exporter

Redis exporterを使用すると、さまざまなRedisメトリクスを測定できます。

詳細については、Redis exporterを参照してください。

PostgreSQL exporter

PostgreSQL exporterを使用すると、さまざまなPostgreSQLメトリクスを測定できます。

詳細については、PostgreSQL exporterを参照してください。

PgBouncer exporter

PgBouncer exporterを使用すると、さまざまなPgBouncerメトリクスを測定できます。

詳細については、PgBouncer exporterを参照してください。

レジストリexporter

レジストリexporterを使用すると、さまざまなレジストリメトリクスを測定できます。

詳細については、レジストリexporterを参照してください。

GitLab exporter

GitLab exporterを使用すると、RedisやデータベースからプルされたさまざまなGitLabメトリクスを測定できます。

詳細については、GitLab exporterを参照してください。

トラブルシューティング

`/var/opt/gitlab/prometheus`がディスク容量を過剰に消費する

Prometheusモニタリングをnot（使用していない場合）:

Prometheusを無効にします。
/var/opt/gitlab/prometheus配下のデータを削除します。

Prometheusモニタリングを使用している場合:

Prometheusを停止します（実行中にデータを削除すると、データが破損する可能性があります）:
```
gitlab-ctl stop prometheus
```
/var/opt/gitlab/prometheus/data配下のデータを削除します。
サービスを再起動します:
```
gitlab-ctl start prometheus
```
サービスが起動して実行中であることを確認します:
```
gitlab-ctl status prometheus
```
オプション。ストレージ保持サイズを設定します。

モニタリングノードがデータを受信していない

モニタリングノードがデータを受信していない場合は、次のようにexporterがデータをキャプチャしていることを確認してください:

curl "http[s]://localhost:<EXPORTER LISTENING PORT>/metrics"

または

curl "http[s]://localhost:<EXPORTER LISTENING PORT>/-/metrics"