Есть много статик методов, внутри есть интересное(банально — исключения).
ничего не логировать, исключения подавлять.
вручную прокидывать в каждый метод логер?
использовать статик логер внутри?
магия АОП?
Да, причем не конкретный класс, а интерфейс, чтобы можно было легко использовать библиотеку, где определены эти методы, с произвольным логгером.
vaa>использовать статик логер внутри?
тоже вариант, но будет весьма жесткая привязка к одному логгеру.
Тем не менее часто встречал такой вариант.
Здравствуйте, vsb, Вы писали:
vsb>В современном окружении.
А можно подробнее?
И хорошо бы с примерами для .Net (все же мы именно в этом разделе), потому что, как я вижу, нет никакого vsb>Нынче принято логгировать в stdout
И уж тем более (даже если нужно вывести логи в консоль) никто не пишет туда напрямую vsb>println пиши
Это какие-то новые тенденции в Java (вы вроде в этой области работаете)?
Ну и за одно в чем смысл валить всё в stdout? Это же всё равно придется потом перенаправлять в какой-нибудь нормальный агрегатор. Почему бы сразу не писать туда (ну или по старинке в файл)?
Здравствуйте, Михаил Романов, Вы писали:
vsb>>В современном окружении. МР>А можно подробнее?
Приложение пишет в stdout. Контейнер складывает всё это в ротирующиеся файлы. Дополнительное приложение эти файлы мониторит и всё, что туда складывается, высылает в центральное хранилище логов, при необходимости фильтруя и добавляя какую-то информацию.
От языка это не зависит.
Хитромудрные библиотеки только усложняют жизнь админам, которым вместо того, чтобы изучать один инструмент, приходится изучать особенности логгирования в каждом приложении.
МР>Ну и за одно в чем смысл валить всё в stdout? Это же всё равно придется потом перенаправлять в какой-нибудь нормальный агрегатор. Почему бы сразу не писать туда (ну или по старинке в файл)?
Потому, что, когда работает 20 приложений, проще, чтобы они себя вели однотипно (что в том числе касается логгирования) и настроить с них однотипную сборку тех же логов, чем настраивать каждое приложение по отдельности.
Есть такая штука — twelve factors. Там в том числе про логгирование написано:
Logs provide visibility into the behavior of a running app. In server-based environments they are commonly written to a file on disk (a “logfile”); but this is only an output format.
Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services. Logs in their raw form are typically a text format with one event per line (though backtraces from exceptions may span multiple lines). Logs have no fixed beginning or end, but flow continuously as long as the app is operating.
A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.
In staging or production deploys, each process’ stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival. These archival destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment. Open-source log routers (such as Logplex and Fluentd) are available for this purpose.
The event stream for an app can be routed to a file, or watched via realtime tail in a terminal. Most significantly, the stream can be sent to a log indexing and analysis system such as Splunk, or a general-purpose data warehousing system such as Hadoop/Hive. These systems allow for great power and flexibility for introspecting an app’s behavior over time, including:
Finding specific events in the past.
Large-scale graphing of trends (such as requests per minute).
Active alerting according to user-defined heuristics (such as an alert when the quantity of errors per minute exceeds a certain threshold).
vsb>Хитромудрные библиотеки только усложняют жизнь админам, которым вместо того, чтобы изучать один инструмент, приходится изучать особенности логгирования в каждом приложении.
Зато упрощает жизнь разработчикам. Если целевая аудитория приложения ожидает, что приложение пишет в stdout, то в default appconfig приложения в секцию библиотеки, отвечающей за логгирование (NLog какой-нибудь) пишем stdout.
Если же целевая аудитория ожидает, что приложение само будет заниматься ротацией, то пишем другое.
Не угадали с аудиторией? Ну перенастроят, админы же все-таки.
Но тут важно даже другое, я в своем ответе предполагал код библиотеки, которая используется другими разрабочиками.
И именно пользователь сторонней библиотеки должен решать, как ему правильно в своем приложении организовать логгирование, а автор библиотеки должен предоставлять такую возможность.
Здравствуйте, vsb, Вы писали:
vsb>Приложение пишет в stdout. Контейнер складывает всё это в ротирующиеся файлы. Дополнительное приложение эти файлы мониторит и всё, что туда складывается, высылает в центральное хранилище логов, при необходимости фильтруя и добавляя какую-то информацию.
Ну сразу несколько встречных вопросов:
— а что делать если у заказчика не используется контейнеры?
— что потом делать с этими тоннами неструктурированных логов? Писать парсеры для извлечения нужных полей или свести всё к чисто полнотекстовому поиску?
Здравствуйте, vsb, Вы писали:
vsb>>>В современном окружении. МР>>А можно подробнее? vsb>Приложение пишет в stdout. Контейнер складывает всё это в ротирующиеся файлы. Дополнительное приложение эти файлы мониторит и всё, что туда складывается, высылает в центральное хранилище логов, при необходимости фильтруя и добавляя какую-то информацию.
Библиотека логгирования ещё позволяет структурировать логи и захватывать стандартные вещи вроде таймстампа, id треда, имени класса, дамп исключений, severity и т.п. Ты это всё предлагаешь колхозить самому через println? А потом ещё захочется иметь разные уровни логгирования в разных envs...
vsb>От языка это не зависит.
Врёшь. У каждого свой любимый формат логов. И тут не только от языка будет зависеть, но и от желания каждой пятки писателя в println.
vsb>Хитромудрные библиотеки только усложняют жизнь админам, которым вместо того, чтобы изучать один инструмент, приходится изучать особенности логгирования в каждом приложении.
Зачем админам что-то изучать? Программисты предоставят админам конфиг логгера для конкретного окружения и он будет всё валить куда удобнее — в файл, в stdout в syslog или вообще сразу напрямую куда-нибудь в какой-нибудь splunk.
МР>>Ну и за одно в чем смысл валить всё в stdout? Это же всё равно придется потом перенаправлять в какой-нибудь нормальный агрегатор. Почему бы сразу не писать туда (ну или по старинке в файл)? vsb>Потому, что, когда работает 20 приложений, проще, чтобы они себя вели однотипно (что в том числе касается логгирования) и настроить с них однотипную сборку тех же логов, чем настраивать каждое приложение по отдельности.
Эти 20 приложений могут спокойно шарить один и тот же конфиг логгера.
Веселее когда каждое из этих 20 приложений валит всё в stdout в своём формате. Какое-то пишет таймстампы как миллисекунды со старта приложения, другое пишет в iso-timestamp, а ещё одно в локальной таймзоне. И для каждого из этих 20 приложений админам придётся писать парсер и фильтр, любое изменение в формате лога теперь придётся согласовывать с админами.
vsb>Есть такая штука — twelve factors. Там в том числе про логгирование написано:
Тут не раскрыта тема как собственно структурировать этот "raw form". Регекспами?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Библиотека логгирования ещё позволяет структурировать логи и захватывать стандартные вещи вроде таймстампа, id треда, имени класса, дамп исключений, severity и т.п. Ты это всё предлагаешь колхозить самому через println? А потом ещё захочется иметь разные уровни логгирования в разных envs...
Накручивать можно много всего, но нужно ли это всё такой ценой — вопрос спорный. Таймстэмп может и сборщик логов проставлять.
vsb>>Хитромудрные библиотеки только усложняют жизнь админам, которым вместо того, чтобы изучать один инструмент, приходится изучать особенности логгирования в каждом приложении. ·>Зачем админам что-то изучать? Программисты предоставят админам конфиг логгера для конкретного окружения и он будет всё валить куда удобнее — в файл, в stdout в syslog или вообще сразу напрямую куда-нибудь в какой-нибудь splunk.
Программисты ничего не предоставят, они в этом не разбираются. Они докерфайл написать не могут по-человечески, какие уж там логи.
vsb>>Потому, что, когда работает 20 приложений, проще, чтобы они себя вели однотипно (что в том числе касается логгирования) и настроить с них однотипную сборку тех же логов, чем настраивать каждое приложение по отдельности. ·>Эти 20 приложений могут спокойно шарить один и тот же конфиг логгера. ·>Веселее когда каждое из этих 20 приложений валит всё в stdout в своём формате. Какое-то пишет таймстампы как миллисекунды со старта приложения, другое пишет в iso-timestamp, а ещё одно в локальной таймзоне. И для каждого из этих 20 приложений админам придётся писать парсер и фильтр, любое изменение в формате лога теперь придётся согласовывать с админами.
А надо быть проще. Есть в спринг буте дефолтный формат — вот пусть он и используется. Есть в голанге дефолтный формат — вот пусть он и используется. Нет формата — значит и не надо.
vsb>>Есть такая штука — twelve factors. Там в том числе про логгирование написано: ·>Тут не раскрыта тема как собственно структурировать этот "raw form". Регекспами?
Никак не структурировать. Это не нужно. Есть стандартный формат вроде var=value. Если в конкретной строчке это нужно залоггировать, то указать. id треда со всеми этими корутинами стал бесполезен. severity тоже не нужен, откуда программисту знать, что важно, а что нет. Надо всё логгировать в разумных объёмах, а там разберутся. Какой-нибудь идентификатор запроса может быть полезно логгировать, это максимум.
Здравствуйте, Михаил Романов, Вы писали:
vsb>>Приложение пишет в stdout. Контейнер складывает всё это в ротирующиеся файлы. Дополнительное приложение эти файлы мониторит и всё, что туда складывается, высылает в центральное хранилище логов, при необходимости фильтруя и добавляя какую-то информацию. МР>Ну сразу несколько встречных вопросов: МР>- а что делать если у заказчика не используется контейнеры? МР>- что потом делать с этими тоннами неструктурированных логов? Писать парсеры для извлечения нужных полей или свести всё к чисто полнотекстовому поиску?
Я не понимаю, кто такие заказчики. Я пишу программы для своей компании, у меня заказчик это я. Если я сказал, что надо использовать контейнеры, значит я буду их использовать, простите за раздвоение личности. Если вы пишете коробочный софт, который запускает кто попало, и даже не в контейнерах, то это, конечно, странно, тогда может такие страдания и оправданы. Хотя я плохо себе представляю, как можно в 2022 году что-то запускать не в контейнерах. Их уже джуниорам на курсах преподают.
В целом — да, всё сводится к тупому поиску. Анализ логов всегда сводится к тупому поиску. Благо, современные системы очень хорошо умеют тупой поиск. Можно, конечно, в логи навешивать какие-нибудь дополнительные атрибуты, но польза от этого спорная. Если я ищу логи, связанные с клиентом 23456 я не буду фильтровать их по info или debug, я всё буду читать, кто его знает, что там программисту в голову пришло, когда он их писал, хоть какие-то написал и слава богу.
Здравствуйте, vsb, Вы писали:
vsb>·>Библиотека логгирования ещё позволяет структурировать логи и захватывать стандартные вещи вроде таймстампа, id треда, имени класса, дамп исключений, severity и т.п. Ты это всё предлагаешь колхозить самому через println? А потом ещё захочется иметь разные уровни логгирования в разных envs... vsb>Накручивать можно много всего, но нужно ли это всё такой ценой — вопрос спорный.
Без id треда ты банально не сможешь определить в каком порядке что происходит.
vsb>Таймстэмп может и сборщик логов проставлять.
Это бред. Нужен таймстамп когда событие произошло, а не когда до него сборщик добрался.
vsb>>>Хитромудрные библиотеки только усложняют жизнь админам, которым вместо того, чтобы изучать один инструмент, приходится изучать особенности логгирования в каждом приложении. vsb>·>Зачем админам что-то изучать? Программисты предоставят админам конфиг логгера для конкретного окружения и он будет всё валить куда удобнее — в файл, в stdout в syslog или вообще сразу напрямую куда-нибудь в какой-нибудь splunk. vsb>Программисты ничего не предоставят, они в этом не разбираются. Они докерфайл написать не могут по-человечески, какие уж там логи.
Представляю какие логи такие программисты напишут через println. И не докер тут нужен, а какой-нибудь logback.xml, который и админ может осилить, типичный конфиг.
vsb>>>Потому, что, когда работает 20 приложений, проще, чтобы они себя вели однотипно (что в том числе касается логгирования) и настроить с них однотипную сборку тех же логов, чем настраивать каждое приложение по отдельности. vsb>·>Эти 20 приложений могут спокойно шарить один и тот же конфиг логгера. vsb>·>Веселее когда каждое из этих 20 приложений валит всё в stdout в своём формате. Какое-то пишет таймстампы как миллисекунды со старта приложения, другое пишет в iso-timestamp, а ещё одно в локальной таймзоне. И для каждого из этих 20 приложений админам придётся писать парсер и фильтр, любое изменение в формате лога теперь придётся согласовывать с админами. vsb>А надо быть проще. Есть в спринг буте дефолтный формат — вот пусть он и используется. Есть в голанге дефолтный формат — вот пусть он и используется. Нет формата — значит и не надо.
А где же обещанное "От языка это не зависит"? Чуда не случилось.
vsb>>>Есть такая штука — twelve factors. Там в том числе про логгирование написано: vsb>·>Тут не раскрыта тема как собственно структурировать этот "raw form". Регекспами? vsb>Никак не структурировать. Это не нужно. Есть стандартный формат вроде var=value.
Можно ссылочку на этот единственный стандарт?
vsb>Если в конкретной строчке это нужно залоггировать, то указать. vsb>id треда со всеми этими корутинами стал бесполезен.
В этом случае нужен будет какой-нибудь correlationId.
vsb>severity тоже не нужен, откуда программисту знать, что важно, а что нет. Надо всё логгировать в разумных объёмах, а там разберутся. Какой-нибудь идентификатор запроса может быть полезно логгировать, это максимум.
Откуда у таких программистов возьмётся хоть что-то разумное, если они даже в десяток строчек логгер-конфига не могут осилить. Либо в логах не будет ничего полезного, либо логов будет столько, что разоритесь на их хранилище.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vsb, Вы писали:
vsb>Я не понимаю, кто такие заказчики. Я пишу программы для своей компании, у меня заказчик это я.
В смысле вы владелец бизнеса? Или вы лицо принимающее все технические решения (что-то типа ведущего архитектора)?
vsb>Если вы пишете коробочный софт, который запускает кто попало, и даже не в контейнерах, то это, конечно, странно, тогда может такие страдания и оправданы. Хотя я плохо себе представляю, как можно в 2022 году что-то запускать не в контейнерах. Их уже джуниорам на курсах преподают.
То, что контейнеры преподают джуниорам, никак не является основанием для их использования.
Есть и другие способы хостинга, а для десктопа контейнеры уместны разве что как среда разработки.
vsb>В целом — да, всё сводится к тупому поиску. Анализ логов всегда сводится к тупому поиску.
Вы, мягко говоря, заблуждаетесь. Современные системы работы с логами всё дальше мигрируют в сторону
— структурированных логов
— автоматизации обработки логов. От банального трассировки end-to-end цепочки (которую физически невозможно сделать не имея некоего id или группы переходящих друг в друга id), до, например, агрегации одинаковых ошибок в одно issue, в рамках которого можно сразу увидеть: когда и на каких релизах проявилась ошибка, на каких машинах, какие пользователи пострадали, id полных трейсов, ....
Если вы до сих пор обходитесь просто поиском по всем логам компании, то единственное что я могу предположить — ИТ-парк компании очень небольшой. Ну или вы что-то недосказываете.
Здравствуйте, vsb, Вы писали:
vsb>>>println пиши. Нынче принято логгировать в stdout. МР>>Это где так принято? vsb>В современном окружении.
В современном окружении принят structured logging, причем в формате и с настройками, общими для всего процесса. Это я не говорю о том, что правильно писать в stdout тоже надо уметь.
Здравствуйте, vsb, Вы писали:
vsb>Я не понимаю, кто такие заказчики. Я пишу программы для своей компании, у меня заказчик это я.
Ну давай про одну компанию поговорим. И даже про вывод исключительно в stdout. Запускаю я сервис локально — мне бы посмотреть логи в коротком формате глазами. А потом я деплою свой контейнер и хочу накормить структурированным логом, к примеру, fluentbit, который потом отправит в ELK.
Вопрос — в твоей мегаутилите в каком формате писать? В виде json и получить нечитаемую кашу в консоли при отладке или в удобном человеку виде, но потом в кибане получить неструктурированную строку?
vsb>Можно, конечно, в логи навешивать какие-нибудь дополнительные атрибуты, но польза от этого спорная.
Польза от структурированных логов спорная? Серьезно? Ты это в 2022 году пишешь?
Здравствуйте, vsb, Вы писали:
vsb>println пиши. Нынче принято логгировать в stdout.
GUI windows application. может ошибаюсь, но там со стд снять сигнал сложно.
