Соображения по поводу полезных сообщений трассировки в C # .NET - PullRequest
Новая
       22

Соображения по поводу полезных сообщений трассировки в C # .NET

0 голосов
/ 10 мая 2011

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

Какие вещи вы нашли полезными в своих сообщениях трассировки, будь то для отладки или фильтрации вещей позже? Очевидно, что есть некоторые вещи, такие как уровень (Info, Alert, Warn, Critical), сообщение, домен приложения, но что еще?

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

Пожалуйста, НЕ предлагайте готовые продукты, такие как log4net, Enterprise Library, ELMAH или что-либо подобное, в качестве ответов на этот вопрос. Мы уже рассмотрели каждое популярное дополнение и отклонили их как бесполезные для наших нужд. Если вы хотите предложить фрагменты данных из этих продуктов, это хорошо, но во многих местах я просил внести свой вклад в зависание рекомендовать то, что мы потратили недели, проверяя и отбрасывая, вместо того, чтобы отвечать на вопрос. Я надеюсь, что Стек покажет еще класс.

Ответы [ 3 ]

2 голосов
/ 10 мая 2011

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

1 голос
/ 10 мая 2011

Мне нравится использовать шаблон использования разных уровней трассировки для вещей, которые "принадлежат" на этих уровнях.Например, в случае веб-службы, которая обрабатывает запросы и объединяет другие запросы с другими серверами, я мог бы зарегистрировать тот факт, что я получил запрос как «информационный», тогда как я мог бы распечатать содержимое полного запроса как «Verbose '.

Я в основном классифицирую различные типы событий с разными уровнями, разбрасываю различные уровни по всей кодовой базе, и тогда потребители фреймворка / продукта могут выбрать режим' Verbose ', чтобы увидеть каждый последний параметр каждого запроса иобъект ответа против «информационного», чтобы просто видеть поток запросов / ответов.

Явно ошибочные события (полученный не-OK код состояния), в зависимости от их серьезности, должны быть либо «предупреждением», либо «ошибкой».Мне нравится думать о вещах, которые вызывают прерывание процесса (например, все внешние серверы не работают, я не могу выполнить ваш запрос) как ценность «Ошибка», и о вещах, которые стоит отметить, но не прерывают рабочий процесс (например, 1Реплика внешнего сервера недоступна или ее ответ в оба конца превышает некоторый порог задержки) как достойное «Предупреждение».

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

    /// <summary>
    /// Any additional layers between this log class and calling classes will cause 
    /// this stack trace to return incorrect 'calling' method name
    /// </summary>
    /// <returns></returns>
    private static string GetCallingMethod()
    {
        var stack = new StackTrace();
        var className = string.Empty;
        var methodName = string.Empty;
        foreach ( var frame in stack.GetFrames() )
        {
            className = frame.GetMethod().DeclaringType.FullName;
            methodName = frame.GetMethod().Name;
            if ( className != typeof( Logger ).FullName )
            {
                break;
            }
        }
        return string.Format( "{0}.{1}", className, methodName );
    }
0 голосов
/ 10 мая 2011

Я думаю, что это зависит от того, что делают ваши приложения.Например, если ваше приложение интенсивно использует базу данных, я думаю, вы наверняка захотите записать свои SQL-операторы.Любой динамический ввод от пользователя также может быть полезен в качестве журнала отладки.Метки даты всегда полезны при просмотре журналов.Стеки на ошибки, как другие уже упоминали.Есть и другие случаи, но это пара.Мне любопытно, почему вы исключили готовые продукты, такие как log4net и т. Д. Если бы вы задавали этот вопрос раньше, я бы хотел увидеть ссылки.

...