You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can see that according to the documentation, REST APIs can automatically propagate requests to their lambda handlers.
However, this isn't supported for HTTP APIs.
Use case
We have a microservices setup where API A might call API B, and we want X-Ray to trace all the way through.
Right now we use a workaround where we parse the x-amzn-trace-id header and create a new segment for each invocation. This kind of works, but it loses the subsegments generated by the Lambda service (which can tell us about e.g. cold start times). It's also ugly because now we get a DAG in the service graph with duplicates, like
client --> lambda --> lambda function
-------------> lambda function
This same kind of issue gets propagated to downstream calls, messing up our service graph.
I guess that this would have to be solved at the api gateway level, telling api gateway to continue the trace, passing this along to the lambda service and finally the lambda function?
Any direction or information here would be helpful. Thanks!
The text was updated successfully, but these errors were encountered:
Hi @alexandervandekleutab - thanks for the feature request for API GateWay HTTP APIs. You are right that today APIGW only supports active tracing on REST APIs, not HTTP APIs. We are aware of this gap but unfortunately do not have it on the roadmap to address this. We will keep this open to track if there are any changes.
I can see that according to the documentation, REST APIs can automatically propagate requests to their lambda handlers.
However, this isn't supported for HTTP APIs.
Use case
We have a microservices setup where API A might call API B, and we want X-Ray to trace all the way through.
Right now we use a workaround where we parse the
x-amzn-trace-id
header and create a new segment for each invocation. This kind of works, but it loses the subsegments generated by the Lambda service (which can tell us about e.g. cold start times). It's also ugly because now we get a DAG in the service graph with duplicates, likeThis same kind of issue gets propagated to downstream calls, messing up our service graph.
I guess that this would have to be solved at the api gateway level, telling api gateway to continue the trace, passing this along to the lambda service and finally the lambda function?
Any direction or information here would be helpful. Thanks!
The text was updated successfully, but these errors were encountered: