Add latest changes from gitlab-org/gitlab@15-2-stable-eev15.2.0-rc42

15 files changed, 221 insertions, 1243 deletions

diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md
index 81ca1bda5d0..d5019f1aa4a 100644
--- a/doc/administration/troubleshooting/debug.md
+++ b/doc/administration/troubleshooting/debug.md
@@ -1,289 +1,11 @@
 ---
-stage: Systems
-group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: '../reference_architectures/troubleshooting.md'
+remove_date: '2022-10-19'
 ---
 
-# Debugging tips **(FREE SELF)**
+This document was moved to [another location](../reference_architectures/troubleshooting.md).
 
-Sometimes things don't work the way they should. Here are some tips on debugging issues out
-in production.
-
-## Starting a Rails console session
-
-Troubleshooting and debugging your GitLab instance often requires a Rails console.
-
-Your type of GitLab installation determines how
-[to start a rails console](../operations/rails_console.md).
-See also:
-
-- [GitLab Rails Console Cheat Sheet](gitlab_rails_cheat_sheet.md).
-- [Navigating GitLab via Rails console](navigating_gitlab_via_rails_console.md).
-
-### Enabling Active Record logging
-
-You can enable output of Active Record debug logging in the Rails console
-session by running:
-
-```ruby
-ActiveRecord::Base.logger = Logger.new($stdout)
-```
-
-This will show information about database queries triggered by any Ruby code
-you may run in the console. To turn off logging again, run:
-
-```ruby
-ActiveRecord::Base.logger = nil
-```
-
-### Disabling database statement timeout
-
-You can disable the PostgreSQL statement timeout for the current Rails console
-session by running:
-
-```ruby
-ActiveRecord::Base.connection.execute('SET statement_timeout TO 0')
-```
-
-This change only affects the current Rails console session and will
-not be persisted in the GitLab production environment or in the next Rails
-console session.
-
-### Output Rails console session history
-
-If you'd like to output your Rails console command history in a format that's
-easy to copy and save for future reference, you can run:
-
-```ruby
-puts Readline::HISTORY.to_a
-```
-
-## Using the Rails runner
-
-If you need to run some Ruby code in the context of your GitLab production
-environment, you can do so using the [Rails runner](https://guides.rubyonrails.org/command_line.html#rails-runner). When executing a script file, the script must be accessible by the `git` user.
-
-**For Omnibus installations**
-
-```shell
-sudo gitlab-rails runner "RAILS_COMMAND"
-
-# Example with a two-line Ruby script
-sudo gitlab-rails runner "user = User.first; puts user.username"
-
-# Example with a ruby script file (make sure to use the full path)
-sudo gitlab-rails runner /path/to/script.rb
-```
-
-**For installations from source**
-
-```shell
-sudo -u git -H bundle exec rails runner -e production "RAILS_COMMAND"
-
-# Example with a two-line Ruby script
-sudo -u git -H bundle exec rails runner -e production "user = User.first; puts user.username"
-
-# Example with a ruby script file (make sure to use the full path)
-sudo -u git -H bundle exec rails runner -e production /path/to/script.rb
-```
-
-## Mail not working
-
-A common problem is that mails are not being sent for some reason. Suppose you configured
-an SMTP server, but you're not seeing mail delivered. Here's how to check the settings:
-
-1. Run a [Rails console](../operations/rails_console.md#starting-a-rails-console-session).
-
-1. Look at the ActionMailer `delivery_method` to make sure it matches what you
-   intended. If you configured SMTP, it should say `:smtp`. If you're using
-   Sendmail, it should say `:sendmail`:
-
-   ```ruby
-   irb(main):001:0> ActionMailer::Base.delivery_method
-   => :smtp
-   ```
-
-1. If you're using SMTP, check the mail settings:
-
-   ```ruby
-   irb(main):002:0> ActionMailer::Base.smtp_settings
-   => {:address=>"localhost", :port=>25, :domain=>"localhost.localdomain", :user_name=>nil, :password=>nil, :authentication=>nil, :enable_starttls_auto=>true}
-   ```
-
-   In the example above, the SMTP server is configured for the local machine. If this is intended, you may need to check your local mail
-   logs (for example, `/var/log/mail.log`) for more details.
-
-1. Send a test message via the console.
-
-   ```ruby
-   irb(main):003:0> Notify.test_email('youremail@email.com', 'Hello World', 'This is a test message').deliver_now
-   ```
-
-   If you do not receive an email and/or see an error message, then check
-   your mail server settings.
-
-## Advanced Issues
-
-For more advanced issues, `gdb` is a must-have tool for debugging issues.
-
-### The GNU Project Debugger (GDB)
-
-To install on Ubuntu/Debian:
-
-```shell
-sudo apt-get install gdb
-```
-
-On CentOS:
-
-```shell
-sudo yum install gdb
-```
-
-<!-- vale gitlab.Spelling = NO -->
-
-### rbtrace
-
-<!-- vale gitlab.Spelling = YES -->
-
-GitLab 11.2 ships with [`rbtrace`](https://github.com/tmm1/rbtrace), which
-allows you to trace Ruby code, view all running threads, take memory dumps,
-and more. However, this is not enabled by default. To enable it, define the
-`ENABLE_RBTRACE` variable to the environment. For example, in Omnibus:
-
-```ruby
-gitlab_rails['env'] = {"ENABLE_RBTRACE" => "1"}
-```
-
-Then reconfigure the system and restart Puma and Sidekiq. To run this
-in Omnibus, run as root:
-
-```ruby
-/opt/gitlab/embedded/bin/ruby /opt/gitlab/embedded/bin/rbtrace
-```
-
-## Common Problems
-
-Many of the tips to diagnose issues below apply to many different situations. We'll use one
-concrete example to illustrate what you can do to learn what is going wrong.
-
-### 502 Gateway Timeout after Unicorn spins at 100% CPU
-
-This error occurs when the Web server times out (default: 60 s) after not
-hearing back from the Unicorn worker. If the CPU spins to 100% while this in
-progress, there may be something taking longer than it should.
-
-To fix this issue, we first need to figure out what is happening. The
-following tips are only recommended if you do not mind users being affected by
-downtime. Otherwise skip to the next section.
-
-1. Load the problematic URL
-1. Run `sudo gdb -p <PID>` to attach to the Puma process.
-1. In the GDB window, type:
-
-   ```plaintext
-   call (void) rb_backtrace()
-   ```
-
-1. This forces the process to generate a Ruby backtrace. Check
-   `/var/log/gitlab/puma/puma_stderr.log` for the backtrace. For example, you may see:
-
-   ```plaintext
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `block in start'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `loop'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:36:in `block (2 levels) in start'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:44:in `sample'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:68:in `sample_objects'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:68:in `each_with_object'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:68:in `each'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:69:in `block in sample_objects'
-   from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:69:in `name'
-   ```
-
-1. To see the current threads, run:
-
-   ```plaintext
-   thread apply all bt
-   ```
-
-1. Once you're done debugging with `gdb`, be sure to detach from the process and exit:
-
-   ```plaintext
-   detach
-   exit
-   ```
-
-If the Puma process terminates before you are able to run these
-commands, GDB will report an error. To buy more time, you can always raise the
-Puma worker timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
-increase it from 60 seconds to 600:
-
-```ruby
-gitlab_rails['env'] = {
-        'GITLAB_RAILS_RACK_TIMEOUT' => 600
-}
-```
-
-For source installations, set the environment variable.
-Refer to [Puma Worker timeout](../operations/puma.md#change-the-worker-timeout).
-
-[Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
-
-#### Troubleshooting without affecting other users
-
-The previous section attached to a running Unicorn process, and this may have
-undesirable effects for users trying to access GitLab during this time. If you
-are concerned about affecting others during a production system, you can run a
-separate Rails process to debug the issue:
-
-1. Log in to your GitLab account.
-1. Copy the URL that is causing problems (for example, `https://gitlab.com/ABC`).
-1. Create a Personal Access Token for your user (User Settings -> Access Tokens).
-1. Bring up the [GitLab Rails console.](../operations/rails_console.md#starting-a-rails-console-session)
-1. At the Rails console, run:
-
-   ```ruby
-   app.get '<URL FROM STEP 2>/?private_token=<TOKEN FROM STEP 3>'
-   ```
-
-   For example:
-
-   ```ruby
-   app.get 'https://gitlab.com/gitlab-org/gitlab-foss/-/issues/1?private_token=123456'
-   ```
-
-1. In a new window, run `top`. It should show this Ruby process using 100% CPU. Write down the PID.
-1. Follow step 2 from the previous section on using GDB.
-
-### GitLab: API is not accessible
-
-This often occurs when GitLab Shell attempts to request authorization via the
-[internal API](../../development/internal_api/index.md) (for example, `http://localhost:8080/api/v4/internal/allowed`), and
-something in the check fails. There are many reasons why this may happen:
-
-1. Timeout connecting to a database (for example, PostgreSQL or Redis)
-1. Error in Git hooks or push rules
-1. Error accessing the repository (for example, stale NFS handles)
-
-To diagnose this problem, try to reproduce the problem and then see if there
-is a Unicorn worker that is spinning via `top`. Try to use the `gdb`
-techniques above. In addition, using `strace` may help isolate issues:
-
-```shell
-strace -ttTfyyy -s 1024 -p <PID of puma worker> -o /tmp/puma.txt
-```
-
-If you cannot isolate which Unicorn worker is the issue, try to run `strace`
-on all the Unicorn workers to see where the
-[`/internal/allowed`](../../development/internal_api/index.md) endpoint gets stuck:
-
-```shell
-ps auwx | grep puma | awk '{ print " -p " $2}' | xargs  strace -ttTfyyy -s 1024 -o /tmp/puma.txt
-```
-
-The output in `/tmp/puma.txt` may help diagnose the root cause.
-
-## More information
-
-- [Debugging Stuck Ruby Processes](https://newrelic.com/blog/best-practices/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9)
-- [Cheat sheet of using GDB and Ruby processes](gdb-stuck-ruby.txt)
+<!-- This redirect file can be deleted after 2022-10-19. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/administration/troubleshooting/defcon.md b/doc/administration/troubleshooting/defcon.md
index 292b4b13967..f2554f523f0 100644
--- a/doc/administration/troubleshooting/defcon.md
+++ b/doc/administration/troubleshooting/defcon.md
@@ -1,35 +1,11 @@
 ---
-stage: Systems
-group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: reference
+redirect_to: '../../ci/troubleshooting.md#disaster-recovery'
+remove_date: '2022-10-04'
 ---
 
-# Disaster recovery **(FREE SELF)**
+This document was moved to [another location](../../ci/troubleshooting.md#disaster-recovery).
 
-This document describes a feature that allows you to disable some important but computationally
-expensive parts of the application to relieve stress on the database during an ongoing downtime.
-
-## `ci_queueing_disaster_recovery_disable_fair_scheduling`
-
-This feature flag, if temporarily enabled, disables fair scheduling on shared runners.
-This can help to reduce system resource usage on the `jobs/request` endpoint
-by significantly reducing the computations being performed.
-
-Side effects:
-
-- In case of a large backlog of jobs, the jobs are processed in the order
-  they were put in the system, instead of balancing the jobs across many projects.
-
-## `ci_queueing_disaster_recovery_disable_quota`
-
-This feature flag, if temporarily enabled, disables enforcing CI/CD minutes quota
-on shared runners. This can help to reduce system resource usage on the
-`jobs/request` endpoint by significantly reducing the computations being
-performed.
-
-Side effects:
-
-- Projects which are out of quota will be run. This affects
-  only jobs created during the last hour, as prior jobs are canceled
-  by a periodic background worker (`StuckCiJobsWorker`).
+<!-- This redirect file can be deleted after <2022-10-04>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/administration/troubleshooting/diagnostics_tools.md b/doc/administration/troubleshooting/diagnostics_tools.md
index 6055746238f..faddf12b97d 100644
--- a/doc/administration/troubleshooting/diagnostics_tools.md
+++ b/doc/administration/troubleshooting/diagnostics_tools.md
@@ -8,7 +8,7 @@ type: reference
 # Diagnostics tools **(FREE SELF)**
 
 These are some of the diagnostics tools the GitLab Support team uses during troubleshooting.
-They are listed here for transparency, and they may be useful for users with experience
+They are listed here for transparency, and for users with experience
 with troubleshooting GitLab. If you are currently having an issue with GitLab, you
 may want to check your [support options](https://about.gitlab.com/support/) first,
 before attempting to use these tools.
@@ -24,6 +24,6 @@ running on.
 [strace-parser](https://gitlab.com/wchandler/strace-parser) is a small tool to analyze
 and summarize raw `strace` data.
 
-## kubesos
+## `kubesos`
 
 The [`kubesos`](https://gitlab.com/gitlab-com/support/toolbox/kubesos/) utility retrieves GitLab cluster configuration and logs from GitLab Cloud Native chart deployments.
diff --git a/doc/administration/troubleshooting/gdb-stuck-ruby.txt b/doc/administration/troubleshooting/gdb-stuck-ruby.txt
deleted file mode 100644
index de8d704f9e3..00000000000
--- a/doc/administration/troubleshooting/gdb-stuck-ruby.txt
+++ /dev/null
@@ -1,142 +0,0 @@
-# Here's the script I'll use to demonstrate - it just loops forever:
-
-$ cat test.rb
-#!/usr/bin/env ruby
-
-loop do
-  sleep 1
-end
-
-# Now, I'll start the script in the background, and redirect stdout and stderr
-# to /dev/null:
-
-$ ruby ./test.rb >/dev/null 2>/dev/null &
-[1] 1343
-
-# Next, I'll grab the PID of the script (1343):
-
-$ ps aux | grep test.rb
-vagrant   1343  0.0  0.4   3884  1652 pts/0    S    14:42   0:00 ruby ./test.rb
-vagrant   1345  0.0  0.2   4624   852 pts/0    S+   14:42   0:00 grep --color=auto test.rb
-
-# Now I start gdb. Note that I'm using sudo here. This may or may not be
-# necessary in your setup. I'd try without sudo first, and fall back to adding
-# it if the next step fails:
-
-$ sudo gdb
-GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
-Copyright (C) 2012 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
-and "show warranty" for details.
-This GDB was configured as "i686-linux-gnu".
-For bug reporting instructions, please see:
-<http://bugs.launchpad.net/gdb-linaro/>.
-
-# OK, now I'm in gdb, and I want to instruct it to attach to our Ruby process.
-# I can do that using the 'attach' command, which takes a PID (the one we
-# gathered above):
-
-(gdb) attach 1343
-Attaching to process 1343
-Reading symbols from /opt/vagrant_ruby/bin/ruby...done.
-Reading symbols from /lib/i386-linux-gnu/librt.so.1...(no debugging symbols found)...done.
-Loaded symbols for /lib/i386-linux-gnu/librt.so.1
-Reading symbols from /lib/i386-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
-Loaded symbols for /lib/i386-linux-gnu/libdl.so.2
-Reading symbols from /lib/i386-linux-gnu/libcrypt.so.1...(no debugging symbols found)...done.
-Loaded symbols for /lib/i386-linux-gnu/libcrypt.so.1
-Reading symbols from /lib/i386-linux-gnu/libm.so.6...(no debugging symbols found)...done.
-Loaded symbols for /lib/i386-linux-gnu/libm.so.6
-Reading symbols from /lib/i386-linux-gnu/libc.so.6...(no debugging symbols found)...done.
-Loaded symbols for /lib/i386-linux-gnu/libc.so.6
-Reading symbols from /lib/i386-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
-[Thread debugging using libthread_db enabled]
-Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
-Loaded symbols for /lib/i386-linux-gnu/libpthread.so.0
-Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
-Loaded symbols for /lib/ld-linux.so.2
-0xb770c424 in __kernel_vsyscall ()
-
-# Great, now gdb is attached to the target process. If the step above fails, try
-# going back and running gdb under sudo. The next thing I want to do is gather
-# C-level backtraces from all threads in the process. The following command
-# stands for 'thread apply all backtrace':
-
-(gdb) t a a bt
-
-Thread 1 (Thread 0xb74d76c0 (LWP 1343)):
-#0  0xb770c424 in __kernel_vsyscall ()
-#1  0xb75d7abd in select () from /lib/i386-linux-gnu/libc.so.6
-#2  0x08069c56 in rb_thread_wait_for (time=...) at eval.c:11376
-#3  0x080a20fd in rb_f_sleep (argc=1, argv=0xbf85f490) at process.c:1633
-#4  0x0805e0e2 in call_cfunc (argv=0xbf85f490, argc=1, len=-1, recv=3075299660, func=0x80a20b0 <rb_f_sleep>)
-    at eval.c:5778
-#5  rb_call0 (klass=3075304600, recv=3075299660, id=9393, oid=9393, argc=1, argv=0xbf85f490, body=0xb74c85a8, flags=2)
-    at eval.c:5928
-#6  0x0805e35d in rb_call (klass=3075304600, recv=3075299660, mid=9393, argc=1, argv=0xbf85f490, scope=1,
-    self=<optimized out>) at eval.c:6176
-#7  0x080651ec in rb_eval (self=3075299660, n=0xb74c4e1c) at eval.c:3521
-#8  0x0805c31c in rb_yield_0 (val=6, self=3075299660, klass=<optimized out>, flags=0, avalue=0) at eval.c:5095
-#9  0x0806a1e5 in loop_i () at eval.c:5227
-#10 0x08058dbd in rb_rescue2 (b_proc=0x806a1c0 <loop_i>, data1=0, r_proc=0, data2=0) at eval.c:5491
-#11 0x08058f28 in rb_f_loop () at eval.c:5252
-#12 0x0805e0c1 in call_cfunc (argv=0x0, argc=0, len=0, recv=3075299660, func=0x8058ef0 <rb_f_loop>) at eval.c:5781
-#13 rb_call0 (klass=3075304600, recv=3075299660, id=4121, oid=4121, argc=0, argv=0x0, body=0xb74d4dbc, flags=2)
-    at eval.c:5928
-#14 0x0805e35d in rb_call (klass=3075304600, recv=3075299660, mid=4121, argc=0, argv=0x0, scope=1, self=<optimized out>)
-    at eval.c:6176
-#15 0x080651ec in rb_eval (self=3075299660, n=0xb74c4dcc) at eval.c:3521
-#16 0x080662c6 in rb_eval (self=3075299660, n=0xb74c4de0) at eval.c:3236
-#17 0x08068ee4 in ruby_exec_internal () at eval.c:1654
-#18 0x08068f24 in ruby_exec () at eval.c:1674
-#19 0x0806b2cd in ruby_run () at eval.c:1684
-#20 0x08053771 in main (argc=2, argv=0xbf860204, envp=0xbf860210) at main.c:48
-
-# C backtraces are sometimes sufficient, but often Ruby backtraces are necessary
-# for debugging as well. Ruby has a built-in function called rb_backtrace() that
-# we can use to dump out a Ruby backtrace, but it prints to stdout or stderr
-# (depending on your Ruby version), which might have been redirected to a file
-# or to /dev/null (as in our example) when the process started up.
-#
-# To get aroundt this, we'll do a little trick and redirect the target process's
-# stdout and stderr to the current TTY, so that any output from the process
-# will appear directly on our screen.
-
-# First, let's close the existing file descriptors for stdout and stderr
-# (FD 1 and 2, respectively):
-(gdb) call (void) close(1)
-(gdb) call (void) close(2)
-
-# Next, we need to figure out the device name for the current TTY:
-(gdb) shell tty
-/dev/pts/0
-
-# OK, now we can pass the device name obtained above to open() and attach
-# file descriptors 1 and 2 back to the current TTY with these calls:
-
-(gdb) call (int) open("/dev/pts/0", 2, 0)
-$1 = 1
-(gdb) call (int) open("/dev/pts/0", 2, 0)
-$2 = 2
-
-# Finally, we call rb_backtrace() in order to dump the Ruby backtrace:
-
-(gdb) call (void) rb_backtrace()
-  from ./test.rb:4:in `sleep'
-  from ./test.rb:4
-  from ./test.rb:3:in `loop'
-  from ./test.rb:3
-
-# And here's how we get out of gdb. Once you've quit, you'll probably want to
-# clean up the stuck process by killing it.
-
-(gdb) quit
-A debugging session is active.
-
-  Inferior 1 [process 1343] will be detached.
-
-Quit anyway? (y or n) y
-Detaching from program: /opt/vagrant_ruby/bin/ruby, process 1343
-$
diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
index b57bc0a1119..0ff1afa86ed 100644
--- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
+++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
@@ -8,9 +8,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 This is the GitLab Support Team's collection of information regarding the GitLab Rails
 console, for use while troubleshooting. It is listed here for transparency,
-and it may be useful for users with experience with these tools. If you are currently
+and for users with experience with these tools. If you are currently
 having an issue with GitLab, it is highly recommended that you first check
-our guide on [navigating our Rails console](navigating_gitlab_via_rails_console.md),
+our guide on [our Rails console](../operations/rails_console.md),
 and your [support options](https://about.gitlab.com/support/), before attempting to use
 this information.
 
@@ -80,7 +80,7 @@ Notify.test_email(u.email, "Test email for #{u.name}", 'Test email').deliver_now
 
 ## Limiting output
 
-Adding a semicolon(`;`) and a follow-up statement at the end of a statement prevents the default implicit return output. This is useful if you are already explicitly printing details and potentially have a lot of return output:
+Adding a semicolon(`;`) and a follow-up statement at the end of a statement prevents the default implicit return output. This can be used if you are already explicitly printing details and potentially have a lot of return output:
 
 ```ruby
 puts ActiveRecord::Base.descendants; :ok
@@ -100,9 +100,9 @@ project.id
 # => 2537
 ```
 
-## Open object in irb
+## Open object in `irb`
 
-Sometimes it is easier to navigate through a method if you are within the context of the object. You can shim into the namespace of `Object` to let you open `irb` within the context of any object:
+Sometimes it is easier to go through a method if you are in the context of the object. You can shim into the namespace of `Object` to let you open `irb` in the context of any object:
 
 ```ruby
 Object.define_method(:irb) { binding.irb }
@@ -311,7 +311,7 @@ end
 
 ### Bulk update push rules for _all_ projects
 
-For example, enable **Check whether the commit author is a GitLab user** and **Do not allow users to remove Git tags with `git push`** checkboxes, and create a filter for allowing commits from a specific e-mail domain only:
+For example, enable **Check whether the commit author is a GitLab user** and **Do not allow users to remove Git tags with `git push`** checkboxes, and create a filter for allowing commits from a specific email domain only:
 
 ``` ruby
 Project.find_each do |p|
@@ -443,7 +443,7 @@ p.create_wiki  ### creates the wiki project on the filesystem
 
 ## Issue boards
 
-### In case of issue boards not loading properly and it's getting time out. We need to call the Issue Rebalancing service to fix this
+### In case of issue boards not loading properly and it's getting time out. Call the Issue Rebalancing service to fix this
 
 ```ruby
 p = Project.find_by_full_path('<username-or-group>/<project-name>')
@@ -515,9 +515,9 @@ If this all runs successfully, you see an output like the following before being
 => nil
 ```
 
-The exported project is located within a `.tar.gz` file in `/var/opt/gitlab/gitlab-rails/uploads/-/system/import_export_upload/export_file/`.
+The exported project is located in a `.tar.gz` file in `/var/opt/gitlab/gitlab-rails/uploads/-/system/import_export_upload/export_file/`.
 
-If this fails, [enable verbose logging](navigating_gitlab_via_rails_console.md#looking-up-database-persisted-objects),
+If this fails, [enable verbose logging](../operations/rails_console.md#looking-up-database-persisted-objects),
 repeat the above procedure after,
 and report the output to
 [GitLab Support](https://about.gitlab.com/support/).
@@ -611,6 +611,13 @@ user.skip_reconfirmation!
 
 ### Disable 2fa for single user
 
+**In GitLab 13.5 and later:**
+
+Use the code under [Disable 2FA | For a single user](../../security/two_factor_authentication.md#for-a-single-user) so that the target user
+is notified that 2FA has been disabled.
+
+**In GitLab 13.4 and earlier:**
+
 ```ruby
 user = User.find_by_username('<username>')
 user.disable_two_factor!
@@ -629,7 +636,7 @@ User.billable.count
 ::HistoricalData.max_historical_user_count(from: 1.year.ago.beginning_of_day, to: Time.current.end_of_day)
 ```
 
-Using cURL and jq (up to a max 100, see the [pagination docs](../../api/index.md#pagination)):
+Using cURL and jq (up to a max 100, see [Pagination](../../api/index.md#pagination)):
 
 ```shell
 curl --silent --header "Private-Token: ********************" \
@@ -1053,6 +1060,9 @@ License.current.expires_at
 
 # Is this a trial license?
 License.current.trial?
+
+# License ID for lookup on CustomersDot
+License.current.license_id
 ```
 
 ### Check if a project feature is available on the instance
@@ -1101,10 +1111,10 @@ License.select(&TYPE).each(&:destroy!)
 
 ### Registry Disk Space Usage by Project
 
-As a GitLab administrator, you may need to reduce disk space consumption.
+As a GitLab administrator, you may want to reduce disk space consumption.
 A common culprit is Docker Registry images that are no longer in use. To find
 the storage broken down by each project, run the following in the
-[GitLab Rails console](../troubleshooting/navigating_gitlab_via_rails_console.md):
+[GitLab Rails console](../operations/rails_console.md):
 
 ```ruby
 projects_and_size = [["project_id", "creator_id", "registry_size_bytes", "project path"]]
@@ -1135,11 +1145,11 @@ end
 
 ### Run the Cleanup policy now
 
-Find this content in the [Container Registry troubleshooting docs](../packages/container_registry.md#run-the-cleanup-policy-now).
+Find this content in the [Container Registry troubleshooting documentation](../packages/container_registry.md#run-the-cleanup-policy-now).
 
 ## Sidekiq
 
-This content has been moved to the [Troubleshooting Sidekiq docs](sidekiq.md).
+This content has been moved to [Troubleshooting Sidekiq](sidekiq.md).
 
 ## Redis
 
@@ -1275,11 +1285,16 @@ project = Project.find_by_full_path('<group/project>')
 Geo::RepositorySyncService.new(project).execute
 ```
 
-### Blob types newer than uploads/artifacts/LFS
+### Blob types
 
+- `Ci::JobArtifact`
+- `Ci::PipelineArtifact`
+- `LfsObject`
+- `MergeRequestDiff`
 - `Packages::PackageFile`
+- `PagesDeployment`
 - `Terraform::StateVersion`
-- `MergeRequestDiff`
+- `Upload`
 
 `Packages::PackageFile` is used in the following examples, but things generally work the same for the other Blob types.
 
diff --git a/doc/administration/troubleshooting/group_saml_scim.md b/doc/administration/troubleshooting/group_saml_scim.md
index c6a102e87ee..145eb5f65ae 100644
--- a/doc/administration/troubleshooting/group_saml_scim.md
+++ b/doc/administration/troubleshooting/group_saml_scim.md
@@ -60,6 +60,10 @@ User claims and attributes:
 
 IdP links and certificate:
 
+NOTE:
+Google Workspace displays a SHA256 fingerprint. To retrieve the SHA1 fingerprint required by GitLab for configuring SAML, download the certificate and calculate the SHA1 certificate
+fingerprint.
+
 ![Google Workspace Links and Certificate](img/GoogleWorkspace-linkscert_v14_10.png)
 
 ## Okta
@@ -109,3 +113,95 @@ Adding a user:
 SSO settings:
 
 ![OneLogin SSO settings](img/OneLogin-SSOsettings.png)
+
+## SAML response example
+
+When a user signs in using SAML, GitLab receives a SAML response. The SAML response can be found in `production.log` logs as a base64-encoded message. Locate the response by
+searching for `SAMLResponse`. The decoded SAML response is in XML format. For example:
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xs="http://www.w3.org/2001/XMLSchema" Destination="https://gitlabexample/-/saml/callback" ID="id4898983630840142426821432" InResponseTo="_c65e4c88-9425-4472-b42c-37f4186ac0ee" IssueInstant="2022-05-30T21:30:35.696Z" Version="2.0">
+ <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.okta.com/exk2y6j57o1Pdr2lI8qh7</saml2:Issuer>
+ <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
+   <ds:SignedInfo>
+     <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
+     <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
+     <ds:Reference URI="#id4898983630840142426821432">
+       <ds:Transforms>
+         <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
+         <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
+           <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>
+         </ds:Transform>
+       </ds:Transforms>
+       <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
+       <ds:DigestValue>neiQvv9d3OgS4GZW8Nptp4JhjpKs3GCefibn+vmRgk4=</ds:DigestValue>
+     </ds:Reference>
+   </ds:SignedInfo>
+   <ds:SignatureValue>dMsQX8ivi...HMuKGhyLRvabGU6CuPrf7==</ds:SignatureValue>
+   <ds:KeyInfo>
+     <ds:X509Data>
+       <ds:X509Certificate>MIIDq...cptGr3vN9TQ==</ds:X509Certificate>
+     </ds:X509Data>
+   </ds:KeyInfo>
+ </ds:Signature>
+ <saml2p:Status xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
+   <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
+ </saml2p:Status>
+ <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="id489" IssueInstant="2022-05-30T21:30:35.696Z" Version="2.0">
+   <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.okta.com/exk2y6j57o1Pdr2lI8qh7</saml2:Issuer>
+   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
+     <ds:SignedInfo>
+       <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
+       <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
+       <ds:Reference URI="#id48989836309833801859473359">
+         <ds:Transforms>
+           <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
+           <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
+             <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>
+           </ds:Transform>
+         </ds:Transforms>
+         <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
+         <ds:DigestValue>MaIsoi8hbT9gsi/mNZsz449mUuAcuEWY0q3bc4asOQs=</ds:DigestValue>
+       </ds:Reference>
+     </ds:SignedInfo>
+     <ds:SignatureValue>dMsQX8ivi...HMuKGhyLRvabGU6CuPrf7==<</ds:SignatureValue>
+     <ds:KeyInfo>
+       <ds:X509Data>
+         <ds:X509Certificate>MIIDq...cptGr3vN9TQ==</ds:X509Certificate>
+       </ds:X509Data>
+     </ds:KeyInfo>
+   </ds:Signature>
+   <saml2:Subject xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
+     <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">useremail@domain.com</saml2:NameID>
+     <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
+       <saml2:SubjectConfirmationData InResponseTo="_c65e4c88-9425-4472-b42c-37f4186ac0ee" NotOnOrAfter="2022-05-30T21:35:35.696Z" Recipient="https://gitlab.example.com/-/saml/callback"/>
+     </saml2:SubjectConfirmation>
+   </saml2:Subject>
+   <saml2:Conditions xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" NotBefore="2022-05-30T21:25:35.696Z" NotOnOrAfter="2022-05-30T21:35:35.696Z">
+     <saml2:AudienceRestriction>
+       <saml2:Audience>https://gitlab.example.com/</saml2:Audience>
+     </saml2:AudienceRestriction>
+   </saml2:Conditions>
+   <saml2:AuthnStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" AuthnInstant="2022-05-30T21:30:35.696Z" SessionIndex="_c65e4c88-9425-4472-b42c-37f4186ac0ee">
+     <saml2:AuthnContext>
+       <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
+     </saml2:AuthnContext>
+   </saml2:AuthnStatement>
+   <saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
+     <saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
+       <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">useremail@domain.com</saml2:AttributeValue>
+     </saml2:Attribute>
+     <saml2:Attribute Name="firtname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
+       <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">John</saml2:AttributeValue>
+     </saml2:Attribute>
+     <saml2:Attribute Name="lastname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
+       <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Doe</saml2:AttributeValue>
+     </saml2:Attribute>
+     <saml2:Attribute Name="Groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
+       <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Super-awesome-group</saml2:AttributeValue>
+     </saml2:Attribute>
+   </saml2:AttributeStatement>
+ </saml2:Assertion>
+</saml2p:Response>
+```
diff --git a/doc/administration/troubleshooting/index.md b/doc/administration/troubleshooting/index.md
index 7d40a9e9683..7fe731bda66 100644
--- a/doc/administration/troubleshooting/index.md
+++ b/doc/administration/troubleshooting/index.md
@@ -17,13 +17,14 @@ installation.
 - [Sidekiq](sidekiq.md)
 - [GitLab Rails console cheat sheet](gitlab_rails_cheat_sheet.md)
 - [Group SAML and SCIM troubleshooting](group_saml_scim.md) **(PREMIUM SAAS)**
-- [Kubernetes cheat sheet](kubernetes_cheat_sheet.md)
+- [Kubernetes cheat sheet](https://docs.gitlab.com/charts/troubleshooting/kubernetes_cheat_sheet.html)
 - [Linux cheat sheet](linux_cheat_sheet.md)
 - [Parsing GitLab logs with `jq`](log_parsing.md)
-- [Navigating GitLab via Rails console](navigating_gitlab_via_rails_console.md)
 - [Diagnostics tools](diagnostics_tools.md)
-- [Debugging tips](debug.md)
 - [Tracing requests with correlation ID](tracing_correlation_id.md)
 
+Some feature documentation pages also have a troubleshooting section at the end
+that you can check for feature-specific help.
+
 If you need a testing environment to troubleshoot, see the
 [apps for a testing environment](test_environments.md).
diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
index 0c93d1ab3ee..15ec8d5940b 100644
--- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
+++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
@@ -1,295 +1,11 @@
 ---
-stage: Systems
-group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: reference
+redirect_to: 'https://docs.gitlab.com/charts/troubleshooting/kubernetes_cheat_sheet.html'
+remove_date: '2022-10-05'
 ---
 
-# Kubernetes, GitLab, and you **(FREE SELF)**
+This document was moved to [another location](https://docs.gitlab.com/charts/troubleshooting/kubernetes_cheat_sheet.html).
 
-This is a list of useful information regarding Kubernetes that the GitLab Support
-Team sometimes uses while troubleshooting. GitLab is making this public, so that anyone
-can make use of the Support team's collected knowledge
-
-WARNING:
-These commands **can alter or break** your Kubernetes components so use these at your own risk.
-
-If you are on a [paid tier](https://about.gitlab.com/pricing/) and are not sure how
-to use these commands, it is best to [contact Support](https://about.gitlab.com/support/)
-and they will assist you with any issues you are having.
-
-## Generic Kubernetes commands
-
-- How to authorize to your GCP project (can be especially useful if you have projects
-  under different GCP accounts):
-
-  ```shell
-  gcloud auth login
-  ```
-
-- How to access Kubernetes dashboard:
-
-  ```shell
-  # for minikube:
-  minikube dashboard —url
-  # for non-local installations if access via Kubectl is configured:
-  kubectl proxy
-  ```
-
-- How to SSH to a Kubernetes node and enter the container as root
-  <https://github.com/kubernetes/kubernetes/issues/30656>:
-
-  - For GCP, you may find the node name and run `gcloud compute ssh node-name`.
-  - List containers using `docker ps`.
-  - Enter container using `docker exec --user root -ti container-id bash`.
-
-- How to copy a file from local machine to a pod:
-
-  ```shell
-  kubectl cp file-name pod-name:./destination-path
-  ```
-
-- What to do with pods in `CrashLoopBackoff` status:
-
-  - Check logs via Kubernetes dashboard.
-  - Check logs via Kubectl:
-
-    ```shell
-    kubectl logs <webservice pod> -c dependencies
-    ```
-
-- How to tail all Kubernetes cluster events in real time:
-
-  ```shell
-  kubectl get events -w --all-namespaces
-  ```
-
-- How to get logs of the previously terminated pod instance:
-
-  ```shell
-  kubectl logs <pod-name> --previous
-  ```
-
-  No logs are kept in the containers/pods themselves. Everything is written to `stdout`.
-  This is the principle of Kubernetes, read [Twelve-factor app](https://12factor.net/)
-  for details.
-
-- How to get cron jobs configured on a cluster
-
-  ```shell
-  kubectl get cronjobs
-  ```
-
-  When one configures [cron-based backups](https://docs.gitlab.com/charts/backup-restore/backup.html#cron-based-backup),
-  you will be able to see the new schedule here. Some details about the schedules can be found
-  in [Running Automated Tasks with a CronJob](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#creating-a-cron-job)
-
-## GitLab-specific Kubernetes information
-
-- Minimal configuration that can be used to [test a Kubernetes Helm chart](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/620).
-
-- Tailing logs of a separate pod. An example for a `webservice` pod:
-
-  ```shell
-  kubectl logs gitlab-webservice-54fbf6698b-hpckq -c webservice
-  ```
-
-- Tail and follow all pods that share a label (in this case, `webservice`):
-
-  ```shell
-  # all containers in the webservice pods
-  kubectl logs -f -l app=webservice --all-containers=true --max-log-requests=50
-
-  # only the webservice containers in all webservice pods
-  kubectl logs -f -l app=webservice -c webservice --max-log-requests=50
-  ```
-
-- One can stream logs from all containers at once, similar to the Omnibus
-  command `gitlab-ctl tail`:
-
-  ```shell
-  kubectl logs -f -l release=gitlab --all-containers=true --max-log-requests=100
-  ```
-
-- Check all events in the `gitlab` namespace (the namespace name can be different if you
-  specified a different one when deploying the Helm chart):
-
-  ```shell
-  kubectl get events -w --namespace=gitlab
-  ```
-
-- Most of the useful GitLab tools (console, Rake tasks, etc) are found in the toolbox
-  pod. You may enter it and run commands inside or run them from the outside.
-
-  NOTE:
-  The `task-runner` pod was renamed to `toolbox` in GitLab 14.2 (charts 5.2).
-
-  ```shell
-  # find the pod
-  kubectl --namespace gitlab get pods -lapp=toolbox
-
-  # enter it
-  kubectl exec -it <toolbox-pod-name> -- bash
-
-  # open rails console
-  # rails console can be also called from other GitLab pods
-  /srv/gitlab/bin/rails console
-
-  # source-style commands should also work
-  cd /srv/gitlab && bundle exec rake gitlab:check RAILS_ENV=production
-
-  # run GitLab check. The output can be confusing and invalid because of the specific structure of GitLab installed via helm chart
-  /usr/local/bin/gitlab-rake gitlab:check
-
-  # open console without entering pod
-  kubectl exec -it <toolbox-pod-name> -- /srv/gitlab/bin/rails console
-
-  # check the status of DB migrations
-  kubectl exec -it <toolbox-pod-name> -- /usr/local/bin/gitlab-rake db:migrate:status
-  ```
-
-  You can also use `gitlab-rake`, instead of `/usr/local/bin/gitlab-rake`.
-
-- Troubleshooting **Infrastructure > Kubernetes clusters** integration:
-
-  - Check the output of `kubectl get events -w --all-namespaces`.
-  - Check the logs of pods within `gitlab-managed-apps` namespace.
-  - On the side of GitLab check Sidekiq log and Kubernetes log. When GitLab is installed
-    via Helm Chart, `kubernetes.log` can be found inside the Sidekiq pod.
-
-- How to get your initial administrator password <https://docs.gitlab.com/charts/installation/deployment.html#initial-login>:
-
-  ```shell
-  # find the name of the secret containing the password
-  kubectl get secrets | grep initial-root
-  # decode it
-  kubectl get secret <secret-name> -ojsonpath={.data.password} | base64 --decode ; echo
-  ```
-
-- How to connect to a GitLab PostgreSQL database.
-
-  NOTE:
-  The `task-runner` pod was renamed to `toolbox` in GitLab 14.2 (charts 5.2).
-
-  In GitLab 14.2 (chart 5.2) and later:
-
-  ```shell
-  kubectl exec -it <toolbox-pod-name> -- /srv/gitlab/bin/rails dbconsole --include-password --database main
-  ```
-
-  In GitLab 14.1 (chart 5.1) and earlier:
-
-  ```shell
-  kubectl exec -it <task-runner-pod-name> -- /srv/gitlab/bin/rails dbconsole --include-password
-  ```
-
-- How to get information about Helm installation status:
-
-  ```shell
-  helm status name-of-installation
-  ```
-
-- How to update GitLab installed using Helm Chart:
-
-  ```shell
-  helm repo upgrade
-
-  # get current values and redirect them to yaml file (analogue of gitlab.rb values)
-  helm get values <release name> > gitlab.yaml
-
-  # run upgrade itself
-  helm upgrade <release name> <chart path> -f gitlab.yaml
-  ```
-
-  After <https://gitlab.com/gitlab-org/charts/gitlab/-/issues/780> is fixed, it should
-  be possible to use [Updating GitLab using the Helm Chart](https://docs.gitlab.com/charts/index.html#updating-gitlab-using-the-helm-chart)
-  for upgrades.
-
-- How to apply changes to GitLab configuration:
-
-  - Modify the `gitlab.yaml` file.
-  - Run the following command to apply changes:
-
-    ```shell
-    helm upgrade <release name> <chart path> -f gitlab.yaml
-    ```
-
-- How to get the manifest for a release. It can be useful because it contains the information about
-all Kubernetes resources and dependent charts:
-
-  ```shell
-  helm get manifest <release name>
-  ```
-
-## Installation of minimal GitLab configuration via minikube on macOS
-
-This section is based on [Developing for Kubernetes with minikube](https://docs.gitlab.com/charts/development/minikube/index.html)
-and [Helm](https://docs.gitlab.com/charts/installation/tools.html#helm). Refer
-to those documents for details.
-
-- Install Kubectl via Homebrew:
-
-  ```shell
-  brew install kubernetes-cli
-  ```
-
-- Install minikube via Homebrew:
-
-  ```shell
-  brew cask install minikube
-  ```
-
-- Start minikube and configure it. If minikube cannot start, try running `minikube delete && minikube start`
-  and repeat the steps:
-
-  ```shell
-  minikube start --cpus 3 --memory 8192 # minimum amount for GitLab to work
-  minikube addons enable ingress
-  ```
-
-- Install Helm via Homebrew and initialize it:
-
-  ```shell
-  brew install helm
-  ```
-
-- Copy the [minikube minimum values YAML file](https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml)
-  to your workstation:
-
-  ```shell
-  curl --output values.yaml "https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml"
-  ```
-
-- Find the IP address in the output of `minikube ip` and update the YAML file with
-  this IP address.
-
-- Install the GitLab Helm Chart:
-
-  ```shell
-  helm repo add gitlab https://charts.gitlab.io
-  helm install gitlab -f <path-to-yaml-file> gitlab/gitlab
-  ```
-
-  If you want to modify some GitLab settings, you can use the above-mentioned configuration
-  as a base and create your own YAML file.
-
-- Monitor the installation progress via `helm status gitlab` and `minikube dashboard`.
-  The installation could take up to 20-30 minutes depending on the amount of resources
-  on your workstation.
-
-- When all the pods show either a `Running` or `Completed` status, get the GitLab password as
-  described in [Initial login](https://docs.gitlab.com/charts/installation/deployment.html#initial-login),
-  and log in to GitLab via the UI. It will be accessible via `https://gitlab.domain`
-  where `domain` is the value provided in the YAML file.
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+<!-- This redirect file can be deleted after 2022-10-05. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/administration/troubleshooting/linux_cheat_sheet.md b/doc/administration/troubleshooting/linux_cheat_sheet.md
index 0245af39e45..66d5fb82936 100644
--- a/doc/administration/troubleshooting/linux_cheat_sheet.md
+++ b/doc/administration/troubleshooting/linux_cheat_sheet.md
@@ -9,7 +9,7 @@ type: reference
 
 This is the GitLab Support Team's collection of information regarding Linux, that they
 sometimes use while troubleshooting. It is listed here for transparency,
-and it may be useful for users with experience with Linux. If you are currently
+and for users with experience with Linux. If you are currently
 having an issue with GitLab, you may want to check your [support options](https://about.gitlab.com/support/)
 first, before attempting to use this information.
 
@@ -107,6 +107,9 @@ grep -2 search_term <filename>
 # Search on all files in directory (recursively)
 grep -r search_term <directory>
 
+# Grep namespace/project/name of a GitLab repository
+grep 'fullpath' /var/opt/gitlab/git-data/repositories/@hashed/<repo hash>/.git/config
+
 # search through *.gz files is the same except with zgrep
 zgrep search_term <filename>
 
@@ -126,6 +129,7 @@ history
 # Search through command history
 <ctrl>-R
 
+
 # Execute last command with sudo
 sudo !!
 ```
diff --git a/doc/administration/troubleshooting/log_parsing.md b/doc/administration/troubleshooting/log_parsing.md
index 4cc62c08f4f..0320b2e52ce 100644
--- a/doc/administration/troubleshooting/log_parsing.md
+++ b/doc/administration/troubleshooting/log_parsing.md
@@ -47,7 +47,7 @@ grep <TERM> <FILE> | jq .
 jq -cR 'fromjson?' file.json | jq <COMMAND>
 ```
 
-By default `jq` will error out when it encounters a line that is not valid JSON.
+By default `jq` errors out when it encounters a line that is not valid JSON.
 This skips over all invalid lines and parses the rest.
 
 #### Print a JSON log's time range
@@ -152,6 +152,51 @@ CT: 297  ROUTE: /api/:version/projects/:id/repository/tags       DURS: 731.39,
 CT: 190  ROUTE: /api/:version/projects/:id/repository/commits    DURS: 1079.02,  979.68,  958.21
 ```
 
+### Print top API user agents
+
+```shell
+jq --raw-output '[.route, .ua] | @tsv' api_json.log | sort | uniq -c | sort -n
+```
+
+**Example output**:
+
+```plaintext
+  89 /api/:version/usage_data/increment_unique_users  # plus browser details
+ 567 /api/:version/jobs/:id/trace       gitlab-runner # plus version details
+1234 /api/:version/internal/allowed     GitLab-Shell
+```
+
+This sample response seems normal. A custom tool or script might be causing a high load
+if the output contains many:
+
+- Third party libraries like `python-requests` or `curl`.
+- [GitLab CLI clients](https://about.gitlab.com/partners/technology-partners/#cli-clients).
+
+You can also [use `fast-stats top`](#parsing-gitlab-logs-with-jq) to extract performance statistics.
+
+### Parsing `gitlab-workhorse/current`
+
+### Print top Workhorse user agents
+
+```shell
+jq --raw-output '[.uri, .user_agent] | @tsv' current | sort | uniq -c | sort -n
+```
+
+**Example output**:
+
+```plaintext
+  89 /api/graphql # plus browser details
+ 567 /api/v4/internal/allowed   GitLab-Shell
+1234 /api/v4/jobs/request       gitlab-runner # plus version details
+```
+
+Similar to the [API `ua` data](#print-top-api-user-agents),
+deviations from this common order might indicate scripts that could be optimized.
+
+The performance impact of runners checking for new jobs can be reduced by increasing
+[the `check_interval` setting](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section),
+for example.
+
 ### Parsing `gitlab-rails/geo.log`
 
 #### Find most common Geo sync errors
@@ -166,7 +211,7 @@ jq --raw-output 'select(.severity == "ERROR") | [.project_path, .message] | @tsv
 
 ### Parsing `gitaly/current`
 
-The following examples are useful to [troubleshoot Gitaly](../gitaly/troubleshooting.md).
+Use the following examples to [troubleshoot Gitaly](../gitaly/troubleshooting.md).
 
 #### Find all Gitaly requests sent from web UI
 
diff --git a/doc/administration/troubleshooting/navigating_gitlab_via_rails_console.md b/doc/administration/troubleshooting/navigating_gitlab_via_rails_console.md
index 51ef3d95a4e..09a5cb8d185 100644
--- a/doc/administration/troubleshooting/navigating_gitlab_via_rails_console.md
+++ b/doc/administration/troubleshooting/navigating_gitlab_via_rails_console.md
@@ -1,465 +1,11 @@
 ---
-stage: Systems
-group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: '../operations/rails_console.md'
+remove_date: '2022-10-05'
 ---
 
-# Navigating GitLab via Rails console **(FREE SELF)**
+This document was moved to [another location](../operations/rails_console.md).
 
-At the heart of GitLab is a web application [built using the Ruby on Rails
-framework](https://about.gitlab.com/blog/2018/10/29/why-we-use-rails-to-build-gitlab/).
-Thanks to this, we also get access to the amazing tools built right into Rails.
-This guide introduces the [Rails console](../operations/rails_console.md#starting-a-rails-console-session)
-and the basics of interacting with your GitLab instance from the command line.
-
-WARNING:
-The Rails console interacts directly with your GitLab instance. In many cases,
-there are no handrails to prevent you from permanently modifying, corrupting
-or destroying production data. If you would like to explore the Rails console
-with no consequences, you are strongly advised to do so in a test environment.
-
-This guide is targeted at GitLab system administrators who are troubleshooting
-a problem or must retrieve some data that can only be done through direct
-access of the GitLab application. Basic knowledge of Ruby is needed (try [this
-30-minute tutorial](https://try.ruby-lang.org/) for a quick introduction).
-Rails experience is helpful to have but not a must.
-
-## Starting a Rails console session
-
-Your type of GitLab installation determines how
-[to start a rails console](../operations/rails_console.md).
-
-The following code examples take place inside the Rails console and also
-assume an Omnibus GitLab installation.
-
-## Active Record objects
-
-### Looking up database-persisted objects
-
-Under the hood, Rails uses [Active Record](https://guides.rubyonrails.org/active_record_basics.html),
-an object-relational mapping system, to read, write, and map application objects
-to the PostgreSQL database. These mappings are handled by Active Record models,
-which are Ruby classes defined in a Rails app. For GitLab, the model classes
-can be found at `/opt/gitlab/embedded/service/gitlab-rails/app/models`.
-
-Let's enable debug logging for Active Record so we can see the underlying
-database queries made:
-
-```ruby
-ActiveRecord::Base.logger = Logger.new($stdout)
-```
-
-Now, let's try retrieving a user from the database:
-
-```ruby
-user = User.find(1)
-```
-
-Which would return:
-
-```ruby
-D, [2020-03-05T16:46:25.571238 #910] DEBUG -- :   User Load (1.8ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
-=> #<User id:1 @root>
-```
-
-We can see that we've queried the `users` table in the database for a row whose
-`id` column has the value `1`, and Active Record has translated that database
-record into a Ruby object that we can interact with. Try some of the following:
-
-- `user.username`
-- `user.created_at`
-- `user.admin`
-
-By convention, column names are directly translated into Ruby object attributes,
-so you should be able to do `user.<column_name>` to view the attribute's value.
-
-Also by convention, Active Record class names (singular and in camel case) map
-directly onto table names (plural and in snake case) and vice versa. For example,
-the `users` table maps to the `User` class, while the `application_settings`
-table maps to the `ApplicationSetting` class.
-
-You can find a list of tables and column names in the Rails database schema,
-available at `/opt/gitlab/embedded/service/gitlab-rails/db/schema.rb`.
-
-You can also look up an object from the database by attribute name:
-
-```ruby
-user = User.find_by(username: 'root')
-```
-
-Which would return:
-
-```ruby
-D, [2020-03-05T17:03:24.696493 #910] DEBUG -- :   User Load (2.1ms)  SELECT "users".* FROM "users" WHERE "users"."username" = 'root' LIMIT 1
-=> #<User id:1 @root>
-```
-
-Give the following a try:
-
-- `User.find_by(email: 'admin@example.com')`
-- `User.where.not(admin: true)`
-- `User.where('created_at < ?', 7.days.ago)`
-
-Did you notice that the last two commands returned an `ActiveRecord::Relation`
-object that appeared to contain multiple `User` objects?
-
-Up to now, we've been using `.find` or `.find_by`, which are designed to return
-only a single object (notice the `LIMIT 1` in the generated SQL query?).
-`.where` is used when it is desirable to get a collection of objects.
-
-Let's get a collection of non-administrator users and see what we can do with it:
-
-```ruby
-users = User.where.not(admin: true)
-```
-
-Which would return:
-
-```ruby
-D, [2020-03-05T17:11:16.845387 #910] DEBUG -- :   User Load (2.8ms)  SELECT "users".* FROM "users" WHERE "users"."admin" != TRUE LIMIT 11
-=> #<ActiveRecord::Relation [#<User id:3 @support-bot>, #<User id:7 @alert-bot>, #<User id:5 @carrie>, #<User id:4 @bernice>, #<User id:2 @anne>]>
-```
-
-Now, try the following:
-
-- `users.count`
-- `users.order(created_at: :desc)`
-- `users.where(username: 'support-bot')`
-
-In the last command, we see that we can chain `.where` statements to generate
-more complex queries. Notice also that while the collection returned contains
-only a single object, we cannot directly interact with it:
-
-```ruby
-users.where(username: 'support-bot').username
-```
-
-Which would return:
-
-```ruby
-Traceback (most recent call last):
-        1: from (irb):37
-D, [2020-03-05T17:18:25.637607 #910] DEBUG -- :   User Load (1.6ms)  SELECT "users".* FROM "users" WHERE "users"."admin" != TRUE AND "users"."username" = 'support-bot' LIMIT 11
-NoMethodError (undefined method `username' for #<ActiveRecord::Relation [#<User id:3 @support-bot>]>)
-Did you mean?  by_username
-```
-
-Let's retrieve the single object from the collection by using the `.first`
-method to get the first item in the collection:
-
-```ruby
-users.where(username: 'support-bot').first.username
-```
-
-We now get the result we wanted:
-
-```ruby
-D, [2020-03-05T17:18:30.406047 #910] DEBUG -- :   User Load (2.6ms)  SELECT "users".* FROM "users" WHERE "users"."admin" != TRUE AND "users"."username" = 'support-bot' ORDER BY "users"."id" ASC LIMIT 1
-=> "support-bot"
-```
-
-For more on different ways to retrieve data from the database using Active
-Record, please see the [Active Record Query Interface documentation](https://guides.rubyonrails.org/active_record_querying.html).
-
-### Modifying Active Record objects
-
-In the previous section, we learned about retrieving database records using
-Active Record. Now, let's learn how to write changes to the database.
-
-First, let's retrieve the `root` user:
-
-```ruby
-user = User.find_by(username: 'root')
-```
-
-Next, let's try updating the user's password:
-
-```ruby
-user.password = 'password'
-user.save
-```
-
-Which would return:
-
-```ruby
-Enqueued ActionMailer::MailDeliveryJob (Job ID: 05915c4e-c849-4e14-80bb-696d5ae22065) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", #<GlobalID:0x00007f42d8ccebe8 @uri=#<URI::GID gid://gitlab/User/1>>
-=> true
-```
-
-Here, we see that the `.save` command returned `true`, indicating that the
-password change was successfully saved to the database.
-
-We also see that the save operation triggered some other action -- in this case
-a background job to deliver an email notification. This is an example of an
-[Active Record callback](https://guides.rubyonrails.org/active_record_callbacks.html)
--- code which is designated to run in response to events in the Active Record
-object life cycle. This is also why using the Rails console is preferred when
-direct changes to data is necessary as changes made via direct database queries
-do not trigger these callbacks.
-
-It's also possible to update attributes in a single line:
-
-```ruby
-user.update(password: 'password')
-```
-
-Or update multiple attributes at once:
-
-```ruby
-user.update(password: 'password', email: 'hunter2@example.com')
-```
-
-Now, let's try something different:
-
-```ruby
-# Retrieve the object again so we get its latest state
-user = User.find_by(username: 'root')
-user.password = 'password'
-user.password_confirmation = 'hunter2'
-user.save
-```
-
-This returns `false`, indicating that the changes we made were not saved to the
-database. You can probably guess why, but let's find out for sure:
-
-```ruby
-user.save!
-```
-
-This should return:
-
-```ruby
-Traceback (most recent call last):
-        1: from (irb):64
-ActiveRecord::RecordInvalid (Validation failed: Password confirmation doesn't match Password)
-```
-
-Aha! We've tripped an [Active Record Validation](https://guides.rubyonrails.org/active_record_validations.html).
-Validations are business logic put in place at the application-level to prevent
-unwanted data from being saved to the database and in most cases come with
-helpful messages letting you know how to fix the problem inputs.
-
-We can also add the bang (Ruby speak for `!`) to `.update`:
-
-```ruby
-user.update!(password: 'password', password_confirmation: 'hunter2')
-```
-
-In Ruby, method names ending with `!` are commonly known as "bang methods". By
-convention, the bang indicates that the method directly modifies the object it
-is acting on, as opposed to returning the transformed result and leaving the
-underlying object untouched. For Active Record methods that write to the
-database, bang methods also serve an additional function: they raise an
-explicit exception whenever an error occurs, instead of just returning `false`.
-
-We can also skip validations entirely:
-
-```ruby
-# Retrieve the object again so we get its latest state
-user = User.find_by(username: 'root')
-user.password = 'password'
-user.password_confirmation = 'hunter2'
-user.save!(validate: false)
-```
-
-This is not recommended, as validations are usually put in place to ensure the
-integrity and consistency of user-provided data.
-
-A validation error prevents the entire object from being saved to
-the database. You can see a little of this in the section below. If you're getting
-a mysterious red banner in the GitLab UI when submitting a form, this can often
-be the fastest way to get to the root of the problem.
-
-### Interacting with Active Record objects
-
-At the end of the day, Active Record objects are just normal Ruby objects. As
-such, we can define methods on them which perform arbitrary actions.
-
-For example, GitLab developers have added some methods which help with
-two-factor authentication:
-
-```ruby
-def disable_two_factor!
-  transaction do
-    update(
-      otp_required_for_login:      false,
-      encrypted_otp_secret:        nil,
-      encrypted_otp_secret_iv:     nil,
-      encrypted_otp_secret_salt:   nil,
-      otp_grace_period_started_at: nil,
-      otp_backup_codes:            nil
-    )
-    self.u2f_registrations.destroy_all # rubocop: disable DestroyAll
-  end
-end
-
-def two_factor_enabled?
-  two_factor_otp_enabled? || two_factor_u2f_enabled?
-end
-```
-
-(See: `/opt/gitlab/embedded/service/gitlab-rails/app/models/user.rb`)
-
-We can then use these methods on any user object:
-
-```ruby
-user = User.find_by(username: 'root')
-user.two_factor_enabled?
-user.disable_two_factor!
-```
-
-Some methods are defined by gems, or Ruby software packages, which GitLab uses.
-For example, the [StateMachines](https://github.com/state-machines/state_machines-activerecord)
-gem which GitLab uses to manage user state:
-
-```ruby
-state_machine :state, initial: :active do
-  event :block do
-
-  ...
-
-  event :activate do
-
-  ...
-
-end
-```
-
-Give it a try:
-
-```ruby
-user = User.find_by(username: 'root')
-user.state
-user.block
-user.state
-user.activate
-user.state
-```
-
-Earlier, we mentioned that a validation error prevents the entire object
-from being saved to the database. Let's see how this can have unexpected
-interactions:
-
-```ruby
-user.password = 'password'
-user.password_confirmation = 'hunter2'
-user.block
-```
-
-We get `false` returned! Let's find out what happened by adding a bang as we did
-earlier:
-
-```ruby
-user.block!
-```
-
-Which would return:
-
-```ruby
-Traceback (most recent call last):
-        1: from (irb):87
-StateMachines::InvalidTransition (Cannot transition state via :block from :active (Reason(s): Password confirmation doesn't match Password))
-```
-
-We see that a validation error from what feels like a completely separate
-attribute comes back to haunt us when we try to update the user in any way.
-
-In practical terms, we sometimes see this happen with GitLab administration settings --
-validations are sometimes added or changed in a GitLab update, resulting in
-previously saved settings now failing validation. Because you can only update
-a subset of settings at once through the UI, in this case the only way to get
-back to a good state is direct manipulation via Rails console.
-
-### Commonly used Active Record models and how to look up objects
-
-**Get a user by primary email address or username:**
-
-```ruby
-User.find_by(email: 'admin@example.com')
-User.find_by(username: 'root')
-```
-
-**Get a user by primary OR secondary email address:**
-
-```ruby
-User.find_by_any_email('user@example.com')
-```
-
-The `find_by_any_email` method is a custom method added by GitLab developers rather
-than a Rails-provided default method.
-
-**Get a collection of administrator users:**
-
-```ruby
-User.admins
-```
-
-`admins` is a [scope convenience method](https://guides.rubyonrails.org/active_record_querying.html#scopes)
-which does `where(admin: true)` under the hood.
-
-**Get a project by its path:**
-
-```ruby
-Project.find_by_full_path('group/subgroup/project')
-```
-
-`find_by_full_path` is a custom method added by GitLab developers rather
-than a Rails-provided default method.
-
-**Get a project's issue or merge request by its numeric ID:**
-
-```ruby
-project = Project.find_by_full_path('group/subgroup/project')
-project.issues.find_by(iid: 42)
-project.merge_requests.find_by(iid: 42)
-```
-
-`iid` means "internal ID" and is how we keep issue and merge request IDs
-scoped to each GitLab project.
-
-**Get a group by its path:**
-
-```ruby
-Group.find_by_full_path('group/subgroup')
-```
-
-**Get a group's related groups:**
-
-```ruby
-group = Group.find_by_full_path('group/subgroup')
-
-# Get a group's parent group
-group.parent
-
-# Get a group's child groups
-group.children
-```
-
-**Get a group's projects:**
-
-```ruby
-group = Group.find_by_full_path('group/subgroup')
-
-# Get group's immediate child projects
-group.projects
-
-# Get group's child projects, including those in subgroups
-group.all_projects
-```
-
-**Get CI pipeline or builds:**
-
-```ruby
-Ci::Pipeline.find(4151)
-Ci::Build.find(66124)
-```
-
-The pipeline and job ID numbers increment globally across your GitLab
-instance, so there's no requirement to use an internal ID attribute to look them up,
-unlike with issues or merge requests.
-
-**Get the current application settings object:**
-
-```ruby
-ApplicationSetting.current
-```
+<!-- This redirect file can be deleted after <2022-10-05>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md
index cdbf786bdb2..61b661d45f8 100644
--- a/doc/administration/troubleshooting/postgresql.md
+++ b/doc/administration/troubleshooting/postgresql.md
@@ -54,7 +54,7 @@ This section is for links to information elsewhere in the GitLab documentation.
   - Including [troubleshooting](../postgresql/replication_and_failover.md#troubleshooting)
     `gitlab-ctl patroni check-leader` and PgBouncer errors.
 
-- [Developer database documentation](../../development/index.md#database-guides),
+- [Developer database documentation](../../development/feature_development.md#database-guides),
   some of which is absolutely not for production use. Including:
   - Understanding EXPLAIN plans.
 
diff --git a/doc/administration/troubleshooting/ssl.md b/doc/administration/troubleshooting/ssl.md
index d5d50127ad5..e1cd92a788f 100644
--- a/doc/administration/troubleshooting/ssl.md
+++ b/doc/administration/troubleshooting/ssl.md
@@ -9,7 +9,7 @@ type: reference
 
 This page contains a list of common SSL-related errors and scenarios that you
 may encounter while working with GitLab. It should serve as an addition to the
-main SSL docs available here:
+main SSL documentation:
 
 - [Omnibus SSL Configuration](https://docs.gitlab.com/omnibus/settings/ssl.html).
 - [Self-signed certificates or custom Certification Authorities for GitLab Runner](https://docs.gitlab.com/runner/configuration/tls-self-signed.html).
@@ -110,8 +110,7 @@ https://gitlab.domain.tld/api/v4/jobs/request: Post https://gitlab.domain.tld/ap
 x509: certificate signed by unknown authority
 ```
 
-If you encounter a similar problem, add your certificate to `/etc/gitlab-runner/certs`,
-and the restart the runner by running `gitlab-runner restart`.
+Follow the details in [Self-signed certificates or custom Certification Authorities for GitLab Runner](https://docs.gitlab.com/runner/configuration/tls-self-signed.html).
 
 ## Mirroring a remote GitLab repository that uses a self-signed SSL certificate
 
@@ -237,7 +236,7 @@ remote server that is serving only HTTP.
 
 One scenario is that you're using [object storage](../object_storage.md), which
 isn't served under HTTPS. GitLab is misconfigured and attempts a TLS handshake,
-but the object storage will respond with plain HTTP.
+but the object storage responds with plain HTTP.
 
 ## `schannel: SEC_E_UNTRUSTED_ROOT`
 
@@ -247,7 +246,7 @@ If you're on Windows and get the following error:
 Fatal: unable to access 'https://gitlab.domain.tld/group/project.git': schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted."
 ```
 
-You may need to specify that Git should use OpenSSL:
+You must specify that Git should use OpenSSL:
 
 ```shell
 git config --system http.sslbackend openssl
diff --git a/doc/administration/troubleshooting/test_environments.md b/doc/administration/troubleshooting/test_environments.md
index 94d17ba714e..d240103a51c 100644
--- a/doc/administration/troubleshooting/test_environments.md
+++ b/doc/administration/troubleshooting/test_environments.md
@@ -45,7 +45,7 @@ docker run --name gitlab_saml -p 8080:8080 -p 8443:8443 \
 -d jamedjo/test-saml-idp
 ```
 
-The following will also need to go in your `/etc/gitlab/gitlab.rb`. See [our SAML docs](../../integration/saml.md)
+The following must also go in your `/etc/gitlab/gitlab.rb`. See [our SAML docs](../../integration/saml.md)
 for more, as well as the list of [default usernames, passwords, and emails](https://hub.docker.com/r/jamedjo/test-saml-idp/#usage).
 
 ```ruby
diff --git a/doc/administration/troubleshooting/tracing_correlation_id.md b/doc/administration/troubleshooting/tracing_correlation_id.md
index fed3604057b..418dd729066 100644
--- a/doc/administration/troubleshooting/tracing_correlation_id.md
+++ b/doc/administration/troubleshooting/tracing_correlation_id.md
@@ -32,7 +32,7 @@ documentation for some popular browsers.
 
 To locate a relevant request and view its correlation ID:
 
-1. Enable persistent logging in your network monitor. Some actions in GitLab will redirect you quickly after you submit a form, so this will help capture all relevant activity.
+1. Enable persistent logging in your network monitor. Some actions in GitLab redirect you quickly after you submit a form, so this helps capture all relevant activity.
 1. To help isolate the requests you are looking for, you can filter for `document` requests.
 1. Select the request of interest to view further detail.
 1. Go to the **Headers** section and look for **Response Headers**. There you should find an `x-request-id` header with a
@@ -121,7 +121,7 @@ find /var/log/gitlab -type f -mtime 0 -exec grep 'LOt9hgi1TV4' '{}' '+'
 ### Searching in distributed architectures
 
 If you have done some horizontal scaling in your GitLab infrastructure, then
-you will need to search across _all_ of your GitLab nodes. You can do this with
+you must search across _all_ of your GitLab nodes. You can do this with
 some sort of log aggregation software like Loki, ELK, Splunk, or others.
 
 You can use a tool like Ansible or PSSH (parallel SSH) that can execute identical commands across your servers in