Constants (Zipkin 2.6.1 API)

java.lang.Object
- zipkin.Constants

public final class Constants
extends Object

Field Summary

Fields
Modifier and Type	Field and Description
`static String`	`CLIENT_ADDR` When present, `BinaryAnnotation.endpoint` indicates a client address ("ca") in a span.
`static String`	`CLIENT_RECV` The client received ("cr") a response from a server.
`static String`	`CLIENT_RECV_FRAGMENT` Optionally logs progress of a (CLIENT_RECV, WIRE_RECV).
`static String`	`CLIENT_SEND` The client sent ("cs") a request to a server.
`static String`	`CLIENT_SEND_FRAGMENT` Optionally logs progress of a (CLIENT_SEND, WIRE_SEND).
`static List<String>`	`CORE_ANNOTATIONS` Zipkin's core annotations indicate when a client or server operation began or ended.
`static String`	`ERROR` When an `Annotation.value`, this indicates when an error occurred.
`static String`	`LOCAL_COMPONENT` The `value` of "lc" is the component or namespace of a local span.
`static String`	`MESSAGE_ADDR` Indicates the remote address of a messaging span, usually the broker.
`static String`	`MESSAGE_RECV` A consumer received ("mr") a message from a broker.
`static String`	`MESSAGE_SEND` Message send ("ms") is a request to send a message to a destination, usually a broker.
`static String`	`SERVER_ADDR` When present, `BinaryAnnotation.endpoint` indicates a server address ("sa") in a span.
`static String`	`SERVER_RECV` The server received ("sr") a request from a client.
`static String`	`SERVER_RECV_FRAGMENT` Optionally logs progress of a (SERVER_RECV, WIRE_RECV).
`static String`	`SERVER_SEND` The server sent ("ss") a response to a client.
`static String`	`SERVER_SEND_FRAGMENT` Optionally logs progress of a (SERVER_SEND, WIRE_SEND).
`static String`	`WIRE_RECV` Optionally logs an attempt to receive a message from the wire.
`static String`	`WIRE_SEND` Optionally logs an attempt to send a message on the wire.

Method Summary
- Methods inherited from class java.lang.Object
  clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

- Field Detail
  - CLIENT_SEND
```
public static final String CLIENT_SEND
```
    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.endpoint 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.
    
    See Also:
    
    Constant Field Values
  - CLIENT_RECV
```
public static final String CLIENT_RECV
```
    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.endpoint 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.
    
    See Also:
    
    Constant Field Values
  - SERVER_SEND
```
public static final String SERVER_SEND
```
    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.endpoint 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.
    
    See Also:
    
    Constant Field Values
  - SERVER_RECV
```
public static final String SERVER_RECV
```
    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.endpoint 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.
    
    See Also:
    
    Constant Field Values
  - MESSAGE_SEND
```
public static final String MESSAGE_SEND
```
    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.endpoint 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.
    
    See Also:
    
    Constant Field Values
  - MESSAGE_RECV
```
public static final String MESSAGE_RECV
```
    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.endpoint 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.
    
    See Also:
    
    Constant Field Values
  - WIRE_SEND
```
public static final String WIRE_SEND
```
    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.
    
    See Also:
    
    Constant Field Values
  - WIRE_RECV
```
public static final String WIRE_RECV
```
    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.
    
    See Also:
    
    Constant Field Values
  - CLIENT_SEND_FRAGMENT
```
public static final String CLIENT_SEND_FRAGMENT
```
    Optionally logs progress of a (CLIENT_SEND, WIRE_SEND). For example, this could be one chunk in a chunked request.
    
    See Also:
    
    Constant Field Values
  - CLIENT_RECV_FRAGMENT
```
public static final String CLIENT_RECV_FRAGMENT
```
    Optionally logs progress of a (CLIENT_RECV, WIRE_RECV). For example, this could be one chunk in a chunked response.
    
    See Also:
    
    Constant Field Values
  - SERVER_SEND_FRAGMENT
```
public static final String SERVER_SEND_FRAGMENT
```
    Optionally logs progress of a (SERVER_SEND, WIRE_SEND). For example, this could be one chunk in a chunked response.
    
    See Also:
    
    Constant Field Values
  - SERVER_RECV_FRAGMENT
```
public static final String SERVER_RECV_FRAGMENT
```
    Optionally logs progress of a (SERVER_RECV, WIRE_RECV). For example, this could be one chunk in a chunked request.
    
    See Also:
    
    Constant Field Values
  - LOCAL_COMPONENT
```
public static final String LOCAL_COMPONENT
```
    The value of "lc" is the component or namespace of a local span.
    BinaryAnnotation.endpoint 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 via host. 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"
    
    See Also:
    
    Constant Field Values
  - ERROR
```
public static final String ERROR
```
    When an Annotation.value, this indicates when an error occurred. When a BinaryAnnotation.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.
    
    Since:
    
    Zipkin 1.3
    
    See Also:
    
    Constant Field Values
  - CLIENT_ADDR
```
public static final String CLIENT_ADDR
```
    When present, BinaryAnnotation.endpoint 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.
    
    See Also:
    
    Constant Field Values
  - SERVER_ADDR
```
public static final String SERVER_ADDR
```
    When present, BinaryAnnotation.endpoint 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.
    
    See Also:
    
    Constant Field Values
  - MESSAGE_ADDR
```
public static final String MESSAGE_ADDR
```
    Indicates the remote address of a messaging span, usually the broker.
    
    See Also:
    
    Constant Field Values
  - CORE_ANNOTATIONS
```
public static final List<String> CORE_ANNOTATIONS
```
    Zipkin's core annotations indicate when a client or server operation began or ended.
    These annotations are used to derive span timestamps and durations or highlight common latency explaining events. However, they aren't intuitive as storage queries, so needn't be indexed.

Class Constants

Field Summary

Method Summary

Methods inherited from class java.lang.Object

Field Detail

CLIENT_SEND

CLIENT_RECV

SERVER_SEND

SERVER_RECV

MESSAGE_SEND

MESSAGE_RECV

WIRE_SEND

WIRE_RECV

CLIENT_SEND_FRAGMENT

CLIENT_RECV_FRAGMENT

SERVER_SEND_FRAGMENT

SERVER_RECV_FRAGMENT

LOCAL_COMPONENT

ERROR

CLIENT_ADDR

SERVER_ADDR

MESSAGE_ADDR

CORE_ANNOTATIONS