Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 11   вперед  Ctrl      все
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
Lelouch
dakeiras,

вот только поток каждый раз ждет, пока файл будет записан. Асинхронные аппендеры это про другое - возможность накапливать много событий в очередь и выводить их в файл 1 куском.


Я понимаю про Буферизующие\асинхронные аппендеры (с отдельным тредом). Всё это было и было выпилено за вредностью\ненадобностью.

Но я не понимаю почему Вы говорите что в Бобине потоки будут ждать, пока будет записан другой файл.
Методы Бобины (store, etc) НЕ синхронные, соотвественно копируются на вызов из каждого потока АСИНХРОННО.

автор
вот только поток каждый раз ждет, пока файл будет записан.



автор
Это асинхронным его не делает. Кроме этого ОЧЕНЬ усложняет анализ логов.

Наоборот, упрощает, потоки надо группировать (threadGroupName) и логи раскидывать по папкам красиво.
У меня 200 логов я кайфую как всё под контролем.

автор
Не могли бы вы показать, где к имени файла примешивается идентификатор потока?

Это хороший вопрос.
Вот тут:
https://github.com/INFINITE-TECHNOLOGY/BOBBIN/blob/master/src/main/groovy/io/infinite/bobbin/BobbinScriptEngine.groovy

    String getThreadName() {
        return Thread.currentThread().getName()
    }

    String getThreadGroupName() {
        return Thread.currentThread().getThreadGroup().getName()
    }


Это даёт использовать неявные field reference (добавленные Groovy при компиляции на основании getter'ов выше) в имени файла:

"fileName": "\"./LOGS/THREADS/${threadGroupName}/${threadName}/${level}/${threadName}_${level}_${date}.log\""
6 авг 19, 19:34    [21943260]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
Lelouch
dakeiras,

Если я правильно понял, то на уровне конфигурации:
"fileName": "\"./LOGS/${threadName}/${level}/${threadName}_${level}_${date}.log\"",

при этом если пользователь НЕ укажет threadName при настроке навзания или пути файла - то видимо он ССЗБ :) прэлэстно


Да, возникнет обычный io congestion, как в других логгерах.
6 авг 19, 19:37    [21943261]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
vas0
dakeiras
пропущено...


на каждый поток отдельный файл и отдельный FileWriter - полностью асинхронная запись, без потерь на synchronized.
Код не смотрел, поэтому мой вопрос может показаться ламерский. Потери на synchronized это же не просто потери, synchronized дает гарантию visibility. Что корректное значение записаное в одним потоке, будет прочитано в другом. Как это достигается здесь, через использование immutable+final объектов или как?


Тут потоки никак не взаимодействуют.
6 авг 19, 19:38    [21943263]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
Хочу ещё раз подчеркнуть - в Бобине НЕТ io waits/congestion (если отдельные файлы на каждый поток настроены).

Там нет ни одного синхронного метода, за исключением нативных методов ОС при записи по конкретному дескриптору.
6 авг 19, 19:40    [21943264]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1768
dakeiras,
dakeiras
потоки будут ждать, пока будет записан другой файл.

Потоки будут ждать, пока будет записан ИХ файл. И да, это долго в ряде случаев.

dakeiras
Наоборот, упрощает, потоки надо группировать (threadGroupName) и логи раскидывать по папкам красиво.
У меня 200 логов я кайфую как всё под контролем.


А теперь представим что одно событие обрабатывается в нескольких потоках:
1) контроллер добавляет сообщение в очередь
2) Поток слушающий очередь, достает его, нарезает на независимые операции и запускает через Executor#invokeAll. После этого отправляет сообщение через условную atmosphere.
3) atmosphere через свой пул рассылает web socket клиентам.
Как в ваших "удобных" логах собрать весь путь сообщения? видимо только через что-то внешнее
6 авг 19, 19:41    [21943267]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
автор
Потоки будут ждать, пока будет записан ИХ файл. И да, это долго в ряде случаев.

Идею понял.

Это тестировалось, асинхронные аппендеры - менее эффективны.
6 авг 19, 19:44    [21943271]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
vas0
Member

Откуда: Таможенный союз (Россия, Казахстан)
Сообщений: 1228
Ну если данные генерируются в каких то потоках, а в каких то других потоках идет запись в файлы. Чем тут поможет ThreadLocal?
Только если работа уже идет на уровне immutable string объектах, для объектов другого типа без синхронизации можешь получить некорректные значение.
6 авг 19, 19:44    [21943272]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1768
dakeiras,

dakeiras
Да, возникнет обычный io congestion, как в других логгерах.

См logstash > fileAppender > prudent.
И да, в других логгерах это возникнет, если пользователь явно настроит 2 разных аппендера на 1 файл. В вашем - если не укажет настроку, которая ни разу не обязательна с его точки зрения.

dakeiras
нет io waits

С чего это вдруг их нет?
6 авг 19, 19:45    [21943273]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
автор
А теперь представим что одно событие обрабатывается в нескольких потоках:
1) контроллер добавляет сообщение в очередь
2) Поток слушающий очередь, достает его, нарезает на независимые операции и запускает через Executor#invokeAll. После этого отправляет сообщение через условную atmosphere.
3) atmosphere через свой пул рассылает web socket клиентам.
Как в ваших "удобных" логах собрать весь путь сообщения? видимо только через что-то внешнее


Через MDC. Имя файла поддерживает MDC, будет кросс-поточный лог файл для конкретного id.
6 авг 19, 19:45    [21943274]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
Точно также это делается для "username", request id, и прочего.
6 авг 19, 19:46    [21943276]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
vas0
Ну если данные генерируются в каких то потоках, а в каких то других потоках идет запись в файлы. Чем тут поможет ThreadLocal?
Только если работа уже идет на уровне immutable string объектах, для объектов другого типа без синхронизации можешь получить некорректные значение.


Данные генерируются и записываются в рамках 1 потока.
6 авг 19, 19:47    [21943277]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1768
dakeiras,


dakeiras
Это тестировалось, асинхронные аппендеры - менее эффективны.


Они более эффективны даже с точки зрения скорости записи этого самого файла, потому что могут писать его 1 куском. Посмотрите хотя тесты последовательного чтения/записи (например по 1мб) и рандомного (по 4к во всяких crystal disk)
6 авг 19, 19:47    [21943278]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1768
dakeiras
Через MDC. Имя файла поддерживает MDC, будет кросс-поточный лог файл для конкретного id.


То есть чтобы не страдать от вашего логгера, пользователь обязан использовать MDC?
6 авг 19, 19:48    [21943279]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
Кстати Бобина даёт невиданный функционал по кросс-поточному и кросс-классовому отслеживанию действий юзера - очень легко настроить чтобы на каждого юзера (или отдельного юзера) были свои лог файлы, через MDC.

Теперь видите какой это царский функционал?
6 авг 19, 19:49    [21943280]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
Lelouch
dakeiras
Через MDC. Имя файла поддерживает MDC, будет кросс-поточный лог файл для конкретного id.


То есть чтобы не страдать от вашего логгера, пользователь обязан использовать MDC?


В других логгерах это без MDC не сделать. Только там будет общий файл-каша.
А тут отдельные файлы.

Единственная альтернатива - переименовывать потоки, что не рекомендуется.
6 авг 19, 19:51    [21943281]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
автор
См logstash > fileAppender > prudent.
И да, в других логгерах это возникнет, если пользователь явно настроит 2 разных аппендера на 1 файл. В вашем - если не укажет настроку, которая ни разу не обязательна с его точки зрения.


Посмотрю, спасибо.

автор
Они более эффективны даже с точки зрения скорости записи этого самого файла, потому что могут писать его 1 куском. Посмотрите хотя тесты последовательного чтения/записи (например по 1мб) и рандомного (по 4к во всяких crystal disk)


Это тоже посмотрю. Благодарю.
6 авг 19, 19:53    [21943282]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1768
dakeiras
Кстати Бобина даёт невиданный функционал по кросс-поточному и кросс-классовому отслеживанию действий юзера - очень легко настроить чтобы на каждого юзера (или отдельного юзера) были свои лог файлы, через MDC.

Теперь видите какой это царский функционал?


Нет не вижу.
Что по остальным пунктам? Например IOException при ошибке записи файла.
6 авг 19, 19:54    [21943283]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
vas0
Member

Откуда: Таможенный союз (Россия, Казахстан)
Сообщений: 1228
dakeiras
vas0
Ну если данные генерируются в каких то потоках, а в каких то других потоках идет запись в файлы. Чем тут поможет ThreadLocal?
Только если работа уже идет на уровне immutable string объектах, для объектов другого типа без синхронизации можешь получить некорректные значение.


Данные генерируются и записываются в рамках 1 потока.
А как же асинхронные апендеры?
6 авг 19, 19:57    [21943285]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1768
vas0
dakeiras
пропущено...


Данные генерируются и записываются в рамках 1 потока.
А как же асинхронные апендеры?

Их нет. Тут ничего нет кроме консоли и файла. Кстати, dakeiras, вы в курсе, что System.out.println синхронный?
6 авг 19, 19:59    [21943286]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1768
Lelouch
vas0
пропущено...
А как же асинхронные апендеры?

Их нет. Тут ничего нет кроме консоли и файла. Кстати, dakeiras, вы в курсе, что System.out.println синхронный?


Даже уточню - выполняет синхронизацию на this.
6 авг 19, 20:01    [21943288]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1768
[quot dakeiras]В других логгерах это без MDC не сделать. Только там будет общий файл-каша.
Решается условным graylog. И это удобнее чем "куча файлов"
6 авг 19, 20:02    [21943289]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1768
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 курсе:
Ваша программа представляет из себя хрупкую игрушку, работающую только в руках создателя.
6 авг 19, 20:29    [21943299]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
dakeiras
Кстати Бобина даёт невиданный функционал по кросс-поточному и кросс-классовому отслеживанию действий юзера - очень легко настроить чтобы на каждого юзера (или отдельного юзера) были свои лог файлы, через MDC.

Теперь видите какой это царский функционал?

Обычно (в 99%) случаев настройкой системы логгирования заняты дев-опсы. И они себе ставят
вполне себе конкретные задачи. Как-то
- безопасность и аудит
- перформанс
- анализ ошибок

Для всех этих задач этот царский функционал не нужен. Ну или я не знаю такого юзкейса.
Логгировать отдельно поток нет никакого смысла. Поток - это ресурс который берут из "обоймы"
доступных ресурсов и роль потока в крупном приложении может серъезно менятся в считанные
секунды.

Вести одновременно 200 логов с точки зрения файловой системы накладно т.к. нужно иметь
200 файловых дескрипторов и соотв 200 объектов представляющих файл (буферов). Накладные
расходы можно считать а можно и нет. Но поинт опять-же в том что это может быть накладно
(так-же как и держать 65000 открытых сокетов на веб-сервере) и иногда количество переходит
в качество. Для старых магнитных накопителей время seektime безсмысленно тратится
на беготню по поверхности диска и вы получаете жалкие 25 мегабайт в секунду потому-что
вместо throughput получили IOPS, и чтобы получить паспортные пропускные способности
диска - вам лучше вернуться к классической схеме где есть 1 или 2 лога на всё приложение.

Если-же вы слишком долго буферизируете лог без флаша то рискуете получить недописанные
хвостики логов в случае краша приложения.

Зачем нужны логи без хвостиков - я не знаю. Это epic fail и такие логи не будут отражать
важные действия которые возможно повлекли за собой падение.

Провертье мою гипотезу. Нажмите reset под нагрузкой и проследите что самые последние
бизнес аудиты были сохранены.
6 авг 19, 22:21    [21943343]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
автор
Обычно (в 99%) случаев настройкой системы логгирования заняты дев-опсы. И они себе ставят
вполне себе конкретные задачи. Как-то
- безопасность и аудит
- перформанс
- анализ ошибок

Для всех этих задач этот царский функционал не нужен. Ну или я не знаю такого юзкейса.
Логгировать отдельно поток нет никакого смысла. Поток - это ресурс который берут из "обоймы"
доступных ресурсов и роль потока в крупном приложении может серъезно менятся в считанные
секунды.

Я завтра с работы подробно отвечу на комментарии.

Касательно ELK - там невозможно вручную логи смотреть, поэтому отдельные файлы на каждый лог - дают выигрыш в производительности - за счёт отсутствия io congestion.

Если нет ELK, в случаях с пакетными приложениями, ETL, индустриальными приложениями с фиксированными потоками - там возможность отдельных лог файлов это супер фича.
Когда требуется вручную разбирать лог файлы. И в процессе отладки приложения.
6 авг 19, 22:44    [21943350]     Ответить | Цитировать Сообщить модератору
 Re: Новый альтернативный Slf4j логгер Бобина  [new]
dakeiras
Member

Откуда:
Сообщений: 294
Lelouch
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 курсе:
Ваша программа представляет из себя хрупкую игрушку, работающую только в руках создателя.


Никто не говорит, что обязательно разделять.

Просто с точки зрения здравого смысла, если у вас есть 500 потоков - писать лог в единый файл - это бред, наркомания укоренившаяся с годами.
Т.к. очевидно что это вызывает очередь на запись в этот файл.

Хрупкая или нет - есть артифакты публично доступные через Magen/Gradle.

Качаем, ломаем - я плачу бабло.
У меня принцип - ОТВЕЧАТЬ за свой опен сорс софт.

PS: если не нравится threadName, ну напишите threadName+Thread.currentThread().getId()
6 авг 19, 22:59    [21943363]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 11   вперед  Ctrl      все
Все форумы / Java Ответить