GitalyとGitalyクラスターのモニタリング

利用可能なログとPrometheusメトリクスを使用して、GitalyとGitaly Cluster（Praefect）を監視することができます。

メトリクス定義が利用できます：

  • Gitaly用に設定されたPrometheus/metrics エンドポイントから直接。
  • Prometheusに対して設定されたGrafanaインスタンスでGrafana Exploreを使用。

Gitalyレート制限の監視

Gitalyは、リクエストを制限するように設定することができます：

  • リクエストの同時性
  • レート制限。

Gitaly リクエスト制限をgitaly_requests_dropped_total Prometheus メトリクスで監視します。このメトリクスはリクエスト制限のために落とされたリクエストの 総カウントを提供します。reason ラベルはリクエストが落とされた理由を示します：

  • rateレート制限のため。
  • max_size同時実行キューのサイズに達したためです。
  • max_timeリクエストが Gitaly で設定されたキューの最大待ち時間を超えたためです。

Gitalyの同時実行制限の監視

GitalyのログとPrometheusを使って、同時実行キューに入ったリクエストの特定の挙動を観察することができます。

Gitaly のログでは、pack-objects の同時実行制限に関連するログを確認できます：

ログ・フィールド説明
limit.concurrency_queue_length進行中の呼び出しの RPC タイプに固有のキューの現在の長さを示します。これは、同時実行の制限のために処理されるのを待っているリクエストの数についてのインサイトを提供します。
limit.concurrency_queue_ms同時 RPC の制限のためにリクエストがキューで待機している時間をミリ秒単位で表します。このフィールドは、同時実行数制限がリクエスト処理時間に与える影響を理解するのに役立ちます。
limit.concurrency_dropped制限に達したためにリクエストが取り除かれた場合、このフィールドはその理由を 指定します。max_time (リクエストがキューで許容される最大時間よりも長く 待たされた) あるいはmax_size (キューが最大サイズに達した) のいずれかです。
limit.limiting_key制限に使われるキーを指定します。
limit.limiting_type制限されるプロセスのタイプを指定します。このコンテキストでは、per-rpc です。これは、RPC 毎に同時実行制限が適用されることを示します。

使用例：

{
  "limit .concurrency_queue_length": 1,
  "limit .concurrency_queue_ms": 0,
  "limit.limiting_key": "@hashed/79/02/7902699be42c8a8e46fbbb450172651786b22c56a189f7625a6da49081b2451.git",
  "limit.limiting_type": "per-rpc"
}

Prometheusで、以下のメトリクスを探してください：

  • gitaly_concurrency_limiting_in_progress は、処理中の同時リクエスト数を示します。
  • gitaly_concurrency_limiting_queued は、指定されたリポジトリに対する RPC リクエストのうち、同時実行数の制限に達したために待機しているリクエストの数を示します。
  • gitaly_concurrency_limiting_acquiring_seconds は、同時実行数制限のためにリクエストが処理されるまでに待たなければならない時間を示します。

Gitalyパックオブジェクトの同時実行制限を監視します。

GitalyのログとPrometheusを使って、pack-objectsの同時実行制限の具体的な挙動を観察することができます。

Gitaly のログでは、pack-objects の同時実行制限に関連するログを確認できます：

ログ・フィールド説明
limit.concurrency_queue_lengthpack-objects プロセスのキューの現在の長さ。同時処理数の制限に達したために処理待ちになっている リクエストの数を示します。
limit.concurrency_queue_msリクエストがキューで待機している時間 (ミリ秒単位)。同時処理数の制限のために、リクエストがどれだけ待たされたかを示します。
limit.limiting_key送信者のリモート IP。
limit.limiting_type制限されるプロセスの種類。この場合、pack-objects 。

設定例

{
  "limit .concurrency_queue_length": 1,
  "limit .concurrency_queue_ms": 0,
  "limit.limiting_key": "1.2.3.4",
  "limit.limiting_type": "pack-objects"
}

Prometheusで、以下のメトリクスを探してください：

  • gitaly_pack_objects_in_progress は、同時に処理されているパック・オブジェクト・プロセスの数を示します。
  • gitaly_pack_objects_queued は、同時実行数の上限に達しているために待機している pack オブジェクトプロセスへのリクエスト数を示します。
  • gitaly_pack_objects_acquiring_seconds は、同時実行数制限のためにパックオブジェクトプロセスへの リクエストが処理されるまでの待ち時間を示します。

Gitaly cgroupsの監視

Prometheusを使用して、コントロールグループ（cgroups）の状態を観察することができます：

  • gitaly_cgroups_reclaim_attempts_totalこれは、メモリ再要求の合計回数を示すものです。この回数はサーバーが再起動されるたびにリセットされます。
  • gitaly_cgroups_cpu_usagecgroup ごとの CPU 使用率を測定するゲージです。
  • gitaly_cgroup_procs_totalGitalyがcgroupsの制御下で生成したプロセスの総数を測定するゲージです。
  • gitaly_cgroup_cpu_cfs_periods_total nr_periodsの値を表すカウンタです。
  • gitaly_cgroup_cpu_cfs_throttled_periods_totalの値に対するカウンタnr_throttled.
  • gitaly_cgroup_cpu_cfs_throttled_seconds_total throttled_time の値を秒単位で表すカウンタ。

pack-objects キャッシュ

pack-objects キャッシュ メトリクスは以下のとおりです：

  • gitaly_pack_objects_cache_enabledキャッシュが有効なときに1 に設定されるゲージ。使用可能なラベル ：dir およびmax_age。
  • gitaly_pack_objects_cache_lookups_totalキャッシュ検索用のカウンタ。利用可能なラベル:result.
  • gitaly_pack_objects_generated_bytes_totalキャッシュに書き込まれたバイト数のカウンタ。
  • gitaly_pack_objects_served_bytes_totalキャッシュから読み出されたバイト数を表すカウンタ。
  • gitaly_streamcache_filestore_disk_usage_bytesキャッシュファイルの合計サイズ。利用可能なラベル:dir.
  • gitaly_streamcache_index_entriesキャッシュのエントリ数。利用可能なラベル:dir.

これらのメトリクスのいくつかは、Gitalyのstreamcache 内部ライブラリパッケージによって生成されるため、gitaly_streamcache で始まります。

使用例：

gitaly_pack_objects_cache_enabled{dir="/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache",max_age="300"} 1
gitaly_pack_objects_cache_lookups_total{result="hit"} 2
gitaly_pack_objects_cache_lookups_total{result="miss"} 1
gitaly_pack_objects_generated_bytes_total 2.618649e+07
gitaly_pack_objects_served_bytes_total 7.855947e+07
gitaly_streamcache_filestore_disk_usage_bytes{dir="/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache"} 2.6200152e+07
gitaly_streamcache_filestore_removed_total{dir="/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache"} 1
gitaly_streamcache_index_entries{dir="/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache"} 1

クエリ

Gitalyを監視するためのクエリを以下に示します：

  • 以下の Prometheus クエリを使用して、Gitaly が本番環境でどのような接続を提供しているかを監視します：

     sum(rate(gitaly_connections_total[5m])) by (type)

  • 次の Prometheus クエリを使用して、GitLab インストールの認証動作を監視します：

     sum(rate(gitaly_authentications_total[5m])) by (enforced, status)

    認証が正しく設定されていてライブトラフィックがあるシステムでは、このように表示されます：

     {enforced="true",status="ok"}  4424.985419441742

    レートが0である他の数字もあるかもしれませんが、0でない数字にだけ注意してください。

    唯一の非ゼロ番号はenforced="true",status="ok" であるべきです。他のゼロでない数字がある場合は、設定が間違っています。

    status="ok" の数字は、現在のリクエストレートを反映します。上の例では、Gitalyは1秒間に約4000リクエストを処理しています。

  • 次の Prometheus クエリを使って、本番環境で使われているGit プロトコルのバージョンを調べてみましょう：

     sum(rate(gitaly_git_protocol_requests_total[1m])) by (grpc_method,git_protocol,grpc_service)

Gitaly クラスタの監視

Gitaly Cluster (Praefect)を監視するには、これらのPrometheusメトリクスを使用できます。2つの別々のメトリクスエンドポイントが用意されており、そこからメトリクスをスクレイピングすることができます：

  • デフォルトの/metrics エンドポイント。
  • /db_metricsこのエンドポイントには、データベース・クエリを必要とするメトリクスが含まれます。

デフォルトの Prometheus/metrics エンドポイント

以下のメトリクスは、/metrics エンドポイントから利用できます：

  • gitaly_praefect_read_distributionリードのディストリビューションを追跡するカウンター。2つのラベルがあります：

    • virtual_storage.
    • storage.

    これらは、このPraefectのインスタンスで定義された設定を反映します。

  • gitaly_praefect_replication_latency_bucketレプリケーションジョブが開始してからレプリケーションが完了するまでの時間を測定するヒストグラムです。GitLab 12.10以降で利用可能です。
  • gitaly_praefect_replication_delay_bucketレプリケーションジョブが作成されてから開始されるまでの時間を測定するヒストグラム。GitLab 12.10以降で利用可能。
  • gitaly_praefect_connections_totalPraefectへの総接続数。GitLab 14.7で導入。
  • gitaly_praefect_method_typesノードごとのアクセサーとミューテーターのRPC数。

強力な一貫性を監視するには、以下の Prometheus メトリクスを使用できます：

  • gitaly_praefect_transactions_total作成され、投票されたトランザクションの数。
  • gitaly_praefect_subtransactions_per_transaction_total1つのトランザクションに対してノードが投票した回数。1つのトランザクションで複数の参照が更新される場合、これは複数回発生する可能性があります。
  • gitaly_praefect_voters_per_transaction_totalトランザクションに参加しているGitalyノードの数。
  • gitaly_praefect_transactions_delay_secondsトランザクションがコミットされるのを待つことによって生じるサーバー側の遅延。
  • gitaly_hook_transaction_voting_delay_secondsトランザクションのコミット待ちによって発生するクライアント側の遅延。

リポジトリ検証を監視するには、以下の Prometheus メトリクスを使用します：

  • gitaly_praefect_verification_jobs_dequeued_totalワーカーによってピックアップされた検証ジョブの数。
  • gitaly_praefect_verification_jobs_completed_total作業員が完了した検証ジョブの数。result ラベルは、ジョブの最終結果を示します：
    • valid はストレージ上に存在するレプリカの予想値を示します。
    • invalid は存在すると予想されたレプリカがストレージ上に存在しなかったことを示します。
    • error はジョブが失敗し、再試行する必要があることを示します。
  • gitaly_praefect_stale_verification_leases_released_totalは、古い検証リースのリリース数です。

Praefectログを監視することもできます。

データベースメトリクス/db_metrics エンドポイント

GitLab 14.5 で導入されました。

以下のメトリクスは、/db_metrics エンドポイントから利用できます：

  • gitaly_praefect_unavailable_repositories健全で最新のレプリカがないリポジトリの数。
  • gitaly_praefect_replication_queue_depthレプリケーション・キュー内のジョブ数。
  • gitaly_praefect_verification_queue_depth検証待ちのレプリカの総数。
  • gitaly_praefect_read_only_repositories仮想ストレージ内の読み取り専用モードのリポジトリ数。
    • このメトリクスはGitLab 15.4で削除されました。