Thanks for the suggestion. I haven’t been able to look at the data (yet), but I suppose it’s collecting some kind of error logs for the apps integration component of Rocket.Chat. The mongo database isn’t easy to get to with Studio3T in our case, since it’s running inside a docker container on a Cloudron platform. The CLI for mongodb is very clunky IMO, so there’s no easy way to review the data here either.
On a separate note though, I don’t really care about the data. 
The problem appears to be that since a recent Rocket.Chat update (I think it was the 7.2.0 server update), these logs are growing at an insane rate. It is filling a 500Gb disk within hours. This wasn’t happening before.
We don’t even have any apps installed. We did have a couple of free ones (polls and reminders) installed before the update, but we have removed them.
Actually since it’s running on Cloudron, the same reason it’s hard to get to the data, seems to be why our server is still operational. A side effect of the container’s virtual file system appears to be that the data lives inside the app container’s virtual file system. Restarting the app starts a new instance, and rebooting the server releases the “virtually” filled disk. I don’t claim to understand this, just that the effect is helping us clean up and stay operational. Otherwise we’d be stuck with a full disk.
The underlying problem is the rocket_chat_apps_logs collection growing at an unmanageable rate. Does anyone have some insight into how this can be fixed?