Change Logging Level

Raise the forwarder's logging level when Stairwell support asks for detail the default logs do not carry, then put it back. On Windows the level is a registry value, on Linux it is a field in the configuration file, and on both the forwarder reads it at startup, so a change needs a service restart to take effect.

Leave the level at its default the rest of the time. This is not a formality: verbose logging on a busy machine produces a lot of writes, and a log that has rotated away before anyone reads it is worse than a quieter one that survived. Raise it, reproduce the problem, collect the logs, put it back.

How do I change the logging level on Windows?

Set the LogLevel DWORD value in the forwarder's registry key, then restart the service. The key depends on the forwarder version.

The values LogLevel accepts:

Information is the default. Debug is the level support asks for most often, and Verbose is for a specific question rather than a general sweep.

The same choice can be made at install time with the LOGLEVEL installer parameter, on forwarder 1.6.0 and later, using the numbers above. That is the one to use when you are deploying a host specifically to reproduce something.

Logs are written to C:\ProgramData\Stairwell\SwellService\logs on forwarder 1.6 and later and 1.4.x, and to C:\ProgramData\Stairwell\Inception\logs on 1.3.x and earlier and 1.5.1.

How do I change the logging level on Linux?

Set logger.loglevel in /etc/stairwell/config.json, then restart the service.

{
  "logger": { "loglevel": "debug" },
  "asset": {
    "EnvId": "YOUR_ENVIRONMENT_ID",
    "Token": "YOUR_TOKEN"
  }
}

sudo systemctl restart stairwell

The levels Linux accepts, from most detail to least:

Edit the file with care. It is JSON, and a syntax error stops the forwarder from starting rather than starting it at the old level. If the service does not come back, Linux Forwarder Troubleshooting covers where a startup failure gets recorded when logging itself never initialized.

On RHEL 7 and later, and on the Debian family, the logs go to the system journal under the stairwell unit:

journalctl -u stairwell -S today --no-tail > stairwell_service.log

On RHEL 6 they are files, in /var/log/stairwell, with /var/log/stairwell/fileshipper.log the most recent.

How do I get more detail on macOS?

Collect the debug bundle rather than changing a level. The macOS forwarder logs into the operating system's own logging subsystem, and the bundle script gathers what support needs in one step. macOS Forwarder Troubleshooting has the command.

What should I read next?

• What to Check First, which is worth working through before raising a logging level at all. Most causes are visible without one.
• Windows Forwarder Troubleshooting, for the service names to restart after a change.
• Linux Forwarder Troubleshooting, for the rest of the files a Linux forwarder keeps.