Troubleshooting a reference architecture set up

原文：https://docs.gitlab.com/ee/administration/reference_architectures/troubleshooting.html

Troubleshooting a reference architecture set up

如果您遵循一种参考体系结构，则此页面可作为故障排除文档.

Troubleshooting object storage

S3 API compatibility issues

并非所有 S3 提供程序都与 GitLab 使用的 Fog 库完全兼容 . 症状包括：

  1. 411 Length Required

GitLab Pages requires NFS

如果您打算使用GitLab 页面 ，则当前需要NFS . 有工作正在进行中去除这种依赖性. 将来，GitLab 页面可能会使用对象存储 .

对磁盘存储的依赖性还阻止了使用GitLab Helm 图表部署 Pages.

Incremental logging is required for CI to use object storage

如果将 GitLab 配置为将对象存储用于 CI 日志和工件，则还必须启用增量日志记录 .

Proxy Download

对象存储的许多使用情况都允许将客户端流量重定向到对象存储后端，例如当 Git 客户端通过 LFS 请求大文件时或在下载 CI 工件和日志时.

当文件存储在本地块存储或 NFS 上时，GitLab 必须充当代理. 对于对象存储，GitLab 的默认行为是重定向到对象存储设备，而不是代理请求.

proxy_download设置控制此行为：默认设置通常为false . 在每个用例的文档中对此进行验证. 将其设置为true可使 GitLab 代理文件而不是重定向.

当不代理文件时，GitLab 将返回HTTP 302 重定向，该重定向带有预先签名的有时间限制的对象存储 URL . 这可能会导致以下一些问题：

  • 如果 GitLab 使用非安全的 HTTP 访问对象存储，则客户端可能会生成https->http降级错误，并拒绝处理重定向. 解决方案是让 GitLab 使用 HTTPS. 例如，LFS 将产生此错误：

    1.  LFS: lfsapi/client: refusing insecure redirect, https->http

  • 客户端将需要信任颁发对象存储证书的证书颁发机构，或者可能返回常见的 TLS 错误，例如：

    1.  x509: certificate signed by unknown authority

  • 客户端将需要网络访问对象存储. 如果没有此访问权限，则可能导致的错误包括：

    1.  Received status code 403 from server: Forbidden

ETag mismatch

Using the default GitLab settings, some object storage back-ends such as MinIO and Alibaba might generate ETag mismatch errors.

使用 GitLab 直接上传时， MinIO的解决方法是在服务器上使用--compat参数.

我们正在致力于 GitLab 组件 Workhorse 的修复，同时，也正在尝试一种解决方法，以允许禁用 ETag 验证 .

Troubleshooting Redis

如果应用程序节点无法连接到 Redis 节点，请检查您的防火墙规则，并确保 Redis 可以接受端口6379下的 TCP 连接.

Troubleshooting Gitaly

Checking versions when using standalone Gitaly nodes

使用独立的 Gitaly 节点时，必须确保它们与 GitLab 的版本相同，以确保完全兼容. 检查您的 GitLab 实例上的管理区域> Gitaly 服务器 ，并确认所有 Gitaly 服务器都是Up to date .

Gitaly standalone software versions diagram

gitaly-debug

gitaly-debug命令提供用于” Gitaly”和” Git”性能的”生产调试”工具. 它旨在帮助生产工程师和支持工程师调查 Gitaly 性能问题.

如果您使用的是 GitLab 11.6 或更高版本，则此工具应已安装在您的 GitLab / Gitaly 服务器上，位于/opt/gitlab/embedded/bin/gitaly-debug . 如果要研究旧版本的 GitLab，可以离线编译此工具，然后将可执行文件复制到服务器：

  1. git clone https://gitlab.com/gitlab-org/gitaly.git
  2. cd cmd/gitaly-debug
  3. GOOS=linux GOARCH=amd64 go build -o gitaly-debug

要查看gitaly-debug的帮助页面以gitaly-debug受支持的子命令列表，请运行：

  1. gitaly-debug -h

Commits, pushes, and clones return a 401

  1. remote: GitLab: 401 Unauthorized

您将需要将gitlab-secrets.json文件与 GitLab 应用程序节点同步.

Client side gRPC logs

Gitaly 使用gRPC RPC 框架. Ruby gRPC 客户端具有自己的日志文件，当您看到 Gitaly 错误时，该文件可能包含有用的信息. 您可以使用GRPC_LOG_LEVEL环境变量控制 gRPC 客户端的日志级别. 默认级别为WARN .

您可以使用以下命令运行 gRPC 跟踪：

  1. sudo GRPC_TRACE=all GRPC_VERBOSITY=DEBUG gitlab-rake gitlab:gitaly:check

Observing gitaly-ruby traffic

gitaly-ruby是gitaly-ruby的内部实现细节，因此，对gitaly-ruby流程内部发生的情况gitaly-ruby .

如果已设置 Prometheus 来抓取 Gitaly 进程，则可以通过查询grpc_client_handled_total来grpc_client_handled_total gitaly-ruby各个 RPC 的请求率和错误代码. 严格来说，此度量标准并未区分gitaly-ruby和其他 RPC，但实际上（自 GitLab 11.9 起），Gitaly 本身进行的所有 gRPC 调用都是从 Gitaly 主过程到其gitaly-ruby边车之一的内部调用.

假设您的grpc_client_handled_total计数器仅观察到 Gitaly，以下查询将显示 RPC 在内部（最有可能）实现为对gitaly-ruby调用：

  1. sum(rate(grpc_client_handled_total[5m])) by (grpc_method) > 0

Repository changes fail with a 401 Unauthorized error

If you’re running Gitaly on its own server and notice that users can successfully clone and fetch repositories (via both SSH and HTTPS), but can’t push to them or make changes to the repository in the web UI without getting a 401 Unauthorized message, then it’s possible Gitaly is failing to authenticate with the other nodes due to having the wrong secrets file.

确认以下所有内容均正确：

  • 当任何用户向该 Gitaly 节点上的任何存储库执行git push ，它都会失败，并显示以下错误（请注意401 Unauthorized ）：

    1. remote: GitLab: 401 Unauthorized
    2. To <REMOTE_URL>
    3. ! [remote rejected] branch-name -> branch-name (pre-receive hook declined)
    4. error: failed to push some refs to '<REMOTE_URL>'

  • 当任何用户使用 GitLab UI 从存储库添加或修改文件时，该文件都会立即失败，并显示红色401 Unauthorized横幅.

  • 创建一个新项目并使用 README 对其进行初始化会成功创建该项目，但不会创建 README.

  • 将日志拖到应用程序节点上并重现错误时，到达/api/v4/internal/allowed端点时会出现401错误：

    1. # api_json.log
    2. {
    3.   "time": "2019-07-18T00:30:14.967Z",
    4.   "severity": "INFO",
    5.   "duration": 0.57,
    6.   "db": 0,
    7.   "view": 0.57,
    8.   "status": 401,
    9.   "method": "POST",
    10.   "path": "\/api\/v4\/internal\/allowed",
    11.   "params": [
    12.     {
    13.       "key": "action",
    14.       "value": "git-receive-pack"
    15.     },
    16.     {
    17.       "key": "changes",
    18.       "value": "REDACTED"
    19.     },
    20.     {
    21.       "key": "gl_repository",
    22.       "value": "REDACTED"
    23.     },
    24.     {
    25.       "key": "project",
    26.       "value": "\/path\/to\/project.git"
    27.     },
    28.     {
    29.       "key": "protocol",
    30.       "value": "web"
    31.     },
    32.     {
    33.       "key": "env",
    34.       "value": "{\"GIT_ALTERNATE_OBJECT_DIRECTORIES\":[],\"GIT_ALTERNATE_OBJECT_DIRECTORIES_RELATIVE\":[],\"GIT_OBJECT_DIRECTORY\":null,\"GIT_OBJECT_DIRECTORY_RELATIVE\":null}"
    35.     },
    36.     {
    37.       "key": "user_id",
    38.       "value": "2"
    39.     },
    40.     {
    41.       "key": "secret_token",
    42.       "value": "[FILTERED]"
    43.     }
    44.   ],
    45.   "host": "gitlab.example.com",
    46.   "ip": "REDACTED",
    47.   "ua": "Ruby",
    48.   "route": "\/api\/:version\/internal\/allowed",
    49.   "queue_duration": 4.24,
    50.   "gitaly_calls": 0,
    51.   "gitaly_duration": 0,
    52.   "correlation_id": "XPUZqTukaP3"
    53. }
    55. # nginx_access.log
    56. [IP] - - [18/Jul/2019:00:30:14 +0000] "POST /api/v4/internal/allowed HTTP/1.1" 401 30 "" "Ruby"

要解决此问题，请确认 Gitaly 节点上的 gitlab gitlab-secrets.json文件与所有其他节点上的 gitlab gitlab-secrets.json文件匹配. 如果不匹配，请更新 Gitaly 节点上的 secrets 文件以使其与其他文件匹配，然后重新配置该节点 .

Command line tools cannot connect to Gitaly

如果使用命令行（CLI）工具连接到 Gitaly 节点时遇到问题，并且某些操作导致出现14: Connect Failed错误消息，则表明 gRPC 无法到达您的 Gitaly 节点.

确认您可以通过 TCP 到达 Gitaly：

  1. sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT]

如果 TCP 连接失败，请检查您的网络设置和防火墙规则. 如果 TCP 连接成功，则您的网络和防火墙规则正确.

如果您在命令行环境（例如 Bash）中使用代理服务器，则这些代理服务器可能会干扰您的 gRPC 通信.

如果使用 Bash 或兼容的命令行环境，请运行以下命令来确定是否配置了代理服务器：

  1. echo $http_proxy
  2. echo $https_proxy

如果这些变量中的任何一个都有值，则您的 Gitaly CLI 连接可能正在通过无法连接到 Gitaly 的代理进行路由.

要删除代理设置，请运行以下命令（取决于哪些变量具有值）：

  1. unset http_proxy
  2. unset https_proxy

Gitaly not listening on new address after reconfiguring

当更新gitaly['listen_addr']或gitaly['prometheus_listen_addr']值时，Gitaly 可能会在sudo gitlab-ctl reconfigure后继续侦听旧地址.

发生这种情况时，执行sudo gitlab-ctl restart将解决此问题. 解决此问题后，将不再需要此操作 .

Permission denied errors appearing in Gitaly logs when accessing repositories from a standalone Gitaly node

如果即使文件许可权正确也发生此错误，则 Gitaly 节点很可能正在发生时钟漂移 .

请确保 GitLab 和 Gitaly 节点已同步，并在可能的情况下使用 NTP 时间服务器使其保持同步.

Troubleshooting the GitLab Rails application

  • mount: wrong fs type, bad option, bad superblock on

您尚未安装必要的 NFS 客户端实用程序. 请参阅上面的步骤 1.

  • mount: mount point /var/opt/gitlab/... does not exist

NFS 服务器上不存在此特定目录. 确保共享已导出并且存在于 NFS 服务器上，然后尝试重新安装.

Troubleshooting Monitoring

如果监视节点未接收到任何数据，请检查导出器是否正在捕获数据.

  1. curl http[s]://localhost:<EXPORTER LISTENING PORT>/metric

or

  1. curl http[s]://localhost:<EXPORTER LISTENING PORT>/-/metric