Simplify search on specific tags

ledor473 commented 6 years ago

Requirement - what kind of business use case are you trying to solve?

We've identified a few tags that are frequently used as a search criteria in Jaeger and would like to make it simpler to search on it.

Problem - what in Jaeger blocks you from solving the requirement?

Searching by Tags requires the tag name in addition to the value. There's no way to "lock" a specific tag that is widely used

Proposal - what do you suggest to solve the problem or improve the existing situation?

It would be nice if we could provide the Query component with a list of tags that would always be shown. Something like this:

A future version of this could be based on the selected service with a default for everyone (similar to the adaptive sampling config)

Any open questions to address

N/A

jkowall commented 3 years ago

I think this would create a lot of confusion, you can still search for multiple tags with the current single box which I think is fine. You can also bookmark a URL with a search in it and simply edit after the search is run. I'm going to close this since it doesn't make sense to implement this change, but feel free to re-open this if you disagree.

yurishkuro commented 3 years ago

@jkowall there are 5 upvotes, summarily closing may not be the best approach.

I do agree with you that this feels like a very specific feature that will be a maintenance burden without much benefit. In particular, in a large enough installation/organization who decides which tags should be elevated to such special status?

I can see a different version of this that could be more useful - a history-based helper. The top text box will remain the generic multi-tag entry, and below it a new section

You used these tags previously [tag1] [tag2] [tag3]

where [tagN] are pills with tag names and clicking on appends tagN= back to the single multi-entry box and puts cursor right after it with focus.

albertteoh commented 3 years ago

I like the idea of seeing the history of previously searched tags by the local user.

FWIW, I recall @yoave23 proposed a similar idea of tag autocompletion (for all known tags) which I think would be a useful feature, but I think we came across limitations because some backends weren't able to index by span tags.

yurishkuro commented 3 years ago

Yes, auto-completion is much harder as it requires backend support. The personal history of tags is pretty trivial to implement.

jkowall commented 3 years ago

Thanks for re-opening @yurishkuro and the feedback @albertteoh

There are several tickets on autocompletion, do we want to try to implement that on the backend?

Most browsers keep a form history and ranking for auto-complete these days, and we can force this on too (https://www.w3schools.com/tags/att_input_autocomplete.asp). I think that would meet the needs for this feature. If you want to store the history on the backend, how would that work exactly since Jaeger doesn't exactly have user management?

albertteoh commented 3 years ago

how would that work exactly since Jaeger doesn't exactly have user management?

Yeah, exactly, because it would be a non-trivial task to introduce server-side user sessions.

I'd imagine this feature would only keep history for the user during their active session and perhaps persisting this information between sessions via cookies, but I don't know how feasible the latter would be.

yurishkuro commented 3 years ago

I don't think auto-completion would work here because it would remember the whole query, and I expect queries to differ while often using similar tags.

Browsers have local storage, I was thinking of that rather than cookies or server side.

yoave23 commented 3 years ago

Yes, auto-completion is much harder as it requires backend support.

Do we have an estimation of how much effort this would take? I guess we'll need to implement it for each supported storage. From my experience, the tags search is a commonly used feature with much room for improvement in terms of UX/UI.

jkowall commented 3 years ago

@yoave23 If we do it client side it shouldn't be too much work I would think.

joe-farro commented 3 years ago

localStorage would work to store a history of any search field. I think the max per domain is generally around 2.5 MB so it can work pretty well for storing anything on that scale. Data is persisted until space runs low or the user clears site data.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API

For larger storage there is IndexDB which, IIRC, can store up to 2 GB (in some cases) or more. So it can work for something like creating an index of span tags from all traces that are fetched (which might be a strange user experience but maybe still be useful).

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Terminolog https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Terminology y

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria

The API is a bit wonky so there are a lot if wrapper available

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#libraries

On Wed, Oct 20, 2021, 7:38 AM Jonah Kowall @.***> wrote:

@yoave23 https://github.com/yoave23 If we do it client side it shouldn't be too much work I would think.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jaegertracing/jaeger-ui/issues/261#issuecomment-947581333, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFW5PM4YCSDCJFB57B4CNLUH2S37ANCNFSM4FYQNTGQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

crobertson-conga commented 2 years ago

Currently I'm evaluating Jaeger to understand how we can use it in my organization. It would be excellent for new users to have some things already set up for them when they come in. While a local tag history helps out if you are already using Jaeger, there are some tags that I would like to be able to have the following:

Make them well known as a general filter.
Potentially populate those tags with a set of well-known values.

Specifically, I'm thinking of Open Telemetry resource parameters and shipping tracing information to a central location for further analysis. I would love to be able to strongly recommend in the UI: deployment.environment (prod, stage, dev, and freeform) and service.namespace (aligned with a static set of product names) as two top-level tags that are recommended to filter upon when searching for traces. I was hoping that we could configure the UI search area with some static additional search tags via JSON...similarly to the menu bar, but ran across this enhancement which sounds very similar to what I was hoping for.

jaegertracing / jaeger-ui