An annotation is similar to a log statement.
An annotation is similar to a log statement. It includes a host field which allows these events to be attributed properly, and also aggregatable.
Binary annotations are tags applied to a Span to give it context.
Binary annotations are tags applied to a Span to give it context. For example, a binary annotation of "http.uri" could the path to a resource in a RPC call.
Binary annotations of type STRING are always queryable, though more a historical implementation detail than a structural concern.
Binary annotations can repeat, and vary on the host. Similar to Annotation, the host indicates who logged the event. This allows you to tell the difference between the client and server side of the same key. For example, the key "http.uri" might be different on the client and server side due to rewriting, like "/api/v1/myresource" vs "/myresource. Via the host field, you can see the different points of view, which often help in debugging.
At connection time, we can let the server know who we are so they can book keep and optionally reject unknown clients.
These are connection-level options negotiated during protocol upgrade.
Serializes an individual delegation.
Indicates the network context of a service recording an annotation with two exceptions.
Indicates the network context of a service recording an annotation with two exceptions.
When a BinaryAnnotation, and key is CLIENT_ADDR or SERVER_ADDR, the endpoint indicates the source or destination of an RPC. This exception allows zipkin to display network context of uninstrumented services, or clients such as web browsers.
This struct serializes com.twitter.finagle.Context
RequestHeader defines headers for the request.
RequestHeader defines headers for the request. These carry the span data, and a flag indicating whether the request is to be debugged.
The Response carries a reply header for tracing.
The Response carries a reply header for tracing. These are empty unless the request is being debugged, in which case a transcript is copied.
A trace is a series of spans (often RPC calls) which form a latency tree.
A trace is a series of spans (often RPC calls) which form a latency tree.
The root span is where trace_id = id and parent_id = Nil. The root span is usually the longest interval in the trace, starting with a SERVER_RECV annotation and ending with a SERVER_SEND.
This is the struct that a successful upgrade will reply with.