а логи на запись логов в субд куда рекомендуется класть?

Аналогично. Довольно странно смотрится) Но это модно, походу, все так делают.

Есть тонна инструментов для этого. Лить логи в транзакционное хранилище - огрести геморрой

ну вот я и спрашиваю, если мы все-таки льем в сложную транзакционную систему, по всем бест практикам такие операции надо обвязывать логами

Обычно логи - безмерный поток всего и вся. Никто их не пишет асинхронно. Это значит, если база чуть чихнет, то кашляет вся система. И наоборот. Просто СУБД поставить в неудобную позу (читай - раком) крайне легко

ну да, именно так. Значит надо писать еще одни логи

Посмотрите на Honeycomb.io

а бинарные логи в systemd это не субд?

Что с ними потом делать?

отлаживать логгирование

мониторить проблемы, что там еще с логами делают

Это больше мониторинговая задача

ну да, то есть берем мониторинговую задачу и начинаем ее саму мониторить.

раз уж решили что надо писать в  базу

Я собственно по этому вопросу и завел дискусию. Логирования полно по коду, а зачем не ясно. Тоесть вроде как ясно, но на самом деле логи плохо выполяют свое непосредственное предназначение. Что то адекватно раздебажить по логам удается далеко не всегда

И да, логи могут сильно увеличить требования к ресурсам

ну без них все-таки хуже чем с ними, чем сложнее задача тем полезнее логи

А чем нагруженнее задача тем больше миллиардов их

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

splunk отлично подходит для первого и второго если что