|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
Lelouchdakeiras, вот только поток каждый раз ждет, пока файл будет записан. Асинхронные аппендеры это про другое - возможность накапливать много событий в очередь и выводить их в файл 1 куском. Я понимаю про Буферизующие\асинхронные аппендеры (с отдельным тредом). Всё это было и было выпилено за вредностью\ненадобностью. Но я не понимаю почему Вы говорите что в Бобине потоки будут ждать, пока будет записан другой файл. Методы Бобины (store, etc) НЕ синхронные, соотвественно копируются на вызов из каждого потока АСИНХРОННО. авторвот только поток каждый раз ждет, пока файл будет записан. авторЭто асинхронным его не делает. Кроме этого ОЧЕНЬ усложняет анализ логов. Наоборот, упрощает, потоки надо группировать (threadGroupName) и логи раскидывать по папкам красиво. У меня 200 логов я кайфую как всё под контролем. авторНе могли бы вы показать, где к имени файла примешивается идентификатор потока? Это хороший вопрос. Вот тут: https://github.com/INFINITE-TECHNOLOGY/BOBBIN/blob/master/src/main/groovy/io/infinite/bobbin/BobbinScriptEngine.groovy Код: java 1. 2. 3. 4. 5. 6. 7.
Это даёт использовать неявные field reference (добавленные Groovy при компиляции на основании getter'ов выше) в имени файла: Код: java 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:34 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
Lelouchdakeiras, Если я правильно понял, то на уровне конфигурации: "fileName": "\"./LOGS/${threadName}/${level}/${threadName}_${level}_${date}.log\"", при этом если пользователь НЕ укажет threadName при настроке навзания или пути файла - то видимо он ССЗБ :) прэлэстно Да, возникнет обычный io congestion, как в других логгерах. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:37 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
vas0dakeirasпропущено... на каждый поток отдельный файл и отдельный FileWriter - полностью асинхронная запись, без потерь на synchronized.Код не смотрел, поэтому мой вопрос может показаться ламерский. Потери на synchronized это же не просто потери, synchronized дает гарантию visibility. Что корректное значение записаное в одним потоке, будет прочитано в другом. Как это достигается здесь, через использование immutable+final объектов или как? Тут потоки никак не взаимодействуют. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:38 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
Хочу ещё раз подчеркнуть - в Бобине НЕТ io waits/congestion (если отдельные файлы на каждый поток настроены). Там нет ни одного синхронного метода, за исключением нативных методов ОС при записи по конкретному дескриптору. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:40 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
dakeiras, dakeiras потоки будут ждать, пока будет записан другой файл. Потоки будут ждать, пока будет записан ИХ файл. И да, это долго в ряде случаев. dakeirasНаоборот, упрощает, потоки надо группировать (threadGroupName) и логи раскидывать по папкам красиво. У меня 200 логов я кайфую как всё под контролем. А теперь представим что одно событие обрабатывается в нескольких потоках: 1) контроллер добавляет сообщение в очередь 2) Поток слушающий очередь, достает его, нарезает на независимые операции и запускает через Executor#invokeAll. После этого отправляет сообщение через условную atmosphere. 3) atmosphere через свой пул рассылает web socket клиентам. Как в ваших "удобных" логах собрать весь путь сообщения? видимо только через что-то внешнее ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:41 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
авторПотоки будут ждать, пока будет записан ИХ файл. И да, это долго в ряде случаев. Идею понял. Это тестировалось, асинхронные аппендеры - менее эффективны. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:44 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
Ну если данные генерируются в каких то потоках, а в каких то других потоках идет запись в файлы. Чем тут поможет ThreadLocal? Только если работа уже идет на уровне immutable string объектах, для объектов другого типа без синхронизации можешь получить некорректные значение. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:44 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
dakeiras, dakeirasДа, возникнет обычный io congestion, как в других логгерах. См logstash > fileAppender > prudent. И да, в других логгерах это возникнет, если пользователь явно настроит 2 разных аппендера на 1 файл. В вашем - если не укажет настроку, которая ни разу не обязательна с его точки зрения. dakeirasнет io waits С чего это вдруг их нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:45 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
авторА теперь представим что одно событие обрабатывается в нескольких потоках: 1) контроллер добавляет сообщение в очередь 2) Поток слушающий очередь, достает его, нарезает на независимые операции и запускает через Executor#invokeAll. После этого отправляет сообщение через условную atmosphere. 3) atmosphere через свой пул рассылает web socket клиентам. Как в ваших "удобных" логах собрать весь путь сообщения? видимо только через что-то внешнее Через MDC. Имя файла поддерживает MDC, будет кросс-поточный лог файл для конкретного id. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:45 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
Точно также это делается для "username", request id, и прочего. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:46 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
vas0Ну если данные генерируются в каких то потоках, а в каких то других потоках идет запись в файлы. Чем тут поможет ThreadLocal? Только если работа уже идет на уровне immutable string объектах, для объектов другого типа без синхронизации можешь получить некорректные значение. Данные генерируются и записываются в рамках 1 потока. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:47 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
dakeiras, dakeirasЭто тестировалось, асинхронные аппендеры - менее эффективны. Они более эффективны даже с точки зрения скорости записи этого самого файла, потому что могут писать его 1 куском. Посмотрите хотя тесты последовательного чтения/записи (например по 1мб) и рандомного (по 4к во всяких crystal disk) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:47 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
dakeirasЧерез MDC. Имя файла поддерживает MDC, будет кросс-поточный лог файл для конкретного id. То есть чтобы не страдать от вашего логгера, пользователь обязан использовать MDC? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:48 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
Кстати Бобина даёт невиданный функционал по кросс-поточному и кросс-классовому отслеживанию действий юзера - очень легко настроить чтобы на каждого юзера (или отдельного юзера) были свои лог файлы, через MDC. Теперь видите какой это царский функционал? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:49 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
LelouchdakeirasЧерез MDC. Имя файла поддерживает MDC, будет кросс-поточный лог файл для конкретного id. То есть чтобы не страдать от вашего логгера, пользователь обязан использовать MDC? В других логгерах это без MDC не сделать. Только там будет общий файл-каша. А тут отдельные файлы. Единственная альтернатива - переименовывать потоки, что не рекомендуется. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:51 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
авторСм logstash > fileAppender > prudent. И да, в других логгерах это возникнет, если пользователь явно настроит 2 разных аппендера на 1 файл. В вашем - если не укажет настроку, которая ни разу не обязательна с его точки зрения. Посмотрю, спасибо. авторОни более эффективны даже с точки зрения скорости записи этого самого файла, потому что могут писать его 1 куском. Посмотрите хотя тесты последовательного чтения/записи (например по 1мб) и рандомного (по 4к во всяких crystal disk) Это тоже посмотрю. Благодарю. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:53 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
dakeirasКстати Бобина даёт невиданный функционал по кросс-поточному и кросс-классовому отслеживанию действий юзера - очень легко настроить чтобы на каждого юзера (или отдельного юзера) были свои лог файлы, через MDC. Теперь видите какой это царский функционал? Нет не вижу. Что по остальным пунктам? Например IOException при ошибке записи файла. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:54 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
dakeirasvas0Ну если данные генерируются в каких то потоках, а в каких то других потоках идет запись в файлы. Чем тут поможет ThreadLocal? Только если работа уже идет на уровне immutable string объектах, для объектов другого типа без синхронизации можешь получить некорректные значение. Данные генерируются и записываются в рамках 1 потока. А как же асинхронные апендеры? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:57 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
vas0dakeirasпропущено... Данные генерируются и записываются в рамках 1 потока. А как же асинхронные апендеры? Их нет. Тут ничего нет кроме консоли и файла. Кстати, dakeiras, вы в курсе, что System.out.println синхронный? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 19:59 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
Lelouchvas0пропущено... А как же асинхронные апендеры? Их нет. Тут ничего нет кроме консоли и файла. Кстати, dakeiras, вы в курсе, что System.out.println синхронный? Даже уточню - выполняет синхронизацию на this. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 20:01 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
[quot dakeiras]В других логгерах это без MDC не сделать. Только там будет общий файл-каша. Решается условным graylog. И это удобнее чем "куча файлов" ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 20:02 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
dakeiras, ну и на последок хочу заметить, что ваш логгер в том числе не защищен от случая, когда 2 потока имеют одинаковое название. https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setName(java.lang.String) Every thread has a name for identification purposes. More than one thread may have the same name. If a name is not specified when a thread is created, a new name is generated for it. Нигде в документации не заостряется, что имя файла явно должно содержать threadName в настройках шаблона имени файла и не указано требование уникальности имени потока (или уникальности пары threadGroupName и threadName). В том числе, если какая-либо сторонняя библиотека по ошибке, или специально, создает потоки с одинаковыми названиями - это делает стабильную работу вашего логгера не возможной. Как когда-то выразился мой преподавать на 1 курсе: Ваша программа представляет из себя хрупкую игрушку, работающую только в руках создателя. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 20:29 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
dakeirasКстати Бобина даёт невиданный функционал по кросс-поточному и кросс-классовому отслеживанию действий юзера - очень легко настроить чтобы на каждого юзера (или отдельного юзера) были свои лог файлы, через MDC. Теперь видите какой это царский функционал? Обычно (в 99%) случаев настройкой системы логгирования заняты дев-опсы. И они себе ставят вполне себе конкретные задачи. Как-то - безопасность и аудит - перформанс - анализ ошибок Для всех этих задач этот царский функционал не нужен. Ну или я не знаю такого юзкейса. Логгировать отдельно поток нет никакого смысла. Поток - это ресурс который берут из "обоймы" доступных ресурсов и роль потока в крупном приложении может серъезно менятся в считанные секунды. Вести одновременно 200 логов с точки зрения файловой системы накладно т.к. нужно иметь 200 файловых дескрипторов и соотв 200 объектов представляющих файл (буферов). Накладные расходы можно считать а можно и нет. Но поинт опять-же в том что это может быть накладно (так-же как и держать 65000 открытых сокетов на веб-сервере) и иногда количество переходит в качество. Для старых магнитных накопителей время seektime безсмысленно тратится на беготню по поверхности диска и вы получаете жалкие 25 мегабайт в секунду потому-что вместо throughput получили IOPS, и чтобы получить паспортные пропускные способности диска - вам лучше вернуться к классической схеме где есть 1 или 2 лога на всё приложение. Если-же вы слишком долго буферизируете лог без флаша то рискуете получить недописанные хвостики логов в случае краша приложения. Зачем нужны логи без хвостиков - я не знаю. Это epic fail и такие логи не будут отражать важные действия которые возможно повлекли за собой падение. Провертье мою гипотезу. Нажмите reset под нагрузкой и проследите что самые последние бизнес аудиты были сохранены. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 22:21 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
авторОбычно (в 99%) случаев настройкой системы логгирования заняты дев-опсы. И они себе ставят вполне себе конкретные задачи. Как-то - безопасность и аудит - перформанс - анализ ошибок Для всех этих задач этот царский функционал не нужен. Ну или я не знаю такого юзкейса. Логгировать отдельно поток нет никакого смысла. Поток - это ресурс который берут из "обоймы" доступных ресурсов и роль потока в крупном приложении может серъезно менятся в считанные секунды. Я завтра с работы подробно отвечу на комментарии. Касательно ELK - там невозможно вручную логи смотреть, поэтому отдельные файлы на каждый лог - дают выигрыш в производительности - за счёт отсутствия io congestion. Если нет ELK, в случаях с пакетными приложениями, ETL, индустриальными приложениями с фиксированными потоками - там возможность отдельных лог файлов это супер фича. Когда требуется вручную разбирать лог файлы. И в процессе отладки приложения. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 22:44 |
|
Новый альтернативный Slf4j логгер Бобина
|
|||
---|---|---|---|
#18+
Lelouchdakeiras, ну и на последок хочу заметить, что ваш логгер в том числе не защищен от случая, когда 2 потока имеют одинаковое название. https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setName(java.lang.String) Every thread has a name for identification purposes. More than one thread may have the same name. If a name is not specified when a thread is created, a new name is generated for it. Нигде в документации не заостряется, что имя файла явно должно содержать threadName в настройках шаблона имени файла и не указано требование уникальности имени потока (или уникальности пары threadGroupName и threadName). В том числе, если какая-либо сторонняя библиотека по ошибке, или специально, создает потоки с одинаковыми названиями - это делает стабильную работу вашего логгера не возможной. Как когда-то выразился мой преподавать на 1 курсе: Ваша программа представляет из себя хрупкую игрушку, работающую только в руках создателя. Никто не говорит, что обязательно разделять. Просто с точки зрения здравого смысла, если у вас есть 500 потоков - писать лог в единый файл - это бред, наркомания укоренившаяся с годами. Т.к. очевидно что это вызывает очередь на запись в этот файл. Хрупкая или нет - есть артифакты публично доступные через Magen/Gradle. Качаем, ломаем - я плачу бабло. У меня принцип - ОТВЕЧАТЬ за свой опен сорс софт. PS: если не нравится threadName, ну напишите threadName+Thread.currentThread().getId() ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2019, 22:59 |
|
|
start [/forum/topic.php?fid=59&msg=39846071&tid=2120876]: |
0ms |
get settings: |
3ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
138ms |
get topic data: |
2ms |
get forum data: |
0ms |
get page messages: |
403ms |
get tp. blocked users: |
1ms |
others: | 310ms |
total: | 864ms |
0 / 0 |