Simplify search on specific tags

[ledor473]

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

Might be related to #235

[jkowall]

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]

@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]

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]

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

[jkowall]

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]

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]

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]

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]

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

[joe-farro]

`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 <#261 (comment)>, 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]

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.