Audit Trail
This page describes how to use the Audit Trail Feature which is provided by the Management Center for the Pro Edition of Eclipse Mosquitto (MMC).
An audit trail (also called audit log) is a security-relevant chronological record, set of records, and/or destination and source of records that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, event, or device.
This feature logs information about user performed operations in the Mosquitto Management Center. The information can be logged to different locations as syslog, file, or console.
Audit Trail can only be set up on the backend side by modifying configuration files. The MMC does not provide an API for querying the log information. It is up to the user to read the Audit Trail logs from syslog or any other supported medium, parse them, and integrate this information into other systems.
Enable Audit Trail Plugin
To enable Audit Trail Feature you should make sure you are using Pro Edition of Mosquitto and that you have the feature enabled in your license. Also, ensure that your config file (specified with CEDALO_MC_PROXY_CONFIG
environmental variable or by default saved in management-center/config/config.json
) contains the following entry inside of the plugins
array:
{
"name": "audit-trail"
}
On start-up, Management Center will print a message that audit-trail
plugin is enabled and loaded into the console:
Loaded plugin: "audit-trail" (Cedalo Audit Trail)
Apart from enabling Audit Trail, you might want to create/modify it's configuration file. More details
Audit Trail Functionality
Audit trail is a forensic analysis tool which logs operations performed by users in MMC, which allows for user behavior analysis, security audits, post-mortem incident analytics, and troubleshooting. The logs can be directed to a syslog service (recommended way), to a file, or simply to the console. The log entries are of json format (see Log entries section below) which are logged according to the log levels used in Syslog protocol from least severe to most severe:
debug
(least severe)info
notice
warning
err
crit
alert
emerg
(most severe)
Note that log levels are mostly relevant for Syslog (check the details of this standard) but they are also included into the contents of log entry wrapper object for the ease of information filtering.
The main focus of this feature is on Syslog. Other mediums like file
or console
are offered but not recommended for gathering logs as they lack the advanced features of Syslog.
Audit trail allows for fine-grained control over which specific operations from which plugins are logged and with which log levels. All the configuration for Audit Trail is performed in the config file usually called audit.json
which is either stored in its default location (plugins/audit-trail/audit.json
) or in location specified in CEDALO_MC_PROXY_CONFIG_AUDIT_TRAIL
variable (note that using this variable you specify not only the path to the config file but also the name of the file).
By default, Audit Trail logs all the operations with the "defaultLoglevel" specified in the config file. However, you can override the loglevel for every operation by specifying it in the respective section of the file. This overridden loglevel will be used for log entries generated by the specified operation unless an error occurs, in which case the level will be err
.
Moreover, you can also set up filters to only allow logins of the specific plugins and operations.
More on how to configure audit.json
can be found under Configuration file section.
The configuration file will be created with default options on the first app startup if it does not already exist. This file generation happens if you specify a different-from-default file location via CEDALO_MC_PROXY_CONFIG_AUDIT_TRAIL
variable, as audit.json
already exists in it's base location (at plugins/audit-trail/audit.json
). However, note that MMC installations usually come with reasonable defaults, and your config files including audit.json
will be stored in the config directory set up for your installation.
You can find how the default config file looks in the Default config file section of this doc page. If you need to make some changes to the config file, restart the MMC to apply them.
Log entries
Each log entry contains the following information:
- Timestamp: information on when the operation was performed (timestamp in millisecond resolution).
- IP Address: information on from which IP address the operation was initiated (Client IP). Note: whether this information is part of the log entry or not can be configured via a configuration file.
- Hostname: the hostname of the broker to which the operation was sent.
- Port: the port of the broker to which the operation was sent.
- Username / Application Token: information on which user or which application (identified by the application token) performed the operation.
- Source (Module name / plugin name): source of the operation, i.e. name of the module or plugin, where the operation was performed.
- Operation Type: the CRUD (Create Retreive Update Delete) operation type which characterizes the application. Currently, supported values are
create
,read
,update
,delete
orother
. Theother
type includes operation types that are not well covered by the first four types, such as broker connection/disconnection or startup/shutdown. - Operation name: the name of the operation that was performed.
- Operation parameters: the parameters passed to the operation that was performed.
Every log entry is logged with a certain log level configured through the config file (audit.json
). However, these levels are not included into the log entry itself and are handled by your syslog service when syslog logger is used.
Log entry example:
{
"timestamp": 1675676434000,
"ipAddress": "127.0.0.1",
"hostname": "localhost",
"operationType": "update", // "create", "read", "update", "delete", or "other"
"port": "8883",
"source": "dynamic-security",
"identifier": {
"username": "max",
// and/or "tokenName": "..."
// and/or "tokenHash": "..."
},
"operation": "createClient",
"params": {
"username": "max",
"clientid": "example-client",
"rolename": "admin",
"textname": "ExampleClient",
"textdescription": "Example client for testing"
}
}
Log entry wrapper
Note that when logging, MMC wraps another object called log entry wrapper around the original log entery.
Every logenry is stored within a message
property of that wrapper object.
Wrapper object contains some metadata about the log entry which is relevant to the logging configuration.
The properties of the logentery wrapper object are:
- Level: Loglevel that the operation in log entry has (For example
startup
operation might haveinfo
loglevel, whereasgetConnection
-debug
) - Message: original log entry object (with all the properties described above)
Here is an example of a log entry wrapper object:
{
"level": "info",
"message": {
"timestamp": 1675676434000,
"ipAddress": "127.0.0.1",
"hostname": "localhost",
"operationType": "update", // "create", "read", "update", "delete", or "other"
"port": "8883",
"source": "dynamic-security",
"identifier": {
"username": "max",
// and/or "tokenName": "..."
// and/or "tokenHash": "..."
},
"operation": "createClient",
"params": {
"username": "max",
"clientid": "example-client",
"rolename": "admin",
"textname": "ExampleClient",
"textdescription": "Example client for testing"
}
}
}
Configuration file
When config file is mentioned in this page and no further context given, then the configuration file for Audit Trail specifically (commonly called audit.json
) is meant, not the main configuration file of MMC (config.json
).
Config file structure
Note that default configuration file will log all the operations to the console. If you want to change this, you will have to create your own file and specify the path in CEDALO_MC_PROXY_CONFIG_AUDIT_TRAIL
(e.g. path/to/dir/audit.json
) or CEDALO_MC_DATA_DIRECTORY_PATH
(e.g. path/to/dir
).
audit.json
is stored in json format and consists of an array of one or many logger objects.
Here is an example of audit.json
file with a single logger object:
[
{
"logger": "syslog",
"options": {
"protocol": "unix",
"path": "/dev/log"
},
"logThreshold": "debug",
"defaultLoglevel": "info",
"disable": true,
"filters": [
{"filterType": "include"}
],
"operations": [
{
"source": "application-tokens",
"operation": "createAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "deleteAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "getAppToken",
"loglevel": "debug"
},
{
"source": "application-tokens",
"operation": "getAppTokens",
"loglevel": "debug"
},
{
"source": "cluster-management",
"operation": "checkClusterHealthStatus",
"loglevel": "notice"
}
]
}
]
Config file properties:
Every logger object contains the following properties:
logger
- type of the logger (Answers the question: where will the logs be sent to?). Option acceptssyslog
,file
, orconsole
values.options
- this property is specific to the logger type set in thelogger
property. It holds settings of the chosen logger. See Logger optionslogThreshold
- minimal level of severity which is to be logged. In other words, MMC will only log operations of this loglevel and higher (the ones which are more severe). Operation which have loglevels belowlogThreshold
severity-wise will not be logged. Possible values for this property are all the valid syslog levels (in the order of increasing severity:debug
,info
,notice
,warning
,err
,crit
,alert
,emerg
). You can also use longer names for severity levels (i. e.debug
,informational
,notice
,warning
,error
,critical
,alert
,emergency
). Note thatlogThreshold
has a higher priority thanfilters
. If you specified a certain threshold, the loglevels below it will not be reported at all regardless of your filters. Also note that even withlogThreshold
property being set, the empty filter array will still exclude all operations by default. So at least oneinclude
filter infilters
property must be specified. Read more about the filters in the respective part of this documentation.
Example:
If you set logThreshold
to warning
, any operations with debug
, info
, or notice
levels will not be logged since they are less severe than warning
. On the other hand, warning
, error
, critical
, alert
, and emergency
messages will be logged.
defaultLoglevel
- the default loglevel assigned to all operations unless overridden for some inoperations
property of this config file.disable
- property which disables the logger, so that nothing is loggedfilters
- custom filters for filtering out operations and/or entire plugins. Contains filter entries. See Using filters sectionoperations
- section where specific loglevel for chosen operation can be specified (for instance, you might not want all the operations to be logged withdefaultLoglevel
. You might want some to havenotice
level, some others -info
, and the rest asdebug
). This property is an array of elements of the form:
{
"source": "...",
"operation": "...",
"loglevel": "..."
}
where:
* `source` - is the name of the plugin which contains the `operation` we want to log. See [List of plugin names](#list-of-plugin-names)
* `operation` - name of the operation to be logged
* `loglevel` - log level that the specified operations will have
So basically, Audit Trail feature logs all the operations by default unless some filters are specified. All these operations have a loglevel specified in defaultLoglevel
unless this level is explicitly overriden for some operations in operations
property.
For example, the following log file will log all the operations with info
loglevel. However, operations createAppToken
and deleteAppToken
from the application-tokens
plugin will have a notice
loglevel, whereas getAppToken
will be logged with debug
level:
[
{
"logger": "syslog",
"options": {
"protocol": "unix",
"path": "/dev/log"
},
"logThreshold": "debug",
"defaultLoglevel": "info",
"disable": true,
"filters": [
{"filterType": "include"}
],
"operations": [
{
"source": "application-tokens",
"operation": "createAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "deleteAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "getAppToken",
"loglevel": "debug"
}
]
}
]
In the following example, we increase the logThreshold
property from debug
to info
, which means that now createAppToken
and deleteAppTokens
will be logged but getAppToken
will not. This is because debug
level which getAppToken
operation has is less severe than info
level set in logThreshold
property. In other words, this logger will only log operations with info
loglevel and above:
[
{
"logger": "syslog",
"options": {
"protocol": "unix",
"path": "/dev/log"
},
"logThreshold": "info",
"defaultLoglevel": "info",
"disable": true,
"filters": [
{"filterType": "include"}
],
"operations": [
{
"source": "application-tokens",
"operation": "createAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "deleteAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "getAppToken",
"loglevel": "debug"
}
]
}
]
Also see Default config file and Config file with syslog. The former provides a restricted config file generated/used by MMC by default and the latter - a recommended config file which uses syslog for logging. The reason why the default file is restricted is because syslog might not be configured or might be configured differently on your system. We want to be explicit that if you want to enable something you have to specifically set it. This is also done to avoid silently flooding your system with logs.
Logger types
There are 3 types of loggers that can be specified through the logger
property in audit.json
file:
"syslog"
- passes logs to a syslog service specified in theoptions
property of theaudit.json
. See Logger options"file"
- saves all the logs into a file as defined inoptions
property inaudit.json
which should hold afilename
property with the path to a file"console"
(default) - prints all the logs into stdout. When specifying this logger type you should leaveoptions
property empty
Example:
// audit.json
[
{
"logger": "typename", // "syslog" or "file" or "console"
"options": {
...
},
...
}
]
Logger options
Config file contains options
property which configures the logger defined in the logger
property.
There are a couple different scenarios for setting up options based on which logger
you are using. Those are described below. Note that options
property is passed as is as transport options to winston
library. In case of syslog
logger, the options are passed to winston-syslog
, so you can check the respective documentations for more information.
Examples of different logger configurations:
- Local syslog (accessed through unix socket)
{
"logger": "syslog",
"options": {
"protocol": "unix",
"path": "/dev/log"
},
...
}
You can read more about syslog options on winston-syslog
github page
- Remote syslog (accessed through udp or tcp)
{
"logger": "syslog",
"options": {
"host": "localhost",
"port": 514,
"protocol": "udp4" // or "tcp4"
},
...
}
- Logging to a file
{
"logger": "file",
"options": {
"filename": "/data/test.log"
},
...
}
Note: In our docker-container setups data
is usually a volume mapped to /mosquitto/management-center/data
. In rpm and other setups you are free to chose any path on your system.
- Logging to console:
{
"logger": "console",
"options": {},
...
}
There is no need to set any options in case of a console logger.
Using filters
Filters are defined in the filters
property of audit.json
. They are used to exclude or include log entries which match certain criterias (defined in filterType
, source
, operation
, operationType
, loglevel
) and patterns (e.g. user-*
, *up
etc). In other words, filters decide which operations are logged and which are skipped.
Filter is an entry under filters
array property (it can sometimes be called a filter object). It has the following format:
{
"filterType": "exclude|include",
"source": "glob pattern",
"operation": "glob pattern",
"operationType": "create|read|update|delete|other",
"loglevel": "emerg|alert|crit|err|warning|notice|info|debug"
}
Filter object is applied to each event to determine whether it is to be logged. For that, all the filter criterias (properties like source
or operation
etc) must match the respective event's parameters.
The filters are evaluated in order and the final result applies. This allows to arrange very specific filters to pick out or exclude certain events. It is recommended to order the filters from most general to most specific.
All the filters properties are optional except the filterType
which must be set to either include
or exclude
. If only filterType
is specified the filter becomes a global filter and is then applied to every event.
If the evaluation result of a set of filter is exlude
then the event will not be logged. On the other hand, if the result is include
- the event will be reported.
The default behaviour is exclude reporting of events, so at least one include
filter must be provided. In some cases you might find yourself defining a global include filter first, after which you specify more fine-grained exclude filter to filter out what you don't need.
The source
property is used to match against the events origin (the module or plugin where the event is being reported from). This property will equal core
for events coming from the core MMC functionality (like startup
or shutdown
events), or it will equal the name of a plugin, e.g. user-management
or app-tokens
. This property supports glob patterns, so if you, for example, want to match all sources that end with a -management
suffix, you can use *-management
value for this property.
The operation
property is matched against the name of the operation (e.g. startup
, connectToBroker
, getLeaderOfCluster
etc). This property also supports glob patterns.
The operationType
property will be matched against the CRUD type of the operation. This must be set to create
, read
, update
, delete
, or other
.
The loglevel
property is matching the loglevels of the operations. If you have an include filter with a certain loglevel
property defined it means that the operations that match your filter and have the specified loglevel or higher will be included and reported. If you have an exclude filter with a specific loglevel
then the operations that have the specified loglevel or lower will be excluded and operations with a higher loglevel - reported.
Below you can find some filter object examples.
The following filter:
{ "filterType": "include" }
{ "filterType": "exclude", "source": "plugin*", "operationType": "read", "loglevel": "warning" }
Excludes (doesn't log) all read operation whose featureId
starts with "plugin"
and whose loglevel is lower or equal to warning
.
Note that we had to specify a global "empty" include filter to change the default behaviour of excluding everything, and only after that we have specified an exclude filter.
source
and operation
fields are using glob patterns for matching
Filter to include all operations with loglevel info
and higher:
{ "filterType": "include", "loglevel": "info" }
The filter below includes all the operations from pluginA
into the logs. Note that if you don't specify any other filters, then all the other operations will be excluded, since excluding all is the default behaviour.
{ "filterType": "include", "source": "pluginA" }
An example of excluding only a startup
operation:
{ "filterType": "include" },
{ "filterType": "exclude", "operation": "startup" }
Exlude all the operations core
operations except connectToBroker
and disconnectFromBroker
.
{ "filterType": "include" },
{ "filterType": "exclude", "source": "core" },
{ "filterType": "include", "operation": "connectToBroker" },
{ "filterType": "include", "operation": "disconnectFromBroker" },
Include all operations except the ones originating from pluginA
and pluginB
{ "filterType": "include" },
{ "filterType": "exclude", "source": "pluginA" },
{ "filterType": "exclude", "source": "pluginB" },
Config file location
You don't usually have to decide where to store audit.json
config file. In most of the MMC installations it's stored in the default config directory with a default name (audit.json
), so you can just create/edit it there. However, for completeness we also explore different options that define the location of the file in this section.
The config file of audit-trail
plugin called audit.json
is by default stored in plugins/audit-trail
directory, but you can change the path and the file name by specifying the path in CEDALO_MC_PROXY_CONFIG_AUDIT_TRAIL
environment variable.
Another option is to specify a parent directory for this file with CEDALO_MC_DATA_DIRECTORY_PATH
. However, this environmental variable has a lower priority than CEDALO_MC_PROXY_CONFIG_AUDIT_TRAIL
.
In case you specify CEDALO_MC_PROXY_CONFIG_AUDIT_TRAIL
or CEDALO_MC_DATA_DIRECTORY_PATH
but don't create a config file yourself, it will be created for you with default options, which might not be what you desire. You can either create this file first, or let it be created by MMC on first startup, change it, and restart the app.
Configuring syslog on your system
Audit Trail was mainly designed to save the logs to the syslog service of your local or remote machine. This behavior can be setup by setting "logger": "syslog"
property in the config file.
Syslog service (sometimes called syslog for short) is a daemon program which stores and manages logs sent to it by different applications which follows Syslog standard.
Syslog works under Unix systems, so this section is only relevant to Unix OS and in particular: Linux (MacOS is not covered here but it's configuration is similar).
For Red Hat based Linux systems (such as RHEL, CentOS, Fedora), rsyslog
syslog daemon is commonly used. For Debian based systems (such as Debian, Ubuntu), rsyslog
and syslog-ng
are widely in use.
In order to inspect syslogs in the most simple case on your local machine, you need to do the following:
On Redhat-based Linux
tail -f /var/log/messages
On Debian-based Linux
tail -f /var/log/syslog
Configuration of syslog service usually has reasonable defaults, but in case you experience some issues, you might want to take a look at the respective configuration files.
Rsyslog Configuration:
For both Redhat and Debian-based systems, the main configuration file for rsyslog is located at /etc/rsyslog.conf
. This file is used to specify the rules for logging. After modifying this file run systemctl restart rsyslog
in order to restart the syslog daemon to apply the changes for Redhat-based systems, and service rsyslog restart
for Debian-based ones.
Open UDP port for rsyslog:
In case you want to transmit the logs via UDP you will also need to ensure that your syslog service on the receiving device is configured to listen on the network interface and not just on the local system. You can do so by editing the /etc/rsyslog.conf
file and uncommenting or adding these lines:
module(load="imudp")
input(type="imudp" port="514")
After making these changes, you will need to restart the rsyslog
service:
systemctl restart rsyslog
Syslog-ng Configuration:
For Debian based systems using syslog-ng
, the main configuration file is /etc/syslog-ng/syslog-ng.conf
. After modifying this file run service syslog-ng restart
in order to restart the syslog daemon and apply the changes.
Limitations
In case of using syslog with udp4
, udp6
, or unix
protocols, note that these are datagram-based and adhere to "fire and forget" principle. This means that you will not get any connection errors being output in case you haven't properly configured audit-trail
plugin or your syslog. The logging will simply be failing silently because UDP protocol has no concept of setting up a proper connection and checking if it works/is alive.
Syslog works under Unix systems. Therefore, this feature is mainly targeted at those operating systems, not Windows. However, logging under Windows is also possible using file
or console
loggers.
Troubleshooting
If you are using remote syslog with UDP protocol and it doesn't work, try switching to TCP for debugging purposes because the latter shows connection errors. After the problem has been identified and solved, you can switch back.
List of sources (plugin names)
Available plugin names are:
audit-trail
(Contains no operations)user-management
saml-sso
(Contains no operations)https
(Contains no operations)application-tokens
monitoring-rest-api
cluster-management
tls
(Contains no operations)user-profile-edit
connections-rest-api
custom-themes
(Contains no operations)multiple-connections
(Contains no operations)system-status-rest-api
topictree-rest-api
dynamic-security-rest-api
cert-management
Additionally there is a core
source which defines the operations of the core MMC like connecting-disconnecting the broker and so on.
Not all the plugins contain operations which can be logged.
Default config file
The default config file defines a global include filter and logs everything into the console.
[
{
"logger": "console",
"options": {},
"logThreshold": "info",
"defaultLoglevel": "info",
"disable": false,
"filters": [
{
"filterType": "include"
}
],
"operations": [
{
"source": "application-tokens",
"operation": "createAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "deleteAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "getAppToken",
"loglevel": "debug"
},
{
"source": "application-tokens",
"operation": "getAppTokens",
"loglevel": "debug"
},
{
"source": "cert-management",
"operation": "addCert",
"loglevel": "notice"
},
{
"source": "cert-management",
"operation": "deleteCert",
"loglevel": "notice"
},
{
"source": "cert-management",
"operation": "deployCert",
"loglevel": "info"
},
{
"source": "cert-management",
"operation": "getCerts",
"loglevel": "debug"
},
{
"source": "cert-management",
"operation": "getCertInfo",
"loglevel": "debug"
},
{
"source": "cert-management",
"operation": "getListeners",
"loglevel": "debug"
},
{
"source": "cert-management",
"operation": "updateCert",
"loglevel": "info"
},
{
"source": "cluster-management",
"operation": "checkClusterHealthStatus",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "createCluster",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "deleteAllClusters",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "deleteCluster",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "getCluster",
"loglevel": "debug"
},
{
"source": "cluster-management",
"operation": "getClusters",
"loglevel": "debug"
},
{
"source": "cluster-management",
"operation": "getClusterStatuses",
"loglevel": "debug"
},
{
"source": "cluster-management",
"operation": "joinCluster",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "leaveCluster",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "modifyCluster",
"loglevel": "notice"
},
{
"source": "connect-disconnect",
"operation": "connectServerToBroker",
"loglevel": "info"
},
{
"source": "connect-disconnect",
"operation": "disconnectServerFromBroker",
"loglevel": "info"
},
{
"source": "connections-rest-api",
"operation": "createConnection",
"loglevel": "notice"
},
{
"source": "connections-rest-api",
"operation": "deleteConnection",
"loglevel": "notice"
},
{
"source": "connections-rest-api",
"operation": "getConnection",
"loglevel": "debug"
},
{
"source": "connections-rest-api",
"operation": "getConnections",
"loglevel": "debug"
},
{
"source": "dynamic-security-rest-api",
"operation": "executeCommand",
"loglevel": "debug"
},
{
"source": "dynamic-security-rest-api",
"operation": "getBrokerInformation",
"loglevel": "debug"
},
{
"source": "core",
"operation": "connectToBroker",
"loglevel": "info"
},
{
"source": "core",
"operation": "createConnection",
"loglevel": "notice"
},
{
"source": "core",
"operation": "deleteConnection",
"loglevel": "notice"
},
{
"source": "core",
"operation": "disconnectFromBroker",
"loglevel": "info"
},
{
"source": "core",
"operation": "getBrokerConnections",
"loglevel": "info"
},
{
"source": "core",
"operation": "getConfiguration",
"loglevel": "debug"
},
{
"source": "core",
"operation": "getPlugins",
"loglevel": "debug"
},
{
"source": "core",
"operation": "loadPlugin",
"loglevel": "notice"
},
{
"source": "core",
"operation": "modifyConnection",
"loglevel": "info"
},
{
"source": "core",
"operation": "shutdown",
"loglevel": "info"
},
{
"source": "core",
"operation": "startup",
"loglevel": "info"
},
{
"source": "core",
"operation": "unloadPlugin",
"loglevel": "notice"
},
{
"source": "core",
"operation": "updateSettings",
"loglevel": "info"
},
{
"source": "monitoring-rest-api",
"operation": "getBroker",
"loglevel": "debug"
},
{
"source": "monitoring-rest-api",
"operation": "getBrokers",
"loglevel": "debug"
},
{
"source": "monitoring-rest-api",
"operation": "getCluster",
"loglevel": "debug"
},
{
"source": "monitoring-rest-api",
"operation": "getClusters",
"loglevel": "debug"
},
{
"source": "system-status-rest-api",
"operation": "getSystemStatus",
"loglevel": "debug"
},
{
"source": "topictree-rest-api",
"operation": "deleteTopicTree",
"loglevel": "notice"
},
{
"source": "topictree-rest-api",
"operation": "getTopicTree",
"loglevel": "debug"
},
{
"source": "core",
"operation": "login",
"loglevel": "info"
},
{
"source": "core",
"operation": "logout",
"loglevel": "info"
},
{
"source": "user-management",
"operation": "createGroup",
"loglevel": "notice"
},
{
"source": "user-management",
"operation": "createUser",
"loglevel": "notice"
},
{
"source": "user-management",
"operation": "deleteGroup",
"loglevel": "notice"
},
{
"source": "user-management",
"operation": "deleteUser",
"loglevel": "notice"
},
{
"source": "user-management",
"operation": "getGroup",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getGroups",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getRoles",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getUser",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getUserGroups",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getUsers",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "updateGroup",
"loglevel": "info"
},
{
"source": "user-management",
"operation": "updateProfile",
"loglevel": "info"
},
{
"source": "user-management",
"operation": "updateUser",
"loglevel": "info"
}
]
}
]
Config file with syslog
The below config file is logging everything into syslog. Note that you might want to tweak options
property.
[
{
"logger": "syslog",
"options": {
"protocol": "unix",
"path": "/dev/log"
},
"disable": false,
"logThreshold": "debug",
"defaultLoglevel": "info",
"filters": [
{
"filterType": "include"
}
],
"operations": [
{
"source": "application-tokens",
"operation": "createAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "deleteAppToken",
"loglevel": "notice"
},
{
"source": "application-tokens",
"operation": "getAppToken",
"loglevel": "debug"
},
{
"source": "application-tokens",
"operation": "getAppTokens",
"loglevel": "debug"
},
{
"source": "cert-management",
"operation": "addCert",
"loglevel": "notice"
},
{
"source": "cert-management",
"operation": "deleteCert",
"loglevel": "notice"
},
{
"source": "cert-management",
"operation": "deployCert",
"loglevel": "info"
},
{
"source": "cert-management",
"operation": "getCerts",
"loglevel": "debug"
},
{
"source": "cert-management",
"operation": "getCertInfo",
"loglevel": "debug"
},
{
"source": "cert-management",
"operation": "getListeners",
"loglevel": "debug"
},
{
"source": "cert-management",
"operation": "updateCert",
"loglevel": "info"
},
{
"source": "cluster-management",
"operation": "checkClusterHealthStatus",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "createCluster",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "deleteAllClusters",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "deleteCluster",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "getCluster",
"loglevel": "debug"
},
{
"source": "cluster-management",
"operation": "getClusters",
"loglevel": "debug"
},
{
"source": "cluster-management",
"operation": "getClusterStatuses",
"loglevel": "debug"
},
{
"source": "cluster-management",
"operation": "joinCluster",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "leaveCluster",
"loglevel": "notice"
},
{
"source": "cluster-management",
"operation": "modifyCluster",
"loglevel": "notice"
},
{
"source": "connect-disconnect",
"operation": "connectServerToBroker",
"loglevel": "info"
},
{
"source": "connect-disconnect",
"operation": "disconnectServerFromBroker",
"loglevel": "info"
},
{
"source": "connections-rest-api",
"operation": "createConnection",
"loglevel": "notice"
},
{
"source": "connections-rest-api",
"operation": "deleteConnection",
"loglevel": "notice"
},
{
"source": "connections-rest-api",
"operation": "getConnection",
"loglevel": "debug"
},
{
"source": "connections-rest-api",
"operation": "getConnections",
"loglevel": "debug"
},
{
"source": "dynamic-security-rest-api",
"operation": "executeCommand",
"loglevel": "debug"
},
{
"source": "dynamic-security-rest-api",
"operation": "getBrokerInformation",
"loglevel": "debug"
},
{
"source": "core",
"operation": "connectToBroker",
"loglevel": "info"
},
{
"source": "core",
"operation": "createConnection",
"loglevel": "notice"
},
{
"source": "core",
"operation": "deleteConnection",
"loglevel": "notice"
},
{
"source": "core",
"operation": "disconnectFromBroker",
"loglevel": "info"
},
{
"source": "core",
"operation": "getBrokerConnections",
"loglevel": "info"
},
{
"source": "core",
"operation": "getConfiguration",
"loglevel": "debug"
},
{
"source": "core",
"operation": "getPlugins",
"loglevel": "debug"
},
{
"source": "core",
"operation": "loadPlugin",
"loglevel": "notice"
},
{
"source": "core",
"operation": "modifyConnection",
"loglevel": "info"
},
{
"source": "core",
"operation": "shutdown",
"loglevel": "info"
},
{
"source": "core",
"operation": "startup",
"loglevel": "info"
},
{
"source": "core",
"operation": "unloadPlugin",
"loglevel": "notice"
},
{
"source": "core",
"operation": "updateSettings",
"loglevel": "info"
},
{
"source": "monitoring-rest-api",
"operation": "getBroker",
"loglevel": "debug"
},
{
"source": "monitoring-rest-api",
"operation": "getBrokers",
"loglevel": "debug"
},
{
"source": "monitoring-rest-api",
"operation": "getCluster",
"loglevel": "debug"
},
{
"source": "monitoring-rest-api",
"operation": "getClusters",
"loglevel": "debug"
},
{
"source": "system-status-rest-api",
"operation": "getSystemStatus",
"loglevel": "debug"
},
{
"source": "topictree-rest-api",
"operation": "deleteTopicTree",
"loglevel": "notice"
},
{
"source": "topictree-rest-api",
"operation": "getTopicTree",
"loglevel": "debug"
},
{
"source": "core",
"operation": "login",
"loglevel": "info"
},
{
"source": "core",
"operation": "logout",
"loglevel": "info"
},
{
"source": "user-management",
"operation": "createGroup",
"loglevel": "notice"
},
{
"source": "user-management",
"operation": "createUser",
"loglevel": "notice"
},
{
"source": "user-management",
"operation": "deleteGroup",
"loglevel": "notice"
},
{
"source": "user-management",
"operation": "deleteUser",
"loglevel": "notice"
},
{
"source": "user-management",
"operation": "getGroup",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getGroups",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getRoles",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getUser",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getUserGroups",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "getUsers",
"loglevel": "debug"
},
{
"source": "user-management",
"operation": "updateGroup",
"loglevel": "info"
},
{
"source": "user-management",
"operation": "updateProfile",
"loglevel": "info"
},
{
"source": "user-management",
"operation": "updateUser",
"loglevel": "info"
}
]
}
]