Allow filtering the trace list #22
Comments
|
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. |
|
Feel free to send a PR! I guess that would be the easiest option for now, then we don’t need to implement filters. |
|
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, ***@***.***> 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
<#22>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD611gKEkGTAsvdbqeSncrJvUXgMis7ks5uhH88gaJpZM4XFmat>
.
|
|
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, ***@***.***> 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, ***@***.***> 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
> <#22>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AAD611gKEkGTAsvdbqeSncrJvUXgMis7ks5uhH88gaJpZM4XFmat>
> .
>
|
|
OPTIONS requests usually doesn't hit the application at all, they are handled by whatever is running in front, nginx or haproxy for example. |
|
sgtm @llinder wdyt?
…On Thu, Oct 4, 2018 at 9:46 PM Eirik Sletteberg ***@***.***> 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
<#22 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAD610uHDO8602LbyK6hlE1Lj4e8Q0GHks5uhhFOgaJpZM4XFmat>
.
|
|
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. |
|
+1 |
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.
The text was updated successfully, but these errors were encountered: