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}%nWhere %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