Мнения о реализации идентификаторов событий в сообщениях журнала - PullRequest
Новая
       22

Мнения о реализации идентификаторов событий в сообщениях журнала

0 голосов
/ 20 апреля 2011

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

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

У меня есть следующие идеи, но приветствуются жизнеспособные альтернативы.Я использовал PHP в этом примере, но было бы полезно кое-что достаточно универсальное, чтобы его можно было применять к большинству языков, таких как PHP / Java / C # / etc.

1) Неявное включение идентификатора в вызов функции журнала: 

abstract class EventId {
    const LOGIN = 1;
    const VALIDATION_FAILURE = 2;
    // etc 
}

Logger::messageDebug(EventID::LOGIN, $username . " logged in"); 
Logger::messageWarning(EventID::VALIDATION_FAILURE, "Form failed to validate, etc.");

Преимуществами этого являются простота, но, боюсь, это может немного запутаться.

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

Logger::messageDebug("%s logged in", $username);
Logger::messageWarning("The %s form failed to validate", $form);

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

3) Отследить и сделать некоторую мерзость 

function messageDebug($message)  {
    $trace = obtainTraceOfCallToMessageDebug();
    $callToMessageDebug = $trace[0];

    $eventId = "";
    $eventId .= $eventId->file;
    $eventId .= $eventId->line;
    $eventId = sha1($eventId);  

    messageImpl($eventId, $message);
}

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

Ждем ваших мнений.Мое главное требование - ремонтопригодность, а не скорость.В настоящее время я смотрю на номер 1 - будь проще.

1 Ответ

0 голосов
/ 20 апреля 2011

Я бы пошел с первым с небольшой модификацией:

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

Logger::messageWarning($message)

Я бы заменил это на 

Logger::messageWarning($message, EventId:someconstant)

и определение класса EventId как 

abstract class EventId {
    const UNSPECIFIED = 1;
    const LOGIN = 2;
    const VALIDATION_FAILURE = 3;
    // etc 
}

, и ваша функция регистрации будет принимать второй параметр, но для этого будет использоваться значение по умолчанию EventId:UNSPECIFIED. 

class Logger {
...
  function messageWarning($message, $message_type = EventId:UNSPECIFIED) {
    ...
  }
}

Таким образом, вы не нарушаете существующий код, не делаете хак, описанный в # 3, и можете заменить ваши вызовы в журнале, где и когда вам нужно, добавив тип события.

...