Spring Boot в проде: три года боли, которая не влезла в официальную доку

Три года в продакшене с Spring Boot на платформе Lakaut — это вам не hello world в IDEA. За это время мы собрали столько логов, инцидентов и метрик, что хватило бы на отдельную книгу «Как не надо». Но официальная документация, как обычно, рисует райский сад, где все дефолты работают идеально. Спойлер: не работают.

Первое, что выясняется — дефолтные настройки JVM в Railway не подходят для реальной нагрузки. Память течет, GC паникует, а вы сидите и смотрите, как приложение падает с OutOfMemoryError. Пришлось вручную тюнить -Xmx, -Xms и выбирать сборщик мусора. G1GC нас спас, но не сразу — сначала мы перепробовали все, включая Serial GC, который, кажется, создан для пыточных.

Второе — логи. Официальная документация советует логировать всё подряд, но в проде с ограниченным хранилищем это путь к банкротству. Мы настроили уровни логирования так, чтобы в dev было подробно, а в prod — только критическое. И да, добавили ротацию логов, иначе через неделю диск забивается под завязку.

Третье — метрики. Micrometer и Prometheus — это круто, но без кастомных алертов они бесполезны. Мы потратили недели, чтобы понять, какие метрики реально важны: latency p99, количество активных соединений с БД, частота GC пауз. Без этого вы летите в пропасть с закрытыми глазами.

Комментарий студии METABYTE: Мы тоже через это прошли, поэтому в наших проектах всегда закладываем время на тюнинг инфраструктуры. И да, мы тоже однажды забыли выключить debug-логи в проде — бывает, но лучше не надо.