Closed maulikpandey closed 4 years ago
@maulikpandey can you provide an example of what you mean by collecting distribute traces from Circuit Breakers?
A hypothetical span of kind CLIENT
might look like this for a Hystrix call:
{
"traceId": "0000000000000aaa",
"id": "0000000000000aaa",
"kind": "CLIENT",
"name": "com.maulikpandey.services.hystrixWrappedCommand/myCommand",
"timestamp": 1575580714412903,
"duration": 22502,
"localEndpoint": {
"serviceName": "sample_app",
"ipv4": "127.0.0.1"
},
"tags": {
"service_asg_name": "myasg",
"service_cluster_name": "mycluster",
"service_name": "sample_app",
"ipc.status": "SUCCESS"
}
}
Consumers of spring-cloud-circuit-breakers
can inject additional tags like retries and error codes based on the context of the application. The responsibility of collecting and transporting traces from individual nodes/instances is out of scope for this instrumentation. A standardized instrumentation (auto-configuration) that starts and stops spans of kind CLIENT
may be ideal for this use case.
Closing this in favor of https://github.com/spring-cloud/spring-cloud-sleuth/pull/1505/files
We would like to see distributed tracing spans for Circuit Breakers via Spring Cloud Sleuth. We have a mix of Hystrix and Resilience4J being used today. Collecting distributed traces from Circuit Breakers will add more observability to our Springboot services. Ideally, traces should be collected via the Spring Cloud Sleuth auto configurations for all supported Circuit Breaker implementations.
We have considered adding custom auto configurations for collecting traces for Hystrix and Resilience4J. But, a standard way of collecting traces that works irrespective of the underlying Circuit Breaker implementation would help.