Troubleshooting a reference architecture set up · Gitlab 中文文檔

# Troubleshooting a reference architecture set up > 原文：[https://docs.gitlab.com/ee/administration/reference_architectures/troubleshooting.html](https://docs.gitlab.com/ee/administration/reference_architectures/troubleshooting.html) * [Troubleshooting object storage](#troubleshooting-object-storage) * [S3 API compatibility issues](#s3-api-compatibility-issues) * [GitLab Pages requires NFS](#gitlab-pages-requires-nfs) * [Incremental logging is required for CI to use object storage](#incremental-logging-is-required-for-ci-to-use-object-storage) * [Proxy Download](#proxy-download) * [ETag mismatch](#etag-mismatch) * [Troubleshooting Redis](#troubleshooting-redis) * [Troubleshooting Gitaly](#troubleshooting-gitaly) * [Checking versions when using standalone Gitaly nodes](#checking-versions-when-using-standalone-gitaly-nodes) * [`gitaly-debug`](#gitaly-debug) * [Commits, pushes, and clones return a 401](#commits-pushes-and-clones-return-a-401) * [Client side gRPC logs](#client-side-grpc-logs) * [Observing `gitaly-ruby` traffic](#observing-gitaly-ruby-traffic) * [Repository changes fail with a `401 Unauthorized` error](#repository-changes-fail-with-a-401-unauthorized-error) * [Command line tools cannot connect to Gitaly](#command-line-tools-cannot-connect-to-gitaly) * [Gitaly not listening on new address after reconfiguring](#gitaly-not-listening-on-new-address-after-reconfiguring) * [Permission denied errors appearing in Gitaly logs when accessing repositories from a standalone Gitaly node](#permission-denied-errors-appearing-in-gitaly-logs-when-accessing-repositories-from-a-standalone-gitaly-node) * [Troubleshooting the GitLab Rails application](#troubleshooting-the-gitlab-rails-application) * [Troubleshooting Monitoring](#troubleshooting-monitoring) # Troubleshooting a reference architecture set up[](#troubleshooting-a-reference-architecture-set-up "Permalink") 如果您遵循一種[參考體系結構，](index.html#reference-architectures)則此頁面可作為故障排除文檔. ## Troubleshooting object storage[](#troubleshooting-object-storage "Permalink") ### S3 API compatibility issues[](#s3-api-compatibility-issues "Permalink") 并非所有 S3 提供程序[都](../../raketasks/backup_restore.html#other-s3-providers)與 GitLab 使用的 Fog 庫[完全兼容](../../raketasks/backup_restore.html#other-s3-providers) . 癥狀包括： ``` 411 Length Required ``` ### GitLab Pages requires NFS[](#gitlab-pages-requires-nfs "Permalink") 如果您打算使用[GitLab 頁面](../../user/project/pages/index.html) ，則當前需要[NFS](../high_availability/nfs.html) . 有[工作正在進行中](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/196)去除這種依賴性. 將來，GitLab 頁面可能會使用[對象存儲](https://gitlab.com/gitlab-org/gitlab/-/issues/208135) . 對磁盤存儲的依賴性還阻止了使用[GitLab Helm 圖表](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/37)部署 Pages. ### Incremental logging is required for CI to use object storage[](#incremental-logging-is-required-for-ci-to-use-object-storage "Permalink") 如果將 GitLab 配置為將對象存儲用于 CI 日志和工件，則[還必須啟用增量日志記錄](../job_logs.html#new-incremental-logging-architecture) . ### Proxy Download[](#proxy-download "Permalink") 對象存儲的許多使用情況都允許將客戶端流量重定向到對象存儲后端，例如當 Git 客戶端通過 LFS 請求大文件時或在下載 CI 工件和日志時. 當文件存儲在本地塊存儲或 NFS 上時，GitLab 必須充當代理. 對于對象存儲，GitLab 的默認行為是重定向到對象存儲設備，而不是代理請求. `proxy_download`設置控制此行為：默認設置通常為`false` . 在每個用例的文檔中對此進行驗證. 將其設置為`true`可使 GitLab 代理文件而不是重定向. 當不代理文件時，GitLab 將返回[HTTP 302 重定向，該重定向帶有預先簽名的有時間限制的對象存儲 URL](https://gitlab.com/gitlab-org/gitlab/-/issues/32117#note_218532298) . 這可能會導致以下一些問題： * 如果 GitLab 使用非安全的 HTTP 訪問對象存儲，則客戶端可能會生成`https->http`降級錯誤，并拒絕處理重定向. 解決方案是讓 GitLab 使用 HTTPS. 例如，LFS 將產生此錯誤： ``` LFS: lfsapi/client: refusing insecure redirect, https->http ``` * 客戶端將需要信任頒發對象存儲證書的證書頒發機構，或者可能返回常見的 TLS 錯誤，例如： ``` x509: certificate signed by unknown authority ``` * 客戶端將需要網絡訪問對象存儲. 如果沒有此訪問權限，則可能導致的錯誤包括： ``` Received status code 403 from server: Forbidden ``` ### ETag mismatch[](#etag-mismatch "Permalink") Using the default GitLab settings, some object storage back-ends such as [MinIO](https://gitlab.com/gitlab-org/gitlab/-/issues/23188) and [Alibaba](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1564) might generate `ETag mismatch` errors. 使用 GitLab 直接上傳時， [MinIO](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1564#note_244497658)的[解決方法](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1564#note_244497658)是在服務器上使用`--compat`參數. 我們正在致力于 GitLab 組件 Workhorse 的修復，同時，也正在嘗試一種解決方法，以[允許禁用 ETag 驗證](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18175) . ## Troubleshooting Redis[](#troubleshooting-redis "Permalink") 如果應用程序節點無法連接到 Redis 節點，請檢查您的防火墻規則，并確保 Redis 可以接受端口`6379`下的 TCP 連接. ## Troubleshooting Gitaly[](#troubleshooting-gitaly "Permalink") ### Checking versions when using standalone Gitaly nodes[](#checking-versions-when-using-standalone-gitaly-nodes "Permalink") 使用獨立的 Gitaly 節點時，必須確保它們與 GitLab 的版本相同，以確保完全兼容. 檢查您的 GitLab 實例上的**管理區域> Gitaly 服務器** ，并確認所有 Gitaly 服務器都是`Up to date` . [![Gitaly standalone software versions diagram](https://img.kancloud.cn/3e/5c/3e5c7e400a6ef2ad74454039c570e336_1038x320.png)](../gitaly/img/gitlab_gitaly_version_mismatch_v12_4.png) ### `gitaly-debug`[](#gitaly-debug "Permalink") `gitaly-debug`命令提供用于" Gitaly"和" Git"性能的"生產調試"工具. 它旨在幫助生產工程師和支持工程師調查 Gitaly 性能問題. 如果您使用的是 GitLab 11.6 或更高版本，則此工具應已安裝在您的 GitLab / Gitaly 服務器上，位于`/opt/gitlab/embedded/bin/gitaly-debug` . 如果要研究舊版本的 GitLab，可以離線編譯此工具，然后將可執行文件復制到服務器： ``` git clone https://gitlab.com/gitlab-org/gitaly.git cd cmd/gitaly-debug GOOS=linux GOARCH=amd64 go build -o gitaly-debug ``` 要查看`gitaly-debug`的幫助頁面以`gitaly-debug`受支持的子命令列表，請運行： ``` gitaly-debug -h ``` ### Commits, pushes, and clones return a 401[](#commits-pushes-and-clones-return-a-401 "Permalink") ``` remote: GitLab: 401 Unauthorized ``` 您將需要將`gitlab-secrets.json`文件與 GitLab 應用程序節點同步. ### Client side gRPC logs[](#client-side-grpc-logs "Permalink") Gitaly 使用[gRPC](https://grpc.io/) RPC 框架. Ruby gRPC 客戶端具有自己的日志文件，當您看到 Gitaly 錯誤時，該文件可能包含有用的信息. 您可以使用`GRPC_LOG_LEVEL`環境變量控制 gRPC 客戶端的日志級別. 默認級別為`WARN` . 您可以使用以下命令運行 gRPC 跟蹤： ``` sudo GRPC_TRACE=all GRPC_VERBOSITY=DEBUG gitlab-rake gitlab:gitaly:check ``` ### Observing `gitaly-ruby` traffic[](#observing-gitaly-ruby-traffic "Permalink") [`gitaly-ruby`](../gitaly/index.html#gitaly-ruby)是[`gitaly-ruby`](../gitaly/index.html#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`調用： ``` sum(rate(grpc_client_handled_total[5m])) by (grpc_method) > 0 ``` ### Repository changes fail with a `401 Unauthorized` error[](#repository-changes-fail-with-a-401-unauthorized-error "Permalink") 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` ）： ``` remote: GitLab: 401 Unauthorized To <REMOTE_URL> ! [remote rejected] branch-name -> branch-name (pre-receive hook declined) error: failed to push some refs to '<REMOTE_URL>' ``` * 當任何用戶使用 GitLab UI 從存儲庫添加或修改文件時，該文件都會立即失敗，并顯示紅色`401 Unauthorized`橫幅. * 創建一個新項目并[使用 README 對其進行初始化會](../../gitlab-basics/create-project.html#blank-projects)成功創建該項目，但不會創建 README. * [將日志拖到](https://docs.gitlab.com/omnibus/settings/logs.html)應用程序節點上并重現錯誤時，到達`/api/v4/internal/allowed`端點時會出現`401`錯誤： ``` # api_json.log { "time": "2019-07-18T00:30:14.967Z", "severity": "INFO", "duration": 0.57, "db": 0, "view": 0.57, "status": 401, "method": "POST", "path": "\/api\/v4\/internal\/allowed", "params": [ { "key": "action", "value": "git-receive-pack" }, { "key": "changes", "value": "REDACTED" }, { "key": "gl_repository", "value": "REDACTED" }, { "key": "project", "value": "\/path\/to\/project.git" }, { "key": "protocol", "value": "web" }, { "key": "env", "value": "{\"GIT_ALTERNATE_OBJECT_DIRECTORIES\":[],\"GIT_ALTERNATE_OBJECT_DIRECTORIES_RELATIVE\":[],\"GIT_OBJECT_DIRECTORY\":null,\"GIT_OBJECT_DIRECTORY_RELATIVE\":null}" }, { "key": "user_id", "value": "2" }, { "key": "secret_token", "value": "[FILTERED]" } ], "host": "gitlab.example.com", "ip": "REDACTED", "ua": "Ruby", "route": "\/api\/:version\/internal\/allowed", "queue_duration": 4.24, "gitaly_calls": 0, "gitaly_duration": 0, "correlation_id": "XPUZqTukaP3" } # nginx_access.log [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 文件以使其與其他文件匹配，然后[重新配置該節點](../restart_gitlab.html#omnibus-gitlab-reconfigure) . ### Command line tools cannot connect to Gitaly[](#command-line-tools-cannot-connect-to-gitaly "Permalink") 如果使用命令行（CLI）工具連接到 Gitaly 節點時遇到問題，并且某些操作導致出現`14: Connect Failed`錯誤消息，則表明 gRPC 無法到達您的 Gitaly 節點. 確認您可以通過 TCP 到達 Gitaly： ``` sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT] ``` 如果 TCP 連接失敗，請檢查您的網絡設置和防火墻規則. 如果 TCP 連接成功，則您的網絡和防火墻規則正確. 如果您在命令行環境（例如 Bash）中使用代理服務器，則這些代理服務器可能會干擾您的 gRPC 通信. 如果使用 Bash 或兼容的命令行環境，請運行以下命令來確定是否配置了代理服務器： ``` echo $http_proxy echo $https_proxy ``` 如果這些變量中的任何一個都有值，則您的 Gitaly CLI 連接可能正在通過無法連接到 Gitaly 的代理進行路由. 要刪除代理設置，請運行以下命令（取決于哪些變量具有值）： ``` unset http_proxy unset https_proxy ``` ### Gitaly not listening on new address after reconfiguring[](#gitaly-not-listening-on-new-address-after-reconfiguring "Permalink") 當更新`gitaly['listen_addr']`或`gitaly['prometheus_listen_addr']`值時，Gitaly 可能會在`sudo gitlab-ctl reconfigure`后繼續偵聽舊地址. 發生這種情況時，執行`sudo gitlab-ctl restart`將解決此問題. 解決[此問題](https://gitlab.com/gitlab-org/gitaly/-/issues/2521)后，將不再需要[此操作](https://gitlab.com/gitlab-org/gitaly/-/issues/2521) . ### Permission denied errors appearing in Gitaly logs when accessing repositories from a standalone Gitaly node[](#permission-denied-errors-appearing-in-gitaly-logs-when-accessing-repositories-from-a-standalone-gitaly-node "Permalink") 如果即使文件許可權正確也發生此錯誤，則 Gitaly 節點很可能正在發生[時鐘漂移](https://en.wikipedia.org/wiki/Clock_drift) . 請確保 GitLab 和 Gitaly 節點已同步，并在可能的情況下使用 NTP 時間服務器使其保持同步. ## Troubleshooting the GitLab Rails application[](#troubleshooting-the-gitlab-rails-application "Permalink") * `mount: wrong fs type, bad option, bad superblock on` 您尚未安裝必要的 NFS 客戶端實用程序. 請參閱上面的步驟 1. * `mount: mount point /var/opt/gitlab/... does not exist` NFS 服務器上不存在此特定目錄. 確保共享已導出并且存在于 NFS 服務器上，然后嘗試重新安裝. ## Troubleshooting Monitoring[](#troubleshooting-monitoring "Permalink") 如果監視節點未接收到任何數據，請檢查導出器是否正在捕獲數據. ``` curl http[s]://localhost:<EXPORTER LISTENING PORT>/metric ``` or ``` curl http[s]://localhost:<EXPORTER LISTENING PORT>/-/metric ```