This blog post is another in the series on the Percona Server for MongoDB 3.4 bundle release. In this blog post, we’ll look at the
pt-mongodb-summary tool in Percona Toolkit.
The pt-mongodb-summary tool from Percona Toolkit provides a quick at-a-glance overview of MongoDB and Percona Server for MongoDB instances. It is equivalent to pt-mysql-summary for MySQL.
pt-mongodb-summary also collects information about a MongoDB cluster. It collects information from several sources to provide an overview of the cluster.
How It Works
The usage for the command is as follows:
pt-mongodb-summary [OPTIONS] [HOST[:PORT]]
Options:
- -a, –auth-db: Specifies the database used to establish credentials and privileges with a MongoDB server. By default, the admin database is used.
- -p, –password: Specifies the password to use when connecting to a server with authentication enabled. Do not add a space between the option and its value:
-p<password>.
If you specify the option without any value, pt-mongodb-summary will ask for the password interactively. - -u, –user: Specifies the user name for connecting to a server with authentication enabled.
By default, if you run pt-mongodb-summary without parameters, it tries to connect to the localhost on port 27017. It collects information about the MongoDB instances by running administration commands, and formatting the output.
Sections
Instances
The first thing the tool does is get the list of hosts connected to the specified MongoDB instance by running the listShards command. It also runs replSetGetStatus on every instance to collect the ID, type, and replica set for each instance.
This host
Next, it gathers information about the host it is connected to by grouping information collected from hostInfo, getCmdLineOpts, serverStatus and the OS process (by process ID). The result provides an overview of the running instance and the underlying OS.
Running ops
This section collects statistics by running the serverStatus command five times at regular intervals (every one second), and provides the minimum, maximum and average operation counters for insert, query, update, delete, getMore and command operations.
Security
This collects information about security configurations by parsing the getCmdLineOpts command and asking the admin.system.users, and admin.system.roles collections.
Oplog
From the MongoDB website:
The oplog (operations log) is a special capped collection that keeps a rolling record of all operations that modify the data stored in your databases. MongoDB applies database operations on the primary and then records the operations on the primary’s oplog. The secondary members then copy and apply these operations in an asynchronous process. All replica set members contain a copy of the oplog, in the local.oplog.rs collection, which allows them to maintain the current state of the database.
How do we get the oplog info? The program collects statistics from the oplog for every host in the cluster, and returns the information on the statistics having the smaller TimeDiffHours value.
Cluster-wide
This section provides information about the number of sharded/unsharded databases, collections and their size.The information is collected by running the listDatabases command, and then running collStats for every collection in every database.
Conditional Sections
You may notice not all sections appear all the time. This is because there are three main patterns:
Sharded Connection to Mongos
- Instances
- This host
- Running ops
- Security
- Cluster-wide
ReplicaSet Connection
- Instances (limited to the current Replica Set)
- This host
- Running ops
- Security
- Oplog
Standalone Connection
- Instances (limited to this host)
- This host
- Running ops
- Security
Output Example
The following is an example of the output for pt-mongodb-summary:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 |
./pt-mongodb-summary # Instances ############################################################################################## PID Host Type ReplSet Engine 11037 localhost:17001 SHARDSVR/PRIMARY r1 wiredTiger 11065 localhost:17002 SHARDSVR/SECONDARY r1 wiredTiger 11136 localhost:17003 SHARDSVR/SECONDARY r1 wiredTiger 11256 localhost:17004 SHARDSVR/ARBITER r1 wiredTiger 11291 localhost:18001 SHARDSVR/PRIMARY r2 wiredTiger 11362 localhost:18002 SHARDSVR/SECONDARY r2 wiredTiger 11435 localhost:18003 SHARDSVR/SECONDARY r2 wiredTiger 11513 localhost:18004 SHARDSVR/ARBITER r2 wiredTiger 11548 localhost:19001 CONFIGSVR - wiredTiger 11571 localhost:19002 CONFIGSVR - wiredTiger 11592 localhost:19003 CONFIGSVR - wiredTiger # This host # Mongo Executable ####################################################################################### Path to executable | /home/karl/tmp/MongoDB32Labs/3.2/bin/mongos # Report On karl-HP-ENVY ######################################## User | karl PID Owner | mongos Hostname | karl-HP-ENVY Version | 3.2.4 Built On | Linux x86_64 Started | 2017-02-22 11:39:20 -0300 ART Processes | 12 Process Type | mongos # Running Ops ############################################################################################ Type Min Max Avg Insert 0 0 0/5s Query 0 0 0/5s Update 0 0 0/5s Delete 0 0 0/5s GetMore 0 0 0/5s Command 1 1 5/5s # Security ############################################################################################### Users : 0 Roles : 0 Auth : disabled SSL : disabled Port : 0 Bind IP: # Cluster wide ########################################################################################### Databases: 4 Collections: 21 Sharded Collections: 5 Unsharded Collections: 16 Sharded Data Size: 134.87 MB Unsharded Data Size: 1.44 GB ### Chunks: 5 : samples.col2 132 : carlos.sample4 400 : carlos.sample3 50 : carlos.sample2 100 : carlos.sample1 # Balancer (per day) Success: 18 Failed: 0 Splits: 682 Drops: 0 |
The following is an output example when connected to a secondary in the replica set.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |