Spring Boot Actuator module basically helps you to observe and control your Spring Boot application. It is done by equipping production-ready features like metrics gathering, health check-up, HTTP detection, etc.
Actuator use an application metrics facade, also known as Micrometer, so that the external application monitoring systems can be incorporated within it.
This becomes easy for you to plug-in any monitoring system with a minimum need for configuration.
You can access those features over HTTP endpoints, JMX, Datadog, Atlas, Elastic
SpringBoot metrics are managed by micrometer, but if you want to go for the actuator, you don’t have to add micrometer dependency.
If you don’t know what Spring Boot Metrics is, let me enlighten you about it briefly. This is the module that registers a lot of metrics through it’s Auto Configurations.
So, Let’s Begin…
MeterRegistry is a combination of Auto-configures Spring Boot. Including that, It also appends a registry to the composite for each of the supported implementations involved in the classpath.
So to start – you have to add actuator dependence to your project
dependence {
Implementation (“org.springframework.boot:spring-boot-starter-actuator ‘)
And to display metric names in actuator endpoint hit
http;//locallhost:8080/actuator/metrics
{
‘Names’: [
“jvm.threads.states”,
“process.files.max” ,
“jvm,memory .used”,
“jvm.gc.memory.promoted” ,
“jvm.memory.max” ,
“system.load.average.1m” ,
. . . .
]
}
Then to see the details – add a metric name to the URL path,
{
“Name”: “system.cpu.count”,
“Description”: “The number of processors available to the Java virtual machine’,
“baseUnit”: null,
“Measurements “: [
{
“Statistic”: ”VALUE” ,
“Value”: 8
}
] ,
“availableTags”: [
]
}
These metrics can be regularly sent to a metrics systems of your choice by producing specific meter registry.
It is one of the simplest registries ever – LogMeterRegistry.
@Config
Class MetricConfig {
@Bean
Log MeterRegistry logMeterRegistry( ) {
return new LogMeter Registry ( ) ;
}
}
Now the metrics can be seen in the logs:
2019-07-17 11:07:09.406 INFO 91283 _ _ _[trics-publisher] i.m.c.i.log.LogMeterRegistry :jvm.buffer.count { id=direct} value=0 buffers
2019-07-17 11:07:09.406 INFO 91283 _ _ _[trics-publisher] i.m.c.i.log.LogMeterRegistry :jvm.buffer.count { id=mapped} value=0 buffers
2019-07-17 11:07:09.406 INFO 91283 _ _ _[trics-publisher] i.m.c.i.log.LogMeterRegistry :jvm.buffer.memory used { id=direct} value=0 B
2019-07-17 11:07:09.406 INFO 91283 _ _ _[trics-publisher] i.m.c.i.log.LogMeterRegistry :jvm.buffer.memory used { id=MAPPED} value=0 B
2019-07-17 11:07:09.408 INFO 91283 _ _ _[trics-publisher] i.m.c.i.log.LogMeterRegistry :jvm.classes.loaded{} value= 8530 classes
2019-07-17 11:07:09.408 INFO 91283 _ _ _[trics-publisher] i.m.c.i.log.LogMeterRegistry :jvm.gc.live data.size{} value=0 B
2019-07-17 11:07:09.408 INFO 91283 _ _ _[trics-publisher] i.m.c.i.log.LogMeterRegistry:jvm.gc.max data.size{} value=0 B
2019-07-17 11:07:09.408 INFO 91283 _ _ _[trics-publisher] i.m.c.i.log.LogMeterRegistry:jvm.memory.commited{area=nonheap,id=Compressed Class} value= 6.25 MiB
2019-07-17 11:07:09.408 INFO 91283 _ _ _[trics-publisher] i.m.c.i.log.LogMeterRegistry:jvm.memory.commited{area=heap},id=G1 Eden Space} value= 168 MiB
Metrics Supply
If you are curious to know how the metrics are supplied, we could set one example for you. WebMvcMetricsFilter adds performance metrics to all your Spring WebMvc endpoints (Http.server.requests.metric ).
However, if all the requests are handled by the Spring framework, it’s a no brainer to add a call generating metrics within this method.
There are exceptions when you use pure encach or some data source to generate music automatically.
It is noticed that cache.* metrics gets generated even if I @Autowired pure net.sf.Ehcache, Cache.
Do you know hibernate.*metrics are automatically generated even if I @Autowired pure org.hibernate.SessionFactory
This is simply because these statistics are provided by monitored components themselves.
If you want to access the statistics and convert them to specific metrics,
Micrometer is the one that enlightens us on the concept of MeterBinder.
You can check out MeterBinder implementation hierarchy to check what groups of metrics are available.
You can check it directly in tools like micrometer repo.
For example, you could open EhCache2Metrics. After doing so, you will find how and what EhCache statistics are mapped to specific Micrometer metrics .
cache.size -> StatisticsGateway:getSize
cache.gets{result=miss} -> StatisticsGateway:cacheMissCount
cache.gets{result=hit} -> StatisticsGateway:cacheHitCount
cache.puts -> StatisticsGateway:cachePutCount
cache.evictions -> StatisticsGateway:cacheEvictedCount
cache.remoteSize -> StatisticsGateway::getRemoteSize
cache.removals -> StatisticsGateway::cacheRemoveCount
cache.puts.added{result=added} -> StatisticsGateway::cachePutAddedCount
cache.puts.added{result=updated} -> StatisticsGateway::cachePutAddedCount
cache.misses{reason=expired} -> StatisticsGateway::cacheMissExpiredCount)
cache.misses{reason=notFound} -> StatisticsGateway::cacheMissNotFoundCount)
cache.xa.commits{result=readOnly} -> StatisticsGateway::xaCommitReadOnlyCount
cache.xa.commits{result=exception} -> StatisticsGateway::xaCommitExceptionCount
cache.xa.commits{result=committed} -> StatisticsGateway::xaCommitCommittedCount
cache.xa.rollbacks{result=exception} -> StatisticsGateway::xaRollbackExceptionCount
cache.xa.rollbacks{result=success} -> StatisticsGateway::xaRollbackSuccessCount
cache.xa.recoveries{result=nothing} -> StatisticsGateway::xaRecoveryNothingCount
cache.xa.recoveries{result=success} -> StatisticsGateway::xaRecoveryRecoveredCount
cache.local.offheap.size -> StatisticsGateway::getLocalOffHeapSize)
cache.local.heap.size -> StatisticsGateway::getLocalHeapSizeInBytes
cache.local.disk.size -> StatisticsGateway::getLocalDiskSizeInBytes
Registering MeterBinder is comparatively easy.
You can go to micrometer documentation so that you can do it by yourself.
new Class LoaderMetrics( ).bindTo (registry);
new JvmMemoryMetrics( ).bindTo (registry);
new EhCache2Metrics (cache, Tags.of (“name”, cache.getName()).bindTo (registry)
new TomcatMetrics(manager, tags).bindTo(registry)
Or take another option to use SpringBoot which will do your job.
MeterRegistryConfigurer will register Uptime and other systematic metrics.
Endpoints of Actuator
Spring Boot’s module actuator allows you to analyze and manage application usages without coding and configuring. The information from analysis and management is disclosed through REST like, endpoint. Here is a list of Actuator endpoints that could be useful for you.
Endpoint Id Description
| auditevents | Exposes audit events (e.g. auth_success, order_failed) for your application |
| info | Displays information about your application. |
| health | Displays your application’s health status. |
| metrics | Shows various metrics information on your application. |
| loggers | Displays and modifies the configured loggers. |
| logfile | Returns the contents of the log file (if logging.file or logging.path properties are set.) |
| httptrace | Displays HTTP trace info for the last 100 HTTP request/response. |
| env | Displays current environment properties. |
| flyway | Shows details of Flyway database migrations. |
| liquidbase | Shows details of Liquibase database migrations. |
| shutdown | Lets you shut down the application gracefully. |
| mappings | Displays a list of all @RequestMapping paths. |
| scheduledtasks | Displays the scheduled tasks in your application. |
| threaddump | Performs a thread dump. |
| heapdump | Returns a GZip compressed JVM heap dump. |
To Conclude
In the above topic, we have discussed SpringBoot and the origin of default metrics. Thus, I hope I could enlighten you on the same.
However, if you are facing any difficulty to understand the entire matter you could go through it once more and analyze the procedure.
