Reputation: 416
I have spring boot 2 REST application, with spring actuator enabled. by default spring generates a number of metrics (jvm, cpu, memory, etc) in /metrics
endpoint. Apart from this I have used Micrometer APIs to create custom metrics. So far its been working really well.
Now, I have a requirement to generate only my custom metrics, but disable all the default metrics that spring provides. Note that I do not want to disable /metrics
endpoint, but I want to disable only the default metrics.
Is this possible directly/indirectly now?
Thanks for any opinions and suggestion!
Upvotes: 8
Views: 12760
Reputation: 15230
The first thing I did to solve this issue in my code was to enable the 'Conditions Evaluation Report'. Setting the property debug=true
in your application.properties
file is sufficient. You should see something like the below in your logs. Just search this block for 'Metric' to find mentions of metrics-related classes.
2021-05-04T11:35:29.001-0300|DEBUG tionEvaluationReportLoggingListener[ 126] -
============================
CONDITIONS EVALUATION REPORT
============================
Positive matches:
-----------------
AopAutoConfiguration matched:
- @ConditionalOnProperty (spring.aop.auto=true) matched (OnPropertyCondition)
...
Next, you'll want to disable any auto-configured metrics classes that are not useful to you. You can do this by adding some attribute values to your @SpringBootApplication
annotation.
This is what I did in my application code:
@SpringBootApplication(
exclude = {
CompositeMeterRegistryAutoConfiguration.class,
JvmMetricsAutoConfiguration.class,
DataSourcePoolMetricsAutoConfiguration.class,
LogbackMetricsAutoConfiguration.class,
HttpClientMetricsAutoConfiguration.class
}
)
Finally, if there is an auto-configured metrics class that publishes some metrics values you want to keep, but others that you do not want, then you can disable individual metrics. This is easy if you are using an application.yaml
file. Below is an example from my code:
management:
metrics:
# Disable Spring Boot auto-configuration of metrics meter registries
use-global-registry: false
enable:
jvm:
# garbage collection, buffer, threads and classes metrics are not useful to us
gc: false
buffer: false
classes: false
threads: false
process:
# process start time is useless
start:
time: false
# system CPU metrics are useless for ECS tasks (we only care about 'process' metrics)
system:
cpu: false
export:
# Disable default in-memory metrics meter registry
simple:
enabled: false
# Publish metrics to AWS Cloudwatch, using the largest submission batch size that AWS supports
cloudwatch:
namespace: /my/metrics/namespace
batchSize: 20
You can do the same with an application.properties
file. It will just be more verbose.
There is also support for writing custom 'filter' classes that give you finer grained control than the properties/yaml file approach above. I haven't used it, but I mention it here for completeness.
Upvotes: 4
Reputation: 131
@SpringBootApplication(
exclude = {
CompositeMeterRegistryAutoConfiguration.class,
DataSourcePoolMetricsAutoConfiguration.class,
TomcatMetricsAutoConfiguration.class,
SimpleMetricsExportAutoConfiguration.class,
SystemMetricsAutoConfiguration.class
}
)
You need to exclude all the metrics auto configuration classes which are responsible for the default metrics in Spring Boot.
You can find all the metrics auto configuration classes here:
Upvotes: 12
Reputation: 6294
Exclude metrics wired by MetricsAutoConfiguration.class
like this:
@SpringBootApplication(exclude = MetricsAutoConfiguration.class)
Upvotes: 0
Reputation: 116091
Like most things in Spring Boot, the default metrics are configured via various auto-configuration classes. To disable the default metrics, exclude their auto-configuration classes using the exclude
attribute on @SpringBootApplication
. To see what auto-configurations are involved, you can launch your app with --debug
or take a look at the source code.
Upvotes: 5
Reputation: 1758
In theory, it should be possible to extend org.springframework.boot.actuate.metrics.MetricsEndpoint and expose only the information that you want to expose.
However, I would suggest to always define a new endpoint to handle your specific use case. In that case, you will not be bound to Spring libraries too tightly.
Upvotes: -1