Центральный анализ логов Apache многих хостов
У нас есть более 30 серверов Apache httpd, и мы собираемся выполнить анализ журналов как для отслеживания исторических событий, так и для мониторинга в режиме реального времени. В основном меня интересуют такие вещи, как частота ошибок (4xx/5xx), время отклика, общая частота запросов и т. Д., Но было бы также очень полезно извлечь статистику, требующую больших вычислительных ресурсов, например уникальные клиентские IP-адреса и пользовательские агенты на единицу время.
Я склоняюсь к созданию этого централизованного сборщика / сервера / хранилища, а также рассматриваю возможность хранения журналов, не относящихся к Apache (т. Е. Общих журналов системного журнала, журналов брандмауэра и т. Д.) В одной и той же системе.
Очевидно, что большая часть этого, вероятно, должна быть нестандартной (по крайней мере, связь между частями и анализом / анализом, который мы проводим), но я не смог найти много информации о людях, которые сделали такие вещи, по крайней мере, в магазинах меньше, чем Google/Facebook/ и т. д. кто может выбросить свои данные журнала в вычислительный кластер из ста узлов и запустить на нем Map/Reduce.
Основные вещи, которые я ищу:
- Все с открытым исходным кодом
- Какой-то способ сбора журналов с компьютеров Apache, который не слишком ресурсоемкий и относительно быстро переносит их по сети
- Какой-то способ их хранения (NoSQL "хранилище значений ключей") на сервере в течение заданного промежутка времени (а затем сведение их в средние значения за прошлые периоды)
- В середине этого - способ построения графиков в режиме, близком к реальному времени (возможно, также с некоторым статистическим анализом) и, как мы надеемся, оповещение об этих графиках.
Любые предложения / указатели / идеи относительно "продуктов"/ проектов или описания того, как другие люди делают это, были бы очень полезны. К сожалению, мы не совсем новый магазин, у которого много старых вещей, однородная инфраструктура и напряженные коробки.
5 ответов
rsyslog может работать довольно хорошо, и если объем данных, которые вы пытаетесь зарегистрировать, достаточно мал, вы даже можете избежать использования бесплатной версии Splunk. Полная версия, вероятно, является более комплексным решением, которое, возможно, соответствует тому, что вы хотите достичь, экономя ваше время на разработку собственных инструментов для внутреннего мониторинга.
На моей работе мы просто придерживаемся syslogd, Nagios и Ganglia для всех наших потребностей в мониторинге, поскольку даже с 600 или около того машинами все они невероятно стабильны.
Джейсон, вы упомянули интерес к использованию Ganglia для мониторинга ваших веб-серверов Apache. Вы рассматривали возможность использования mod-sflow с Ganglia?
Использование Ganglia для мониторинга веб-ферм
Недавно были добавлены активные, неактивные, максимальные рабочие метрики. Несмотря на то, что Ganglia отлично подходит для отслеживания метрик кластера, вам потребуется использовать анализатор журналов для составления отчетов о подробных данных журналов. mod-sflow отправляет данные счетчика и журнала в виде двоичных структур в кодировке XDR по UDP. Вы можете использовать sflowtool для преобразования двоичных данных в стандартные журналы ASCII или в качестве основы вашего собственного инструмента анализа.
Если вы хотите настроить сервер системного журнала общего назначения, я определенно рекомендую вам взглянуть на rsyslog, это очень мощная современная реализация системного журнала. Одна из вещей, которые мне нравятся, это то, что он может регистрировать данные в реляционной базе данных, а не в плоских файлах, что значительно упрощает анализ данных.
Я никогда не использовал системный журнал с Apache, поэтому я не могу помочь с этой частью вашего вопроса, к сожалению.
Вы можете попробовать LogZilla. Это 99% с открытым исходным кодом (один файл нет). Это очень быстро и очень дешево по сравнению с другими решениями в этом классе.
Это не такое общее решение, как вы просили, но, вспоминая сессию лондонской конференции PHP, BBC заявили, что у них есть хитрый способ передачи файлов журнала apache со многих серверов на центральный сервер в режиме реального времени. думаю, они прозвали его телепортом.
Я не могу вспомнить точные детали, но суть заключалась в том, что у них был небольшой скрипт автозапуска, работающий на каждом из серверов apache, который в основном открыл канал с именем fifo с именем /var/log/apache2/access_log и использовал netcat для копирования это уникальный порт TCP на серверах журналов. Затем серверы журналов снова отправили его обратно в / var / log / myApacheServer / access_log.
С осторожностью этот подход будет работать и для общих файлов системного журнала, хотя может потребоваться первоначальная синхронизация во время запуска системы.
Если вы в порядке с полу-реальным временем, я бы выбрал гораздо более простое решение - вращать файлы журнала каждые n минут и пересылать их на центральный сервер в [postrotate].
Многие пакеты webstats, такие как awstats и friends, предполагают, что файлы журналов отсортированы, поэтому что-то вроде awstats 'logresolvemerge.pl может быть полезным препроцессором на logServer: / var / log / * / access_log, прежде чем вы запустите любую статистику, которая вам требуется в Результаты.
Cacti будет рисовать графики, которые вы ищите, с помощью rrdtool, но вам нужно будет получать их из данных, извлеченных из внутренних файлов данных веб-статистики, что немного неструктурировано для моих вкусов.
Этот подход пригоден для написания сценариев, но с большими количествами виртуальных хостов он станет утомительным, так как вы получите число TCP-потоков vhosts * serverCount.
Хотя все это основано на файловой системе, так что в современном мире это не слишком технологично, извините.