The logs functionality is very important to gain insight into what happens in a qbee controlled system. Most (but not all) configuration changes will create a log entry and thus allow to follow what is happening. There are 4 different levels of log entries. Usually only critical and error messages need attention, while warning and info messgaes just flag events.
Basic information about events that have happened. No action needed.
Information that has impacted the device but usually no action needed. A typical example is the restart of an application.
This an indication that something has not happened the way it was intended to. This is a status message that usually demands action.
Here immediate action is needed as something is critically wrong and needs fixing.
A typical info message can be an information about a successfully downloaded config file template:
A warning could be the message that a process had to be restarted (in this case because a config file had to be reloaded due to changes):
Most configuration events create a log file entry. Setting changes will not be visible in the log.
Critical and error messages
Critical and error messages usually mandate additional investigation. Maybe a file path was incorrect, a service was not existing or it was in general not possible for the qbee agent to converge to the desired state of the configuration. This could be wrong permissions or any other of the myriad reasons Linux does not behave as expected. Please find the root cause and correct this.
Warning and info messages
Warning messages often contain valuable information but the system continues to operate without problems. A typical warning could be a process that was restarted to activate new configuration or a connectivity watchdog that triggered.
The main log page looks as follows:
It is possible to sort the log with regards to any time range. The select labels function allows to filter for which events you search for. In the example below "software_management", password and NTP is selected.
Additional search options are for host name, message content, commit ID and which log level severity should be shown. In the example below only critical events are selected.
There is a function that allows to mark log entries as read. This may help to track down critical or error logs.