Add docs for `api_json.log` file

[ci skip]

doc/administration/logs.md

@@ -18,8 +18,7 @@ other than production, the corresponding logfile is shown here.)
 
 It contains a structured log for Rails controller requests received from
 GitLab, thanks to [Lograge](https://github.com/roidrage/lograge/). Note that
-requests from the API [are not yet logged to this
-file](https://gitlab.com/gitlab-org/gitlab-ce/issues/36189).
+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 Elasticsearch, Splunk, etc. For example:
 
@@ -73,6 +72,27 @@ In this example we can see that server processed an HTTP request with URL
 19:34:53 +0200. Also we can see that request was processed by
 `Projects::TreeController`.
 
+## `api_json.log`
+
+Introduced in GitLab 10.0, this file lives in
+`/var/log/gitlab/gitlab-rails/api_json.log` for Omnibus GitLab packages or in
+`/home/git/gitlab/log/api_json.log` for installations from source.
+
+It helps you see requests made directly to the API. For example:
+
+```json
+{"time":"2017-10-10T12:30:11.579Z","severity":"INFO","duration":16.84,"db":1.57,"view":15.27,"status":200,"method":"POST","path":"/api/v4/internal/allowed","params":{"action":"git-upload-pack","changes":"_any","gl_repository":null,"project":"root/foobar.git","protocol":"ssh","env":"{}","key_id":"[FILTERED]","secret_token":"[FILTERED]"},"host":"127.0.0.1","ip":"127.0.0.1","ua":"Ruby"}
+```
+
+This entry above shows an access to an internal endpoint 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:
+
+1. `method`: The HTTP method used to make the request
+1. `path`: The relative path of the query
+1. `params`: Key-value pairs passed in a query string or HTTP body. Sensitive parameters (e.g. passwords, tokens, etc.) are filtered out.
+1. `ua`: The User-Agent of the requester
+
 ## `application.log`
 
 This file lives in `/var/log/gitlab/gitlab-rails/application.log` for