It's in the nature of a multi-tenant system that the various system logs will contain information pertaining to users from different subscribing companies. This sets up a potential conflict, when a subscriber has need for a log capture, e.g. by data subpoena, for troubleshooting, or otherwise, and for confidentiality reasons we can't disclose information about other tenants. We need to be prepared to quickly scrub a log of information about other tenants' transactions and deliver a subset of the log entries showing just those entries, which are relevant to the customer requesting the log. That subset of the log is what we generally refer to as a journal.
We also need to specify the retention time for logs. That's a decision on-premises customers make themselves, but for a Cloud system we need to set that value, and set it so everybody is satisfied, and compliance requirements are met. There is naturally only one log retention period, and it applies to all subscribers.
Finally, we carefully manage access to production system logs. In the interest of our subscribers, only production system administrators can access these logs. Developers needing to extract log information to troubleshoot on behalf of a customer – even though their work is customer requested - need to go through an exception process, demonstrate their legitimate need for the information, and have an extract provided to them. This is not vastly different from on-premises environments, where log access is also controlled. They key difference in the cloud is that the server logs contain information generated by multiple tenants, and we need a repeatable mechanism to filter logs and provide single-tenant extracts.