Вопросы Теги

Веб-Синтаксический анализатор Журнала для mod_log_sql

Без любых религиозных намерений: Я могу настоятельно рекомендовать использование распределенного VCS, предпочтительно Базар. Это вызвано тем, что:

  • Базар легко установить (на Ubuntu и серверах Debian, из которых это является просто вопрос apt-get install bzr)
  • Легко установить и начать:
cd /etc
bzr init .
bzr add .
bzr commit . -m "Initial configuration"
  • Никакая установка сервера не требуется. Базар может соединить и продвинуть в удаленный репозиторий без любого удаленного выполнения сервера Базара. Будет работать отлично с любым FTP-сервером или WebDAV, и т.д.

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

2
задан 17 July 2009 в 23:58
2 ответа

Существует сценарий PHP под названием Skeith, который делает то, что Вы хотите.

Пойдите сюда для загрузки http://skeith.sourceforge.net/

Вот надрез от сайта:

Skeith является простым журналом анализатор и генератор отчетов. А именно, Skeith работает на mod_log_sql модуль для Apache (он должен работать на mod_log_mysql также, но к настоящему времени тестирование было только сделано с mod_log_sql).

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

2
ответ дан 3 December 2019 в 12:26

Я не рекомендовал бы хранить, входит в систему любой вид базы данных SQL. Механизмы устройства хранения данных SQL просто не подходят для этого, когда объем данных увеличивается (поскольку он, конечно, будет приблизительно с 1 000 виртуальных хостов), скорость записи пострадает от серьезного замедления. Удаление от базы данных является также болезненной операцией, поскольку таблица станет фрагментированной, далее увеличивающаяся задержка чтения-записи и уменьшит скорость.

Это, который Вы настаиваете, храня, входит в базу данных SQL, необходимо будет приложить все усилия отфильтровывание такого же количества неважных данных так, Вы можете.

0
ответ дан 3 December 2019 в 12:26
  • 1
    На самом деле даже довольно основные машины (например, ноутбуки) могут сделать ~100k строки минута, регистрируясь к MySQL. Да это добавляет наверху, но действительно не так очень. –  LapTop006 18 July 2009 в 16:52
  • 2
    согласитесь с вышеупомянутым комментарием: Мы используем postgreSQL для входа наших блогов, и у нас есть два сервера PostgreSQL с помощью RAID10, чтобы обработать апачские журналы, среди других баз данных, зарегистрироваться для более чем 900 веб-сайтов через 6 серверов. Если/Когда мы сталкиваемся с проблемой производительности базы данных, там кэшируют инструменты, доступные, такие как PGPOOL и КЭШ-ПАМЯТЬ для баз данных. Хотя, asadmin' s точка допустимо в этом, она имеет потенциал, чтобы быть узким местом если не контролируемый и/или установка правильно. –  Kilo 18 July 2009 в 17:39
  • 3
    LapTop006: конечно, сырые данные пишущий базу данных возможны с невероятной скоростью (как долго, поскольку индексы не используются, и данные не удалены), но как только данные удалены (фрагментированные таблицы) или индексируют представленный (вставка кошмара), или довольно простой " like" сравнение строк происходит (помните, необработанный текст), база данных оказывается бесполезной. Конечно, архивация от таблиц SQL является болью, поскольку никто не хотел бы позволить базе данных SQL вырасти навсегда. Архивация также означает удаление, таким образом, фрагментированные таблицы вернулись в бизнесе... –  asdmin 20 July 2009 в 14:53

Теги

Похожие вопросы