Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support series selector for label/names and label/:name/values API #5248

Closed
jobrs opened this Issue Feb 21, 2019 · 7 comments

Comments

Projects
None yet
3 participants
@jobrs
Copy link

jobrs commented Feb 21, 2019

Proposal

Add support for series selectors (i.e. match[]) to the label/names resp. label/:name/values APIs, so that the list of label names and values can be constrained to a subset of series.

This is useful to build

  • Multi-tenancy using on labels for separating tenants (similar to #1813 (comment)_): To constrain a API call to a tenant you need to add a filter like tenant=xyz.
  • Sophisticated UIs supporting multiple filter conditions: To narrow down possible values iteratively (see also #407)

You could use the /series API for that purpose but that's quite a complex operation (example). I am hoping that this could be implemented in a much more efficient way on a lower layer.

@jobrs jobrs changed the title Support series selector for label/:name/values Support series selector for label/names and label/:name/values API Feb 21, 2019

@codesome

This comment has been minimized.

Copy link
Member

codesome commented Feb 21, 2019

This discussion had come up during the implementation of /label/names, but there was no efficient way to do it as of now. The best way now is equivalent to querying the tsdb for series and filter the required information - which is inefficient.

@jobrs

This comment has been minimized.

Copy link
Author

jobrs commented Feb 21, 2019

@codesome Agreed, see my last sentence. Still I would find the API addition useful, since future versions of the TSDB might (wishful thinking) allow for an optimised implementation and the addition would be consistent with the rest of the API.

@codesome

This comment has been minimized.

Copy link
Member

codesome commented Feb 21, 2019

Quoting prometheus/tsdb#530 (comment) from @brian-brazil

That's the only way to do it and the most efficient, I don't see the need to extend the API.

@krasi-georgiev

This comment has been minimized.

Copy link
Member

krasi-georgiev commented Feb 25, 2019

@jobrs is there anything else we need to add the the issue?
Otherwise I agree that we should extend the API only when we have a more efficient way that the current implementation.

@jobrs

This comment has been minimized.

Copy link
Author

jobrs commented Feb 25, 2019

@krasi-georgiev no, these are the points I wanted to raise

@krasi-georgiev

This comment has been minimized.

Copy link
Member

krasi-georgiev commented Feb 25, 2019

In that case I hope you don't mind closing the issue and can revisit at a later point when we can have a better answer.

@jobrs

This comment has been minimized.

Copy link
Author

jobrs commented Feb 25, 2019

closing this one, since the requested API addition is not needed from functional and performance perspective

@jobrs jobrs closed this Feb 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.