Лучший способ сохранить логи / статистику - PullRequest
Новая
       5

Лучший способ сохранить логи / статистику

2 голосов
/ 07 мая 2009

Я использую Catalyst (MVC Framework для Perl), но вопрос, вероятно, относится ко всем MVC Framework.

До сих пор я использовал файлы журналов Apache для получения статистики о посетителях: пользовательский агент, доступ по URL, время и т. Д. Но теперь, когда я перешел на MVC-фреймворк, я не думаю, что этого достаточно. Если запрос к / 1 / foo и / 1 / bar одинаков для меня, я хочу показать / 1 / только в моем журнале, например.

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

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

Ответы [ 2 ]

4 голосов
/ 07 мая 2009

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

use Attribute::Handlers;

sub Log : ATTR(CODE) {
    my ($pkg, $sym, $code) = @_;


    my $name = *{ $sym }{NAME};

    no warnings 'redefine';

    *{ $sym } = sub {
        log_message("Entering sub $pkg\:\:$name");
        $code->( @_ );
    };
}

sub foo : Log { 
    # this will be logged
}
2 голосов
/ 07 мая 2009

Ответ Фридо невероятно изящен, если требуется такая степень гибкости.

OTOH вы можете продолжать использовать Apache error_log для записи этих данных, просто используя $c->log->info() или одного из его братьев и сестер. Расширить Catalyst :: Log довольно просто, чтобы сообщать о других видах сообщений. Я использую вариант $c->log->sql(), который записывает SQL в журнал error_log, который был запущен, например, через SQL :: Beautify.

Я могу представить что-то вроде 

sub auto {
    ...
    $c->log->audit(sprintf("%s called by %s", $c->action->reverse, $c->userid));
    ...
}

Поместить его в начале (в авто) не то, что вы хотели, но это определенно менее проблематично, поскольку вы знаете, что он будет вызываться всегда, в отличие от конечных обработчиков.

...