@@ -26,7 +26,7 @@ GitLab, thanks to [Lograge](https://github.com/roidrage/lograge/). Note that
requests from the API are logged to a separate file in `api_json.log`.
Each line contains a JSON line that can be ingested by services like Elasticsearch and Splunk.
Line breaks have been added to this example for legibility:
Line breaks were added to examples for legibility:
```json
{
...
...
@@ -79,7 +79,7 @@ seconds:
User clone and fetch activity using HTTP transport appears in this log as `action: git_upload_pack`.
In addition, the log contains the originating IP address,
(`remote_ip`),the user's ID (`user_id`), and username (`username`).
(`remote_ip`),the user's ID (`user_id`), and username (`username`).
Some endpoints such as `/search` may make requests to Elasticsearch if using
[Advanced Global Search](../user/search/advanced_global_search.md). These will
...
...
@@ -227,7 +227,7 @@ It helps you see requests made directly to the API. For example:
}
```
This entry shows an access to an internal endpoint to check whether an
This entry shows an internal endpoint accessed to check whether an
associated SSH key can download the project in question via a `git fetch` or
`git clone`. In this example, we see:
...
...
@@ -320,7 +320,7 @@ packages or in `/home/git/gitlab/log/kubernetes.log` for
installations from source.
It logs information related to the Kubernetes Integration including errors
during installing cluster applications on your GitLab managed Kubernetes
during installing cluster applications on your managed Kubernetes
clusters.
Each line contains a JSON line that can be ingested by services like Elasticsearch and Splunk.
...
...
@@ -362,7 +362,7 @@ After 12.2, this file was renamed from `githost.log` to
`git_json.log` and stored in JSON format.
GitLab has to interact with Git repositories, but in some rare cases
something can go wrong, and in this case you will know what exactly
something can go wrong, and in this case you may need know what exactly
happened. This log file contains all failed requests from GitLab to Git
repositories. In the majority of cases this file will be useful for developers
only. For example:
...
...
@@ -473,8 +473,8 @@ This file lives in `/var/log/gitlab/gitlab-rails/sidekiq_client.log` for
Omnibus GitLab packages or in `/home/git/gitlab/log/sidekiq_client.log` for
installations from source.
This file contains logging information about jobs before they are start
being processed by Sidekiq, for example before being enqueued.
This file contains logging information about jobs before Sidekiq starts
processing them, such as before being enqueued.
This log file follows the same structure as
[`sidekiq.log`](#sidekiqlog), so it will be structured as JSON if
...
...
@@ -571,32 +571,45 @@ User clone/fetch activity using SSH transport appears in this log as `executing
## Gitaly Logs
This file lives in `/var/log/gitlab/gitaly/current` and is produced by [runit](http://smarden.org/runit/). `runit` is packaged with Omnibus and a brief explanation of its purpose is available [in the omnibus documentation](https://docs.gitlab.com/omnibus/architecture/#runit). [Log files are rotated](http://smarden.org/runit/svlogd.8.html), renamed in Unix timestamp format and `gzip`-compressed (e.g.`@1584057562.s`).
This file lives in `/var/log/gitlab/gitaly/current` and is produced by [runit](http://smarden.org/runit/). `runit` is packaged with Omnibus GitLab and a brief explanation of its purpose is available [in the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/architecture/#runit). [Log files are rotated](http://smarden.org/runit/svlogd.8.html), renamed in Unix timestamp format, and `gzip`-compressed (like`@1584057562.s`).
### `grpc.log`
This file lives in `/var/log/gitlab/gitlab-rails/grpc.log` for Omnibus GitLab packages. Native [gRPC](https://grpc.io/) logging used by Gitaly.
## `puma_stderr.log` & `puma_stdout.log`
## Puma Logs
This file lives in `/var/log/gitlab/puma/puma_stderr.log` and `/var/log/gitlab/puma/puma_stdout.log` for
Omnibus GitLab packages or in `/home/git/gitlab/log/puma_stderr.log` and `/home/git/gitlab/log/puma_stdout.log`
for installations from source.
### `puma_stdout.log`
This file lives in `/var/log/gitlab/puma/puma_stdout.log` for
Omnibus GitLab packages, and `/home/git/gitlab/log/puma_stdout.log` for
installations from source.
### `puma_stderr.log`
This file lives in `/var/log/gitlab/puma/puma_stderr.log` for
Omnibus GitLab packages, or in `/home/git/gitlab/log/puma_stderr.log` for
installations from source.
## `unicorn_stderr.log` & `unicorn_stdout.log`
## Unicorn Logs
NOTE: **Note:**
Starting with GitLab 13.0, Puma is the default web server used in GitLab
all-in-one package based installations as well as GitLab Helm chart deployments.
This file lives in `/var/log/gitlab/unicorn/unicorn_stderr.log` and `/var/log/gitlab/unicorn/unicorn_stdout.log` for
Omnibus GitLab packages or in `/home/git/gitlab/log/unicorn_stderr.log` and `/home/git/gitlab/log/unicorn_stdout.log`
### `unicorn_stdout.log`
This file lives in `/var/log/gitlab/unicorn/unicorn_stdout.log` for
Omnibus GitLab packages or in `/home/git/gitlab/log/unicorn_stdout.log` for
for installations from source.
### `unicorn_stderr.log`
This file lives in `/var/log/gitlab/unicorn/unicorn_stderr.log` for
Omnibus GitLab packages or in `/home/git/gitlab/log/unicorn_stderr.log` for
for installations from source.
Unicorn is a high-performance forking Web server which is used for
serving the GitLab application. You can look at this log if, for
example, your application does not respond. This log contains all
information about the state of Unicorn processes at any given time.
These logs contain all information about the state of Unicorn processes at any given time.
```plaintext
I, [2015-02-13T06:14:46.680381 #9047] INFO -- : Refreshing Gem list