<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 October 2015 at 04:17, Nate Finch <span dir="ltr"><<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">IMO, all-machines.log is a bad idea anyway (it duplicates what's in the log files already, and makes it very likely that the state machines will run out of disk space, since they're potentially aggregating hundreds or thousands of machines' logs, not to mention adding a lot of network overhead). I'd be happy to see it go away.  </div></blockquote><div><br></div><div>Collecting the logs in a central place provides a single audit log and makes it possible to get the big picture when investigating why something happened. It also means we still have logs even when machines have been decommissioned.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">However, I am not convinced that dropping text file logs in general is a good idea, so I'd love to hear what we're gaining by putting logs in Mongo.</div></blockquote><div><br></div><div>The machine-*.log and unit-*.log files will remain as they are now. This change only affects the way logs get to the Juju controllers and how they're stored there.<br><br></div><div>The main driver for  putting the logs into the database was so we can cleanly separate logs for different environments running under a single controller. This is difficult to achieve reliably  with rsyslog. There are other benefits too:  more powerful filtering of logs, faster log queries (via indexes), allowing for structured log data to be emitted.<br></div></div><br></div></div>