Блог

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

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

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

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

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

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

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

Очевидно, что ошибочные события (получен код состояния «не в порядке»), в зависимости от их серьезности, должны быть либо «Предупреждением», либо «Ошибкой». Мне нравится думать о вещах, которые приводят к прерыванию процесса (например, все внешние серверы отключены, я не могу выполнить ваш запрос), как об «Ошибке», а о вещах, которые стоит отметить, но не прерывают рабочий процесс (например, 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 );
    }
  

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