Структура Perl-программы для разбора - PullRequest
1 голос
/ 05 мая 2011

У меня вопрос по архитектуре программы. Допустим, у вас есть 100 различных файлов журналов в разных форматах, и вам нужно проанализировать и поместить эту информацию в базу данных SQL. Мой взгляд на это как:

  1. использовать общий конфигурационный файл, например:

    program1->name1("apache",/var/log/apache.log) (modulename,path to logfile1)
    program2->name2("exim",/var/log/exim.log) (modulename,path to logfile2)
    
    ....
    
    sqldb->configuration
    
  2. использовать что-то вроде модуля (1 файл на программу) type1.module (regexp, logstructure (somevariables), sql (таблицы и функции))

  3. процессы ветвления или потока (не знаю, что лучше в Linux) для различных программ.

Итак, вопрос в том, верен ли мой взгляд на это? Я должен использовать один модуль для каждой программы (web / MTA / iptablat) или есть какой-то лучший способ? Я думаю, что некоторые регулярные выражения будут такими же, как date / time / ip / url. Что с этим делать? Или что я пропустил?


пример: основной журнал mta exim4

2011-04-28 13:16:24 1QFOGm-0005nQ-Ig <= exim@mydomain.org.ua** <strong>H = localhost (Exim.mydomain.org.ua) [127.0.0.1]: 51127 I = [127.0.0.1]: 465 Р = esmtpsa Х = TLS1.0: DHE_RSA_AES_256_CBC_SHA1: 32 CV = нет A = обычный_сервер: спам S = 763 id=1303985784.4db93e788cb5c@mydomain.org.ua T = "тест" от <<strong>exim@exim.mydomain.org.ua> для test@domain.ua

все, что является полужирным , уже проанализировано и будет помещено в таблицу sqldb.incoming. Теперь у меня есть структура в Perl для хранения каждой анализируемой переменной, как $exim->{timstamp} or $exim->{host}->{ip}

моя программа будет делать что-то вроде tail -f /file и анализировать ее построчно

Гибкость: допустим, я хочу добавить supprot к серверу apache (просто отметка времени userip и загруженный файл). все, что мне нужно знать, что лог-файл для анализа, что регулярное выражение должно быть и какова структура sql. Так что я планирую иметь это как модуль. просто форк или нить основной процесс с параметрами (logfile, filetype). Может быть, в дальнейшем я бы добавил несколько опций, которые не нужно анализировать (может быть, какой-то уровень журнала низкий, и вы просто не видите там mutch)

Ответы [ 3 ]

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

Средство контроля журналов wots может сделать для вас много тяжелой работы. Он работает как демон, просматривая столько файлов журналов, сколько вам нужно, запускает над ними любые комбинации регулярных выражений perl и выполняет что-то при обнаружении совпадений.

Я был бы склонен модифицировать сам wots (что позволяет его лицензия свободно) для поддержки метода записи в базу данных - взглянем на его существующие handle_* методы.

Большая часть тяжелой работы уже сделана для вас, и вы можете заняться интересными моментами.

0 голосов
/ 16 декабря 2011

Я думаю, что File :: Tail хорошо подходит. Вы можете создать массив объектов File :: Tail и опрашивать их с помощью команды select следующим образом:

   while (1) {
       ($nfound,$timeleft,@pending)=
         File::Tail::select(undef,undef,undef,$timeout,@files);
       unless ($nfound) {
              # timeout - do something else here, if you need to
       } else {
           foreach (@pending) {
                # here you can handle log messages depending on filename  
                print $_->{"input"}." (".localtime(time).") ".$_->read;
       }

(из perl File :: Tail doc)

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

Я бы сделал это так:

  1. Создайте файл конфигурации в следующем формате: appname: logpath: logformatname
  2. Создать коллекцию класса Perl, которая наследуется от базового класса синтаксического анализатора.
  3. Напишите скрипт, который загружает файл конфигурации и затем перебирает его содержимое, передавая каждую итерацию соответствующему объекту-обработчику.

Если вам нужен пример шагов 1 и 2, у нас есть один в нашем проекте . См. MT :: FileMgr и MT :: FileMgr :: * здесь .

...