Skip to content

Add parameters to BlobStore#stats() request for different dimensions #126262

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

Open
mhl-b opened this issue Apr 4, 2025 · 3 comments
Open

Add parameters to BlobStore#stats() request for different dimensions #126262

mhl-b opened this issue Apr 4, 2025 · 3 comments
Labels
:Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs Team:Distributed Coordination Meta label for Distributed Coordination team >tech debt

Comments

@mhl-b
Copy link
Contributor

mhl-b commented Apr 4, 2025

default Map<String, BlobStoreActionStats> stats() {

Map<String, BlobStoreActionStats> stats() is an interface to get stats from the blob store for every repository implementation (S3, Azure, GCS). The problem with this API that it returns different keys depending on the environment. Specifically every cloud implementation checks if it's serverless:

S3:

    @Override
    public Map<String, BlobStoreActionStats> stats() {
        return statsCollectors.statsMap(service.isStateless);
    }

Azure:

    @Override
    public Map<String, BlobStoreActionStats> stats() {
        return requestMetricsRecorder.statsMap(service.isStateless());
    }

GCS:

    @Override
    public Map<String, BlobStoreActionStats> stats() {
        return statsCollector.operationsStats(storageService.isServerless());
    }

And outcome of API will be different. In stateful Map<Operation, BlobStoreActionStats> and serverless Map<OperationPurpose_Operation, BlobStoreActionStats>. So serverless returns two dimensional data, every pair of purpose and operation. Caller of this API needs to know how to deal with different outputs.

We need to change API so it accepts arguments that describe what kind of stats caller needs. For example, which dimensions OperationPurpose, Operation, or maybe both stats(List<Dimensions>) or more rigid stats(boolean withOperationPurpose). Also remove serverless flag.

@mhl-b mhl-b added :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs good first issue low hanging fruit Team:Distributed Coordination Meta label for Distributed Coordination team labels Apr 4, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

@hye-on
Copy link
Contributor

hye-on commented Apr 4, 2025

@mhl-b Can I take this on? :)

@mhl-b
Copy link
Contributor Author

mhl-b commented Apr 4, 2025

@hye-on this issue a bit hard for external contributor, need to touch elastic private code too, sorry

@mhl-b mhl-b removed the good first issue low hanging fruit label Apr 11, 2025
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 Team:Distributed Coordination Meta label for Distributed Coordination team >tech debt
Projects
None yet
Development

No branches or pull requests

3 participants