search

openzipkin / zipkin-browser-extension

Chrome and Firefox browser extensions for Zipkin
Apache License 2.0
25 stars 13 forks source link

Allow filtering the trace list #22

Open shakuzen opened 6 years ago

shakuzen commented 6 years ago

When there are many traces shown in the trace list, it isn't always easy to find what you are looking for.

Some ideas for things to include and be able to filter on: HTTP status, HTTP method, URI.

Background

The idea for this came to me because of the following.

We have cases where an OPTIONS request will be sent before a GET/POST/PATCH request to the same URI. Both of these requests are intercepted by the plugin and shown in the Zipkin tab, but other than knowing that the OPTIONS request comes before the other, it isn't clear which is which. Since the OPTIONS request is handled by our API gateway (uninstrumented) and not sent to the API, this trace won't actually be in Zipkin. It would be nice to at least clearly distinguish the OPTIONS request and even better would be a way to filter it out of the list.

eirslett commented 6 years ago

I guess we could discard all OPTIONS requests, it doesn’t make sense to instrument them...

shakuzen commented 6 years ago

I guess we could discard all OPTIONS requests, it doesn’t make sense to instrument them...

That would be a welcome improvement regardless of whether we do filters, since as you say, it doesn't make sense to instrument them. That would mitigate the inconvenience that caused me to want filters in the first place.

eirslett commented 6 years ago

Feel free to send a PR! I guess that would be the easiest option for now, then we don’t need to implement filters.

codefromthecrypt commented 6 years ago

options is probably pre flight check for CORS. incidentally brave has no default sampling policy.. sleuth has a whitelist but not something for methods I think.

On Wed, 3 Oct 2018, 17:11 Tommy Ludwig, notifications@github.com wrote:

When there are many traces shown in the trace list, it isn't always easy to find what you are looking for.

Some ideas for things to include and be able to filter on: HTTP status, HTTP method, URI. Background

The idea for this came to me because of the following.

We have cases where an OPTIONS request will be sent before a GET/POST/PATCH request to the same URI. Both of these requests are intercepted by the plugin and shown in the Zipkin tab, but other than knowing that the OPTIONS request comes before the other, it isn't clear which is which. Since the OPTIONS request is handled by our API gateway (uninstrumented) and not sent to the API, this trace won't actually be in Zipkin. It would be nice to at least clearly distinguish the OPTIONS request and even better would be a way to filter it out of the list.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openzipkin/zipkin-browser-extension/issues/22, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD611gKEkGTAsvdbqeSncrJvUXgMis7ks5uhH88gaJpZM4XFmat .

codefromthecrypt commented 6 years ago

also trying haystack UI I noticed they have some pre canned filtering stuff. not saying related or not but it is neat. might relate to an outstanding Cassandra issue where we wanted to pre declare tags we index for load purposes.. if we had an inventory of indexed tags it might be usable here cc @drolando

On Thu, 4 Oct 2018, 06:57 Adrian Cole, adrian.f.cole@gmail.com wrote:

options is probably pre flight check for CORS. incidentally brave has no default sampling policy.. sleuth has a whitelist but not something for methods I think.

On Wed, 3 Oct 2018, 17:11 Tommy Ludwig, notifications@github.com wrote:

When there are many traces shown in the trace list, it isn't always easy to find what you are looking for.

Some ideas for things to include and be able to filter on: HTTP status, HTTP method, URI. Background

The idea for this came to me because of the following.

We have cases where an OPTIONS request will be sent before a GET/POST/PATCH request to the same URI. Both of these requests are intercepted by the plugin and shown in the Zipkin tab, but other than knowing that the OPTIONS request comes before the other, it isn't clear which is which. Since the OPTIONS request is handled by our API gateway (uninstrumented) and not sent to the API, this trace won't actually be in Zipkin. It would be nice to at least clearly distinguish the OPTIONS request and even better would be a way to filter it out of the list.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openzipkin/zipkin-browser-extension/issues/22, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD611gKEkGTAsvdbqeSncrJvUXgMis7ks5uhH88gaJpZM4XFmat .

eirslett commented 6 years ago

OPTIONS requests usually doesn't hit the application at all, they are handled by whatever is running in front, nginx or haproxy for example.

codefromthecrypt commented 6 years ago

sgtm @llinder wdyt?

On Thu, Oct 4, 2018 at 9:46 PM Eirik Sletteberg notifications@github.com wrote:

OPTIONS requests usually doesn't hit the application at all, they are handled by whatever is running in front, nginx or haproxy for example.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openzipkin/zipkin-browser-extension/issues/22#issuecomment-427025047, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD610uHDO8602LbyK6hlE1Lj4e8Q0GHks5uhhFOgaJpZM4XFmat .

llinder commented 6 years ago

Filtering would be interesting. Based on some of our use cases for Zipkin I can say that ignoring OPTIONS requests all together might not be ideal. One example is starting a trace client side based on some user action where we want to record latency from the clients perspective. Since a CORS preflight check could be part of the latency for the user action, dropping theses all together would give less overall insight.

All of that said, we don't use the browser extension heavily so I don't have a strong opinion against ignoring OPTIONS requests from the extension.

sideroad commented 6 years ago

+1