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 repositories metering API #60371

Merged
merged 37 commits into from
Sep 8, 2020
Merged

Conversation

fcofdez
Copy link
Contributor

@fcofdez fcofdez commented Jul 29, 2020

This pull request adds a new set of APIs that allows tracking the number of requests performed
by the different repositories.

In order to avoid losing data, the repository statistics are archived after the repository is closed for
a configurable retention period repositories.stats.archive.retention_period. The API exposes the
statistics for the active repositories as well as the archived statistics.

The pull request is quite big but most of the code is needed for exposing the new endpoints and
for the integration tests.

@fcofdez
Copy link
Contributor Author

fcofdez commented Jul 31, 2020

@elasticmachine update branch

@fcofdez fcofdez changed the title Add repositories stats tracking API Add repositories utilization statistics API Aug 3, 2020
@fcofdez fcofdez added Team:Distributed Meta label for distributed team (obsolete) :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs >enhancement labels Aug 3, 2020
@fcofdez fcofdez marked this pull request as ready for review August 3, 2020 12:36
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore)

Copy link
Member

@original-brownbear original-brownbear left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thansk @fcofdez tried to get as far as I could for today and left a number of questions/suggestions for now.

@@ -89,6 +98,7 @@ public RepositoriesService(Settings settings, ClusterService clusterService, Tra
clusterService.addHighPriorityApplier(this);
}
this.verifyAction = new VerifyNodeRepositoryAction(transportService, clusterService, this);
this.repositoriesStatsArchive = new RepositoriesStatsArchive(REPOSITORIES_STATS_ARCHIVE_RETENTION_PERIOD.get(settings));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a cluster setting?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a strong opinion about that, we can move the new settings to the cluster level if we think it would be better.

@fcofdez
Copy link
Contributor Author

fcofdez commented Aug 5, 2020

Thanks for your initial review @original-brownbear ! I've applied most of your suggestions.

Copy link
Member

@original-brownbear original-brownbear left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple more points (particularly some questions on how the API should look as well)

@@ -0,0 +1,31 @@
[[clear-repositories-stats-archive-api]]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized :) Do we actually want to publicly document this API? If so I think we should make it very clear that this API is not supported/stable (regardless of what kind of stability we might offer here).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can state that this API is not stable and can suffer changes, I think it can be useful for consumers of this API to have the information at hand. But I'm not sure what's our policy here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now, we can just put on the "experimental tag", and mark the license as basic.

Copy link
Contributor

@ywelsch ywelsch Aug 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also add a header that this is an API meant to be used by Elastic's commercial offerings, to avoid any confusion.

[[clear-repositories-stats-archive-api-request]]
==== {api-request-title}

`DELETE /_nodes/<node_id>/_repositories_stats`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After I had some time to think about this ... I wonder, why make life for users so hard by adding node_id here. Wouldn't it be much easier if we just allowed for passing a list of emphemeral_id for archived entries instead so that the consuming API can delete after having safely persisted an id avoiding essentially all kinds of possible races and making this much easier to use?
In the implementation we could simply broadcast the delete to all nodes so we don't have to figure out what id lives on what node I guess to keep it simple.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ywelsch maybe you have an opinion on this as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we think this API would be hard to use, maybe we can limit its scope to a single node? I added it as I needed a way to clear the archive between tests, if there's a simpler way that can simplify this I'm open to it 👍 .

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we can use a logical timestamp here to say "only clear repositories that I've observed", and use the cluster state version as such a logical timestamp. I think I would prefer that over a list of all IDs for archived entries. The API would still allow the ability to select nodes (in particular allow for _local).

Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@fcofdez
Copy link
Contributor Author

fcofdez commented Sep 7, 2020

Thanks for the review @ywelsch!
@original-brownbear do you want to take a look to the latest changes?

Copy link
Member

@original-brownbear original-brownbear left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM thanks Francisco :)

@fcofdez
Copy link
Contributor Author

fcofdez commented Sep 7, 2020

@elasticmachine update branch

@fcofdez
Copy link
Contributor Author

fcofdez commented Sep 8, 2020

@elasticmachine update branch

@fcofdez fcofdez merged commit f55b204 into elastic:master Sep 8, 2020
fcofdez added a commit to fcofdez/elasticsearch that referenced this pull request Sep 8, 2020
This pull request adds a new set of APIs that allows tracking the number of requests performed
by the different registered repositories.

In order to avoid losing data, the repository statistics are archived after the repository is closed for
a configurable retention period `repositories.stats.archive.retention_period`. The API exposes the
statistics for the active repositories as well as the modified/closed repositories.

Backport of elastic#60371
fcofdez added a commit that referenced this pull request Sep 8, 2020
This pull request adds a new set of APIs that allows tracking the number of requests performed
by the different registered repositories.

In order to avoid losing data, the repository statistics are archived after the repository is closed for
a configurable retention period `repositories.stats.archive.retention_period`. The API exposes the
statistics for the active repositories as well as the modified/closed repositories.

Backport of #60371
stevejgordon added a commit to stevejgordon/elasticsearch that referenced this pull request Jul 15, 2021
A new experimental X-Pack API was added for repositories, but is missing a REST spec. The API was added in elastic#60371
stevejgordon added a commit that referenced this pull request Jul 16, 2021
* Add missing repositories API REST specs

A new experimental X-Pack API was added for repositories, but is missing a REST spec. The API was added in #60371

* Move this under the nodes namespace

* Rename max_version_to_clear parameter

* Update docs URL to use current
elasticsearchmachine pushed a commit to elasticsearchmachine/elasticsearch that referenced this pull request Jul 16, 2021
* Add missing repositories API REST specs

A new experimental X-Pack API was added for repositories, but is missing a REST spec. The API was added in elastic#60371

* Move this under the nodes namespace

* Rename max_version_to_clear parameter

* Update docs URL to use current
stevejgordon added a commit that referenced this pull request Jul 16, 2021
* Add missing repositories API REST specs

A new experimental X-Pack API was added for repositories, but is missing a REST spec. The API was added in #60371

* Move this under the nodes namespace

* Rename max_version_to_clear parameter

* Update docs URL to use current

Co-authored-by: Steve Gordon <[email protected]>
ywangd pushed a commit to ywangd/elasticsearch that referenced this pull request Jul 30, 2021
* Add missing repositories API REST specs

A new experimental X-Pack API was added for repositories, but is missing a REST spec. The API was added in elastic#60371

* Move this under the nodes namespace

* Rename max_version_to_clear parameter

* Update docs URL to use current
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs >enhancement Team:Distributed Meta label for distributed team (obsolete) v7.10.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants