пока в периметре - можно

Но от стека зависит, конечно.

но там зависит.. я ранние редакции закона о ПД помню, можно внезапно оказаться не в том классе, конечно..

Эээ, только нужно шифровать диски с Кафкой.
Ну и там есть тонкости.

диски шифровать в 2021 вроде не проблема уже 🙂

но я согласен, что лучше бы прям на хосте с приложением отрубать

И, главное, легче на уровне логстеша или вектора.
Ну или адаптер указать в logback

но кому-то придется написать стопицот правил и поддерживать их

Там три-пять простых правил обычно хватает.

Поддержка - через стандартные сценарии развертывания.

моя практика показывает, что через полгода там станет все печально

но зато всегда можно будет найти виноватых

Ну, по опыту, раз в два года надо смотреть на список правил и опять сводить к трем-пяти
Там как раз до 20-30 доходит.

не в этом проблема.. а в "разработчики внезапно поменяли формат логов и включили дебаг"

Вот потому правила и надежнее. Они же не на имя поля ориентируются, а на контент.
Ну и тесты нужно делать на логи

тесты на полноту логов полностью поддерживаю, даже практикуем
но на наличие чувствительных данных — не думал

unix-сокет блокирующий. Что с nginx сочетаться будет не очень хорошо. Лучше сделать udp на lo, и мониторить проливы логов на сокете. А также убрать блокировки в пайплайне rsyslog, чтобы, если что, логи терялись не на сокете, а в самом рсислоге, что удобнее наблюдается в метриках.
Насчет балансировки: зависит от способов балансировки, которые доступны в вашей инфре.
У меня в тестах на 80keps логи на сокете не терялись после отключения блокировок в пайплайне (утилизация CPU была в районе 1-2 ядер, можно масштабировать вширь потоками). Но, если очередь кончится, то логи, конечно, рсислог будет дропать. Что приоритетнее: обслужить нагрузку или записать логи, решайте сами.

Зависит от поведения приложения. Вообще, unix-сокет блокирующий.

Они оба блокирующие, насколько я помню. И у syslog-а стандартным является stream unix-сокет.