Gitalyのモニタリング

Gitalyをモニタリングするには、利用可能なログとPrometheusメトリクスを使用します。

メトリクスの定義は以下で可能です:

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

Gitalyは、（アダプティブまたは非アダプティブ）リクエストの並行処理に基づいてリクエストを制限するように設定できます。

Gitalyの並行処理制限をモニタリング

GitalyのログとPrometheusを使用して、並行処理待ちリクエストの特定の動作を観察できます。

Gitalyログでは、次のようなエントリを使用して、pack-objectsの並行処理制限に関連するログを識別できます:

例:

{
  "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_requests_dropped_totalは、リクエスト制限のためにドロップされたリクエストの合計数を提供します。reasonラベルは、リクエストがドロップされた理由を示します:
  • max_size。これは、並行処理キューサイズに達したためです。
  • max_time。これは、Gitalyで設定されているように、リクエストが最大キュー待機時間を超えたためです。

Gitalyのpack-objects並行処理制限をモニタリング

GitalyログとPrometheusを使用して、pack-objects制限の特定の動作を観察できます。

Gitalyログでは、次のようなエントリを使用して、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は、いくつのpack-objects処理が並行処理で処理されているかを示します。
• gitaly_pack_objects_queuedは、並行処理制限に達したために、いくつのpack-objects処理に対するリクエストが待機しているかを示します。
• gitaly_pack_objects_acquiring_secondsは、pack-object処理に対するリクエストが処理される前に並行処理制限のためにどれくらいの時間待機する必要があるかを示します。

Gitalyのアダプティブ並行処理制限をモニタリング

GitalyログとPrometheusを使用して、アダプティブ並行処理制限の特定の動作を観察できます。

アダプティブ並行処理制限は静的な並行処理制限の拡張であるため、静的な並行処理制限に適用可能なすべてのメトリクスとログは、アダプティブ制限をモニタリングする場合にも関連します。さらに、アダプティブ制限は、制限の動的な調整をモニタリングするのに役立ついくつかの特定のメトリクスを導入します。

アダプティブ制限ログ

Gitalyログでは、現在の制限が調整されたときに、アダプティブ並行処理制限に関連するログを識別できます。「Multiplicative decrease」メッセージと「Additive increase」メッセージについて、ログの内容（msg）をフィルタリングできます。

これらのデバッグログはデバッグ重大度レベルでのみ使用可能であり、詳細になる可能性がありますが、アダプティブ制限の調整に関する詳細なインサイトを提供します。

ログの例:

{
  "msg": "Multiplicative decrease",
  "limit": "pack-objects",
  "new_limit": 14,
  "previous_limit": 29,
  "reason": "cgroup CPU throttled too much",
  "watcher": "CgroupCpu",
  "stats.time_diff": 15.0,
  "stats.throttled_duration": 13.0,
  "stat.sthrottled_threshold": 0.5
}

アダプティブ制限メトリクス

Prometheusで、次のメトリクスを探します:

静的制限とアダプティブ制限の両方に適用可能な一般的な並行処理制限メトリクス:

• gitaly_concurrency_limiting_in_progress - 処理されているリクエストの数。
• gitaly_concurrency_limiting_queued - 並行処理制限のためにキューで待機しているリクエストの数。
• gitaly_concurrency_limiting_acquiring_seconds - 処理が開始される前に、並行処理制限のために待機しているリクエストによって費やされた時間。

アダプティブ並行処理制限固有のメトリクス:

• gitaly_concurrency_limiting_current_limit - 各RPCタイプのアダプティブ並行処理制限の現在の制限値を示すゲージ。このメトリクスには、アダプティブ制限のみが含まれています。
• gitaly_concurrency_limiting_backoff_events_total - リソースの負荷により制限が軽減される時期と理由を表す、バックオフイベントの総数を示すカウンター。
• gitaly_concurrency_limiting_watcher_errors_total - Gitalyがリソースデータを取得できなかった場合に発生するエラーを追跡するカウンター。これにより、Gitalyが現在のリソース状況を評価する能力に影響を与える可能性があります。

アダプティブ制限に関する問題を調査する場合は、これらのメトリクスを一般的な並行処理制限メトリクスおよびログと関連付けて、システム動作の全体像を把握します。

Gitaly cgroupsをモニタリング

Prometheusを使用して、コントロールグループ（cgroups）のステータスを観察できます:

• gitaly_cgroups_reclaim_attempts_total。これは、メモリー再利用が試行された合計回数を示すゲージです。この数値は、サーバーが再起動されるたびにリセットされます。
• gitaly_cgroups_cpu_usage。これは、cgroupごとのCPU使用率を測定するゲージです。
• gitaly_cgroup_procs_total。これは、Gitalyがcgroupの制御下で起動した処理の合計数を測定するゲージです。
• 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サーバーサイドバックアップをモニタリング

次のメトリクスを使用してサーバー側のリポジトリバックアップをモニタリングします:

• gitaly_backup_latency_seconds。これは、サーバー側のバックアップの各フェーズにかかる時間（秒単位）を測定するヒストグラムです。さまざまな段階はrefs、bundle、およびcustom_hooksであり、各ステージで処理されるデータのタイプを表します。
• gitaly_backup_bundle_bytes。これは、GitalyバックアップサービスによってオブジェクトストレージにプッシュされるGitバンドルのアップロードデータレートを測定するヒストグラムです。

これらのメトリクスは、GitLabインスタンスに大きなリポジトリが含まれている場合に特に役立ちます。

クエリ

以下は、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の他の数値も存在する可能性がありますが、ゼロ以外の数値にのみ注意する必要があります。

  ゼロ以外の数値のみに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)