From 61d28eeea43b0359177416d625d07c3a3e556b92 Mon Sep 17 00:00:00 2001 From: Sergey Golitsynskiy Date: Thu, 3 Mar 2022 13:51:26 -0500 Subject: [PATCH] First pass at editing logging config docs --- doc/source/admin/config_logging.rst | 121 ++-------------------------- 1 file changed, 5 insertions(+), 116 deletions(-) diff --git a/doc/source/admin/config_logging.rst b/doc/source/admin/config_logging.rst index db3e9fc5073..3d713ae096f 100644 --- a/doc/source/admin/config_logging.rst +++ b/doc/source/admin/config_logging.rst @@ -10,18 +10,9 @@ There are two ways in which you can configure logging for Galaxy servers: 2. More complex configuration using the Python :mod:`logging` module's :func:`logging.config.dictConfig` or :func:`logging.config.fileConfig`. By default, Galaxy logs all messages to standard output at the ``DEBUG`` logging level, unless the ``--daemon`` argument -is passed to ``run.sh``, in which case, output is logged to the file ``galaxy.log`` in the current directory. +is passed to ``run.sh``, in which case, output is logged to a location configured in `gravity`_. -The way in which you configure logging depends on whether you are using a YAML or INI configuration file, and also on -whether you are using the uWSGI application server, or Python Paste. Galaxy servers that were created starting with -Galaxy Release 18.01 or later use a YAML configuration file with uWSGI. Galaxy servers that were created with 17.09 or -older use an INI configuration file, and Python Paste by default, but they could be configured to run under uWSGI (and -this was the recommendation for production servers). If you upgrade a pre-18.01 server running under Paste to 18.01 or -later but do not convert your INI config (``galaxy.ini``) to a YAML config (``galaxy.yml``), the INI config and Paste -will still be used. - -uWSGI, Paste, and related terminology are explained in detail in the :doc:`Scaling and Load Balancing ` -documentation. +Gravity and related terminology are explained in detail in the :doc:`Scaling and Load Balancing ` documentation. Basic Configuration ---------------------------- @@ -32,9 +23,8 @@ is controlled by the ``log_level`` configuration option. If not set, Galaxy logs all messages at the ``DEBUG`` level (versions prior to 18.01 defaulted to ``INFO`` if unset, but the default config file shipped with ``log_level`` explicitly set to ``DEBUG`` for development purposes). -Galaxy logs all messages to standard output by default if running in the foreground. If running in the background (``sh -run.sh --daemon``) under uWSGI, the log is written to ``galaxy.log`` in the current directory. If running in the -background under Paste, the log is written to ``paster.log``. +Galaxy logs all messages to standard output by default if running in the foreground. If running in the background, the +log is written to a location configured in `gravity`_. **Setting the log level:** @@ -68,7 +58,7 @@ To change the log file name or location, use the ``$GALAXY_LOG`` environment var Advanced Configuration ---------------------------- -For more useful and manageable logging when running Galaxy with forking application stacks (e.g. uWSGI) where multiple +For more useful and manageable logging when running Galaxy with forking application stacks where multiple Galaxy server processes are forked after the Galaxy application is loaded, some extensions to standard Python :mod:`logging` are available in Galaxy: @@ -98,107 +88,6 @@ The default as of this Galaxy release can be found (in Python syntax) in the .. include:: config_logging_default_yaml.rst -Split Logfiles -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Using ``run.sh --daemon`` causes Galaxy to log to ``galaxy.log``, but this is done using uWSGI's logging functionality -and does not allow for splitting logging in to multiple files. The following logging definition uses the -``filename_template`` custom handler configuration option to split logging in to the files ``galaxy_web_0.log`` (the -combined messages of all web workers) and ``galaxy_job-handlers_N.log`` where ``N`` is the instance ID of the server -process in its pool (aka the mule's position in its farm argument). In addition to the split file logging, the combined -output is also still logged to standard error. - -.. code-block:: yaml - - galaxy: - logging: - filters: - stack: - (): galaxy.web.stack.application_stack_log_filter - formatters: - stack: - (): galaxy.web.stack.application_stack_log_formatter - handlers: - console: - class: logging.StreamHandler - filters: - - stack - formatter: stack - level: DEBUG - stream: ext://sys.stderr - files: - class: logging.FileHandler - filters: - - stack - level: DEBUG - formatter: stack - filename: galaxy_default.log - filename_template: galaxy_{pool_name}_{server_id}.log - loggers: - galaxy: - handlers: - - console - - files - level: DEBUG - propagate: 0 - qualname: galaxy - paste.httpserver.ThreadPool: - level: WARN - qualname: paste.httpserver.ThreadPool - routes.middleware: - level: WARN - qualname: routes.middleware - root: - handlers: - - console - - files - level: INFO - version: 1 - -The list of available template facts for use in ``filename_template`` with all Galaxy application server types, and -their values under the various possible :doc:`server deployment scenarios ` are given below: - -+-------------------+-----------------------------------------------------------------------------------------------+ -| Fact | Application server | -+-------------------+-------------------------------+-------------------------------+-------------------------------+ -| | Paste/webless | uWSGI web worker | uWSGI mule | -+===================+===============================+===============================+===============================+ -| ``server_name`` | ``NAME`` for | ``main``, but can be modified with ``server_name`` in | -| | ``[server:]`` in | ``galaxy.yml`` | -| | ``galaxy.ini`` | | -+-------------------+-------------------------------+-------------------------------+-------------------------------+ -| ``server_id`` | ``None`` | 1-indexed worker ID | 1-indexed mule ID | -+-------------------+-------------------------------+-------------------------------+-------------------------------+ -| ``pool_name`` | ``None`` | ``web`` | Mule's farm name | -+-------------------+-------------------------------+-------------------------------+-------------------------------+ -| ``instance_id`` | ``None`` | Same as ``server_id`` | Mule's 1-indexed position in | -| | | | its defined farm | -+-------------------+-------------------------------+-------------------------------+-------------------------------+ -| ``fqdn`` | Fully-qualified domain name of the host on which Galaxy is running | -+-------------------+-----------------------------------------------------------------------------------------------+ -| ``hostname`` | "Short" hostname (with domain portion stripped) of the host on which Galaxy is running | -+-------------------+-----------------------------------------------------------------------------------------------+ - -The log message format can be customized by adding a (or modifying the default) formatter as in the following (partial) -example. Note that in addition to the new format, the value of ``formatter`` in the ``console`` handler has been -changed: - -.. code-block:: yaml - - galaxy: - logging: - formatters: - myformat: - (): '%(name)s %(levelname)s %(asctime)s [p:%(process)s,w:%(worker_id)s,m:%(mule_id)s] [%(threadName)s] %(message)s' - handlers: - console: - class: logging.StreamHandler - filters: - - stack - formatter: myformat - level: DEBUG - stream: ext://sys.stderr - INI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~