Thrift module: zipkinCore

The client sent ("cs") a request to a server. There is only one send per
span. For example, if there's a transport error, each attempt can be logged
as a WIRE_SEND annotation.

If chunking is involved, each chunk could be logged as a separate
CLIENT_SEND_FRAGMENT in the same span.

Annotation.host is not the server. It is the host which logged the send
event, almost always the client. When logging CLIENT_SEND, instrumentation
should also log the SERVER_ADDR.

The client received ("cr") a response from a server. There is only one
receive per span. For example, if duplicate responses were received, each
can be logged as a WIRE_RECV annotation.

If chunking is involved, each chunk could be logged as a separate
CLIENT_RECV_FRAGMENT in the same span.

Annotation.host is not the server. It is the host which logged the receive
event, almost always the client. The actual endpoint of the server is
recorded separately as SERVER_ADDR when CLIENT_SEND is logged.

The server sent ("ss") a response to a client. There is only one response
per span. If there's a transport error, each attempt can be logged as a
WIRE_SEND annotation.

Typically, a trace ends with a server send, so the last timestamp of a trace
is often the timestamp of the root span's server send.

If chunking is involved, each chunk could be logged as a separate
SERVER_SEND_FRAGMENT in the same span.

Annotation.host is not the client. It is the host which logged the send
event, almost always the server. The actual endpoint of the client is
recorded separately as CLIENT_ADDR when SERVER_RECV is logged.

The server received ("sr") a request from a client. There is only one
request per span.  For example, if duplicate responses were received, each
can be logged as a WIRE_RECV annotation.

Typically, a trace starts with a server receive, so the first timestamp of a
trace is often the timestamp of the root span's server receive.

If chunking is involved, each chunk could be logged as a separate
SERVER_RECV_FRAGMENT in the same span.

Annotation.host is not the client. It is the host which logged the receive
event, almost always the server. When logging SERVER_RECV, instrumentation
should also log the CLIENT_ADDR.

Message send ("ms") is a request to send a message to a destination, usually
a broker. This may be the only annotation in a messaging span. If WIRE_SEND
exists in the same span, it follows this moment and clarifies delays sending
the message, such as batching.

Unlike RPC annotations like CLIENT_SEND, messaging spans never share a span
ID. For example, "ms" should always be the parent of "mr".

Annotation.host is not the destination, it is the host which logged the send
event: the producer. When annotating MESSAGE_SEND, instrumentation should
also tag the MESSAGE_ADDR.

A consumer received ("mr") a message from a broker. This may be the only
annotation in a messaging span. If WIRE_RECV exists in the same span, it
precedes this moment and clarifies any local queuing delay.

Unlike RPC annotations like SERVER_RECV, messaging spans never share a span
ID. For example, "mr" should always be a child of "ms" unless it is a root
span.

Annotation.host is not the broker, it is the host which logged the receive
event: the consumer.  When annotating MESSAGE_RECV, instrumentation should
also tag the MESSAGE_ADDR.

Optionally logs an attempt to send a message on the wire. Multiple wire send
events could indicate network retries. A lag between client or server send
and wire send might indicate queuing or processing delay.

Optionally logs an attempt to receive a message from the wire. Multiple wire
receive events could indicate network retries. A lag between wire receive
and client or server receive might indicate queuing or processing delay.

Optionally logs progress of a (CLIENT_SEND, WIRE_SEND). For example, this
could be one chunk in a chunked request.

Optionally logs progress of a (CLIENT_RECV, WIRE_RECV). For example, this
could be one chunk in a chunked response.

Optionally logs progress of a (SERVER_SEND, WIRE_SEND). For example, this
could be one chunk in a chunked response.

Optionally logs progress of a (SERVER_RECV, WIRE_RECV). For example, this
could be one chunk in a chunked request.

The domain portion of the URL or host header. Ex. "mybucket.s3.amazonaws.com"

Used to filter by host as opposed to ip address.

The HTTP method, or verb, such as "GET" or "POST".

Used to filter against an http route.

The absolute http path, without any query parameters. Ex. "/objects/abcd-ff"

Used as a filter or to clarify the request path for a given route. For example, the path for
a route "/objects/:objectId" could be "/objects/abdc-ff". This does not limit cardinality like
HTTP_ROUTE("http.route") can, so is not a good input to a span name.

The Zipkin query api only supports equals filters. Dropping query parameters makes the number
of distinct URIs less. For example, one can query for the same resource, regardless of signing
parameters encoded in the query line. Dropping query parameters also limits the security impact
of this tag.

Historical note: This was commonly expressed as "http.uri" in zipkin, even though it was most

The route which a request matched or "" (empty string) if routing is supported, but there was no
match. Ex "/users/{userId}"

Unlike HTTP_PATH("http.path"), this value is fixed cardinality, so is a safe input to a span
name function or a metrics dimension. Different formats are possible. For example, the following
are all valid route templates: "/users" "/users/:userId" "/users/*"

Route-based span name generation often uses other tags, such as HTTP_METHOD("http.method") and
HTTP_STATUS_CODE("http.status_code"). Route-based names can look like "get /users/{userId}",
"post /users", "get not_found" or "get redirected".

The entire URL, including the scheme, host and query parameters if available. Ex.
"https://mybucket.s3.amazonaws.com/objects/abcd-ff?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Algorithm=AWS4-HMAC-SHA256..."

Combined with HTTP_METHOD, you can understand the fully-qualified request line.

This is optional as it may include private data or be of considerable length.

The HTTP status code, when not in 2xx range. Ex. "503"

Used to filter for error status.

The size of the non-empty HTTP request body, in bytes. Ex. "16384"

Large uploads can exceed limits or contribute directly to latency.

The size of the non-empty HTTP response body, in bytes. Ex. "16384"

Large downloads can exceed limits or contribute directly to latency.

The value of "lc" is the component or namespace of a local span.

BinaryAnnotation.host adds service context needed to support queries.

Local Component("lc") supports three key features: flagging, query by
service and filtering Span.name by namespace.

While structurally the same, local spans are fundamentally different than
RPC spans in how they should be interpreted. For example, zipkin v1 tools
center on RPC latency and service graphs. Root local-spans are neither
indicative of critical path RPC latency, nor have impact on the shape of a
service graph. By flagging with "lc", tools can special-case local spans.

Zipkin v1 Spans are unqueryable unless they can be indexed by service name.
The only path to a service name is by (Binary)?Annotation.host.serviceName.
By logging "lc", a local span can be queried even if no other annotations
are logged.

The value of "lc" is the namespace of Span.name. For example, it might be
"finatra2", for a span named "bootstrap". "lc" allows you to resolves
conflicts for the same Span.name, for example "finatra/bootstrap" vs
"finch/bootstrap". Using local component, you'd search for spans named
"bootstrap" where "lc=finch"

When an annotation value, this indicates when an error occurred. When a
binary annotation key, the value is a human readable message associated
with an error.

Due to transient errors, an ERROR annotation should not be interpreted
as a span failure, even the annotation might explain additional latency.
Instrumentation should add the ERROR binary annotation when the operation
failed and couldn't be recovered.

Here's an example: A span has an ERROR annotation, added when a WIRE_SEND
failed. Another WIRE_SEND succeeded, so there's no ERROR binary annotation
on the span because the overall operation succeeded.

Note that RPC spans often include both client and server hosts: It is
possible that only one side perceived the error.

Indicates a client address ("ca") in a span. Most likely, there's only one.
Multiple addresses are possible when a client changes its ip or port within
a span.

Indicates a server address ("sa") in a span. Most likely, there's only one.
Multiple addresses are possible when a client is redirected, or fails to a
different server ip or port.

Indicates the remote address of a messaging span, usually the broker.