7.11.11. Connector Audit Logging

Audit Logging allows for logging data transferred between client application and MySQL servers to a file, database or socket.

Configuration of audit logging is done directly in the connector’s tungsten-connector/conf/log4j.properties configuration file by editing the parameters explained below. Changes to this configuration file do NOT need a full restart, the command connector reconfigure will reload the log4j configuration and apply changes immediately.

5 categories of information can be printed:

  • ClientRequests : client application sends a MySQL request (select, insert, update, …) to the server. Compatible with both bridge and proxy mode, full packet text will have to be printed in order to see the actual request

  • ServerResponses : MySQL server returns a result in response to a client request. Compatible with both bridge and proxy mode, full packet text will have to be printed in order to see the actual responses

  • AppConnections : client application connects or disconnects to/from the Connector. Compatible with both bridge and proxy mode, will print one log entry per connection and one per disconnection

  • Commands : proxy mode only. Will print each "mysql command" that is sent by the application to the connector. Commands include not only regular COM_QUERY and COM_STMT_xxx used for executing requests and prepared statements, but also more specific commands such as COM_PING, COM_SLEEP, or COM_INIT_DB and COM_CHANGE_USER to switch user or schema. Full list of commands is available here

  • Perf : proxy mode only. When set to info, this logger will print the round trip time to execute individual MySQL commands (see above). A typical use of this logger is to track individual requests execution time.

Each of these categories logs may be enabled of disabled individually with:

logger.{category}.level=[OFF|INFO]

For example, all incoming client requests can be printed with the following line:

logger.ClientRequests.level=INFO

Individual log entries (individual line printed) format can be adjusted in this same conf/log4j.properties with the line:

appender.audit.layout.pattern=%d - [%X{client-ip}:%X{client-port}]<->%X{datasource} %X{user} %X{schema} %m: %X{packet-text}%n

Where %X entries are:

  • client-ip : client application IP address as seen by the connector

  • client-port : client application outgoing TCP port. Convenient to identify a given client application since a connected IP/port pair is unique at any given time

  • user : (not available in bridge mode) user name authenticated to the connector. Since bridge mode doesn’t inspect packet internals, it will not be able to display this information

  • schema : (not available in bridge mode) schema on which the client application is connected. Will be blank if no schema has been selected. Since bridge mode doesn’t inspect packet internals, it will not be able to display this information

  • datasource : cluster data source used to execute the request, composed of <hostname>@<dataservice>(role:STATE)

  • packet-header : MySQL packet header as Packet #<packet number> size=<full packet length (inc. header)> pos=<internal pointer position>

  • packet-text : internal packet bytes printable as characters. This will display a readable form of the requests. Note that the header bytes are not printed here

  • packet-binary : internal packet bytes as hexadecimal values. Will display the full packet, yet non-human-readable form. Note that the header bytes are also printed

By default, audit logging will be output in tungsten-connector/log/connector-audit.log file.

Log4j 2, the logging system used by Tungsten, allows for many other options and ways to log data, including Socket and Database logging. Deeper insight and exhaustive documentation will be found directly on the log4j 2 documentation page