MySQL Bugs: #42403: Agent database connection logging

Bug #42403	Agent database connection logging
Submitted:	28 Jan 2009 9:04	Modified:	29 Jan 2009 11:10
Reporter:	Roger David Nay	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Agent	Severity:	S4 (Feature request)
Version:	2.0+	OS:	Any
Assigned to:	Kay Roepke	CPU Architecture:	Any

Description:
The Agent should log connections and disconnects to the MySQL monitored database similar to that already provided for connecting and disconnecting from the dashboard (merlin).

In this way it is easy to see if the Agent is connected to the database by looking at the log file, instead of logging into the database and checking current connections.

If an agent is configured to monitor more than one db server then there should be one line representing each db instance that the agent logs into.

How to repeat:
N/A

Suggested fix:
More precisely login state changes: unknown -> connected, connected -> error/disconected, disconnected -> connected. That is, we want to know when a db login is successful, but of course also when it fails. Currently successful logins are not shown so it's not EXPLICITLY clear that the agent has been able to login, nor to which db server as which user. Making this explicitly clear is helpful and shouldn't add much logging overhead as normally the db thread stays logged in.

Log messages should be something like:

2009-01-27 HH:MM:SS: (critical) network-io.c:XXX: successfully connected to instance <db-server>:<port>  as user <agent_username>
.
.
.
2009-01-27 HH:MM:SS: (critical) network-io.c:XXX: disconnected from instance <db-server>:<port>  user <agent_username>
.
.
.
2009-01-27 HH:MM:SS: (critical) network-io.c:XXX: successfully reconnected to instance <db-server>:<port>  as user <agent_username>

A patch for this is pending.

Log output will be like below. The agent does not distinguish between initial connect and reconnects, but instead always use the same message, showing either the hostname/port or the socket path it used to connect to the database.
Logging on connection errors is unaffected by this change.

2009-01-28 12:03:00: (critical) agent_mysqld.c:632: successfully connected to database at 127.0.0.1:3306 as user merlin_usage (with password: YES)

verified fixed (logging added) in build 2.0.4.7141

An entry was added to the 2.0.4 changelog:

The Service Agent did not log connections to, and disconnects from, the monitored database.

This meant it was not possible to check if the Agent was connected to the database by simply looking at the log file.