feat(frontend): new app selector #712
Conversation
| const response = await requestWithOrgID('/querier.v1.QuerierService/Series', { | ||
| method: 'POST', | ||
| body: JSON.stringify({ | ||
| matchers: [], | ||
| }), | ||
| headers: { | ||
| 'content-type': 'application/json', | ||
| }, | ||
| }); |
There was a problem hiding this comment.
@simonswine I wonder if there isn't a better way to get this data...
There was a problem hiding this comment.
Are you asking for this https://connect.build/docs/web/getting-started ?
There was a problem hiding this comment.
Not quite, more like if we shouldn't create an endpoint that does most of this work (create an "App" that combines most of its labels). Plus I don't know how bad it currently is performance wise.
There was a problem hiding this comment.
I am unsure what the method is supposed to achieve.
- Do you just want to get a flat list of unique values for
pyroscope_app(or soon__service_name__): Then you should rather use LabelValues:
curl -vL -d '{"name":"__service_name__"}' -X POST -H "content-type: application/json" http://localhost:4100/querier.v1.QuerierService/LabelValues
It also supports matchers just like Series - Or do you need the full label set?: Then series is the way to go
There was a problem hiding this comment.
I think I need the full label set, since I need __service_name__ + profileID (to be able to create a "query") + other metadata fields, like __type__ and __name__ (to be able to display more info about what you are selecting) :(
There was a problem hiding this comment.
I see then maybe we should have a specific endpoint that allows that better.
Two ideas:
Seriesbut with the ability to give it the labels we are interested in e.g.labelNames=[...](I prefer that)LabelValueswith the ability to give it multiple labelNames
I would prefer both over a specialized endpoint for the menu
I think in the meantime it is probably good enough with series. Speaking with cyril earlier today we also discussed how maybe we would like to change the navigation longer term (let's catch-up on this later)
eh-am
changed the title
Features: * Adds an Application Selector to enable users to make more targeted queries by default, similar to OG Pyroscope. * Users can still write their own complex queries if desired. * Supports both "pyroscope_app" and "service_name" as indexes. Caveats: * Utilizes the /querier.v1.QuerierService/Series to create a list of apps, which returns more data than necessary. * Only returns data that is currently in memory, specifically recently ingested apps. (Related to [ui] 'ProfileID/Applications' only shows data that has been ingested recently https://github.com/grafana/phlare/issues/630) * Parsing an "App" from a non-trivial query (e.g., using !~) does not function correctly. In this PR, it primarily affects the dropdown population, which should not match a query like "cpu{app="myapp.*"}" to an "App" accurately. * Does not preserve tags when switching between apps. For example, if the current query is "cpu{mytag="foo", pyroscope_app="myapp"}" and the user clicks on "myapp2", even if "myapp2" shares the exact tags, the new query will completely remove "mytag="foo"": "cpu{pyroscope_app="myapp2"}". * The "pyroscope_app/service_name" tag is present in the app selector. * There is no filtering mechanism similar to OG Pyroscope.
Related grafana/pyroscope#2055
Example (updated)
Screen.Recording.2023-05-29.at.17.32.48.mov
It also supports mixing and matching
pyroscope_appand__service_name__:Screen.Recording.2023-05-30.at.11.33.02.mov
Features
pyroscope_appand__service_name__as "indexes"Caveats/Limitations
/querier.v1.QuerierService/Seriesto create a list of apps, which returns more data than needed.!~etc). In this PR it doesn't make too much difference, as the only thing that happens is not populating the dropdown correctly (which to be honest, it shouldn't, after all, a query likecpu{app="myapp.*"}doesn't really match to an "App"cpu{mytag="foo", pyroscope_app="myapp"}and clicking onmyapp2, even ifmyapp2shares the exact tags, the new query will completely stripmytag="foo":cpu{pyroscope_app="myapp2"}pyroscope_app/__service_name__tag is present in the app selector.