Лекция 114: Метрики производительности и мониторинг памяти

Метрики — это те самые показатели, по которым оценивается состояние вашего приложения, его производительность и здоровье. Если проводить аналогии, то метрики — это как показатели здоровья у человека: температура, давление, пульс. Например, если ваш сервер вдруг начинает "задыхаться", Actuator может подсказать, в чём проблема: слишком много запросов, нехватка памяти или, возможно, ваш сервер просто решил устроить себе отпуск.

Метрики Actuator

Spring Boot Actuator из коробки предоставляет множество метрик. Вот несколько самых интересных:

Неплохо, да? Причём это только базовый набор. Если вы хотите больше, так сказать, специй в суп, вы можете добавлять и свои метрики (о кастомных метриках мы поговорим чуть позже в курсе).

Метрики доступны на эндпоинте /actuator/metrics. Чтобы изучить все метрики, достаточно зайти на этот эндпоинт через браузер или Postman, и вы получите полный список доступных показателей.

Например:

{
  "names": [
    "jvm.memory.used",
    "http.server.requests",
    "logback.events",
    "jvm.threads.live",
    "system.cpu.usage"
  ]
}

Если вы хотите получить конкретные данные по определённой метрике (например, использование памяти JVM), используйте эндпоинт /actuator/metrics/{имя_метрики}.

Пример:

curl http://localhost:8080/actuator/metrics/jvm.memory.used

Результат может выглядеть так:

{
  "name": "jvm.memory.used",
  "measurements": [
    {
      "statistic": "VALUE",
      "value": 12345678
    }
  ],
  "availableTags": [
    {
      "tag": "area",
      "values": ["heap", "nonheap"]
    }
  ]
}

Здесь value — это текущий объём используемой памяти, а теги вроде area указывают, относится ли память к heap или non-heap (не пытайтесь запомнить все термины сейчас, позже мы всё разберём).

Мониторинг производительности: HTTP-запросы как лакмусовая бумажка

Одной из ключевых метрик для мониторинга производительности является http.server.requests. Она отслеживает все HTTP-запросы, поступающие в ваше приложение. Эти данные могут стать золотым рудником для понимания поведения пользователей и выявления проблем.

Вот какую информацию можно получить из http.server.requests?

• Количество запросов. Сколько запросов ваше приложение обработало за заданное время?
• Среднее время отклика. Как быстро ваше приложение отвечает на запросы?
• Ошибки. Сколько запросов вернули статус 4xx или 5xx?

Используем всё тот же эндпоинт /actuator/metrics/http.server.requests для подробностей. Вот пример ответа:

{
  "name": "http.server.requests",
  "measurements": [
    {
      "statistic": "COUNT",
      "value": 438
    },
    {
      "statistic": "TOTAL_TIME",
      "value": 125.8
    },
    {
      "statistic": "MAX",
      "value": 2.5
    }
  ],
  "availableTags": [
    {
      "tag": "status",
      "values": ["200", "404", "500"]
    },
    {
      "tag": "uri",
      "values": ["/api/users", "/api/orders"]
    }
  ]
}

Как прочитать этот ответ?

• COUNT — общее количество запросов (в данном случае 438 запросов).
• TOTAL_TIME — общее время, затраченное на обработку всех запросов (125,8 секунд).
• MAX — максимальное время, затраченное на обработку одного запроса (2,5 секунды).

Tags (теги) позволяют фильтровать запросы, например, по статусу ответа (200, 404) или по URI (/api/users, /api/orders). Это очень удобно для детальной аналитики.

Практическая ситуация

Если вы видите, что время отклика для какого-то конкретного URI слишком велико, это может быть связано с долгим запросом к базе данных или нагрузкой на CPU. Вы можете начать копать глубже, чтобы устранить проблему.

Память: мониторим JVM, чтобы она не закипела

Java Virtual Machine (JVM) — это как двигатель вашего приложения. Если с ним что-то не так, всё сломается. Actuator предоставляет полезные метрики для мониторинга памяти:

• jvm.memory.used — текущее использование памяти.
• jvm.memory.max — максимальное количество доступной памяти.
• jvm.gc.pause — время пауз сборщика мусора.

Разбираемся с heap и non-heap

Память JVM делится на два основных типа:

• Heap memory (куча) — используется для хранения объектов, созданных через new.
• Non-heap memory — используется для хранения метаданных классов, статических переменных и других вещей.

Пример анализа метрики jvm.memory.used:

{
  "name": "jvm.memory.used",
  "measurements": [
    {
      "statistic": "VALUE",
      "value": 98765432
    }
  ],
  "availableTags": [
    {
      "tag": "area",
      "values": ["heap", "nonheap"]
    }
  ]
}

Если heap memory заполнена на 90% (или больше), это может быть признаком утечек памяти или необходимости увеличения параметра -Xmx для JVM.

Практические кейсы: когда метрики спасают день

Кейc 1: Высокая загруженность CPU

Метрика system.cpu.usage показывает общую загруженность CPU. Если она постоянно превышает 80%, это явный сигнал о перегрузке сервера. Причиной может быть недостаточная оптимизация кода или слишком высокая нагрузка.

Кейc 2: Частые сборки мусора (GC)

Метрика jvm.gc.pause отслеживает паузы сборщика мусора. Если паузы происходят слишком часто или длительное время (десятки миллисекунд), это может замедлять всю систему. Проверьте, не выделяете ли вы слишком много объектов в короткий период времени.

Практическое задание

1. Интеграция Actuator в проект. Если вы ещё не сделали этого, добавьте зависимость spring-boot-starter-actuator в ваш pom.xml или build.gradle.
2. Настройка метрик. Изучите эндпоинты /actuator/metrics и /actuator/metrics/{имя_метрики}. Попробуйте получить данные о метриках http.server.requests и jvm.memory.used.
3. Анализ данных. На основе полученных данных попробуйте сделать выводы о состоянии вашего приложения. Например, сколько времени требуется для обработки HTTP-запросов? Каково текущее использование памяти JVM?

// Проверяем текущую загруженность CPU через Actuator
RestTemplate restTemplate = new RestTemplate();
ResponseEntity<Map> response = restTemplate.getForEntity("http://localhost:8080/actuator/metrics/system.cpu.usage", Map.class);
System.out.println("Загруженность CPU: " + response.getBody());

Анализируйте, делайте выводы, оптимизируйте — и ваш сервер скажет спасибо!