Logging is used to track the running software events. An event is described by a descriptive message, which can optionally contain variable data. Salt logging approach is used to get any issues, you may face. You can check out with specific log levels.
Let us understand the different configuration settings for logging, in detail.
Salt log records are passed through the file, which contains the local path name or the network location for identification. This file is considered as the log file.
log_file: /var/log/salt/master
Here, the file dependent of the binary being executed in master. Similarly, you can execute in the minion as well, which is shown below.
log_file: /var/log/salt/minion
You can also use remote address. The syntax for using the remote address is − <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>.
log_file: udp://loghost:port
Here, the Log-facility defaults to LOG_USER.
The log levels are ordered in a numerically assigned value. Python library has defined most of the logging levels by default. In addition to that, Salt uses some more levels. Some of the levels are explained below.
log_level: error; level value is 40 − It indicates log statement record at error.
log_level: quiet; level value is 1000 − It indicates that nothing should be logged at this level.
log_level: info; level value is 20 − It indicates the normal log information.
log_level: warn; level value is 30 − It indicates log statement record at warning.
log_level: debug; level value is 10 − Information useful for debugging both salt implementations and salt code.
log_level: trace; level value is 5 − More detailed code-debugging information.
It defines the level of messages to send to the log file.
log_level_logfile: info
It defines the log date format. By default, it is represented as %Y-%m-%d %H:%M:%S.
log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
It defines the format of the console logging the messages. Salt uses a custom LogRecord attributes to colorize the console log output. It follows the following syntax −
'%(colorlevel)s' # log level name colorized by level '%(colorname)s' # colorized module name '%(colorprocess)s' # colorized process number '%(colormsg)s' # colorized messages name
It defines the format of the log file logging the messages. The basic syntax is as follows −
%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s
This level is used to control logging levels more specifically.
log_granular_levels: 'salt': 'info' 'salt.modules': ‘trace'
Here, the Main salt library at the ‘info’ level sets the salt.modules to log at the trace level.
Salt uses LogStash and Sentry external log handler for logging. Let us understand about it in detail in this chapter.
LogStash is an open source; server-side secure data processing pipeline. Let us consider a simple UDP logging handler in Salt that uses LogStash.
Specify the following changes in the Salt master file −
logstash_udp_handler: host: 127.0.0.1 port: 9999 version: 1 msg_type: logstash
Then add the changes in the Logstash configuration file −
input { udp { port ⇒ 9999 codec ⇒ json } }
Here, UDP – is the input that needs to have a format as json_event, which is what we send over the wire.
Sentry is real-time error tracking in production deployments and information to reproduce and fix crashes. The default configuration in the master file is defined below.
sentry_handler: dsn: https://pub-key:secret-key@app.getsentry.com/app-id log_level: debug
Here, the default logging level for the sentry handler is ERROR, but we defined the debug log_level under the sentry_handler configuration key.