{"id":13832,"date":"2019-10-21T17:09:45","date_gmt":"2019-10-21T15:09:45","guid":{"rendered":"https:\/\/touk.pl\/blog\/?p=13832"},"modified":"2023-03-20T16:08:50","modified_gmt":"2023-03-20T15:08:50","slug":"deep-dive-into-spring-boot-actuator-http-metrics","status":"publish","type":"post","link":"https:\/\/touk.pl\/blog\/2019\/10\/21\/deep-dive-into-spring-boot-actuator-http-metrics\/","title":{"rendered":"Deep dive into Spring Boot Actuator HTTP metrics"},"content":{"rendered":"

\"\"<\/p>\n

Actuator Metrics<\/h3>\n

As reported in Micha\u0142 Bobowski post<\/a>, we heavily use Spring Boot Actuator metrics system based on Micrometer. It provides a set of practical metrics regarding JVM stats like CPU or memory utilization. Our applications have to meet the most sophisticated needs of our clients thus we try to take advantage of http.server.request<\/code> endpoint.<\/p>\n

Introduction<\/h3>\n

By default, Spring Boot Actuator gathers endpoint statistics for all classes annotated with @RestController<\/code>. It registers a WebMvcMetricsFilter<\/a> bean, which is responsible for timing a request. A special TimingContext<\/code> attribute is attached to the request so that Spring Boot knows when the request started.<\/p>\n

Actuator metrics model<\/h3>\n

When you call http:\/\/localhost:8080\/actuator\/metrics\/http.server.request<\/code> endpoint you will get something similar to this:<\/p>\n

\r\n{\r\n  \"name\": \"http.server.requests\",\r\n  \"description\": null,\r\n  \"baseUnit\": \"milliseconds\",\r\n  \"measurements\": [\r\n    {\r\n      \"statistic\": \"COUNT\",\r\n      \"value\": 12\r\n    },\r\n    {\r\n      \"statistic\": \"TOTAL_TIME\",\r\n      \"value\": 21487.256644\r\n    },\r\n    {\r\n      \"statistic\": \"MAX\",\r\n      \"value\": 2731.787888\r\n    }\r\n  ],\r\n  \"availableTags\": [\r\n    {\r\n      \"tag\": \"exception\",\r\n      \"values\": [\r\n        \"None\",\r\n        \"RuntimeException\"\r\n      ]\r\n    },\r\n    {\r\n      \"tag\": \"method\",\r\n      \"values\": [\r\n        \"GET\"\r\n      ]\r\n    },\r\n    {\r\n      \"tag\": \"uri\",\r\n      \"values\": [\r\n        \"\/example\/success\"\r\n      ]\r\n    },\r\n    {\r\n      \"tag\": \"outcome\",\r\n      \"values\": [\r\n        \"SERVER_ERROR\",\r\n        \"SUCCESS\"\r\n      ]\r\n    },\r\n    {\r\n      \"tag\": \"status\",\r\n      \"values\": [\r\n        \"500\",\r\n        \"200\"\r\n      ]\r\n    }\r\n  ]\r\n}\r\n<\/pre>\n
You will surely see the measurements<\/code> section. It provides types and values of statistics recorded at a certain point in time. Types of statistics are ones described in Statistics<\/a> enum.
\nAnother one is the availableTags<\/code> section, which contains a set of default tags distinguishing each metric by URI, status, or method. You can easily put your tags there like a host or container. If you want to check metric for a particular tag, Actuator lets you do this by using tag query http:\/\/localhost:8080\/actuator\/metrics\/http.server.request?tag=status:200<\/code><\/p>\n
Metric system model<\/h3>\n
However, each monitoring system has its own metrics model and therefore uses different names for the same things. In our case, we use Influx Registry<\/a>.
\nLet’s look into InfluxMeterRegistry<\/a> class implementation.<\/p>\n
private Stream writeTimer(Timer timer) {\r\n    final Stream fields = Stream.of(\r\n        new Field(\"sum\", timer.totalTime(getBaseTimeUnit())),\r\n        new Field(\"count\", timer.count()),\r\n        new Field(\"mean\", timer.mean(getBaseTimeUnit())),\r\n        new Field(\"upper\", timer.max(getBaseTimeUnit()))\r\n    );\r\n\r\n    return Stream.of(influxLineProtocol(timer.getId(), \"histogram\", fields));\r\n}\r\n<\/pre>\n
We see which field in influx corresponds to actuators measurement. Moreover, our registry equips us with an additional mean<\/code> field, which is basically TOTAL_TIME<\/code> divided by COUNT<\/code>. Therefore we don’t need to calculate it manually inside our monitoring system.<\/p>\n
Summary<\/h3>\n
(1) Be aware that the Actuator metric model directly corresponds to Micrometer model
\n(2) When it comes to timing requests carefully choose the step in which metrics are exported
\n(3) Do not mix composing metric values with aggregations, selectors, and transformations, e.g. mean(mean)<\/p>\n","protected":false},"excerpt":{"rendered":"Actuator Metrics As reported in Micha\u0142 Bobowski post, we heavily use Spring Boot Actuator metrics system based on…\n","protected":false},"author":79,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":{"0":"post-13832","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-development-design"},"_links":{"self":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/13832","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/users\/79"}],"replies":[{"embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/comments?post=13832"}],"version-history":[{"count":13,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/13832\/revisions"}],"predecessor-version":[{"id":15447,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/13832\/revisions\/15447"}],"wp:attachment":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/media?parent=13832"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/categories?post=13832"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/tags?post=13832"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}