Add troubleshooting instructions for debugging (#1358)

* debugging
* add streaming instructions
* add streaming log_level to config page
This commit is contained in:
Michael Stanclift 2023-12-10 14:41:43 -06:00 committed by GitHub
parent ae825222ea
commit 4f4b1e6935
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 16 additions and 1 deletions

View File

@ -198,7 +198,11 @@ If set to true, Mastodon will answer requests for files in its `public` director
#### `RAILS_LOG_LEVEL` #### `RAILS_LOG_LEVEL`
Determines the amount of logs generated by Mastodon. Defaults to `info`, which generates a log entry about every request served by Mastodon and every background job processed by Mastodon. This can be useful but can get quite noisy and strain the I/O of your machine if there is a lot of traffic/activity. In that case, `warn` is recommended, which will only output information about things that are going wrong, and otherwise stay quiet. Possible values are `debug`, `info`, `warn`, `error`, `fatal` and `unknown`. Determines the amount of logs generated by Mastodon for the web and Sidekiq processes. Defaults to `info`, which generates a log entry about every request served by Mastodon and every background job processed by Mastodon. This can be useful but can get quite noisy and strain the I/O of your machine if there is a lot of traffic/activity. In that case, `warn` is recommended, which will only output information about things that are going wrong, and otherwise stay quiet. Possible values are `debug`, `info`, `warn`, `error`, `fatal` and `unknown`.
#### `LOG_LEVEL`
Determines the amount of logs generated by Mastodon for the streaming processes. Defaults to `info`. Possible values are `silly` and `info`.
#### `TRUSTED_PROXY_IP` #### `TRUSTED_PROXY_IP`

View File

@ -15,6 +15,17 @@ Specific details of server-side errors are _never_ displayed to the public, as t
Each response from Mastodons web server carries a header with a unique request ID, which is also reflected in the logs. By inspecting the headers of the error page, you can easily find the corresponding stack trace in the log. Each response from Mastodons web server carries a header with a unique request ID, which is also reflected in the logs. By inspecting the headers of the error page, you can easily find the corresponding stack trace in the log.
## **I'm not seeing much in my logs. How do I enable additional logging/debugging information?**
By default your logs will show `info` level logging. To see more debugging messages, you can your `.env.production` file to increase the level, for the relevant service:
- **Web/Sidekiq:** Set the value of `RAILS_LOG_LEVEL` to `debug` and then restart the service that you're attempting to troubleshoot.
- **Streaming:** Set the value of `LOG_LEVEL` to `silly` and then restart the service that you're attempting to troubleshoot.
More information on other logging levels for these option can be found on the [Configuring your environment](https://docs.joinmastodon.org/admin/config) page.
The `debug` or `silly` levels can be very verbose and you should take care to change the log level back to a lower level, once you have completed your troubleshooting.
## **After an upgrade to a newer version, some pages look weird, like they have unstyled elements. Why?** ## **After an upgrade to a newer version, some pages look weird, like they have unstyled elements. Why?**
Check that you have run `RAILS_ENV=production bin/rails assets:precompile` after the upgrade, and restarted Mastodons web process, because it looks like its serving outdated stylesheets and scripts. Its also possible that the precompilation fails due to a lack of RAM, as webpack is unfortunately extremely memory-hungry. If that is the case, make sure you have some swap space assigned. Alternatively, its possible to precompile the assets on a different machine, then copy over the `public/packs` directory. Check that you have run `RAILS_ENV=production bin/rails assets:precompile` after the upgrade, and restarted Mastodons web process, because it looks like its serving outdated stylesheets and scripts. Its also possible that the precompilation fails due to a lack of RAM, as webpack is unfortunately extremely memory-hungry. If that is the case, make sure you have some swap space assigned. Alternatively, its possible to precompile the assets on a different machine, then copy over the `public/packs` directory.