Comment 5 for bug 1680683

I think this change would let you run it on a secondary:
$ diff -u sizes.js sizes2.js
--- sizes.js 2017-04-11 07:34:48.000000000 +0400
+++ sizes2.js 2017-04-11 07:34:37.000000000 +0400
@@ -17,7 +17,7 @@
 var collStats = [];
 for (i = 0; i < collectionNames.length; i++) {
   coll = collectionNames[i];
- s = db[coll].stats();
+ s = db[coll].stats({"slaveOk": 1});
   var storageSizeMB = s['storageSize'] / bytesInMB;
   var indexSizeMB = s['totalIndexSize'] / bytesInMB;
   var totalSizeMB = storageSizeMB + indexSizeMB;

That is the primary Juju database, and while you're experience a bit of bloat (256MB for txns) which should get better, that's clearly not where the bulk of your data is.

Another command you can run in the mongo shell is:

juju:PRIMARY> show databases
admin 0.000GB
backups 4.279GB
blobstore 1.821GB
juju 6.124GB
local 0.577GB
logs 3.434GB
presence 0.325GB

(I think it can be run on a secondary.)

"backups" shouldn't be interesting, as we shouldn't be grabbing data from there. 'logs' and 'blobstore' in particular are the ones that I think could be contributing to your 6GB backup.
You should be able to run 'sizes2.js' (with the patch is attached which hopefully runs on a secondary), but run it against specific databases:

for db in blobstore juju logs presence; do echo $db; /usr/lib/juju/mongo3.2/bin/mongo --ssl --sslAllowInvalidCertificates -u ${agent} -p $pw localhost:37017/$db --authenticationDatabase admin sizes2.js; done