MongoDB shard keeps growing, I don't know why?
If you have one database with hundreds of collections (it's not clear that is the case because you have not included an sh.status() or similar but that seems to be what you are implying), then here is the likely scenario:


The prodLN database has rs1 as its primary shard
Therefore all new collections created within that database will be created on rs1
If you then shard the collections (data is sharded on a collection level, not a database level) the data will be migrated from rs1 to other shards, but then you must rely on MongoDB to clean up the data post-delete (this also assumes a good shard key to distribute the data well across the shards)
You have not mentioned what version you are running, but there are lots of answers out there about deleted space reuse already (some pointers: 1 2 3), let's just say it's not very efficient for certain usage patterns (including yours)
Someone has added a maxSize parameter to the database, so it will be considered "full" and never be a target for chunk migrations, but that does not override the primary shard behavior when creating new databases, they still go on the primary shard, take up space, then get moved off by the balancer


What can you do? Well, you have a few options, but they require changes and/or downtime for the use of the current database:


Start using more than one database, make sure that the new databases have different primary shards (use movePrimary if not), start writing data there, maybe rotate around several
You can use movePrimary on the current database, but you have to stop writing to any unsharded collections (read the behavior section in the link above).  Depending on how much data there is in unsharded collections this could take some time.
You can attempt to reclaim space on the problem shard to buy yourself some time.  If you want to minimize downtime then I would recommend a rolling resync but this is only possible if you have 3 voting members in each set - you may only have two based on your output, unless arbiters have been excluded.  You could add a third member temporarily to the problem shard to perform the resyncs, then remove it later.