feat: fetch chain-specific metrics in standalone task #3214
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3214 +/- ##
=========================================
+ Coverage 0 67.65% +67.65%
=========================================
Files 0 99 +99
Lines 0 1014 +1014
Branches 0 106 +106
=========================================
+ Hits 0 686 +686
- Misses 0 284 +284
- Partials 0 44 +44
|
tkporter
reviewed
Feb 7, 2024
…to dan/optimize-chain-metrics-fetching
…to dan/optimize-chain-metrics-fetching
tkporter
approved these changes
Feb 8, 2024
2 tasks
yorhodes
pushed a commit
that referenced
this pull request
Feb 12, 2024
### Description Spawning a tokio task to fetch chain-specific metrics in provider middleware was wasteful because we ended up with 15 tasks doing the same job. Now there is a single task that is spawned inside the relayer, which I added in the struct that used to only fetch relayer balance. Some questions: - I'm realising in the current state I'm probably removing these metrics from validators. Lmk if yes and I'll add back - the chain-specific metrics were moved out of `MiddlewareMetrics` because they're no longer part of middleware, but I wasn't sure where to place them. Maybe `CoreMetrics` is a better place than the current `custom_metrics.rs` file? `tokio-metrics` turned out not to be useful because we'd need to instrument every call site of `tokio::spawn` with it. We should still do it but as a separate task imo. ### Drive-by changes - This PR also makes it very easy to add the metrics tasks for new chains, by extending the `HyperlaneProvider` trait with a `get_chain_metrics` call which seems reasonably general to me to have implemented by all providers. (Bc we currently only track these for evm chains) - the description, naming and logic of the `gas_price` metric was also changed to support new chains ### Related issues - Fixes #3047 ### Backward compatibility Yes ### Testing Still need to manually test
ltyu
pushed a commit
to ltyu/hyperlane-monorepo
that referenced
this pull request
Mar 13, 2024
…3214) ### Description Spawning a tokio task to fetch chain-specific metrics in provider middleware was wasteful because we ended up with 15 tasks doing the same job. Now there is a single task that is spawned inside the relayer, which I added in the struct that used to only fetch relayer balance. Some questions: - I'm realising in the current state I'm probably removing these metrics from validators. Lmk if yes and I'll add back - the chain-specific metrics were moved out of `MiddlewareMetrics` because they're no longer part of middleware, but I wasn't sure where to place them. Maybe `CoreMetrics` is a better place than the current `custom_metrics.rs` file? `tokio-metrics` turned out not to be useful because we'd need to instrument every call site of `tokio::spawn` with it. We should still do it but as a separate task imo. ### Drive-by changes - This PR also makes it very easy to add the metrics tasks for new chains, by extending the `HyperlaneProvider` trait with a `get_chain_metrics` call which seems reasonably general to me to have implemented by all providers. (Bc we currently only track these for evm chains) - the description, naming and logic of the `gas_price` metric was also changed to support new chains ### Related issues - Fixes hyperlane-xyz#3047 ### Backward compatibility Yes ### Testing Still need to manually test
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Spawning a tokio task to fetch chain-specific metrics in provider middleware was wasteful because we ended up with 15 tasks doing the same job. Now there is a single task that is spawned inside the relayer, which I added in the struct that used to only fetch relayer balance.
Some questions:
MiddlewareMetricsbecause they're no longer part of middleware, but I wasn't sure where to place them. MaybeCoreMetricsis a better place than the currentcustom_metrics.rsfile?tokio-metricsturned out not to be useful because we'd need to instrument every call site oftokio::spawnwith it. We should still do it but as a separate task imo.Drive-by changes
HyperlaneProvidertrait with aget_chain_metricscall which seems reasonably general to me to have implemented by all providers. (Bc we currently only track these for evm chains)gas_pricemetric was also changed to support new chainsRelated issues
Backward compatibility
Yes
Testing
Still need to manually test