Это ожидаемое поведение. Docker разделяет сообщения журнала размером 16 КБ из-за буфера размером 16 КБ для сообщений журнала. Если длина сообщения превышает 16 КБ, оно должно быть разделено регистратором файлов json и объединено в конечной точке.
Он отмечает журнал как частичное сообщение, но действительно зависит от драйвера / службы для повторной сборки.
Docker Docs упоминает, что существуют различные поддерживаемые драйверы.
С вашей архитектурой (Stacktraces) json-driver может быть не лучшим вариантом.
И я нашел эту ветку на github, которая добавляет дополнительную информацию по теме (а также как много оффтопа).
Редактировать.
Архитектура ведения журнала говорит, что все, что контейнерное приложение записывает в stdout и stderr, обрабатывается и перенаправляется куда-то контейнерным движком.
Движок контейнера Docker перенаправляет эти два потока драйверу ведения журнала, который настроен в Kubernetes для записи в файл в формате json.
Примечание. Драйвер ведения журнала Docker json обрабатывает каждую строку как отдельное сообщение. Еще одна особенность заключается в том, что при использовании драйвера ведения журнала Docker нет прямой поддержки многострочных сообщений. Вам необходимо обрабатывать многострочные сообщения на уровне агента ведения журнала или выше.
Я действительно не понимаю, что я могу с этим сделать?
Это ограничение на размер Docker. Вот еще одно хорошее обсуждение, которое заканчивается идеей использования filebeat / fluentd.
Похоже, что вариант Docker_mode для Fluentbit может помочь, но Я не уверен, как именно вы разбираете журналы контейнеров.
Должен ли я сократить свой stackTrace?
Это зависит от того, нужны ли вам следы в журналах или нет.
Или подгонять размер? Я искал какую-то «ручку» для настройки на стороне Docker и на данный момент не могу найти ни одной.
Похоже, что единственное решение для этого - использовать какой-нибудь инструмент обработки журналов, который может комбинировать линии разделения.
person
Nick
schedule
23.04.2020
