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

Add ability to clear history for individual metrics #382

Closed
juliusv opened this Issue Mar 10, 2014 · 8 comments

Comments

Projects
None yet
3 participants
@juliusv
Copy link
Member

juliusv commented Mar 10, 2014

From @mweiden:

"Adding the ability to clear the history for one metric instead of removing all storage via 'sudo rm -rf /srv/prometheus/storage/*' would make debugging metric design much less painful and leave other crucial data intact."

@beorn7

This comment has been minimized.

Copy link
Member

beorn7 commented May 27, 2015

#743 has added the required method to the storage. Now we need an API...

@fabxc

This comment has been minimized.

Copy link
Member

fabxc commented May 27, 2015

We wanted to document an official v1 HTTP-API.
So we first will want to define a consistent one. Not sure whether the current endpoints fulfill that - especially in terms of the response format.

@juliusv

This comment has been minimized.

Copy link
Member Author

juliusv commented May 28, 2015

At least there's nothing obvious I'd want to change about the response formats for now. We made some adjustments to the response format (#389) before the January announcement, so that we wouldn't have to change it so much anymore afterwards.

We can think if we want to amend/adjust the query parameters. Currently you provide end and range for range queries, instead of start and end. We could allow optionally specifying start instead of end, but that could be added later in a non-breaking way.

@fabxc

This comment has been minimized.

Copy link
Member

fabxc commented May 28, 2015

Yes, was not so much about changing but about verifying that everything is consistent.
I actually started a design doc this morning - let's see.

If there's something we can do better, we shouldn't be hold back by a semi-official announcement in a buried issue.

Backwards compatibility is always an option.

@juliusv

This comment has been minimized.

Copy link
Member Author

juliusv commented May 28, 2015

Keep in mind that PromDash, Grafana, and other tools already use the query API as it stands today, so even without an official API announcement there's already tons of things we'd break if we changed something in a backwards-incompatible way. Hoping for v1 of the API to be compatible with today's API in the best case...

@fabxc

This comment has been minimized.

Copy link
Member

fabxc commented May 28, 2015

That's why I think we should just define a public API and provide the old one in parallel. We will want to do API-versioning, so the endpoint paths break anyway.

Filing two PRs for Grafana and PromDash over time to eventually switch shouldn't be the issue.

@juliusv

This comment has been minimized.

Copy link
Member Author

juliusv commented Jun 11, 2015

This just got fixed in #783

@juliusv juliusv closed this Jun 11, 2015

simonpasquier pushed a commit to simonpasquier/prometheus that referenced this issue Oct 12, 2017

Merge pull request prometheus#382 from prometheus/clarify-replace
Clarify replace relabel behavior with non-matching regex
@lock

This comment has been minimized.

Copy link

lock bot commented Mar 24, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Mar 24, 2019

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