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)infonoticewarningerrcritalertemerg(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,deleteorother. Theothertype 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
startupoperation might haveinfologlevel, 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": [],
"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, orconsolevalues.options- this property is specific to the logger type set in theloggerproperty. 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 belowlogThresholdseverity-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 thatlogThresholdhas 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 withlogThresholdproperty being set, the empty filter array will still exclude all operations by default. So at least oneincludefilter infiltersproperty 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 inoperationsproperty 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 havenoticelevel, 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": [],
"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": [],
"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 theoptionsproperty of theaudit.json. See Logger options"file"- saves all the logs into a file as defined inoptionsproperty inaudit.jsonwhich should hold afilenameproperty with the path to a file"console"(default) - prints all the logs into stdout. When specifying this logger type you should leaveoptionsproperty 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-managementsaml-sso(Contains no operations)https(Contains no operations)application-tokensmonitoring-rest-apicluster-managementtls(Contains no operations)user-profile-editconnections-rest-apicustom-themes(Contains no operations)multiple-connections(Contains no operations)system-status-rest-apitopictree-rest-apidynamic-security-rest-apicert-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"
}
]
}
]