Sharepoint 2010: Протоколирование

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

try
{
    var i = 0;
    var a = 2 / i;
}
catch (Exception ex)
{
    SPDiagnosticsService.Local.WriteTrace(0, new SPDiagnosticsCategory("My Category", TraceSeverity.Unexpected, EventSeverity.Error), TraceSeverity.Unexpected, ex.Message, ex.StackTrace);
}

Протоколирование. Часть 4. Популярные платформы протоколирования.

1. TraceListener

Сайт разработчика: microsoft.com
Последняя дата обновления: Входит в состав .NET Framework

Функционал протоколирования, который поставляется совместно в .NET Framework (System.Diagnostics.TraceListener). Ранее я упоминал, что в составе .NET Framework есть функции Trace.Write и Debug.Write, которые являются одной из наиболее полезных особенностей отладки.NET Framework. Функционально Trace очень похож на Debug, но в отличие от своего Debug брата, который должен быть использован только во время отладки, Trace функция может быть внедрена в программу и поставлена заказчикам, в том случае, если пользователи сталкиваются с проблемой, они могут активировать Trace, просто редактируя файл конфигурации приложений.

1.1. Переключатели

Следующий элемент, с помощью которого можно управлять протоколированием – это переключатели. Грубо говоря – это флаги, которые можно использовать перед вызовов функции протоколирования.

Протоколирование. Часть 3. Критерии выбора логгеров

В данной статье рассматриваются критерии выбора профессиональных решений для протоколирования.

1.   Основные

1.1.     Протоколирование простых текстовых сообщений

Таких как отладочная информация или ошибки и связанная с ними информация, такая как время.

1.2.     Уровни логов для фильтрации сообщений

Большинство инструментов протоколирования позволяют разработчикам указывать уровень лога, такой как debug, info, warning и error для каждого сообщения и фильтровать сообщения по степени важности. В зависимости от пользователя ему могут быть интересны сообщения определенного уровня. Например, разработчикам необходима более детальная информация  в процессе отладки.

Протоколирование. Часть 2 Внедрение протоколирования.

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

Уровень 1. Начинающий.

Как правило, о протоколировании начинаешь задумываться, когда сталкиваешься с проблемами работы приложения на производственной среде Заказчика. Т.к., как говорилось ранее, не всегда у Заказчика возможно развернуть графические инструменты отладки, то приходится реализовывать инструмент протоколирования, например, запись в файл. Обычно разработчики начиняют свой код разного рода сообщениями, по которым он может понять до куда программа дошла, какие значения переменных имела и т.д. Иногда даже удается найти источник ошибки. После чего разработчику необходимо пересобрать приложение, убрав излишнее протоколирование или просто закомментировать, т.к. сильно частый вывод сообщений в протоколировании может уменьшить быстродействие приложения, поскольку тратится время на сам вывод сообщений. Но что происходит, когда появляется новая ошибка в приложении? Правильно, разработчик опять внедряет отладочные сообщения. Кстати, вполне реально, что он будет это делать в уже «отлаженном» в прошлый раз коде.

Протоколирование. Часть 1.

Всех с наступившим 2011 годом!!! Начнем цикл статей... 

Введение
Этот цикл статей родился не просто так. Тема протоколирования широкая (это демонстрирует объем прочитанных статей в интернете, на основе которых вкупе со своим опытом и создан этот материал), и каждый программист решает, как ему удобно отлаживать свои программы. Т.о. количество средств протоколирования растет очень быстро, т.к. постоянно изобретаются велосипеды. Вред подобного «велосипедостроительства» рано или поздно становится понятен каждому разработчику. К сожалению, я не стал исключением, реализовав свою систему протоколирования в нескольких проектах. Цель этого цикла статей – дать разработчику информацию о существующих системах протоколирования. И пусть каждый разработчик сам выбирает готовый инструмент в зависимости от своих потребностей. Если появятся интересы, то можно будет провести тестирования средств и понять, какое из них нам все же по душе.

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