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
Is your feature request related to a problem? Please describe.
Data Prepper produces a lot of metrics. And not all of them are necessary for all users. I'd like a way to disable metrics in Data Prepper.
Describe the solution you'd like
Add a list to the data-prepper-config.yaml file - disabled_metrics. This will disable metrics by name. It can also support Ant glob patterns to control how they are disabled.
Describe alternatives you've considered (Optional)
I considered adding this into a new file. But, the metrics are all configured in data-prepper-config.yaml, so I think we should keep it there for consistency.
We could also have some heuristic to know when a metric is part of a pipeline or not. Then we could avoid the * and **. But, using * and ** would be more flexible. And probably clearer.
For example, this could attempt to determine that the metric is associated with a pipeline and then disable.
disabled_metrics:
- add_entries.recordsOut.count
Additional context
N/A
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Data Prepper produces a lot of metrics. And not all of them are necessary for all users. I'd like a way to disable metrics in Data Prepper.
Describe the solution you'd like
Add a list to the
data-prepper-config.yaml
file -disabled_metrics
. This will disable metrics by name. It can also support Ant glob patterns to control how they are disabled.Describe alternatives you've considered (Optional)
I considered adding this into a new file. But, the metrics are all configured in
data-prepper-config.yaml
, so I think we should keep it there for consistency.We could also have some heuristic to know when a metric is part of a pipeline or not. Then we could avoid the
*
and**
. But, using*
and**
would be more flexible. And probably clearer.For example, this could attempt to determine that the metric is associated with a pipeline and then disable.
Additional context
N/A
The text was updated successfully, but these errors were encountered: