openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <>
Subject Re: logging baby step -- worth pursuing?
Date Thu, 16 Aug 2018 00:29:48 GMT
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.


> On Aug 14, 2018, at 2:49 PM, Dragos Dascalita Haut <>
> "...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
> ________________________________
> From: David P Grove <>
> Sent: Tuesday, August 14, 2018 2:29:12 PM
> To:
> 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

View raw message