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

Clarify the use of Scopes in Multi-Application Environments #626

Open
jbee opened this issue Nov 24, 2020 · 3 comments
Open

Clarify the use of Scopes in Multi-Application Environments #626

jbee opened this issue Nov 24, 2020 · 3 comments

Comments

@jbee
Copy link
Contributor

jbee commented Nov 24, 2020

While the specification defines which metrics should be contained in which scope it is not fully clear that each application would have its own base, vendor and application instance of the MetricRepository.

Most of the metrics described in MP specification refer to environment properties that would not be different for different applications suggesting that base and possibly vendor are "shared" for all applications. This however is not the case for the JAX-RS metrics or FT metrics which both are clearly related to a specific application but still belong to the base scope. This suggests that within an application context there should be a base, vendor and application instance of the MetricRepository. In that scenario the logical way to avoid duplication of the environment properties per application (which mostly would look wrong during export) would be to add a "global" base and vendor MetricRepository as well.

Another issue with only a "shared" or "global" base and vendor instance of the MetricRepository would be that when application related sources add to these "collisions" can occur where two different applications update the same shared metric. Also during export the relation to an application is lost and no _app tag could be added again suggesting that there should be a base and vendor instance for each application.

This issue should start the discussion how to make the specification less ambiguous when it comes to scopes and instances of MetricRepository in multi-application environments.

@jbee
Copy link
Contributor Author

jbee commented Nov 30, 2020

Maybe the most obvious issue - with only a single base instance that exists throughout the life of the container different applications using the same class (for example bean classes used in TCK) will affect each other as the metrics never "reset".

@donbourne
Copy link
Member

@jbee , at this point the spec hasn't been specific about which metrics would be expected to be given an app label and which wouldn't. I expect that different server vendors have made different decisions on how to handle that. Perhaps first step on this could be to have different vendors that have multi-app servers show how they handle different metrics and see if we're already consistent or have differences to discuss?

@jbee
Copy link
Contributor Author

jbee commented Dec 2, 2020

@donbourne FYI: we moved towards base, vendor, application per application with an additional "global" context that only has base and vendor because this seemed the only logical way to implement what FT spec describes when it comes to metrics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants