Spring -boot metrics vs spring -cloud metrics

Я играл с метриками в spring -boot и немного запутывался, как выглядит spring -cloud, чтобы изменить поведение.

Простое минимальное приложение spring -boot 1.3.3.RELEASE с приводом и с одним контроллером:

@RestController
public class HelloController {

    @Autowired
    private CounterService counterService;

    @RequestMapping("/hello")
    public String sayHello(@RequestParam("name") String name) {
        counterService.increment("counter.calls.hello");
        return "Hello, " + name;
    }
}

конечная точка метрики для этого приложения имеет

...
gauge.response.hello: 5,
gauge.response.metrics: 69,
gauge.response.star-star.favicon.ico: 2,
counter.status.200.star-star.favicon.ico: 4,
counter.status.200.metrics: 1,
counter.calls.hello: 5,
counter.status.200.hello: 5

который описан в spring -boot docs. Мой пользовательский счетчик (counter.calls.hello) функционирует как счетчик, как ожидалось.

Теперь, если я добавлю spring -cloud-starter-eureka (Brixton.RC1) в мой pom и ничего не изменю, конечная точка метрики имеет

...
gauge.servo.counter.calls.hello: 1,
normalized.servo.rest.totaltime: 0,
normalized.servo.rest.count: 0,
gauge.servo.rest.min: 0,
gauge.servo.rest.max: 0,
gauge.servo.response.hello: 7,
gauge.servo.response.star-star.favicon.ico: 2,

нормальные метрики MVC исчезли. Где информация кода ответа? Мой пользовательский счетчик сообщается как gauge.servo.counter.calls.hello, но он больше не работает как счетчик, он, кажется, просто показывает значение 1, даже если я сделал 5 вызовов HelloController. Небольшая отладка и поиск привели меня к изменению метрического имени счетчика на meter.calls.hello, что приводит к counter.servo.calls.hello в ответе метрик и восстанавливает функции счетчика.

Дальнейшее чтение указывает, что spring -cloud использует сервопривод по умолчанию для показателей и указывает, что если я использую java 8, я должен использовать зрителя. Добавив spring -cloud-starter-spectator к моему pom и возвращаясь к "counter.calls.hello" в качестве имени счетчика, конечная точка метрики имеет

...
counter.calls.hello(): 3,
response.hello(): 7,
response.metrics(): 9,
response.star-star.favicon.ico(): 2,

у этого есть еще менее встроенная информация о конечной точке останова, но мой пользовательский счетчик, похоже, функционирует.

Spring -cloud docs о показателях, похоже, указывают, что я должен использовать ServoRegistry, используя серво или зритель. Терминология в разделе метрик зрителя отличается. Счетчик работает не так, как я ожидал. Когда я публикую простой счетчик посещений, используя ServoRegistry, как описано в документах, я возвращаю некоторую скорость в конечной точке метрики.

Есть ли добавленное значение в серво и/или зрителе над тем, что обеспечивается spring -boot? spring -cloud docs указывают на то, что в стандартную контрольную метрику записывается больше информации, но они не отображаются в/метриках. Должен ли я просто исключить ServoMetricsAutoConfiguration и использовать реализацию spring -boot?

Ответы

Ответ 1

В соответствии с Spring Документация Cloud Brixton преимущество показателей Servo/Spectator заключается в том, что они помечены (aka dimension), а регулярные Spring Показатели загрузки являются иерархическими.

Spring Загрузка

"counter.status.200.root": 20
"counter.status.400.root": 3

Netflix

"root(method=GET,status=200,statistic=count)": 20
"root(method=GET,status=400,statistic=count)": 3

Размерные показатели позволяют больше гибкости запросов и по умолчанию запросы MVC помечены с помощью HTTP-метода, статуса HTTP, URI и исключения (если обработчик запроса сделал исключение).

К сожалению, размерные показатели Netflix, похоже, не хорошо переводится, когда они отображаются в конечной точке исполнительного механизма /metrics, поэтому, если все, что вам нужно, это счетчики запросов по умолчанию, которые Spring Boot предоставляет в конечной точке метрики, вы будете лучше отключить конфигурацию сервопривода:

spring.metrics.servo.enabled=false