-
Notifications
You must be signed in to change notification settings - Fork 485
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[zpage] initial implementation #595
Conversation
Codecov Report
@@ Coverage Diff @@
## main #595 +/- ##
=====================================
Coverage 54.7% 54.7%
=====================================
Files 101 101
Lines 8943 8943
=====================================
Hits 4897 4897
Misses 4046 4046
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a great start! Should we add a note about the experimental status in the readme? seems to be suggested in https://github.com/open-telemetry/opentelemetry-specification/tree/main/experimental
* Added proto. * We use a dedicated SpanAggregator to collect information from ZPagesProcessor so that we could collect information from multiple span processor in the future should we needed to do so. * Always copy SpanData information and send it to aggregator. It may seems unnecessary to refresh the information on running span whenever a span is started. But consider that if the span is generating too fast. Some span may fail to notify the aggregator they already ended. So to make sure no span is stuck as running span example. We refresh the running span example whenever there is a new span started.
We aggregate the information for running spans, error spans and spans in different latencies bucket into SpanStats to better manage them.
* Updated proto.
…ries. 1. We use counts to trace the total number of spans. It's different from the len because len function tracks the number of sampled spans. 2. Added examples on how to query tracez results.
related #269.
Adding a
tracez
implementation to debug spans.It consists of three parts: a
ZPageSpanProcessor
to install with theTracerProvider
; aSpanAggregator
to accumulate the sample spans; a channel to send query requests toSpanAggregator
.We probably can extract the protobuf related transform into a separate crate(
opentelemetry-proto
maybe?) to be shared betweenopentelemetry-otlp
andopentelemetry-zpage
.Another limitation is we cannot record the status of the running spans as it requires we keep an immutable reference to the span. I don't think it's possible without introducing a lock inside the span. #602
Note to reviewers:
transform.rs
contains duplicate code fromopentelemetry-otlp
to transform between protobuf generated types and internal types.