Хочу менять библиотеки для логирования, например, на лету, не рыская по приложения и не меняя все вызовы конкретной библиотеки на вызовы другой (все эти LogDebug, LogTrace). Но у них у всех разный набор уровней логирования, форматтеры, таргеты и вообще понятия. Ладно там с форматтерами-таргетами - в конфиг-файле написать можно. Но в коде как?

Можно ли написать свой универсальный интерфейс для всех этих библиотек или большинства из них? По мне, или придётся делать ещё больше уровней логирования (чтобы покрыть все случаи во всех популярных либах), или придётся ограничиваться некими универсальными и все остальные сводить к ним. Т.е. мой универсальный интерфейс будет либо невероятно навороченным, либо ограниченным, подходящим лишь для текущего приложения.

У МС есть что-то подобное, но там, похоже, пошли по пути навороченности, где подавляющая часть перегрузок (типа EventId) просто не нужна, т.к. в некоторых логгерах и приложениях даже понятия такого нет.

Как вообще решается такая проблема? Или вы для проекта выбираете какой-то логгер и надеетесь, что с ним всё будет в порядке на протяжении всей жизни приложения, и мигрировать на другой логгер не придётся?

Всякие чуваки так и делают - пишут фреймворк для сопряжения кучи разных других логирующих фреймворков. Типа такого (статья - реклама Papertrail). Но это надо забить на основную работу и переквалифицироваться в написателя своего фреймворка - т.е. не подходит.

А что конкретно хочется иметь в логах?

Вполне достаточно иметь

ILogger

{

Debug(message);

Error(message);

}

В зависимости от хотелок можно еще чего добавить.

Но обычно выбирают один логгер и им пользуются, зачем их менять непонятно.

"Кабы я была царица"... Хотят универсальности, понимаешь. Кто первый крикнул на митинге "я за абстрагироваться и универсализироваться", тот и помидор. Главное, фонтанировать заученными в умных книжках паттернами и слоганами, а надо ли оно тут и сейчас - говно вопрос.

А создатели логгеров это знают и специально вставляют палки в колёса - у одних есть Critical, у других Fatal - мы, мать их, художники, мы так видим. А третьи собирают всё дерьмо отовсюду и хранят по 10-15 разных уровней логирования, пытаясь удовлетворить всех.

Короче, понятно - от недостатка ресурсов поддерживать совместимость всего со всем, нищебродские поцаны лепят минимально удовлетворящий интерфейс и надеются, что начальство не будет чудить хотелками дальше. ))

Заинтригован. А если у вас достаточно ресурсов ну вот вааще на всё, как вы лично поддерживали бы совместимость "всего со всем"?

Ну вот как те парни по ссылкам - либо своя фирма, заточенная на продукт, пытающийся совместить и конвергировать кучи разных логгеров (хз, как они там внутри всё делают, но уверен, что дерьмо ещё то через кучи слоёв и абстракций), либо МС, выкатившая обобщённый интерфейс с двумя десятками логгирующих функций на все случаи жизни (и всё равно не хватает вариантов).

То, что я сейчас переписываю, тоже содержит свой логгер поверх стандартной распространённой библиотеки. Там чел пошёл по пути "всего и побольше" - ввёл несколько десятков логирующих функций на все случаи жизни, и к каждой ещё несколько перегрузок (ну вдруг ещё какие параметры пригодятся?) - типа LogErrorWhenSomethingIsHappend, где "WhenSomethingIsHappend" может быть каким угодно условием. Главное, что это условие в название логирующего метода включено. Т.е. чел не какой-то один объект передаёт, куда всё дерьмо собирает, а дробит объект на части и множит методы с этими частями.

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

и всё равно не хватает вариантов

Странно, отчего-то нам всегда хватало.

Что нужно то обычно?

Знать откуда пришло сообщение и когда. 25.05.2022 19:07:05.345 [Thread 100500] MySuperClass.cs MyGreatFunction line 65, pos. 16

Возможно еще группа (ошибка, инфо) и текст. Всё остальное от лукавого.

Любая перегрузка убьёт первую часть, которая обычно создается автоматом.

Log4Net, Serilog, NLog - Выберите что больше нравится и успокойтесь.

Знать откуда пришло сообщение и когда. 25.05.2022 19:07:05.345 [Thread 100500] MySuperClass.cs MyGreatFunction line 65, pos. 16
Возможно еще группа (ошибка, инфо) и текст. Всё остальное от лукавого.

А контекст кто будет логировать? Или вам никогда не нужен был контекст?

В приложухе, что я переписываю, логируют кучу контекста - типа ввода пользователя, состояния некоторых объектов, данных сессии и прочее.

А контекст кто будет логировать?

А что есть контекст?

Если в функцию пришло 2 конфеты, то текст может быть следующий: "пришло 2 конфеты, но подарков null"

Ну я написал, что есть контекст. Или допустим, у вас глубокая вложенность модальных диалогов. Где-то в глубине ошибка из-за неправильного ввода. Но вы хотели бы знать и состояние других диалогов, а также ещё кучи объектов в приложении. Вот и добавляете их в логирование. Что тогда, как логировать? По идее, можно сериализовать все эти объекты в одну гигантскую строку с кастомным форматированием и отдать эту строку в логгер. Ну и потом нужен кастомный десериализатор для анализа такого лога. Ну или чтобы такой лог легко читаем был.

глубокая вложенность модальных диалогов

Называется - вначале делаем бардак, а после думаем как бы во всём этом разобраться

Да даже и в этом случае всё делается самым обычным способом, причем в категории инфо, которая обычно не логируется.

"Открыли диалог А"

"Изменили имя Лекс на Вася"

"Изменили возраст 16 на 32"

...

Ну и ко всему этому - состояние предыдущих диалогов не должно нарушать работу текущего.

Какая то история не помешает, чтобы понять происходящее, но копировать маниакально всё

У больных людей карточки с их историями болезней есть. Вот и с прогами так нужно. Только вместо болезней - баги. За инструмент, который залогирует всё, что привело юзера к такому-то багу, и потом сможет воспроизвести это на машине разработчика, люди отвалят миллиарды. Большие системы у больших дядей столько инфы пересылают при возникновении ошибки, что против них в суды подают за пересылку персональных данных. Там чуть ли не слепок оперативной памяти, плюс запись последних действий пользователя и всего состояния программы. Но это, конечно, в идеале.

У больных людей карточки с их историями болезней есть.

Вот именно что у больных и толку от них? Кто то будет долго всё изучать и сопоставлять? Чем больше информации тем меньше вероятность найти там что то полезное.

и потом сможет воспроизвести это на машине разработчика,

Нужно поменьше фантастики читать на ночь. Что бы на утро не возникали бредовые идеи

Вот помню пару проектов. На одном, устройство с софтом работало где то неделю, потом софт вылетал. При попытках эмуляции всё работало прекрасно.

На реальном оборудовании логи показывали всё время различные части где вылетало. Можно было увеличивать количество "контекста" до бесконечности, но решения так и не найти.

Решилось многократными обзорами проги - что может работать ненадежно.

Проект 2. Оборудование для проверки качества рельсов, расположено за пару тысяч километров. Стояло два фото барьера на вход и выход рельса. Все работало хорошо до какого-то времени, пока один из сенсоров не начал выдавать совершенно странные показания - рельс выходит и через очень короткое время заходит опять и так еще раз. Начали пытать людей возле машины. В итоге оказалось, что они сделали две дырки в рельсе и световой луч попадал как раз на дырки. Каким чудо "логированием" это можно выяснить?

И таких примеров можно продолжить до бесконечности.

Чем больше информации тем меньше вероятность найти там что то полезное.

Вы это читаете, Мурр? Со своими тоннами документации, где вы откапываете офигенский функционал, недоступный легко в менюшках. )

В итоге оказалось, что они сделали две дырки в рельсе и световой луч попадал как раз на дырки. Каким чудо "логированием" это можно выяснить?

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

Но в общем, как я говорил, почему большие системы, написанные большими дядями (т.е. не какими-то там семизнаками :) ), пытаются отослать тонны контекстной инфы при ошибках? Они, поди, собаку на этом съели и лучше знают?

написанные большими дядями

Ну вот сейчас одна большая страна пытается военными действиями добиться каких то своих задач.

А давно вот, какая то другая большая страна сделала самую большую бомбу в мире и решила посмотреть сколько людей она убьёт.

Они, поди, собаку на этом съели и лучше знают?

Они, поди, собаку на этом съели и лучше знают?

Совершенно верно!

Если Майкрософт или там Гугл хочет отправить отчёт об ошибке на несколько мегабайт данных, значит и нам что-то подобное нужно делать. Большьие дяди лаптей не плетут. И вообще, не надо бояться нюков.

Вот вы используете джаваскрипт в сложных приложениях, несмотря на то, что это дерьмо-язык. А всё потому, что его раскрутил Гугл и стал писать на нём не просто маленькие сайтики с минимальной функциональностью, а здоровенные приложения. И все стали за ним повторять, плюясь и чертыхаясь. Потому что, наверное эти парни знают что-то, раз с JS всё слезать не могут. И мы будем за ними повторять и пихать JS везде и всюду.

Так он сам своим примером с рельсами подтвердил что логгировать надо, и чем больше данных тем лучше.

На предприятиях используют системы типа канбан, так каждую детальку и её путь можно на фабрике отследить.

Сколько информации собирать зависит от пропускной способности и места в хранилище (переписывай в цикле).

они сделали две дырки в рельсе и световой луч попадал как раз на дырки.
Каким чудо "логированием" это можно выяснить?
И таких примеров можно продолжить до бесконечности.

А не надо предсказывать "дырки" отверстия, надо просто логировать все артефакты, + дату, время, температуру, смену, начальника смены, идт итп..

Что-то непонятное произошло? Смотрят в логах, проверяют на участке, либо отсеивают артефакты такого типа, либо чинят линию и лишают премии.

И вообще "программирование" это всего лишь инструмент, гораздо важней сопровождающий программист, который отвечает за отладку и настройку.

По поводу яваскрипта:

Допустим человек хочет достичь большего, чем сравнивать дешёвые сорта маргарина в Новосибирске, то он начинает изучать яваскрипт и солидити.

Открываются новые возможности, покупать лучшее сливочное масло, с черной икрой, пересаживается со стыдной машины в теслу. Слушай Виталика.

Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.

о, расскажи, какая у тебя тесла? За границу ездить не напряжно?

Зачем заграницу? На дачу надо ехать - картошку до сих пор ещё не посадили, с такой погодой.

Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.

ну да. А для дачи зачем Теслу - достаточно сумки на колёсиках.

значит и нам что-то подобное нужно делать

ну просто изумительная идея повторять всё что видим вокруг не понимая зачем.

Допустим человек хочет достичь большего, чем сравнивать дешёвые сорта маргарина в Новосибирске, то он начинает изучать яваскрипт и солидити.

Открываются новые возможности, покупать лучшее сливочное масло, с черной икрой, пересаживается со стыдной машины в теслу. Слушай Виталика.

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

На дачу надо ехать - картошку до сих пор ещё не посадили

Надо спросить у Маска или Гейтса - ездиют ли они на дачи, чтобы сажать картошку. В дойчланде этим не будет заниматься даже беженец или переселенец на пособии, а в руссланде - каждый второй инженер или врач после трудовой недели едет на дачу - попой кверху дополнительно батрачить, руками всё вспахивая и перебирая. В совке вообще поголовное было. Я другой такой страны не знаю, где так вольно дышит человек. Централизованное сельское хозяйство и вообще технический прогресс как будто мимо прошли.

Зато в то время, как в России любой клерк при необходимости заказывает доставку холодильника, программист и кандидат наук Алекс покупает себе автобус, чтобы на доставке сэкономить.
И когда клерк там отдаёт машину на мойку с химчисткой, среднестатистический Алекс корячится со шлангом на заправке за монетки.
А сколько тут людей сами себе ремонт делают…

В России тоже почти все делают себе ремонт сами. Заказать ремонт - это во-первых очень дорого (доступно разве что этим вашим новомодным программистам и разным начальникам), а во-вторых - следить надо, чтобы не накосячили. Заказать могут разве что что-то отдельное - типа установки батарей или труб. Но это тоже обычно у местного ЖЭКа заказывают.

А "тут" сдают построенные дома с голыми стенами, где ты должен отделку и покраску сам сделать? Я имею ввиду не частный дом, а многоэтажку или дом с несколькими квартирами.

А зачем мне на мойку и химчистку отдавать, когда мне проще за монетку ополоснуть тачку и поехать дальше? Ну как стану ещё побогаче, может и буду отдавать.

И "автобус" я хочу не столько для доставки, сколько для удобства путешествий (которых у меня будет от силы 1-2 в год). Я вам ещё раз пишу, что мой "автобус" по занимаемому месту - что ваш универсал, так что вопросы парковки, стоянки и маневрирования одни и те же. А то, что у меня повыше будет, так это хорошо - не надо нагибаться, и запихнуть можно при случае чего габаритное.

А "тут" сдают построенные дома с голыми стенами, где ты должен отделку и покраску сам сделать? Я имею ввиду не частный дом, а многоэтажку или дом с несколькими квартирами.

Сдают. Можешь конечно отделку заказать, но переплатишь в двойне.

Типа такого? Правда тут перебор - стен даже нет. Но бывает что есть лишь стены и батареи... и голые кирпичи или панельки, которые надо сначала штукатурить, затем красить или клеить обои - короче, вложить ещё тонны денег и времени.

Я знаю, что частные дома часто можно так заказать - без отделки. Народ пытается экономить. Но чтобы в многокомнатных кондоминиумах так продавали...

А что по качеству? Много брака и недоделок бывает?

про кондоминимумы не знаю

Знакомый(инженер в сименсе) брал отпуск за свой счёт и сам отделывал таунхаус.

А что по качеству? Много брака и недоделок бывает?

Просто дохрена. И даже больше. За все мои 25 лет в Германии я видел только 2-х хандверкеров, у которых руки не из жопы и голова чтобы думать, а не только в неё есть. Всё, что могу, я стараюсь сделать сам. Не из-за экономии, а из-за того, что я сделаю это лучше, чем эти криворукие кретины.

Я так и не смог объяснить немецким водопроводчикам, что нельзя соединять алюминиевую трубу с медной. Алюминий проржавеет. Они даже слова такого "гальваническая коррозия" не слышали...

А истребовать по гарантии нельзя с них потом будет? С компенсацией ущерба?

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

Странно - алюминий, медь. А разве сейчас не пластик? Канализация - полностью пластик (вплоть до центральной трубы). Подвод - стальная труба в пластике или полностью пластик. В России подача вод под 10 атмосферами идёт, поэтому там нужен толстый пластик или лучше всё же сталь в пластике. А в Германии вроде всего 3 - можно чистый пластик. А пластиковые трубы подачи воды просто паяются. Водоотведение - так они вкладываются через резиновые прокладки - можно каналью всю самому собрать-разобрать за несколько часов, не мудохаясь с чугуном.

Но вроде с собственников всё равно можно сдёрнуть, если они раньше фирмой накосячившей владели?

Алёша, в универе вообще не преподавали виды правовых форм юридических лиц?

Вы имеете ввиду, что они сейчас все с "ограниченной ответственностью"? Т.е. вобщем говоря, нет на них управы? Можно косячить, потом растворяться в воздухе, и никто ни за что не ответит?

предположу, что да.

Как вообще решается такая проблема?

Адаптер

Этот МСовский ILogger и есть адаптер. Понятно, что надо писать прослойку. Я спрашивал, какой подход лучше - пытаться все кейсы всех логгеров покрыть, или лишь минимальные для своего приложения. Первый путь - это явно больше на универсальное решение и создание собственного продукта тянет. Второй - быстро подогнать под текущие реалии.

Кстати, чем адаптер от фасада отличается? И там ещё кучка похожих названий есть.

адаптер от фасада отличается?

https://bambielli.com/posts/2017-09-09-the-adapter-pattern...

Спасибо за ссылку. Но когда я вижу такие штуки

я понимаю, что мне просто ипут мозги чрезмерными классификациями. Таким студентов хорошо на лекциях мучить. Сидим, конспектируем классификации, рисуем квардратики, к ним стрелочки, списочки заполняем - толку нет никакого, зато все типа при деле.

А главное, все эти названия мне ничего не говорят. Я думаю, они и носителю английского ничего не говорят. Почему, например, декоратор добавляет новое поведение, хотя он всего лишь декорирует, а адаптер не добавляет, хотя он адаптирует? В моей системе понятий я бы сделал наоборот. Ну и далее всё в таком духе - понапридумывали ни о чём не говорящих понятий, отличающихся лишь в деталях, и давай на своём птичьем языке говорить, изображая умных. ))

https://qastack.ru/programming/2961307/what-is-the-differe...

...мозги чрезмерными классификациями

ну кому как. ГОФ тогда тоже нужно запретить - какая то просто вредительская банда

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

на дачи, чтобы сажать картошку. В дойчланде этим не будет заниматься даже беженец или переселенец на пособии

Ключевое слово: Schrebergarten погугли, кто побогаче конечно нужно брать поместье, лошади, пруд...

Ты просто живёшь в каморке, а если был бы свой дом, терраса - плодовые деревья, цветочки, смотри что продают в садовых центрах.

В детстве был большой сливовый сад, все соседи приходили за сливами. Если собираются 3 немца обязательно грюндуют ферайн,

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

В общем рассказывать немцу как и чем живут немцы... Пока не поздно, погугли блокчейн и как на нем программировать, купишь дом.

Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.

В упор не вижу, когда у немцев, особенно программистов, есть время возиться с землёй, ландшафтным дизайном, разведением живности. Я же говорю, мне банально лень в моей каморке пыль протереть, а что я буду с большим домом делать? Домработниц нанимать? Разве что если у тебя профессия с этим связана - ну там цветы продаёшь, овощи, фрукты - полуфермер, короче.

Вот кто у тех же семизнаков дом обхаживает?

Эти гартены и есть дачи по российским понятиям. Т.е. не загородний дом, где ты живёшь постоянно, а именно место, куда приезжаешь. В основном летом. Просто в России их раньше использовали для выращивания овощей в основном - чтобы прокормиться. Если же у тебя свой постоянный жилой дом с участком, то в упор не вижу, зачем ещё такой гартен иметь - всё на своём участке и делаешь.

Теоретически все эти кучи терминов и классификаций придумали...

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

Я тебе дал ссылку на маленькие садовые участки, ты тут же стал переобуваться, КАРТОШКА не на еду, а как хобби.

В прошлом году например, я посадил фиолетовую картошку (внутри клубень синий), сделал сотни прививок (груша).

просто в лом писать об этом на форуме, а вот решать задачки по программированию это можно, я пишу ты решаешь)))

Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.