Spring Boot 2 Actuator не публикует метрику jvm - PullRequest
0 голосов
/ 03 сентября 2018

Я запускаю приложение Spring Boot 2 и добавил зависимость запуска пружины загрузчика привода. Я включил все веб-конечные точки и затем позвонил:

http://localhost:8080/actuator/metrics

результат:

{
    "names": ["jdbc.connections.active", 
              "jdbc.connections.max", 
              "jdbc.connections.min", 
              "hikaricp.connections.idle", 
              "hikaricp.connections.pending", 
              "hikaricp.connections", 
              "hikaricp.connections.active", 
              "hikaricp.connections.creation", 
              "hikaricp.connections.max", 
              "hikaricp.connections.min", 
              "hikaricp.connections.usage", 
              "hikaricp.connections.timeout", 
              "hikaricp.connections.acquire"]
}

Но мне не хватает всей статистики JVM и других встроенных показателей. Что мне здесь не хватает? Все, что я прочитал, говорит, что эти показатели должны быть доступны в любое время.

Спасибо за любые подсказки.

Ответы [ 4 ]

0 голосов
/ 02 ноября 2018

В случае, если это когда-нибудь случится с кем-либо еще: У меня была похожая проблема (за исключением того, что это был не Графит, а Прометей, и я не использовал Широ).

По сути, у меня были только метрики Hikari и HTTP, и ничего больше (нет метрик JVM, таких как GC).

Я ударился головой о несколько стен, прежде чем выяснил причину: в Spring Boot Autoconfigure был постпроцессор автоконфигурирования Hikari, который с нетерпением извлекал MeterRegistry, поэтому у всех bean-компонентов Metric раньше не было времени на инициализацию.

И, к моему удивлению, при просмотре этого кода в Github я не нашел его. Поэтому я увеличил свою spring-boot-starter-parent версию с 2.0.4.RELEASE до 2.1.0.RELEASE и теперь все работает нормально. Я правильно получаю все показатели.

0 голосов
/ 07 сентября 2018

Я хочу поделиться с вами результатами. Проблема заключалась в том, что сторонняя библиотека (Shiro) и моя конфигурация для нее. Загрузка бина микрометра была перепутана, что привело к слишком поздней инициализации необходимого PostProcessingBean, который настраивает MicroMeterRegistry (в моем случае PrometheusMeterRegistry).

Я не знаю, целесообразно ли конфигурировать Реестры через другой Бин (PostProcessor), что может привести к ситуациям, которые у меня были ... Реестры должны конфигурировать себя, не полагаясь на другие Бины, которые могут быть сконструированы слишком поздно.

0 голосов
/ 23 октября 2018

Как я и ожидал, эта проблема вызвана порядком загрузки бинов.

Я использовал Широ в проекте.

Метод проверки Широ использовал MyBatis для чтения данных из базы данных.

Я использовал @Autowired для файла Mapper MyBatis, из-за которого SpringBoot не собирал bean-компоненты, связанные с метрикой Actuator (я не знаю, в чем причина).

Итак, я отключил автоматическую сборку файла Mapper при ручной сборке .

Код выглядит следующим образом:

public class SpringContextUtil implements ApplicationContextAware {

    private static ApplicationContext applicationContext;

    public void setApplicationContext(ApplicationContext applicationContext)
            throws BeansException {
        SpringContextUtil.applicationContext = applicationContext;
    }

    public static ApplicationContext getApplicationContext() {
        return applicationContext;
    }

    public static Object getBean(String beanId) throws BeansException {
        return applicationContext.getBean(beanId);
    }
}

Тогда

StoreMapper userMapper = (UserMapper) SpringContextUtil.getBean("userMapper");
UserModel userModel = userMapper.findUserByName(name);

Проблема пока решена. Это всего лишь временная мера, но на данный момент у меня нет лучшего способа.

0 голосов
/ 03 сентября 2018

У меня есть рабочий образец с пружинным загрузчиком, микрометром и графитом , и он подтвердил, что MeterBinder работают "из коробки" следующим образом:

{
  "names" : [ "jvm.memory.max", "process.files.max", "jvm.gc.memory.promoted", "tomcat.cache.hit", "system.load.average.1m", "tomcat.cache.access", "jvm.memory.used", "jvm.gc.max.data.size", "jvm.gc.pause", "jvm.memory.committed", "system.cpu.count", "logback.events", "tomcat.global.sent", "jvm.buffer.memory.used", "tomcat.sessions.created", "jvm.threads.daemon", "system.cpu.usage", "jvm.gc.memory.allocated", "tomcat.global.request.max", "tomcat.global.request", "tomcat.sessions.expired", "jvm.threads.live", "jvm.threads.peak", "tomcat.global.received", "process.uptime", "tomcat.sessions.rejected", "process.cpu.usage", "tomcat.threads.config.max", "jvm.classes.loaded", "jvm.classes.unloaded", "tomcat.global.error", "tomcat.sessions.active.current", "tomcat.sessions.alive.max", "jvm.gc.live.data.size", "tomcat.servlet.request.max", "tomcat.threads.current", "tomcat.servlet.request", "process.files.open", "jvm.buffer.count", "jvm.buffer.total.capacity", "tomcat.sessions.active.max", "tomcat.threads.busy", "my.counter", "process.start.time", "tomcat.servlet.error" ]
}

Обратите внимание, что образец в ветви graphite, а не в ветви master.

Если бы вы могли разбить образец так, как видите, я могу взглянуть еще раз.

...