Обобщённый интерфейс для разных библиотек?
Хочу менять библиотеки для логирования, например, на лету, не рыская по приложения и не меняя все вызовы конкретной библиотеки на вызовы другой (все эти LogDebug, LogTrace). Но у них у всех разный набор уровней логирования, форматтеры, таргеты и вообще понятия. Ладно там с форматтерами-таргетами - в конфиг-файле написать можно. Но в коде как?
Можно ли написать свой универсальный интерфейс для всех этих библиотек или большинства из них? По мне, или придётся делать ещё больше уровней логирования (чтобы покрыть все случаи во всех популярных либах), или придётся ограничиваться некими универсальными и все остальные сводить к ним. Т.е. мой универсальный интерфейс будет либо невероятно навороченным, либо ограниченным, подходящим лишь для текущего приложения.
У МС есть что-то подобное, но там, похоже, пошли по пути навороченности, где подавляющая часть перегрузок (типа EventId) просто не нужна, т.к. в некоторых логгерах и приложениях даже понятия такого нет.
Как вообще решается такая проблема? Или вы для проекта выбираете какой-то логгер и надеетесь, что с ним всё будет в порядке на протяжении всей жизни приложения, и мигрировать на другой логгер не придётся?
"Кабы я была царица"... Хотят универсальности, понимаешь. Кто первый крикнул на митинге "я за абстрагироваться и универсализироваться", тот и помидор. Главное, фонтанировать заученными в умных книжках паттернами и слоганами, а надо ли оно тут и сейчас - говно вопрос.
А создатели логгеров это знают и специально вставляют палки в колёса - у одних есть 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
Возможно еще группа (ошибка, инфо) и текст. Всё остальное от лукавого.
А контекст кто будет логировать? Или вам никогда не нужен был контекст?
В приложухе, что я переписываю, логируют кучу контекста - типа ввода пользователя, состояния некоторых объектов, данных сессии и прочее.
Ну я написал, что есть контекст. Или допустим, у вас глубокая вложенность модальных диалогов. Где-то в глубине ошибка из-за неправильного ввода. Но вы хотели бы знать и состояние других диалогов, а также ещё кучи объектов в приложении. Вот и добавляете их в логирование. Что тогда, как логировать? По идее, можно сериализовать все эти объекты в одну гигантскую строку с кастомным форматированием и отдать эту строку в логгер. Ну и потом нужен кастомный десериализатор для анализа такого лога. Ну или чтобы такой лог легко читаем был.
глубокая вложенность модальных диалогов
Называется - вначале делаем бардак, а после думаем как бы во всём этом разобраться 
Да даже и в этом случае всё делается самым обычным способом, причем в категории инфо, которая обычно не логируется.
"Открыли диалог А"
"Изменили имя Лекс на Вася"
"Изменили возраст 16 на 32"
...
Ну и ко всему этому - состояние предыдущих диалогов не должно нарушать работу текущего.
Какая то история не помешает, чтобы понять происходящее, но копировать маниакально всё
У больных людей карточки с их историями болезней есть. Вот и с прогами так нужно. Только вместо болезней - баги. За инструмент, который залогирует всё, что привело юзера к такому-то багу, и потом сможет воспроизвести это на машине разработчика, люди отвалят миллиарды. Большие системы у больших дядей столько инфы пересылают при возникновении ошибки, что против них в суды подают за пересылку персональных данных. Там чуть ли не слепок оперативной памяти, плюс запись последних действий пользователя и всего состояния программы. Но это, конечно, в идеале.
У больных людей карточки с их историями болезней есть.
Вот именно что у больных и толку от них? Кто то будет долго всё изучать и сопоставлять? Чем больше информации тем меньше вероятность найти там что то полезное.
и потом сможет воспроизвести это на машине разработчика,
Нужно поменьше фантастики читать на ночь. Что бы на утро не возникали бредовые идеи
Вот помню пару проектов. На одном, устройство с софтом работало где то неделю, потом софт вылетал. При попытках эмуляции всё работало прекрасно.
На реальном оборудовании логи показывали всё время различные части где вылетало. Можно было увеличивать количество "контекста" до бесконечности, но решения так и не найти.
Решилось многократными обзорами проги - что может работать ненадежно.
Проект 2. Оборудование для проверки качества рельсов, расположено за пару тысяч километров. Стояло два фото барьера на вход и выход рельса. Все работало хорошо до какого-то времени, пока один из сенсоров не начал выдавать совершенно странные показания - рельс выходит и через очень короткое время заходит опять и так еще раз. Начали пытать людей возле машины. В итоге оказалось, что они сделали две дырки в рельсе и световой луч попадал как раз на дырки. Каким чудо "логированием" это можно выяснить?
И таких примеров можно продолжить до бесконечности.
Чем больше информации тем меньше вероятность найти там что то полезное.
Вы это читаете, Мурр? Со своими тоннами документации, где вы откапываете офигенский функционал, недоступный легко в менюшках. )
В итоге оказалось, что они сделали две дырки в рельсе и световой луч попадал как раз на дырки. Каким чудо "логированием" это можно выяснить?
Ну да, если рабочие делают что-то, что не предусмотрено технологией, инструкцией, или просто не говорят начальству и разработчикам, что они что-то изменили, то такого не предусмотришь. Значит нужно отчитываться об изменениях на местах, а не самодельничать.
Но в общем, как я говорил, почему большие системы, написанные большими дядями (т.е. не какими-то там семизнаками :) ), пытаются отослать тонны контекстной инфы при ошибках? Они, поди, собаку на этом съели и лучше знают?
написанные большими дядями
Ну вот сейчас одна большая страна пытается военными действиями добиться каких то своих задач.
А давно вот, какая то другая большая страна сделала самую большую бомбу в мире и решила посмотреть сколько людей она убьёт.
Они, поди, собаку на этом съели и лучше знают?
Они, поди, собаку на этом съели и лучше знают?
Совершенно верно!
Если Майкрософт или там Гугл хочет отправить отчёт об ошибке на несколько мегабайт данных, значит и нам что-то подобное нужно делать. Большьие дяди лаптей не плетут. И вообще, не надо бояться нюков.
Вот вы используете джаваскрипт в сложных приложениях, несмотря на то, что это дерьмо-язык. А всё потому, что его раскрутил Гугл и стал писать на нём не просто маленькие сайтики с минимальной функциональностью, а здоровенные приложения. И все стали за ним повторять, плюясь и чертыхаясь. Потому что, наверное эти парни знают что-то, раз с JS всё слезать не могут. И мы будем за ними повторять и пихать JS везде и всюду.
Так он сам своим примером с рельсами подтвердил что логгировать надо, и чем больше данных тем лучше.
На предприятиях используют системы типа канбан, так каждую детальку и её путь можно на фабрике отследить.
Сколько информации собирать зависит от пропускной способности и места в хранилище (переписывай в цикле).
они сделали две дырки в рельсе и световой луч попадал как раз на дырки.
Каким чудо "логированием" это можно выяснить?
И таких примеров можно продолжить до бесконечности.
А не надо предсказывать "дырки" отверстия, надо просто логировать все артефакты, + дату, время, температуру, смену, начальника смены, идт итп..
Что-то непонятное произошло? Смотрят в логах, проверяют на участке, либо отсеивают артефакты такого типа, либо чинят линию и лишают премии.
И вообще "программирование" это всего лишь инструмент, гораздо важней сопровождающий программист, который отвечает за отладку и настройку.
По поводу яваскрипта:
Допустим человек хочет достичь большего, чем сравнивать дешёвые сорта маргарина в Новосибирске, то он начинает изучать яваскрипт и солидити.
Открываются новые возможности, покупать лучшее сливочное масло, с черной икрой, пересаживается со стыдной машины в теслу. Слушай Виталика.
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.
Зачем заграницу? На дачу надо ехать - картошку до сих пор ещё не посадили, с такой погодой. 
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.