-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Conversation
ae14671
to
bfd1ff2
Compare
@elasticmachine update branch |
0beac90
to
fc7ca20
Compare
Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore) |
There was a problem hiding this 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.
server/src/main/java/org/elasticsearch/repositories/RepositoriesStatsArchive.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoryStatsSnapshot.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/Repository.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/blobstore/MeteredBlobStoreRepository.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoriesStatsArchive.java
Outdated
Show resolved
Hide resolved
@@ -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)); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
plugins/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3Repository.java
Outdated
Show resolved
Hide resolved
...ain/java/org/elasticsearch/xpack/repositories/stats/action/RepositoriesNodeStatsRequest.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoriesStatsArchive.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoriesStatsArchive.java
Outdated
Show resolved
Hide resolved
Thanks for your initial review @original-brownbear ! I've applied most of your suggestions. |
There was a problem hiding this 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]] |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
server/src/main/java/org/elasticsearch/repositories/RepositoryInfo.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoryInfo.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoryInfo.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoryStats.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/repositories/stats/action/TransportRepositoriesStatsAction.java
Outdated
Show resolved
Hide resolved
[[clear-repositories-stats-archive-api-request]] | ||
==== {api-request-title} | ||
|
||
`DELETE /_nodes/<node_id>/_repositories_stats` |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 👍 .
There was a problem hiding this comment.
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).
docs/reference/repositories-stats/apis/get-repositories-stats.asciidoc
Outdated
Show resolved
Hide resolved
docs/reference/repositories-stats/apis/get-repositories-stats.asciidoc
Outdated
Show resolved
Hide resolved
Allow clearing up to a particular cluster version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks for the review @ywelsch! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks Francisco :)
@elasticmachine update branch |
@elasticmachine update branch |
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
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
A new experimental X-Pack API was added for repositories, but is missing a REST spec. The API was added in elastic#60371
* 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
* 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
* 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]>
* 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
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 thestatistics 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.