#c# #logging #nlog #milliseconds
Вопрос:
Я использую Nlog и не смог найти функции здесь ниже. Конечно, я мог бы сделать их сам, но, поскольку NLog обычно заботится обо всех потребностях, возможно, у меня может быть все это встроено.
Дельта секунд между каждой записью
У меня есть макет как «[${дата:формат=дд.ММ.гггг ЧЧ:мм:сс.ффф}] (${уровень:верхний регистр=истина}): ${сообщение}», Так что я получаю что-то вроде:
[20.05.2021 11:53:33.667] (INFO): --- 20210520_1153 Starting ---
[20.05.2021 11:53:33.784] (INFO): *.cfg not found going for TRIAL LICENCE
[20.05.2021 11:53:33.784] (INFO): Reg Hive found. Verifying
[20.05.2021 11:53:33.784] (INFO): Key length = 3
Можно ли автоматически добавить дельта-время? так, как здесь, ниже
[20.05.2021 11:53:33.667 - 0.000] (INFO): --- 20210520_1153 Starting ---
[20.05.2021 11:53:33.784 - 0.117] (INFO): *.cfg not found going for TRIAL LICENCE
[20.05.2021 11:53:33.784 - 0.000] (INFO): Reg Hive found. Verifying
[20.05.2021 11:53:33.784 - 0.000] (INFO): Key length = 3
Избегайте повторяющихся строк (по желанию)
[20.05.2021 11:53:33.667] (INFO): AAA
[20.05.2021 11:53:33.784] (INFO): AAA
[20.05.2021 11:53:33.784] (INFO): AAA
[20.05.2021 11:53:33.784] (INFO): AAA
чтобы стать чем-то вроде
[20.05.2021 11:53:33.667] (INFO): AAA
...
И иметь возможность распространить это также более чем на один уровень
[20.05.2021 11:53:33.667] (INFO): AAA
[20.05.2021 11:53:33.784] (INFO): BBB
[20.05.2021 11:53:33.784] (INFO): AAA
[20.05.2021 11:53:33.784] (INFO): BBB
стать
[20.05.2021 11:53:33.667] (INFO): AAA
[20.05.2021 11:53:33.784] (INFO): BBB
...
Это сэкономило бы много символов
Заранее спасибо
Патрик
Ответ №1:
Эти функции (особенно вторая) потребовали бы непрерывного анализа содержимого существующего файла журнала, что значительно повлияет на производительность.
Я сомневаюсь, что NLog будет содержать функцию повторного анализа, и даже если бы это было так, я сомневаюсь, что было бы хорошей идеей использовать ее.
В обоих случаях значительно проще выполнить предварительную обработку записи сообщения журнала, чем ретроактивно анализировать журнал и выяснять, следует ли записывать текущее сообщение журнала или нет.
Комментарии:
1. Ну да, но для исключения повторяющихся строк вам нужно будет сохранить только последнюю написанную строку (или несколько строк) и не записывать ее, если она одинакова. Это то, что я делаю в своем коде. Было бы здорово, если бы это было сделано автоматически
2. @Patrick И где именно хранить эти строки? Не забывайте, что несколько регистраторов могут записывать данные в один и тот же файл журнала. Один экземпляр регистратора не может гарантировать, что журнал не изменился между записью различных сообщений журнала. Вот почему это имеет мало смысла с точки зрения NLog. Однако, с вашей точки зрения, вы могли бы гарантировать, что для данного файла журнала существует только один регистратор исходного кода. NLog не может слепо объяснить это, как и произвольную логику. Действительно проще написать его самостоятельно, чем выяснить, как настроить произвольную реализацию такой функции в NLog.
3. Ты права, мерси! В моей логике у меня есть один основной журнал. Кроме того, могут быть и другие журналы. Так что никакой записи в один и тот же журнал. Когда я создаю регистратор, я создаю строку, в которую помещаю последнюю запись в журнале. Я не знал, что в этом NL может быть несколько регистраторов, записывающих в один и тот же журнал. Есть ли шанс на время дельты? Это может быть сделано даже в логике с несколькими логами
Ответ №2:
Вы можете использовать ${processtime} , чтобы увидеть время с момента запуска программы. См. также: https://github.com/NLog/NLog/wiki/Processtime-Layout-Renderer (Полезно для просмотра дельт).
Вы можете использовать WhenRepeated -фильтр для блокировки повторяющихся событий входа. Но лучше избегать повторного ведения журнала, когда это возможно (и убедитесь, что правила ведения журнала были правильно настроены). См. также: https://github.com/NLog/NLog/wiki/WhenRepeated-Filter
Комментарии:
1. Спасибо за помощь. Давайте рассмотрим оба пункта: (1.) Я хотел бы знать время дельты между строками, а не с самого начала. (2.) Пожалуйста, не могли бы вы подробнее изложить эту концепцию? Я не совсем понимаю, лучше ли мне заняться этим вопросом или оставить это на усмотрение NLog.
2. Для первого пункта я просто использую свои глаза, чтобы увидеть дельту между двумя моментами. Для второго пункта, то
whenRepeatedиспользуется только в качестве последнего средства, когда приложение не может быть изменено.3. Для 1 — го пункта моих глаз недостаточно, когда мне нужно просмотреть тысячи или миллионы записей. И даже не мой мозг. Что касается 2-го, пожалуйста, подтвердите, что я понимаю, а именно, что в ДОЛГОСРОЧНОЙ перспективе лучше не реализовывать стратегию сохранения символов, поскольку это замедлит процесс записи журнала. Лучше действовать по-другому и мудро выбирать, какие сообщения направлять в журнал.
4. @Patrick Для сбора метрик приложений в крупномасштабных системах, тогда у меня, вероятно, были бы специальные сборщики метрик, которые сохранялись бы в базе данных временных рядов, а затем имели бы таблицу Графана (вместо того, чтобы зависеть от операторов журнала). И да, если у вас есть возможность настроить приложение, то лучше удалить дубликаты ведения журнала, вместо последующей фильтрации.