центральный анализ журналов Apache для многих хостов [закрыто]
У нас есть 30+ серверов apache httpd, и мы хотим выполнить анализ журналов как на предмет исторического тренда, так и на мониторинг / оповещение в режиме реального времени.Меня в основном интересуют такие вещи, как частота ошибок (4xx / 5xx), время отклика, общая частота запросов и т. Д., Но также было бы очень полезно получить статистику, требующую более интенсивных вычислений, такую как уникальные IP-адреса клиентов и пользовательские агенты на единицу время.
Я склоняюсь к созданию централизованного сборщика / сервера / хранилища, а также рассматриваю возможность хранения журналов, не относящихся к Apache (то есть общих журналов системного журнала, журналов брандмауэра и т. Д.) В той же системе.
Очевидно, что большая часть этого, вероятно, должна быть настраиваемой (по крайней мере, связь между частями и анализ / анализ, который мы делаем), но я не смог найти много информации о людях, которые делали такие вещи , по крайней мере, в магазинах меньше, чем Google / Facebook и т. д. которые могут перебросить свои данные журнала в вычислительный кластер из ста узлов и запустить на нем Map / Reduce.
Главное, что я ищу:
- Все с открытым исходным кодом
- Какой-то способ сбора журналов с компьютеров Apache, который не слишком ресурсоемкий, и относительно быстро транспортирует их по сети
- Какой-то способ их хранения (NoSQL? Хранилище ключей и значений?) На бэкэнде в течение заданного времени (с последующим преобразованием их в исторические средние значения)
- Посередине - способ построения графиков почти в- в реальном времени (возможно, также с некоторым статистическим анализом) и, надеюсь, с предупреждением об этих графиках.
Любые предложения / указатели / идеи в отношении «продуктов» / проектов или описания того, как это делают другие люди, были бы очень полезны. К сожалению, мы не совсем магазин DevOps нового века, много старых вещей, однородная инфраструктура и перегруженные коробки.
rsyslog может работать довольно хорошо, и если объем данных, которые вы пытаетесь записать, достаточно мал, вы можете даже использовать бесплатную версию Splunk . Полная версия, вероятно, является более комплексным решением, которое, возможно, соответствует тому, что вы хотите достичь, и сэкономит вам время на разработку собственных инструментов мониторинга.
В моей работе мы просто придерживаемся syslogd, Nagios и Ganglia для все наши потребности в мониторинге, поскольку даже с 600 или около того машинами все они невероятно стабильны.
If you're looking to set up a general purpose syslog server I'd definitely recommend you have a look at rsyslog, it's a very powerful modern syslog implementation. One of the things I like about it is that it can log to a relational database rather than to flat files, which makes data crunching a lot easier.
I've never used syslog with Apache, so I can't help with that part of your question unfortunately.
Это не такое общее решение, как вы просили, но, вспоминая сеанс лондонской конференции PHP, BBC заявила, что у них есть хитрый способ передачи файлов журналов Apache из многих с серверов на центральный сервер в реальном времени, я думаю, они назвали его телепортом.
Я не могу вспомнить точных деталей, но суть заключалась в том, что у них был небольшой скрипт автоматического перезапуска, работающий на каждом из серверов apache, который в основном открыл именованный канал fifo с именем / var / log / apache2 / access_log и использовал netcat, чтобы скопировать его на уникальный порт tcp на серверах журналов. Затем серверы журналов снова поместили его обратно в /var/log/myApacheServer/access_log.
. С осторожностью этот подход также будет работать для общих файлов системного журнала, хотя может потребоваться первоначальная синхронизация во время запуска системы.
Если ты' Если нормально работать с полуреальным временем, то я бы выбрал гораздо более простое решение: ротацию файлов журналов каждые n минут и их синхронизацию с центральным сервером в [postrotate].
Многие пакеты веб-статистики, такие как awstats и другие, предполагают, что файлы журналов отсортированы, поэтому что-то вроде logresolvemerge.pl от awstats может быть полезным препроцессором на logServer: / var / log / * / access_log перед тем, как вы запустите любую статистику, которая вам нужна по результатам.
Cacti будет рисовать нужные вам графики с помощью rrdtool, но вам нужно будет кормить его из данных, собранных из внутренних файлов данных веб-статистики, которые, на мой вкус, немного неструктурированы.
Этот подход можно использовать в сценариях, но при большом количестве виртуальных хостов он станет утомительным, так как вы получите число TCP-потоков vhosts * serverCount.
Это все основано на файловой системе, так что в современном мире немного неаккуратно, извините.
Джейсон, вы упомянули интерес к использованию Ganglia для мониторинга ваших веб-серверов Apache. Рассматривали ли вы возможность использования mod-sflow с Ganglia?
Использование Ganglia для мониторинга веб-ферм
Недавно были добавлены метрики active, idle, max worker. Хотя Ganglia отлично подходит для анализа трендов кластерных метрик, вам нужно будет использовать анализатор журналов для получения подробных данных журнала. mod-sflow отправляет данные счетчиков и журналов в виде структур в двоичной кодировке XDR по UDP. Вы можете использовать sflowtool для преобразования двоичных данных в стандартные журналы ASCII или как основу вашего собственного инструмента анализа.