Mongodb – How to disable ChunkManager logging for MongoDB? mongoconfig.log gets huge

mongodbmongodb-3.4

I'm using MongoDB 3.4 for saving other systems logs and mongoconfig.log is getting too much verbosity. It's a sharded clusted, if that helps.

I checked the default mongo log verbosity and is set at default (0). But I believe this is another setting not found under /etc/mongod.conf

2017-06-13T02:54:44.868-0400 I SHARDING [Balancer] ChunkManager loading chunks for collection_user sequenceNumber: 36210965 based on: (empty)
2017-06-13T02:54:44.915-0400 I SHARDING [Balancer] ChunkManager load took 46 ms and found version 2392|1||58ade4d8189e1651990a98d2
2017-06-13T02:54:44.920-0400 I SHARDING [Balancer] ChunkManager loading chunks for collection_user sequenceNumber: 36210966 based on: (empty)
2017-06-13T02:54:44.921-0400 I SHARDING [Balancer] ChunkManager load took 0 ms and found version 3|10||58adf0e5189e1651990d9af8
2017-06-13T02:54:44.921-0400 I SHARDING [Balancer] ChunkManager loading chunks for collection_user sequenceNumber: 36210967 based on: (empty)
2017-06-13T02:54:45.026-0400 I SHARDING [Balancer] ChunkManager load took 104 ms and found version 4385|1||58adf0ed189e1651990d9c89
2017-06-13T02:54:45.035-0400 I SHARDING [Balancer] ChunkManager loading chunks for collection_user sequenceNumber: 36210968 based on: (empty)
2017-06-13T02:54:45.127-0400 I SHARDING [Balancer] ChunkManager load took 92 ms and found version 4258|1||58adf0f4189e1651990d9dd4
2017-06-13T02:54:45.136-0400 I SHARDING [Balancer] ChunkManager loading chunks for collection_user sequenceNumber: 36210969 based on: (empty)
2017-06-13T02:54:45.162-0400 I SHARDING [Balancer] ChunkManager load took 26 ms and found version 1349|1||58adf0f9189e1651990d9f26

Getting log components information returns this:

db.getLogComponents()
{
    "verbosity" : 0,
    "accessControl" : {
        "verbosity" : -1
    },
    "command" : {
        "verbosity" : -1
    },
    "control" : {
        "verbosity" : -1
    },
    "executor" : {
        "verbosity" : -1
    },
    "geo" : {
        "verbosity" : -1
    },
    "index" : {
        "verbosity" : -1
    },
    "network" : {
        "verbosity" : -1,
        "asio" : {
            "verbosity" : -1
        },
        "bridge" : {
            "verbosity" : -1
        }
    },
    "query" : {
        "verbosity" : -1
    },
    "replication" : {
        "verbosity" : -1
    },
    "sharding" : {
        "verbosity" : -1
    },
    "storage" : {
        "verbosity" : -1,
        "journal" : {
            "verbosity" : -1
        }
    },
    "write" : {
        "verbosity" : -1
    },
    "ftdc" : {
        "verbosity" : -1
    },
    "tracking" : {
        "verbosity" : -1
    }
}

Best Answer

I have not tested this myself.

Reference:

You can do this by:

systemLog.quiet Type: boolean

Run mongos or mongod in a quiet mode that attempts to limit the amount of output.

systemLog.quiet is not recommended for production systems as it may make tracking problems during particular connections much more difficult.

--quiet

Runs mongos in a quiet mode that attempts to limit the amount of output.

This option suppresses:

output from database commands

replication activity connection accepted

events connection

closed events

All Sharding Commands are listed under database commands which I assume will suppress the logging you are referring to.

Related Solutions

MongoDB – How to Change Logging Level

You have the verbosity set to 0 overall and every individual component is set to -1, which means they will all inherit the parent verbosity setting (of 0). That is as low as the verbosity setting goes, to further reduce the logging you can set systemLog.quiet but that is not recommended for production systems because it can make tracking down issues too difficult and it may not address the root cause in any case.

You mention that the reason you are looking into this is the volume of logs you are seeing, so I would suggest the best thing to do would be to figure out what is causing the excessive logging (slow queries? something else?) at the lowest verbosity level and address that.

Note that if it is slow queries (and you are OK with them being that slow) you may just want to adjust the default 100ms operationProfiling.slowOpThresholdMs threshold upward to reduce that logging specifically.

Mongodb – How to find sources of connections to Mongodb

As per your log i am able to see you are using linux O.S. So, the below grep command you are able to see how connections open to the MongoDB port (27017) on my computer.

$ sudo lsof | grep mongod | grep TCP

As per you log statement, After execution the above query . which you have already said in your question statement.

I am able to see your log statement like

TCP localhost:27017 (LISTEN)
TCP localhost:27017->localhost:52582 (ESTABLISHED)
TCP localhost:27017->localhost:52584 (ESTABLISHED)
TCP localhost:27017->localhost:52586 (ESTABLISHED)

I would like to say that here in your case three connections open for the mongodb by default port 27017.

And for the number of connection

db.serverStatus()

It gives no of connections opend and avail but not shows the connections from which client.

Even you can also get directly by querying

db.serverStatus().connections

for your ref Here

Best Answer

Related Solutions

MongoDB – How to Change Logging Level

Mongodb – How to find sources of connections to Mongodb

Related Question