Лекція 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.

Практичні кейси: коли метрики рятують день

Кейс 1: Висока завантаженість CPU

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

Кейс 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());

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