Comments 9
Дополнение с элементом пиара: если не хочется ставить promtail на машины, можно слать логи из джавы напрямую, используя, например, loki-logback-appender.
Я бы сказал что это антипаттерн - писать логи напрямую в систему сбора логов.
Что будет с логами приложения или вообще с приложением, если в какой-то момент не будет работать loki (будет медленно отвечать, не будет вообще отвечать, будет в этот момент перезапускаться и т.д.)?
Скорее всего или приложение будет тормозить на отправке логов, или вообще упадёт, хотя могло бы работать. Да и отправляемый лог пропадёт. Именно поэтому пишут в stdout, который просто пишется на диск в файл. А другой сервис уже этот логотправляет.
Боюсь, все далеко не так просто и однозначно, как вы описали.
Во-первых, на момент разработки logback-appender'а нормальных внешних тулов для отправки Java-логов в Loki просто не было. Promtail и fluent-bit максимально криво парсили стандартный текстовый формат, особенно плохо было со стек-трейсами и записями, задержищими перевод строки. Давно не смотрел, что там с promtail, но у fluent-bit проблема сохраняется до сих пор.
Во-вторых, зачем вообще что-то сериализовать в строку, чтобы потом парсить с потерей информации, если можно отправить напрямую точно без потерь? Это более прямолинейное решение с инженерной точки зрения.
В-третьих, STDOUT вы все равно пишите через аппендер. Почему то же самое через такой же аппендер нельзя писать в локи? В плане полноты логов там будет абсолютно то же самое. Но при этом вы будете использовать тот же знакомый всем джавистам инструмент, и бесплатно получите все его богатые возможности в преломлении к специфике Loki. Например, можно делать динамические лейблы, используя MDC.
Не скажу за все возможные аппендеры, но конкретно мой при тормозах или недоступности Loki не упадет и не будет тормозить приложение (или точнее сказать будет тормозить даже меньше, чем сторонняя тула для отправки логов, которая в любом случае ест сколько-то дополнительного CPU и RAM на ненужную сериализацию/десериализацию).
Ваш единственный аргумент сводится к тому, что при недоступности Loki логи могут потеряться. Да, могут. И это одинаково справедливо и для отправки из приложения и через стороннюю тулу. Если не хотите терять логи, просто делайте высокодоступную инфраструктуру, Loki как раз предназначен для этого.
Хочу еще раз пояснить свою позицию. Она совсем не в том, что promtail и иже с ним вообще не нужны, что не нужно слушать STDOUT контейнера и т.п. Она в том, что конкретно для Java-приложения, сложнее чем HelloWorld, есть варианты лучше, чем писать логи в STDOUT, чтобы потом их парсить и отправлять в Loki отдельной тулзой.
А что, там на столько не страшно протерять данные, что используется Deployment без волюмов?
Непонятно в чём плюс использования k8s в вашем сценарии. С тем же успехом можно было бы запустить все контейнеры через docker-compose и оно бы работало.
Использовать k8s только ради использования k8s — точно плохая идея.
Зачем helm для единственного компонента?
Зачем графана для просмотра единственных логов, у локи что своего интерфейса нет?
Зачем вообще собирать логи отдельно для единственного приложения, если их можно и в файл кинуть, раз уж есть база с файловой системой
Зачем вообще кубернетес для запуска единственного инстанса с единственной базой
Чем в принципе Spring Boot приложение отличается от любого другого, что статья специально его оговаривает? Не потому ли, что автор нашел maven jkube plugin из которого в принципе и выросла вся статья? Так jkube это не про Spring Boot, а про любое приложение которое собирается в maven…
Спасибо конечно за примеры, но они выглядят очень оторванными от жизни, в результате ни цели ни общего видения зачем это — нет.
Spring Boot приложение в Kubernetes с Postgresql и Loki