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

POC for enabling services to manage their own metrics #16224

Open
mhess-swl opened this issue Oct 29, 2024 · 0 comments · May be fixed by #16237
Open

POC for enabling services to manage their own metrics #16224

mhess-swl opened this issue Oct 29, 2024 · 0 comments · May be fixed by #16237
Assignees
Labels
Feature Enhancement Enhancing an existing feature driven by business requirements. Typically backwards compatible.
Milestone

Comments

@mhess-swl
Copy link
Member

mhess-swl commented Oct 29, 2024

Many of the services-related node metrics are metrics generated for each transaction type, independent of the service that produces them. However, as part of an EVM metric requirements effort, we want to provide a way for a service to manage a set of its own metrics. A first pass has been done here. This ticket is for exploring the possibility of creating a more generic solution, and to demonstrate the concept with a POC.

The services layer follows a typical pattern of injecting needed system functionality via context objects, while also restricting service access to each service's own scope (in the majority of cases). For example, the com.hedera.node.app.spi.store.StoreFactory interface is used to create restricted wrappers around a service's portions of state. Having a similar mechanism for creating and managing metrics would give each service a built-in way to focus on their own metrics logic while avoiding the hassle of integrating said metrics into the internals of the consensus node. However, if this approach will not work, we likely want to find another solution.

We will need a solution for contracts, at the very least, to go into the 0.57 release. In the worst case, the code from PR #16077 is a possible candidate if a better design can't be decided on before the deadline.

@mhess-swl mhess-swl self-assigned this Oct 29, 2024
@mhess-swl mhess-swl converted this from a draft issue Oct 29, 2024
@mhess-swl mhess-swl added this to the v0.57 milestone Oct 29, 2024
@mhess-swl mhess-swl added the Feature Enhancement Enhancing an existing feature driven by business requirements. Typically backwards compatible. label Oct 29, 2024
@mhess-swl mhess-swl linked a pull request Oct 30, 2024 that will close this issue
@netopyr netopyr moved this from 👷🏼‍♀️ In Progress to 📋 Backlog in Services Team Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Enhancement Enhancing an existing feature driven by business requirements. Typically backwards compatible.
Projects
Status: 📋 Backlog
Development

Successfully merging a pull request may close this issue.

1 participant