Hey Ted, great video! Looking forward to the up coming ones. I have a question on using AWS Lambda + Open Telemetry. As far as I know, Lambda supports OpenTelemetry via Lambda layers, doesnt this mean I could use B3?
Hi Alvin. The problem is that accessing HTTP headers on Lambda can be difficult and annoying. The X-Ray tracing header is automatically converted into the _X_AMZN_TRACE_ID env var, so it is easier to access. Also, certain AWS services associated with lambda will only take part in the trace when they see this header. The OpenTelemetry lambda support we provide presumes you are using the X-Ray header, and automatically extracts it to create a span for your function: github.com/open-telemetry/opentelemetry-lambda In the future AWS plans to support the W3C TraceContext header, and possibly B3. But I don't know the timeframe on that.
Hello Ted, Thanks for the quick explanation. I am just curious, is it possible to use the open-telemetry as a log/trace collector of third party product (e.g. Forgerock IDAM suite) logs in which, any of opentelemetry API or SDK is NOT used? We want to push the (ForgeRock OpenAM, OpenIDM and OpenIG) product logs in Splunk using OpenTelemetry (as log collector) and monitor them on Splunk dashboard. Is it doable? Also, could you please suggest if opentelemetry can support context propagation in such integration (with third party product) where no API/SDK is injected in the product?
The entire context isn't passed, just the Trace ID and parent Span ID. Some other bits but the 'entire' context is constructed on the back end based on the meta data of each span.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Very crisp and clear explanation. Easy to understand. Thanks!
I've come back to your videos over and over again over the last few years. They are super well done.
Looking to get into OTEL, and this was a great well paced intro. Sub'd, and looking for more!
Well done video and well explained. Thank you!
Well explained. Thank you!
Great explanation 👌
Nice explanation, very helpful video
Very cool! Thx!
You're welcome! :)
Thank you!
+1 for the Tolkien reference.
Is there a good practice for correlation with Netflow or packet capture data? For example, maybe a community id to correlation id?
Can you provide golang code to construct context from the headers.
In my case the second service is a pub/sub subscriber service
perfect
Hey Ted, great video! Looking forward to the up coming ones. I have a question on using AWS Lambda + Open Telemetry. As far as I know, Lambda supports OpenTelemetry via Lambda layers, doesnt this mean I could use B3?
Hi Alvin. The problem is that accessing HTTP headers on Lambda can be difficult and annoying. The X-Ray tracing header is automatically converted into the _X_AMZN_TRACE_ID env var, so it is easier to access. Also, certain AWS services associated with lambda will only take part in the trace when they see this header. The OpenTelemetry lambda support we provide presumes you are using the X-Ray header, and automatically extracts it to create a span for your function: github.com/open-telemetry/opentelemetry-lambda
In the future AWS plans to support the W3C TraceContext header, and possibly B3. But I don't know the timeframe on that.
Hello Ted, Thanks for the quick explanation. I am just curious, is it possible to use the open-telemetry as a log/trace collector of third party product (e.g. Forgerock IDAM suite) logs in which, any of opentelemetry API or SDK is NOT used? We want to push the (ForgeRock OpenAM, OpenIDM and OpenIG) product logs in Splunk using OpenTelemetry (as log collector) and monitor them on Splunk dashboard. Is it doable? Also, could you please suggest if opentelemetry can support context propagation in such integration (with third party product) where no API/SDK is injected in the product?
Hi Ted, nice explanation. How one should approach open tracing and open telemetry and how exactly these to are different/similar?
I like the video
I hope you will now know that I found it interesting
Wouldn't the size of the http headers blow up if you keep passing along the entire context all the time? Seems unnecessary
The entire context isn't passed, just the Trace ID and parent Span ID. Some other bits but the 'entire' context is constructed on the back end based on the meta data of each span.
Hi Ted! Awesome video! Thank you for doing this! Are the remaining videos out yet? Where can I find them?