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

Expose total bus capacity as metric #2677

Open
CodeDrivenMitch opened this issue Apr 6, 2023 · 1 comment
Open

Expose total bus capacity as metric #2677

CodeDrivenMitch opened this issue Apr 6, 2023 · 1 comment
Labels
Priority 2: Should High priority. Ideally, these issues are part of the release they’re assigned to. Status: Under Discussion Use to signal that the issue in question is being discussed. Type: Enhancement Use to signal an issue enhances an already existing feature of the project.

Comments

@CodeDrivenMitch
Copy link
Member

Enhancement Description

Exposing the capacity of a bus will allow users to better monitor the capacity of the application,

Current Behaviour

The capacity metrics expose the percentage of time the thread pool was busy - reflecting the amount of busy threads, up to the max thread pool size.
When monitoring this, the maximum value depends on the number of instances, which can be increased dynamically. This is very easy to do wrong.

Wanted Behaviour

Expose a commandBus_capacity_total and queryBus_capacity_total, containing the thread pool sizes for these busses.
This will allow a prometheus query resulting in a percentual capacity, like so:
image
sum by(app) (commandBus_capacity) / sum by(app) (commandBus_capacity_total)

Possible Workarounds

Build it yourself, like this:

public class CapacityMetricProvider {

    public CapacityMetricProvider(MeterRegistry meterRegistry,
                                  Long queryThreads,
                                  Long commandThreads) {
        meterRegistry.gauge("commandBus_capacity_total", commandThreads);
        meterRegistry.gauge("queryBus_capacity_total", queryThreads);
    }
}
@Configuration
public class MetricsConfig {
    @Bean
    public CapacityMetricProvider capacityMetricProvider(MeterRegistry meterRegistry,
                                                         @Value("${axon.axonserver.query-threads:10}") Long queryThreads,
                                                         @Value("${axon.axonserver.command-threads:10}") Long commandThreads) {
        return new CapacityMetricProvider(meterRegistry, queryThreads, commandThreads);
    }
}
@CodeDrivenMitch CodeDrivenMitch added Type: Enhancement Use to signal an issue enhances an already existing feature of the project. Priority 2: Should High priority. Ideally, these issues are part of the release they’re assigned to. labels Apr 6, 2023
@CodeDrivenMitch CodeDrivenMitch changed the title Expose available capacity as metric Expose total capacity as metric Apr 6, 2023
@CodeDrivenMitch CodeDrivenMitch changed the title Expose total capacity as metric Expose total bus capacity as metric Apr 6, 2023
@idugalic
Copy link
Member

idugalic commented Apr 6, 2023

I like the idea to expose commandThreads and queryThreads over the Metrics API! These represent the max size of the thread pool for command/query handling and it will make the Capacity graph look much better (the y-axis can show percentages being used, and not just the number of threads being used)

It would be nice to trigger this Gauage and increment or decrement the value on every application restart (or thread pools size being changed)

@smcvb smcvb added the Status: Under Discussion Use to signal that the issue in question is being discussed. label Apr 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority 2: Should High priority. Ideally, these issues are part of the release they’re assigned to. Status: Under Discussion Use to signal that the issue in question is being discussed. Type: Enhancement Use to signal an issue enhances an already existing feature of the project.
Projects
None yet
Development

No branches or pull requests

3 participants