Interface CollectorMetrics
- All Known Implementing Classes:
InMemoryCollectorMetrics
decoding them into spans
,
apply sampling
, and queues them for storage
.
Callbacks on this type are invoked by zipkin collectors to improve the visibility of the system. A typical implementation will report metrics to a telemetry system for analysis and reporting.
Spans Collected vs Queryable Spans
A span queried may be comprised of multiple spans collected. While instrumentation should report complete spans, Instrumentation often patch the same span twice, ex adding annotations. Also, RPC spans include at least 2 messages due to the client and the server reporting separately. Finally, some storage components merge patches at ingest. For these reasons, you should be cautious to alert on queryable spans vs stored spans, unless you control the instrumentation in such a way that queryable spans/message is reliable.
Key Relationships
The following relationships can be used to consider health of the tracing system.
- Successful Messages =
Accepted messages
-Dropped messages
. Alert when this is less than amount of messages sent from instrumentation. - Stored spans <=
Accepted spans
-Dropped spans
. Alert when this drops below thecollection-tier sample rate
.
-
Field Summary
-
Method Summary
Modifier and TypeMethodDescriptionforTransport
(String transportType) Those who wish to partition metrics by transport can call this method to include the transport type in the backend metric key.void
incrementBytes
(int quantity) Increments the number of bytes containing serialized spans in a message.void
Increments count of messages received, which contain 0 or more spans.void
Increments count of messages that could not be read.void
incrementSpans
(int quantity) Increments the count of spans read from a successful message.void
incrementSpansDropped
(int quantity) Increments the count of spans dropped for any reason.
-
Field Details
-
NOOP_METRICS
-
-
Method Details
-
forTransport
Those who wish to partition metrics by transport can call this method to include the transport type in the backend metric key.For example, an implementation may by default report
incremented spans
to the key "zipkin.collector.span.accepted". Whenmetrics.forTransport("kafka"
is called, the counter would report to "zipkin.collector.kafka.span.accepted"- Parameters:
transportType
- ex "http", "rabbitmq", "kafka"
-
incrementMessages
void incrementMessages()Increments count of messages received, which contain 0 or more spans. Ex POST requests or Kafka messages consumed. -
incrementMessagesDropped
void incrementMessagesDropped()Increments count of messages that could not be read. Ex malformed content, or peer disconnect. -
incrementSpans
void incrementSpans(int quantity) Increments the count of spans read from a successful message. When bundling is used, accepted spans will be a larger number than successful messages. -
incrementBytes
void incrementBytes(int quantity) Increments the number of bytes containing serialized spans in a message.Note: this count should relate to the raw data structures, like json or thrift, and discount compression, enveloping, etc.
-
incrementSpansDropped
void incrementSpansDropped(int quantity) Increments the count of spans dropped for any reason. For example, failure queueing to storage or sampling decisions.
-