Help us learn about your current experience with the documentation. Take the survey.

Service Ping 故障排除

在本地设置和测试 Service Ping

要在本地设置 Service Ping，您必须：

  1. 设置本地仓库。
  2. 测试本地设置。
  3. 可选。测试基于 Prometheus 的 Service Ping。

设置本地仓库

  1. 克隆并启动 GitLab。
  2. 克隆并启动 Versions Application。 确保运行 docker-compose up 来启动 PostgreSQL 和 Redis 实例。
  3. 将 GitLab 指向 Versions Application 端点，而不是默认端点：
    1. 在本地打开 service_ping/submit_service.rb 并修改 STAGING_BASE_URL。
    2. 将其设置为本地 Versions Application URL：http://localhost:3000。

测试本地设置

  1. 使用 gitlab Rails 控制台，手动触发 Service Ping：

    GitlabServicePingWorker.new.perform('triggered_from_cron' => false)

  2. 使用 versions Rails 控制台检查 Service Ping 是否成功接收、解析并存储在 Versions 数据库中：

    UsageData.last

测试基于 Prometheus 的 Service Ping

如果提交的数据包含您想要检查和验证的 从 Prometheus 查询的指标，您必须：

  • 确保本地运行着 Prometheus 服务器。
  • 确保相应的 GitLab 组件正在将指标导出到 Prometheus 服务器。

如果您不需要测试来自 Prometheus 的数据，则无需进一步操作。在没有运行中的 Prometheus 服务器的情况下，Service Ping 应该能够优雅地降级。

有三种类型的组件可能会将数据导出到 Prometheus，并包含在 Service Ping 中：

  • node_exporter：导出来自主机的节点指标。
  • gitlab-exporter：导出来自各种 GitLab 组件的进程指标。
  • 其他各种 GitLab 服务，如 Sidekiq 和 Rails 服务器，它们会导出自己的指标。

使用 Omnibus 容器测试

这是测试基于 Prometheus 的 Service Ping 的推荐方法。

要验证您的更改，请使用 CI/CD 从您的代码分支构建新的 Omnibus 镜像，下载该镜像，并运行本地容器实例：

  1. 从您的合并请求中，选择 qa 阶段，然后触发 e2e:test-on-omnibus-ee 作业。此作业会在 omnibus-gitlab-mirror 项目的下游管道 中触发 Omnibus 构建。
  2. 在下游管道中，等待 gitlab-docker 作业完成。
  3. 打开作业日志并查找包含完整版本的容器名称。它采用以下形式：registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>。
  4. 在您的本地机器上，确保您已登录到 GitLab Docker 注册表。您可以在 GitLab 容器注册表认证 中找到相关说明。
  5. 登录后，使用 docker pull registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION> 下载新镜像。
  6. 有关在 Docker 中使用和运行 Omnibus GitLab 容器的更多信息，请参阅 GitLab Docker 镜像 文档。

使用 GitLab 开发工具包测试

这是不太推荐的方法，因为在模拟真实的 GitLab 部署时会带来一些困难。

GDK 没有设置为与其他 GitLab 组件一起运行 Prometheus 服务器或 node_exporter。如果您想这样做，使用 Prometheus 监控 GDK 是一个良好的起点。

GCK 对测试基于 Prometheus 的 Service Ping 支持有限。 默认情况下，它附带一个完全配置的 Prometheus 服务，该服务设置为抓取多个组件。 但是，它有以下限制：

  • 它不运行 gitlab-exporter 实例，因此来自 Gitaly 等服务的几个 process_* 指标可能缺失。
  • 虽然它运行 node_exporter，但 docker-compose 服务模拟主机，这意味着它通常报告自己与任何其他运行中的服务不关联。在生产设置中，节点指标的报告方式并非如此，其中 node_exporter 始终作为进程与其他 GitLab 组件一起在任何给定节点上运行。对于 Service Ping，因此没有任何节点数据会与任何运行中的服务关联，因为它们似乎都在不同的主机上运行。为了缓解这个问题，GCK 中的 node_exporter 被任意"分配"给 web 服务，这意味着只有此服务的 node_* 指标出现在 Service Ping 中。

生成 Service Ping

在 Rails 控制台中生成或获取缓存的 Service Ping

在 Rails 控制台 中使用以下方法。

Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values, cached: true)

生成全新的 Service Ping

在 Rails 控制台 中使用以下方法。

这也会刷新 Admin 区域中显示的缓存的 Service Ping。

Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values)

生成包含今日使用数据的新 Service Ping

在 Rails 控制台 中使用以下方法。

require_relative 'spec/support/helpers/service_ping_helpers.rb'

ServicePingHelpers.get_current_service_ping_payload

# To get a single metric's value, provide the metric's key_path like so:
ServicePingHelpers.get_current_usage_metric_value('counts.count_total_render_duo_pro_lead_page')

生成并打印

生成 JSON 格式的 Service Ping 数据。

gitlab-rake gitlab:usage_data:generate

生成 YAML 格式的 Service Ping 数据：

gitlab-rake gitlab:usage_data:dump_sql_in_yaml

生成并发送 Service Ping

打印保存在 conversational_development_index_metrics 中的指标。

gitlab-rake gitlab:usage_data:generate_and_send