У нас есть 30+ серверов apache httpd, и мы стремимся выполнять анализ журналов как на предмет исторических тенденций, так и на мониторинг / оповещение в режиме реального времени. Меня в основном интересуют такие вещи, как частота ошибок (4xx / 5xx), время отклика, общая частота запросов и т. Д., Но также было бы очень полезно получить статистику, требующую более интенсивных вычислений, такую как уникальные IP-адреса клиентов и пользовательские агенты на единицу время.
Я склоняюсь к созданию этого централизованного сборщика / сервера / хранилища, а также рассматриваю возможность хранения журналов, отличных от Apache (то есть общих журналов системного журнала, журналов брандмауэра и т. Д.) В той же системе.
Очевидно, большая часть этого, вероятно, должна быть индивидуализирована (по крайней мере, связь между частями и анализ / анализ, который мы делаем), но я не смог найти много информации о людях, которые делали такие вещи, по крайней мере в магазинах меньше, чем Google / Facebook и т. д. которые могут перебросить свои данные журнала в вычислительный кластер из ста узлов и запустить на нем Map / Reduce.
Главное, что я ищу:
Любые предложения / указатели / идеи относительно «продуктов» / проектов или описания того, как это делают другие люди, были бы очень полезны. К сожалению, мы не совсем магазин DevOps нового века, много старых вещей, однородная инфраструктура и перегруженные коробки.
Джейсон, вы упомянули об интересе к использованию Ganglia для мониторинга ваших веб-серверов Apache. Вы рассматривали возможность использования mod-sflow с Ganglia?
Использование Ganglia для мониторинга веб-ферм
Недавно были добавлены метрики active, idle, max worker. Хотя Ganglia отлично подходит для отслеживания трендов кластерных метрик, вам нужно будет использовать анализатор журналов для создания отчетов по подробным данным журнала. mod-sflow отправляет данные счетчиков и журналов в виде структур в двоичной кодировке XDR по UDP. Вы можете использовать sflowtool для преобразования двоичных данных в стандартные журналы ASCII или как основу вашего собственного инструмента анализа.
rsyslog может работать довольно хорошо, и если объем данных, которые вы пытаетесь записать, достаточно мал, вы можете даже использовать бесплатную версию Splunk. Полная версия, вероятно, является более комплексным решением, которое, возможно, соответствует тому, что вы хотите достичь, и сэкономит вам время на разработку собственных инструментов мониторинга.
Однако в моей работе мы просто придерживаемся syslogd, Nagios и Ganglia для всех наших потребностей в мониторинге, поскольку даже с 600 или около того компьютерами все они невероятно стабильны.
Если вы хотите настроить сервер системного журнала общего назначения, я определенно рекомендую вам взглянуть на rsyslog, это очень мощная современная реализация системного журнала. Что мне нравится в нем, так это то, что он может вести журнал в реляционной базе данных, а не в плоских файлах, что значительно упрощает обработку данных.
Я никогда не использовал системный журнал с Apache, поэтому, к сожалению, я не могу помочь с этой частью вашего вопроса.
Вы можете дать LogZilla попытка. Это на 99% открытый исходный код (один файл - нет). Это чрезвычайно быстро и очень дешево по сравнению с другими решениями этого класса.
Это не такое общее решение, как вы просили, но, вспоминая сеанс лондонской конференции 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.
Однако все это основано на файловой системе, так что в современном мире это немного не технологично, извините.