У меня такой паттерн (если я правильно тебя понял)

2019-12-03T19:42:31.787Z 1bd7a32d-884e-41b8-aa60-df3839394ab4 [INFO][EventService:process] Payload: {bla-bla}

DateTime RequestGUID [TYPE][Class:method] Message: data

morgan + формат почти как у Николая выше, только в случае нескольких серверов/инстансов обязательно добавить  номер этого сервера/инстанса

Мы логи сразу в json отдаём, но в твоём случае с payload такая же проблема. Вы его никак не контроллируете?

Верно. У меня просто это в AWS и у каждого микросервиса свой лог стрим и автоматический маппинг на метрики в инструментах мониторинга. А так да + "номер этого сервера/инстанса"

а какая проблема с json?

Стоило уточнить что я имел ввиду контроль data/context/payload у кого что. А не общего формата лога.

Проблема в том что если один разработчик отправил в лог entity :{ Id :1}, а другой entity: 1, то будет конфликт с понятными последствиями.

В данном случае речь не про json, а в целом про логи с динамической структурой

1) В пределах одного приложения - путем классов JS, либо типов TS + Code Review
2) В распределенной архитектуре, где Code Review осуществляется разными командами, тоже самое, но с shared-lib, где будут общие переиспользуемые models, interfaces (которая задаст контракты и избавит от copy past)

Да это то понятно.
Мне был интересен конкретный опыт)

Куда конкретнее)

Делайте больше индексов. В плане у меня формат индекса примерно такой: logstash-$projectCode-$logname-$module-$level-$date. Собирает эту колбасу fluentd, но подозреваю в logstash можно аналогичное сделать. Да, это отодвигание проблемы конфликтов, но я если честно узнал о проблеме конфликтов типов на своей шкуре только через 4 года работы с EFK 🙈 На предыдущем проекте как то удалось делать нормально и было нормально 😁

Одни товарищи тут организовали dead letter queue через rabbit и насколько я помню всё что не смогло   из-за конфликтов конвертят обратно в строку и пишут plaintext. Ну и можно другие хитрые костыли делать, типа схлопывания вложенных объектов до foo_bar из foo.bar и т.д.

да, сейчас делаем в том числе и это.
Проблема то не сильно насущная, просто задетектить будет не просто.
если  в один индекс запись пойдет, то запись с конфликтным типом просто не пройдёт, а если нарваться на ротацию и успеть записать другой тип, то эластик перестанет его использовать.
Сейчас просто бьем индексы по сервисам, плюс есть общая нотация по логированию.
Часть кейсов можно решить на уровне обработки события логгером, но пока нет желания это использовать.

У нас тут коллеги с другого офиса проектик новый недавно запустили на PHP, так там вообще ж нет разницы между ассоциативными массивами и массивами по структуре языка, поэтому пустой объект в json пишется как пустой массив 😂 Теперь у них половина логов теряется)

Короче у всех боль, страдание, пожёвывание кактусов

интересно как с этим обстоит у Splunk, у них же вроде не ES, а своё хранилище

Так и там и там Lucene под капотом.

всм, они использовали кролика для логов?

filebeat -> logstash -> RabbitMQ -> logstash -> elastic