Мне нужно проанализировать журналы, созданные веб-сервером Apache2. Я подумываю либо передать журнал в сценарий, который будет просто ждать ввода на стандартный ввод, либо анализировать журналы каждую ночь с помощью пакетного задания.
Одно из моих требований связано с записью некоторой информации в базу данных (например, время выполнения, размер, URI, удаленный IP-адрес). По этой причине я опасаюсь подключаться к сценарию и поддерживать соединение с базой данных открытым. Так что я склоняюсь к ночному анализу.
Кто-нибудь использует такую установку в производственной среде или есть какие-то мысли?
Я бы рекомендовал не использовать канал, потому что при запросе foreach вы потеряете много времени в apache, чтобы передать сценарий и дождаться конца сценария, чтобы освободить ресурс apache. Итак, если по какой-то причине ваша база данных становится очень медленной для выполнения INSERT, у вас могут быть все потоки / процессы apache, которые ждут, пока ваш скрипт завершит вашу работу, и не могут использоваться для обработки нового запроса пользователя.
Вы можете попробовать использовать мод-журнал-sql для входа в базу данных по каждому запросу. Я предпочитаю что-нибудь на ночь, когда у вас меньшая нагрузка, но это зависит от того, насколько актуальными вам нужны данные.
Если вам не нужно обновлять данные в режиме реального времени, у выполнения анализа журналов как ночной работы есть несколько преимуществ:
Вы можете контролировать нагрузку на веб-сервер и сервер базы данных, вызванную анализом журнала, т.е. на него не влияют пики трафика. Вы даже можете переместить свои файлы журналов на другой сервер для анализа после их ротации, если хотите. Это очень полезно, если ваше приложение работает на нескольких веб-серверах.
При необходимости вы можете выполнить агрегирование данных перед их вставкой в базу данных.
Несколько движков баз данных поддерживают некоторую массовую вставку, которая намного быстрее, чем вставка одних и тех же данных по одной записи за раз.
Обработка ошибок (ошибки в коде анализа, недоступность базы данных и т. Д.) Проще - просто повторно запустите тот же сценарий для соответствующих данных журнала после устранения проблемы.
Я уверен, что есть и другие, в зависимости от ваших требований и ситуации с хостингом. Лично я бы даже не стал рассматривать трубопровод от Apache, если обновления в реальном времени не были абсолютными должен, и даже тогда я извлекал только то, что было необходимо в конвейерном сценарии, и обрабатывать все остальное с ночной работой.
Если вам нужно решение, близкое к реальному времени, вам следует рассмотреть возможность использования системы очереди сообщений (например, ActiveMQ, например), и отправлять сообщения в очередь через канал журнала Apache.