-
Notifications
You must be signed in to change notification settings - Fork 288
Conversation
1 similar comment
observer.go
Outdated
for _, obs := range o.observers { | ||
obs.OnSetTag(key, value) | ||
} | ||
|
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.
nit: extra line here.
Why do we have a method like "OnSetTag", but not something like "OnSetLog"? |
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.
@oibe the current use case for the observer is for metrics which needs tags, operationName, and startime to build the metrics name. If in the future we need further functionality for an observer, we can add OnSetLog.
LGTM, I'm still not completely sure why observer trumps decorator in this case but this looks good.
observer.go
Outdated
OnFinish(options opentracing.FinishOptions) | ||
} | ||
|
||
// observer is a disatcher to other observers |
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.
typo
|
||
// noopSpanObserver is used when there are no observers registered on the Tracer | ||
// or none of them returns span observers from OnStartSpan. | ||
var noopSpanObserver = spanObserver{} |
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.
shouldn't this implement SpanObserver funcs?
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.
it does
spanObs := obs.OnStartSpan(operationName, options) | ||
if spanObs != nil { | ||
if spanObservers == nil { | ||
spanObservers = make([]SpanObserver, 0, len(o.observers)) |
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.
is this what we want? what if spanObs is nil for 1 out of len(o.observers)? we allocate more mem than needed.
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.
do you have a better suggestion?
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.
can't we get rid of L40:L42?
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.
When you use append()
the first capacity of the slice is 2, then it's doubled when it needs to grow. So it's quite possible that in your approach (a) even more memory is allocated than needed, and what's worse (b) potentially more than one memory allocation happens should the slice needs to be extended.
In my approach you get no more than one allocation, and the memory (a pointer) is only wasted if some observers are not interested in the span. I don't think this memory waste is that critical, the service would need to keep a lot of spans in-flight for this to matter
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.
Aren't you tired of always being right?
@oibe we can add onSetLog if/when this becomes necessary. Right now there's no use case for it so I am not adding it. Also, logs API is quite verbose, it's not clear what the callback should look like. |
1 similar comment
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.
LGTM, the point i made does not apply to this diff directly.
startTime := options.StartTime | ||
if startTime.IsZero() { | ||
startTime = t.timeNow() | ||
if options.StartTime.IsZero() { |
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.
why test for this? If we are testing that FinishTime is zero, and StartTime is also zero, the failure of a startTime to be set will be apparent in the UI, is a visible (and ugly) bug.
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.
A span must have a start time. But options.startTime
is an optional parameter, we do not expect most users to set it.
@black-adder cf. #103 (rpcmetrics/observer.go). There is not a lot of difference with the decorator, but
|
1 similar comment
Metrics are useful to gain insights in a distributed application. But there can be a lot of metrics in different domains. Adding such metrics to any one (client) tracer breaks cross platform compatibility. This commit adds a new observer and span observer API which defines a standard interface to add such metrics. To expose the metrics, one would have to implement the observer interface. The (client) tracers would just have to install callbacks for methods such as StartSpan, SetOperationName, SetTag and Finish. The registered callbacks would then be called on the span events if an observer is created. This is based on the work done by Yuri here : jaegertracing/jaeger-client-go#94 Signed-off-by: Yuri Shkuro <[email protected]> Signed-off-by: Hemant Kumar <[email protected]>
1 similar comment
|
||
type testObserver struct{} | ||
|
||
type testSpanObserver struct { |
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.
Is there a reason to create a test struct vs using "mockery"? Is it just because this is simpler?
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.
for the clients, we want them as lightweight as possible, the fewer deps the better
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.
@oibe is there a reason to use mockery instead of creating a struct?
Metrics are useful to gain insights in a distributed application. But there can be a lot of metrics in different domains. Adding such metrics from one domain (metrics exporter pkg) into zipkin is not good for cross platform compatibility. This commit adds a new observer and span observer API which defines a standard interface to add such metrics. To expose the metrics, one would have to implement the observer interface in the metrics exporter. zipkin will need to implement this interface and install callbacks for methods such as StartSpan, SetOperationName, SetTag and Finish. The registered callbacks would then be called on the span events if an observer is created. This is based on the work done by Yuri here : jaegertracing/jaeger-client-go#94 Signed-off-by: Yuri Shkuro <[email protected]> Signed-off-by: Hemant Kumar <[email protected]>
Intended to add observer to emit RPC metrics.
@black-adder @badiib