监控 Gitaly

使用可用的日志和 Prometheus 指标 来监控 Gitaly。

指标定义可通过以下方式获取：

• 直接从为 Gitaly 配置的 Prometheus /metrics 端点获取。
• 在针对 Prometheus 配置的 Grafana 实例上使用 Grafana Explore。

监控 Gitaly 速率限制（已移除）

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 日志中，当当前限制被调整时，您可以识别与自适应并发限制相关的日志。 您可以过滤日志内容（msg）中的"Multiplicative decrease"和"Additive increase"消息。

这些调试日志仅在调试严重性级别可用，可能很冗长，但它们提供了对自适应限制调整的详细洞察。

示例日志：

{
  "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 在 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 服务器端备份

使用以下指标监控服务器端仓库备份：

• 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 每秒处理约 4000 个请求。

• 使用以下 Prometheus 查询来观察生产环境中使用的 Git 协议版本：

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