public static final class InMemoryStorage.Builder extends StorageComponent.Builder
Constructor and Description |
---|
Builder() |
Modifier and Type | Method and Description |
---|---|
InMemoryStorage |
build() |
InMemoryStorage.Builder |
maxSpanCount(int maxSpanCount)
Eldest traces are removed to ensure spans in memory don't exceed this value
|
InMemoryStorage.Builder |
searchEnabled(boolean searchEnabled)
False is an attempt to disable indexing, leaving only
SpanStore.getTrace(String)
supported. |
InMemoryStorage.Builder |
strictTraceId(boolean strictTraceId)
Zipkin supports 64 and 128-bit trace identifiers, typically serialized as 16 or 32 character
hex strings.
|
public InMemoryStorage.Builder strictTraceId(boolean strictTraceId)
Zipkin historically had 64-bit trace IDs
, but it now supports 128-bit
trace IDs via 32-character hex representation. While instrumentation update to propagate
128-bit IDs, it can be ambiguous whether a 64-bit trace ID was sent intentionally, or as an
accident of truncation. This setting allows Zipkin to be usable until application
instrumentation are upgraded to support 128-bit trace IDs.
Here are a few trace IDs the help explain this setting.
In the above example, Trace ID A and Trace ID B might mean they are in the same trace,
since the lower-64 bits of the IDs are the same. This could happen if a server A created the
trace and propagated it to server B which ran an older tracing library. Server B could have
truncated the trace ID to lower-64 bits. When strictTraceId == false
, spans matching
either trace ID A or B would be returned in the same trace when searching by ID A or B. Spans
with trace ID C or D wouldn't be when searching by ID A or B because trace IDs C and D don't
share lower 64-bits (right-most 16 characters) with trace IDs A or B.
It is also possible that all servers are capable of handling 128-bit trace identifiers,
but are configured to only send 64-bit ones. In this case, if strictTraceId == false
trace ID A and B would clash and be put into the same trace, causing confusion. Moreover,
there is overhead associated with indexing spans both by 64 and 128-bit trace IDs. When a
site has finished upgrading to 128-bit trace IDs, they should enable this setting.
See https://github.com/openzipkin/b3-propagation/issues/6 for the status of known open source libraries on 128-bit trace identifiers.
strictTraceId
in class StorageComponent.Builder
public InMemoryStorage.Builder searchEnabled(boolean searchEnabled)
StorageComponent.Builder
SpanStore.getTrace(String)
supported. For example, query requests will be disabled.
The use case is typically to support 100% sampled data, or when traces are searched using
alternative means such as a logging index.
Refer to implementation docs for the impact of this parameter. Operations that use indexes should return empty as opposed to throwing an exception.
searchEnabled
in class StorageComponent.Builder
public InMemoryStorage.Builder maxSpanCount(int maxSpanCount)
public InMemoryStorage build()
build
in class StorageComponent.Builder
Copyright © 2015–2018 OpenZipkin. All rights reserved.