<div dir="ltr">Hey, In an effort to move forward with juju's windows integration I have summarized what seems to be the core points of this discussion to the best of my ability (please excuse me if I missed or misunderstood something).<div>
The two core points of discussion on this thread are:</div><div>* should we remove all-machines.log: which has been voted against, at least for the moment, since it is used for debug-log.</div><div>* how do we support logging in windows: The strongest suggestions here are a syslog package by gabriel and logging into MongoDB by Gustavo.</div>
<div><br></div><div>We do require some decision on the front of windows logging to have a complete windows support. Ideally we need senior citizens of juju dev community to weight into this in order to get a clear path to follow.</div>
<div><br></div><div>Here is a summary I made to help myself while following this discussion:</div><div><br></div>​Nate original suggestion:<div>* Remove all-machines.log: Claiming it takes a lot of space and it is not a multi platform solution</div>
<div><br></div><div>Tim, John, Aaaron, etc:</div><div>* all-machines.log is required for debug-log</div><div>* makes it big and it would be nice to rotate it.</div><div><br></div><div>Nate, gabriel:</div><div>* keep all-machines.log</div>
<div>* use a go-only solution (syslog package with ports from gabriel for windows)</div><div>John</div><div>* agrees.</div><div><br></div><div>Nate, gabriel:</div><div>* remove rsyslog from al OSes in favor of one solution that fits all OSes</div>
<div>* Replace with go only solution.</div><div><br></div><div>Dave:</div><div>* Dont mind about the logs, make it just output and let external tools handle logging and rotation.</div><div>* all-machines.log might be a bit bloated and it could contain less data that is more useful.</div>
<div>(Here is the reference to 12factor that will later be attibuted to nate)</div><div>Ian:</div><div>* Agrees with dave, yet we should provide a rolling mechanism.<br></div><div><br></div><div>Gabriel:</div><div>* Windows does not support capturing stdout as a logging mechanism, it requires to explicitly log into the event log.</div>
<div>* Thinks that using rsyslog to stream logs from agents to state server is too much overhead on external tools.</div><div>* Proposes replacing external rsyslog with in app solution for the case of streaming logs.</div>
<div>* Alternative solution, he does not recommend it, to create (and bundle with jujud.exe) a wrapper for windows only.</div><div><br></div><div>Gustavo:</div><div>* Present a possible alternative by using a MongoDB "capped collection" which will suit our use cases but does not recommend it because of the idea needs maturing on some details.</div>
<div><br></div><div>Matt:</div><div>* We should provide the option to log to stdout or syslog.</div><div><br></div><div>Kapil:</div><div>* Supports Gustavo's idea of logging in a structured form into Mongo as it makes sense to dump structured data with structure instead of serializing it to be de-serialized later.</div>
<div>* We can send also messages to syslog and let OPS people collec them themselves.</div><div><br></div><div>Gabriel (summarizing)</div><div>* I will be looking into event log for local windows logging. This will probably require writing a package.</div>
<div>* the syslog change will solve in the sort term, the aggregation issue from Windows nodes (when something better comes along, I will personally send a case of beer or ice-cream...or both, to whomever removes syslog as a dependency)</div>
<div>* lumberjack works *now* for local logging on both Windows and Ubuntu. It simply removes 2 dependencies (for logging) with just a few lines of code...</div><div><br></div><div>--</div><div>Horacio</div><div><br></div>
</div>