Лучшие практики ведения журнала C# в 2021 году с примерами и инструментами

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

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

Двенадцать Фактора-App методология приобрела популярность как набор руководящих принципов для построения современной программного обеспечения как услуги. Один из двенадцати факторов — лесозаготовки.

Согласно методологии приложения с двенадцатью факторами, данные журнала следует рассматривать как поток событий. Потоки данных отправляются слушателям как своего рода «широковещательная рассылка», независимо от того, что произойдет с полученными данными. По двенадцатифакторному методу каротажа:

«Приложение с двенадцатью факторами никогда не занимается маршрутизацией или хранением своего выходного потока».

Цель этой рекомендации — разделить функции приложения и сбор и индексирование данных журнала. Метод двенадцати факторов дошел до того, что рекомендовал отправлять все данные журнала stdout(также известный как «консоль»). Это один из нескольких способов отделить приложение от ведения журнала. Независимо от используемого метода разделение этих проблем упрощает код приложения. Разработчики могут сосредоточиться на том, какие данные они хотят регистрировать, не беспокоясь о том, куда идут данные журнала или как ими управлять.

Популярные платформы ведения журналов для.NET framework помогают разработчикам поддерживать такое разделение задач. Они также предоставляют параметры конфигурации для изменения уровней ведения журнала и целей вывода, так что ведение журнала может быть изменено в любой среде, от разработки до производства, без необходимости обновления кода.

Фреймворки журналирования

Фреймворки ведения журналов обычно поддерживают такие функции, как:

• Уровни ведения журнала
• Цели регистрации
• Структурированное (также называемое «семантическим») ведение журнала.

NLog

NLog — один из самых популярных и один из самых эффективных фреймворков для ведения журналов для.NET. Настроить NLog довольно просто. Разработчики могут использовать Nuget для загрузки зависимости, а затем отредактировать NLog.configфайл, чтобы настроить цели. Цели подобны приемникам данных журнала. NLog может нацеливаться на консоль, что является методом с двенадцатью факторами. Другие цели включают файл и почту. Обертки изменяют и улучшают поведение цели. AsyncWrapper, например, повышает производительность за счет асинхронной отправки журналов. Целевая конфигурация может быть изменена путем обновления NLog.configфайла и не требует изменения кода или перекомпиляции.

NLog поддерживает следующие уровни ведения журнала :

• ОТЛАДКА: дополнительная информация о поведении приложения для случаев, когда эта информация необходима для диагностики проблем.
• ИНФОРМАЦИЯ: События приложений общего назначения
• ПРЕДУПРЕЖДЕНИЕ: события приложения, которые могут указывать на проблему.
• ОШИБКА: обычно регистрируется в catchблоке, блоке try / catch, включает исключение и контекстные данные.
• FATAL: критическая ошибка, приводящая к завершению работы приложения.
• TRACE: используется для обозначения входа и выхода функций в целях профилирования производительности.

Уровни ведения журнала используются для фильтрации данных журнала. Типичная производственная среда может быть настроена на регистрацию только уровней ОШИБКИ и ФАТАЛА. Если возникают проблемы, уровень ведения журнала можно увеличить, включив в него события DEBUG и WARN. Дополнительный контекст, предоставляемый этими журналами, может помочь в диагностике сбоев.

Вот пример кода, который ведет журнал с помощью NLog:

    namespace MyNamespace
	{
	  public class MyClass
	  {
	    //NLog recommends using a static variable for the logger object
	    private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();

		//NLog supports several logging levels, including INFO
		logger.Info("Hello {0}", "Earth");
		try
		{
			//Do something
		}
		catch (Exception ex)
		{
		    //Exceptions are typically logged at the ERROR level
		    logger.Error(ex, "Something bad happened");
		}
	  }
	}

Log4NET

Log4NET — это порт популярной и мощной среды ведения журналов Log4J для Java. Установка и настройка Log4NET аналогична NLog, где файл конфигурации содержит параметры, определяющие, как и куда Log4NET отправляет данные журнала. В конфигурации можно настроить автоматическую перезагрузку настроек при изменении файла.

Log4Net использует appenders для передачи данных журнала в различных целях. Можно настроить несколько приложений для отправки данных журнала нескольким целевым объектам. Дополнения можно комбинировать с конфигурацией, чтобы задать подробность или объем выводимых данных по уровню ведения журнала. Log4NET поддерживает тот же набор уровней ведения журнала, что и NLog, за исключением того, что он не имеет встроенного уровня TRACE.

Синтаксис ведения журнала в Log4NET также похож на NLog:

private static readonly ILog log = LogManager.GetLogger(typeof(MyApp));
log.Info("Starting application.");
log.Debug("DoTheThing method returned X");

ELMAH (модули и обработчики регистрации ошибок)

ELMAH специально разработан для приложений ASP.NET. Его довольно легко настроить, и он включает в себя приложение панели управления, которое можно использовать для просмотра ошибок. ELMAH популярен и доступен уже давно, однако на самом деле он не использует метод двенадцати факторов. ELMAH сохраняет данные в базах данных, включая MySQL, SQL Server, Postgres и другие. В этом методе проблемы ведения журнала сочетаются с проблемами сохранения журнала. Данные журналов хранятся в реляционной базе данных, что не является оптимальным методом хранения журналов (я расскажу о лучшем способе чуть позже).

Что и как регистрировать

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

Уровни журнала

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

Каждый уровень регистрации связан с типом регистрируемых данных. События DEBUG, INFO и TRACE обычно не являются ошибочными состояниями, которые сообщают о поведении приложения.

В зависимости от того, как они используются, они обычно включены в непроизводственные среды и отключены в производственной среде. В производственных средах обычно есть уровни ОШИБКИ и ПРЕДУПРЕЖДЕНИЯ, позволяющие сообщать о проблемах. Это ограничивает ведение производственных журналов только важными, чувствительными ко времени данными, которые влияют на доступность приложений.

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

Лучшие практики ведения журнала

Журналы отладки обычно сообщают о событиях приложений, которые полезны при диагностике проблемы. При расследовании сбоев приложений требуются слова «W»: Кто, Что, Когда, Где и почему:

• Кто использовал систему, когда она вышла из строя?
• Где в коде приложение потерпело неудачу?
• Что делала система, когда вышла из строя?
• Когда произошел сбой?
• Почему приложение не удалось?

«Почему произошло сбой приложения» — это результат расследования сбоя и цель регистрации. Цели ведения журнала обычно обрабатывают «когда» с помощью отметок времени, добавленных к записям журнала. Остальные «W» получены из операторов регистрации, добавленных в код.

Есть два метода, которые помогут сделать ведение журнала более эффективным: ведение журнала контекста и структурированное ведение журнала.

Контекст ведения журнала означает добавление буквы «W» в записи журнала. Без контекста может быть трудно связать сбои приложений с журналами.

Это обычный оператор журнала:

try {
	//Do something
}
catch(ex as Exception) {
	logger.Error(ex);
	throw;
}

Объект исключения в этом примере отправляется как запись журнала в цель (цели) ведения журнала. Это необходимо, но нет никакого контекста. Какой метод выполнялся (где приложение не удалось)? Что делает приложение? Кто пользовался приложением?

И NLog, и Log4NET имеют функции, которые помогают добавлять эту контекстную информацию в журналы, что делает их гораздо более полезными. Контекстные данные добавляются как метаданные в записи журнала.

Структурированное ведение журнала означает согласованное форматирование регистрируемых данных. NLog и Log4NET поддерживают макеты. Это классы и другие утилиты, которые форматируют журналы и сериализуют объекты в общий формат. Структурированные журналы можно индексировать гораздо эффективнее, что упрощает их поиск.

Куда отправлять данные журнала

Ранее я упоминал, что реляционные базы данных — не лучшее место для отправки данных журнала. Базы данных временных рядов (TSDB) намного эффективнее хранят данные журналов. TSDB требует меньше места на диске для хранения событий, которые поступают в определенном порядке, как и события журнала. TSDB с открытым исходным кодом, например InfluxDB, гораздо лучше подходят для хранения данных журнала, чем реляционные базы данных.

Стек ELK является популярным решением для агрегации журнала. ELK — это аббревиатура от Elasticsearch, Logstash и Kibana.

Elasticsearch — это быстрая поисковая система, которая используется для поиска данных в больших наборах данных.

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

Kibana — это веб-визуализатор данных и поисковая система, которая интегрируется с Elasticsearch.

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

Проблема с инструментами ведения журнала

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

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

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

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

Отчеты о сбоях и регистрация ошибок

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

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

Заключительные мысли о лучших методах ведения журнала

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

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