- 监控 Gitaly 速率限制(已弃用)
- 监控 Gitaly 并发限制
- 监控 Gitaly pack-objects 并发限制
- 监控 Gitaly 自适应并发限制
- 监控 Gitaly cgroups
pack-objects
缓存- 监控 Gitaly 服务器端备份
- 查询
- 监控 Gitaly Cluster
你可以使用可用的日志和 Prometheus metrics 来监控 Gitaly 和 Gitaly 集群(Praefect)。
指标定义可用:
- 直接从为 Gitaly 配置的 Prometheus
/metrics
端点获取。 - 使用 Grafana Explore 在针对 Prometheus 配置的 Grafana 实例中使用。
监控 Gitaly 速率限制(已弃用)
{{< alert type=”warning” >}}
此功能在极狐 GitLab 17.7 中已弃用,计划在 18.0 中移除。请使用并发限制代替。
{{< /alert >}}
Gitaly 可以配置为根据以下内容限制请求:
- 请求的并发性。
- 速率限制。
使用 gitaly_requests_dropped_total
Prometheus 指标监控 Gitaly 请求限制。此指标提供由于请求限制而丢弃的请求总数。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 pack-objects 并发限制
你可以使用 Gitaly 日志和 Prometheus 观察 pack-objects limiting 的特定行为。
在 Gitaly 日志 中,你可以识别与 pack-objects 并发限制相关的日志条目,例如:
日志字段 | 描述 |
---|---|
limit.concurrency_queue_length |
pack-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
指示正在处理的并发 pack-objects 进程数量。 -
gitaly_pack_objects_queued
指示由于达到并发限制,pack-objects 进程请求等待的数量。 -
gitaly_pack_objects_acquiring_seconds
指示请求 pack-object 进程由于并发限制而必须等待的时间。
监控 Gitaly 自适应并发限制
{{< history >}}
- 引入于极狐 GitLab 16.6。
{{< /history >}}
你可以使用 Gitaly 日志和 Prometheus 观察 adaptive concurrency limiting 的特定行为。
在 Gitaly 日志 中,你可以识别与自适应并发限制相关的日志,当当前限制被调整时。你可以过滤日志内容 (msg
) 中的 “Multiplicative decrease” 和 “Additive increase” 消息。
日志字段 | 描述 |
---|---|
limit |
正在调整的限制名称。 |
previous_limit |
调整前的限制。 |
new_limit |
调整后的限制。 |
watcher |
决定节点处于压力下的资源监视器。例如:CgroupCpu 或 CgroupMemory 。 |
reason |
限制调整的原因。 |
stats.* |
调整决策背后的统计数据。用于调试目的。 |
示例日志:
{
"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_current_limit
自适应并发限制的当前限制值。 -
gitaly_concurrency_limiting_watcher_errors_total
表示在获取资源指标时监视器错误的总数。 -
gitaly_concurrency_limiting_backoff_events_total
表示由于资源压力调整限制时的回退事件总数。
监控 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
cache 指标可用:
-
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 服务器端备份
{{< history >}}
- 引入于极狐 GitLab 16.7。
{{< /history >}}
使用以下指标监控 服务器端存储库备份:
-
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)
监控 Gitaly Cluster
要监控 Gitaly 集群(Praefect),你可以使用这些 Prometheus 指标。可以从两个单独的指标端点获取指标:
- 默认的
/metrics
端点。 -
/db_metrics
,包含需要数据库查询的指标。
默认 Prometheus /metrics
端点
以下指标可从 /metrics
端点获取:
-
gitaly_praefect_read_distribution
,一个计数器,用于跟踪 reads 的分布。它有两个标签:-
virtual_storage
。 -
storage
。
它们反映了为此 Praefect 实例定义的配置。
-
-
gitaly_praefect_replication_latency_bucket
,一个直方图,测量复制作业开始后复制完成所需的时间。 -
gitaly_praefect_replication_delay_bucket
,一个直方图,测量从复制作业创建到开始之间的时间。 -
gitaly_praefect_connections_total
,到 Praefect 的连接总数。 -
gitaly_praefect_method_types
,每个节点的访问者和修改者 RPC 的计数。
要监控 强一致性,你可以使用以下 Prometheus 指标:
-
gitaly_praefect_transactions_total
,创建和投票的事务数量。 -
gitaly_praefect_subtransactions_per_transaction_total
,为单个事务节点投票的次数。如果在单个事务中更新了多个引用,这可能会发生多次。 -
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 logs。
数据库指标 /db_metrics
端点
以下指标可从 /db_metrics
端点获取:
-
gitaly_praefect_unavailable_repositories
,没有健康的最新副本的存储库数量。 -
gitaly_praefect_replication_queue_depth
,复制队列中的作业数量。 -
gitaly_praefect_verification_queue_depth
,待验证的副本总数。 -
gitaly_praefect_read_only_repositories
,虚拟存储中处于只读模式的存储库数量。- 此指标在极狐 GitLab 15.4 中已移除。