search

openzipkin / zipkin

Zipkin is a distributed tracing system
https://zipkin.io/
Apache License 2.0
16.95k stars 3.09k forks source link

Allow disabling some search options #3116

Open mrajah-twttr opened 4 years ago

mrajah-twttr commented 4 years ago

Feature: Currently the Zipkin UI has a standard set of trace look up criteria. Each of these options requires an API in the backend and and index to support it.. Some services may not have some of these due to scaling constraints. It would be very helpfiul if we can specify as a part of the config json which search options are supported by the backend.

Rational This helps keep the UI honest on what criteria the user can actually use to find traces

Example Scenario User wants to find some traces and tries to use the criteria like tags or remoteServiceName which are not supported by the backend.

Prior Art

jorgheymans commented 4 years ago

This does not sound unreasonable to me. Rule of three may apply though.

Curious: which storage backend do you use and which search criteria are troublesome for your site ?

mrajah-twttr commented 4 years ago

We have a custom key value store and due to some scale constraints dont have some of these indices setup yet.

codefromthecrypt commented 4 years ago

@mrajah-twttr are the v1 lookup fields "serviceName" and "spanName" still ok? or is it only "serviceName" that you have at the moment.

PS there is a way to disable the search screen at the moment, just not to pare down the criteria (only add.. ex the site-specific tags features allows more not less choices)

codefromthecrypt commented 4 years ago

Some other points:

The tags search is implemented the same as the old annotationQuery "foo=bar and baz", even if it looks different on the new UI. Do you not have this feature at all?

remoteServiceName is dependent on serviceName and is auto-populated.. It might be possible to control the visibility of this when the result is empty (which could have the same effect and still honor browser cache controls)

mrajah-twttr commented 4 years ago
  1. Yes, We dont have anno search index currently.
  2. serviceName is fine, spanName doesnt seem to work (when the page loads i can see a call to zipkin/api/v2/services made nothing for span). may be its never meant to be the top level criteria?
  3. When i choose serviceName i can see the call being made to "zipkin/api/v2/remoteServices?serviceName=" and "zipkin/api/v2/spans?serviceName=" the former doesn't exist and latter [works]. Is there any doc on the APIs the UI calls and the expected response structures?
codefromthecrypt commented 4 years ago

spanName should be conditional on serviceName.. it won't work top-level remoteServices was a recent index (twitter won't have it) but this is something I think we can special case 404 response (which I thought we did at some point!) empty string should never be sent.. that seems a bug

https://zipkin.io/zipkin-api/#/default is the api I use in-mem server (default jar file) plus the instructions in the zipkin-lens folder to do dev. You can also point the node app to your real backend.

this tip about the "debugger" keyword can help if you end up using the 'npm start' approach https://github.com/openzipkin/zipkin-js#debugging

mrajah-twttr commented 4 years ago

"empty string should never be sent.. that seems a bug" i dont have this issue, i truncated the URL i gave :) apologies for the confusion. it does send the right name..

If service name selection is required may be we should hide options like spanName, minDuration, maxDuration until a serviceName is chosen?

(Still need a way to disable remoteService and tags)