<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Oct 22, 2015 at 5:39 PM roger peppe <<a href="mailto:roger.peppe@canonical.com">roger.peppe@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This seems reasonable to me. For myself, the time I'm looking at<br>
all-machines.log<br>
is often when the system is broken. I wonder whether a reasonable<br>
substitute might be a low level tool that can operate directly on the mongo<br>
database to fetch the logs, bypassing the juju system.<br></blockquote><div><br></div><div>+1<br></div><div>I'd like to see rsyslog gone, and the new logging to be enabled by default, but I think we do need some tooling to extract logs when things go awry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have one objection to the debug-log command - it doesn't<br>
appear to be possible to get the log up until the current time<br>
without blocking to wait for more messages when it gets<br>
to the end. So it's not quite a substitute because I can't easily<br>
grep the log without interrupting the grep command.<br>
<br>
  cheers,<br>
    rog.<br>
<br>
On 22 October 2015 at 09:51, Menno Smits <<a href="mailto:menno.smits@canonical.com" target="_blank">menno.smits@canonical.com</a>> wrote:<br>
> I implemented the ability for Juju's logs to go to MongoDB some time ago.<br>
> This feature is available in 1.25 behind a feature flag and also gets<br>
> enabled automatically if the "jes" feature flag is enabled (logging via<br>
> rsyslog doesn't make much sense when using multiple environments in the one<br>
> system).<br>
><br>
> There's also another separate feature flag which turns off rsyslog based<br>
> logging.<br>
><br>
> The "jes" feature flag will be removed soon meaning that database logging<br>
> will need to become default functionality. The question is do we then also<br>
> remove logging to rsyslog functionality, or perhaps reverse the sense of the<br>
> rsyslog feature flag so that it's off by default but can be enabled if<br>
> people want it for some reason?<br>
><br>
> I'm confident that the logging to the database feature is solid. I spent of<br>
> lot of time confirming that performance wouldn't be an issue. The code is<br>
> well tested. Automatic log rotation is implemented.<br>
><br>
> The main issue I can see is that once rsyslog based logging is turned off we<br>
> lose the all-machines.log file which some people and systems no doubt rely<br>
> on. The logs for an environment can of course still be retrieved using the<br>
> "juju debug-log" command.<br>
><br>
> If we really want something like all-machines.log, it wouldn't be /too/ hard<br>
> to implement a worker which generates an all-machines.log style file in<br>
> real-time from the database logs. All the pieces to implement that already<br>
> exist, but I really don't have the bandwidth this cycle to do the work.<br>
><br>
> Thoughts?<br>
><br>
> - Menno<br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Juju-dev mailing list<br>
> <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
> Modify settings or unsubscribe at:<br>
> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
><br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div></div>