You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The exporter's current behavior is that the first matching rule consumes the metric which will not be visible to subsequent matches. In the example below only the first rule will display any metrics from MyLegacyMetricsBean.
# The old way when I had a single class
- pattern: 'com.example.myproduct.metrics<type=MyLegacyMetricsBean><>([^:]+)'
name: myproduct_$1
...
# The new way with multiple classes
- pattern: 'com.example.myproduct.metrics<type=(.*)><>([^:]+)'
name: myproduct_$1_$2
...
I am doing a refactoring of my metrics and I would like to support the old and the new metrics for the foreseeable future. These overlapping rules would provide backward compatibility while also exposing the legacy metrics on the new naming convention.
I recommend a property settable on the rule level to override the current behavior (e.g. consume which defaults to true).
The text was updated successfully, but these errors were encountered:
The exporter's current behavior is that the first matching rule consumes the metric which will not be visible to subsequent matches. In the example below only the first rule will display any metrics from
MyLegacyMetricsBean
.I am doing a refactoring of my metrics and I would like to support the old and the new metrics for the foreseeable future. These overlapping rules would provide backward compatibility while also exposing the legacy metrics on the new naming convention.
I recommend a property settable on the rule level to override the current behavior (e.g.
consume
which defaults totrue
).The text was updated successfully, but these errors were encountered: