This seems to be an elusive bug nobody wants to fix
According to http://bugs.mysql.com/bug.php?id=24761, the aborted connect is recorded in the general log
[29 Sep 2008 8:03] Konstantin Osipov
OK, it was fixed differently:
/*
Log the command before authentication checks, so that the user can
check the log for the tried login tried and also to detect
break-in attempts.
*/
general_log_print(thd, command,
(thd->main_security_ctx.priv_user ==
thd->main_security_ctx.user ?
(char*) "%s@%s on %s" :
(char*) "%s@%s as anonymous on %s"),
thd->main_security_ctx.user,
thd->main_security_ctx.host_or_ip,
db ? db : (char*) "");
So, this is logged in the general log at least.
I was reviewing a patch that added more logging,
but I can't remember the worklog task number.
We just have to wait on MySQL (I mean Oracle) to fix it. (That was sarcasm)
I've listed some alternatives for connection management below, in order of most to least recommended.
Increase the connections allowed on the server
The total incoming connection limit on the server is determined by the lesser of the limits imposed by the operating system or maxIncomingConnections (aka maxConns in MongoDB 2.4 and earlier).
Typically Linux distributions limit file descriptors per process to 1024, of which MongoDB will use 80% for incoming connections (leaving about 819 available connections).
You can check current and available connections in the mongo shell via:
db.serverStatus().connections
For production systems it is typical to adjust the ulimit settings on Linux to allow more concurrent connections. For more best practices, I would recommend reviewing the Production Notes in the MongoDB manual.
Provide an API
If you are managing a shared server with resource limits, it is common to provide your own API rather than direct database access. This approach gives you an extra layer of abstraction so you can manage resource usage and server deployment independent of the client configuration. For example, you could move your database server or reconfigure from a standalone to a replica set, and the clients would not have to be aware of this. You can also manage custom resource limits (such as connections per client) via your API, based on the credentials the client uses to connect.
Reduce the connection pool size in the clients
MongoDB (as at 2.6) doesn't have an option to limit the connections per client. Normally client limits would be imposed via the driver (i.e. setting the connection pool size). For example, in the Java driver the MongoClient default maximum pool size is 100.
You've already suggested this isn't a desirable option as you don't want the clients to mess with the connection limits, but if you are going to impose a server side limit it would still be reasonable to have them set the pool size appropriately. Otherwise their applications will get frequent exceptions as you kill off excess connections.
Monitor client operations
If adjusting limits on the client or server isn't an option, an alternative to consider is implementing a script to count concurrent client connections (by IP) via db.currentOp() and kill excess connections via db.killOp(). You'd have to be very careful to only kill client requests. The killOp() command is a superuser command that will let you kill internal database threads as well (which can lead to unpredictable outcomes).
NOTE: This approach will be unsuccessful if your clients are connecting via a shared gateway (i.e. where the source IP does not uniquely identify a client).
Best Answer
All aborted connections tells you is the number of aborted connections. It doesn't tell you why they didn't connect.
Do you have some kind of monitoring system or network scanning system in place? e.g. Nagios, Spiceworks? They will/can make a connection to the database network socket, then either not authenticate or fail to authenticate because they haven't been configured correctly.
These would cause the value of aborted connections to rise every time they attempt a connection, which could be very frequently.