Hi - FWIW This won’t help with concurrent activations since the logs from concurrent activations will be interleaved (I think Dave was not suggesting to use this for concurrent activations). It will only help in the case where log processing is done outside of the invoker, and logs are not interleaved from multiple activations. I’m not sure having a start sentinel is simpler than just including the activation id in the existing sentinel line (end of log segment, not the beginning), but it would be probably simpler to read for a human.
If people use blackbox actions, and if blackbox containers have different log collection than managed actions, I think that would be a reason to not do anything until there is better support for structured logging, since if you are still using invoker to collect blackbox logs, you might as well use it to collect all logs? It may be that majority log collection is not blackbox so you could get some efficiencies there, but the added mess of multiple log collection approaches may bring different problems (my logs behave different for different types of actions, etc). One option might be to allow the /init endpoint to return some details about the container image, so that it can hint how it expects logs to be handled (if at all) at the invoker - currently /init response is only interpreted in case of a non-200 response. This same approach may be useful for other optional facilities like support of concurrency or gpu, where the container can signal it’s support and fail early if there is a mismatch with the action being executed. This would not resolve the different behavior problem, but would provide a smooth transition for older blackbox images. Thanks Tyson > On Aug 14, 2018, at 2:49 PM, Dragos Dascalita Haut > <ddas...@adobe.com.INVALID> wrote: > > "...we should be able to fully > process the logs offline and in a streaming manner and get the needed > activation id injected into every logline..." > > > +1 IIRC for concurrent activations Tyson Norris and Dan McWeeney were going > down this path as well. Having this natively supported by all OpenWhisk > runtimes can only make things easier. > > ________________________________ > From: David P Grove <gro...@us.ibm.com> > Sent: Tuesday, August 14, 2018 2:29:12 PM > To: dev@openwhisk.apache.org > Subject: logging baby step -- worth pursuing? > > > > Even if we think structured logging is the right eventual goal, it could > take a while to get there (especially since it is changing functionality > users may have grown accustomed to). > > However, for non-concurrent, non-blackbox runtimes we could make a small, > not-user visible change, that could enable fully offline and streaming log > processing. We already generate an end-of-log sentinel to stdout/stderr > for these runtimes. If we also generated a start-of-log sentinel to > stdout/stderr that included the activation id, we should be able to fully > process the logs offline and in a streaming manner and get the needed > activation id injected into every logline. > > Is this worth pursuing? I'm motivated to get log processing out of the > Invoker/ContainerRouter so we can push ahead with some of the scheduler > redesign....without tackling logging, I don't think we'll be able to assess > the true scalability potential of the new scheduling architectures. > > --dave
