diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-03 03:08:30 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-03 03:08:30 +0000 |
commit | f4d27d532e3abeecd1caffeb3a56e698ae982e5b (patch) | |
tree | 27a1b43761cd6eedbdbf57b46b8fd9c5cc519a61 /doc/administration | |
parent | a2a712139fc7fa58aa02b143f2767286d28ef28d (diff) | |
download | gitlab-ce-f4d27d532e3abeecd1caffeb3a56e698ae982e5b.tar.gz |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/administration')
5 files changed, 20 insertions, 12 deletions
diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md index 2fd8753fa89..dbdbbd07caa 100644 --- a/doc/administration/monitoring/prometheus/gitlab_metrics.md +++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md @@ -84,6 +84,13 @@ The following metrics are available: | `failed_login_captcha_total` | Gauge | 11.0 | Counter of failed CAPTCHA attempts during login | | | `successful_login_captcha_total` | Gauge | 11.0 | Counter of successful CAPTCHA attempts during login | | | `auto_devops_pipelines_completed_total` | Counter | 12.7 | Counter of completed Auto DevOps pipelines, labeled by status | | +| `sidekiq_jobs_cpu_seconds` | Histogram | 12.4 | Seconds of cpu time to run Sidekiq job | | +| `sidekiq_jobs_completion_seconds` | Histogram | 12.2 | Seconds to complete Sidekiq job | | +| `sidekiq_jobs_queue_duration_seconds` | Histogram | 12.5 | Duration in seconds that a Sidekiq job was queued before being executed | | +| `sidekiq_jobs_failed_total` | Counter | 12.2 | Sidekiq jobs failed | | +| `sidekiq_jobs_retried_total` | Counter | 12.2 | Sidekiq jobs retried | | +| `sidekiq_running_jobs` | Gauge | 12.2 | Number of Sidekiq jobs running | | +| `sidekiq_concurrency` | Gauge | 12.5 | Maximum number of Sidekiq jobs | | ## Metrics controlled by a feature flag diff --git a/doc/administration/operations/filesystem_benchmarking.md b/doc/administration/operations/filesystem_benchmarking.md index 0a20e94a778..019909e2e89 100644 --- a/doc/administration/operations/filesystem_benchmarking.md +++ b/doc/administration/operations/filesystem_benchmarking.md @@ -37,7 +37,7 @@ completes. The output will vary depending on what version of `fio` installed. The following is an example output from `fio` v2.2.10 on a networked solid-state drive (SSD): -``` +```plaintext test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64 fio-2.2.10 Starting 1 process diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md index d54ffacd281..a11bce9aa02 100644 --- a/doc/administration/operations/moving_repositories.md +++ b/doc/administration/operations/moving_repositories.md @@ -21,7 +21,7 @@ overhead and tar is almost always already installed on your system. However, it is not possible to resume an interrupted tar pipe: if that happens then all data must be copied again. -``` +```shell sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\ tar -C /mnt/gitlab/repositories -xf -' ``` @@ -34,7 +34,7 @@ You can also use a tar pipe to copy data to another server. If your `git` user has SSH access to the newserver as `git@newserver`, you can pipe the data through SSH. -``` +```shell sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\ ssh git@newserver tar -C /mnt/gitlab/repositories -xf -' ``` @@ -50,7 +50,7 @@ with tar. In this scenario it is better to use rsync. This utility is either already installed on your system or easily installable via apt, yum etc. -``` +```shell sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \ /mnt/gitlab/repositories' ``` @@ -64,7 +64,7 @@ If you want to see progress, replace `-a` with `-av`. If the `git` user on your source system has SSH access to the target server you can send the repositories over the network with rsync. -``` +```shell sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \ git@newserver:/mnt/gitlab/repositories' ``` @@ -99,7 +99,7 @@ First we create a new directory, owned by `git`, to hold transfer logs. We assume the directory is empty before we start the transfer procedure, and that we are the only ones writing files in it. -``` +```shell # Omnibus sudo mkdir /var/opt/gitlab/transfer-logs sudo chown git:git /var/opt/gitlab/transfer-logs @@ -110,7 +110,7 @@ sudo -u git -H mkdir /home/git/transfer-logs We seed the process with a list of the directories we want to copy. -``` +```shell # Omnibus sudo -u git sh -c 'gitlab-rake gitlab:list_repos > /var/opt/gitlab/transfer-logs/all-repos-$(date +%s).txt' @@ -124,7 +124,7 @@ the number of jobs done by GNU Parallel should converge to zero. If it does not, some repositories listed in `all-repos-1234.txt` may have been deleted/renamed before they could be copied. -``` +```shell # Omnibus sudo -u git sh -c ' cat /var/opt/gitlab/transfer-logs/* | sort | uniq -u |\ @@ -154,7 +154,7 @@ Then you might only want to sync repositories that were changed via GitLab _after_ that time. You can use the `SINCE` variable to tell `rake gitlab:list_repos` to only print repositories with recent activity. -``` +```shell # Omnibus sudo gitlab-rake gitlab:list_repos SINCE='2015-10-1 12:00 UTC' |\ sudo -u git \ diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md index 2a9a4cff34e..b18c15e6b91 100644 --- a/doc/administration/operations/ssh_certificates.md +++ b/doc/administration/operations/ssh_certificates.md @@ -54,8 +54,9 @@ The SSH certificates being issued by that CA **MUST** have a "key id" corresponding to that user's username on GitLab, e.g. (some output omitted for brevity): -``` +```shell $ ssh-add -L | grep cert | ssh-keygen -L -f - + (stdin):1: Type: ssh-rsa-cert-v01@openssh.com user certificate Public key: RSA-CERT SHA256:[...] diff --git a/doc/administration/operations/unicorn.md b/doc/administration/operations/unicorn.md index 969f1211643..a19617daaef 100644 --- a/doc/administration/operations/unicorn.md +++ b/doc/administration/operations/unicorn.md @@ -29,7 +29,7 @@ requests. This is what a Unicorn worker timeout looks like in `unicorn_stderr.log`. The master process has PID 56227 below. -``` +```plaintext [2015-06-05T10:58:08.660325 #56227] ERROR -- : worker=10 PID:53009 timeout (61s > 60s), killing [2015-06-05T10:58:08.699360 #56227] ERROR -- : reaped #<Process::Status: pid 53009 SIGKILL (signal 9)> worker=10 [2015-06-05T10:58:08.708141 #62538] INFO -- : worker=10 spawned pid=62538 @@ -79,7 +79,7 @@ threshold is a random value between 200 and 250 MB. The master process (PID 117565) then reaps the worker process and spawns a new 'worker 4' with PID 127549. -``` +```plaintext [2015-06-05T12:07:41.828374 #125918] WARN -- : #<Unicorn::HttpServer:0x00000002734770>: worker (pid: 125918) exceeds memory limit (256413696 bytes > 254802235 bytes) [2015-06-05T12:07:41.828472 #125918] WARN -- : Unicorn::WorkerKiller send SIGQUIT (pid: 125918) alive: 23 sec (trial 1) [2015-06-05T12:07:42.025916 #117565] INFO -- : reaped #<Process::Status: pid 125918 exit 0> worker=4 |