Как считать количество обращений к картинке через nginx?

Question

[pupsor]

Господа, поковырялся сегодня с утра и внятного ничего не нашел. Требуется выводить статистику по обращениям к картинкам, картинки ес-но в статике и не хотелось бы их выдавать по средствам скриптов. Как умные люди считают количество обращений к статичному контенту? Смотрел уже и парсеры логов типа wiki.nginx.org/NginxHttpLogRequestSpeed, но что-то подсказывает, что не самый хороший путь решения задачи.



Вот имеется такой модуль wiki.nginx.org/HttpEchoModule#echo_exec но не знаю на счет быстроты работы. Вообщем, у кого были аналогичные задачи, поделитесь вариантами решения. Заранее благодарю за ответ!

Answer 1

[Sergey]

да нормальный способ с парсингом лога. Заведите отдельный лог для картинок и считайте его.

Comments

[pupsor]

а если разносить на 5 серверов? 10? как быть потом? и нагрузка большая, не две картинки хранится, поэтому и решил спросить.

[Sergey]

что разносить на 5 серверов? Статика лежит на нескольких серваках? Да, считать на всех и аггрегировать отдельной считалкой, т.е. получаем, (скажем раз в сутки) сырые данные из логов каждого сервера (они ведь одинаковые, типовые), пихаем в БД, выводим суммарную статистику.

[Евгени Яблочкин]

надо с минимальными задержками, поэтому парсинг лога раз в сутки в данном случае не очень хороший вариант

[Евгени Яблочкин]

а шустро отслеживать все изменения в логе тоже геморно мне кажется, не знаю на сколько это быстро будет, хотелось бы чтобы при каждом запросе к серверу статики, выполнялся специальный скрипт, который бы и считал всё что нужно

[Sergey]

напишите/найдите сишное приложение для парсинга. Тот же analog у меня распарсивает 30-гигабайтный лог (несколько десятков миллионов строк) за 2-3 минуты. Можно его и использовать, кстати.

Answer 2

[SMiX]

Решение с x_accel_redirect породит кучу постоянных запусков cgi-процессов, а это большая нагрузка на систему.
Лучше, чтобы в системе висел один процесс-демон, который мониторит вывод команды `tail -f /var/log/access.log` и в реальном времени пишет в базу.

Comments

[pupsor]

а есть решения по парсингу логов и отправки в базу? тут такой узкий момент, что самописное может работать хуже чем x_accel_redirect. Спросил у парочке сайтов с очень высокой нагрузкой и ответ был в пользу любителей логов ;)
@pupsor Yup! That's exactly how it's done. Parse logs and count GETs with status code 200.

[SMiX]

Парсить вы можете с помозью grep, awk, чтобы очистить логи от мусора(или ведите отдельный лог в нужно формате для картинок). А скрипт должен получиться очень тривиальный.

[SMiX]

Еще момент: если у вас высокая нагрузка, то не нужно писать в базу каждый раз при получении новой строчки от команды tail. Сделайте буфер с оптимальным для вас числом строк.

Answer 3

[SMiX]

Обратите внимание на Scribe

Scribe is a server for aggregating log data streamed in real time from a large number of servers. It is designed to be scalable, extensible without client-side modification, and robust to failure of the network or any specific machine.

Comments

[pupsor]

очень похоже на решение хорошее, посмотрим-с =) спасибо!

Answer 4

[Tonik]

У нас была несколько другая задача, но я согласен с мнение выше. Лучше всего парсить логи. При помощи syslog-ng мы сделали перенаправление нужных логов на центральный сервер, где небольшой демон парсит логи и вносит данные в бд. Очень удобной.
hint — nginx не умеет пихать данные в syslog. Зато syslog-ng умеет мониторить произвольный лог файл

Comments

[pupsor]

да чего вы к этим логами прилипли) реалтайм нужны данные, а не раз в сутки. даже если каждые 5 минут гонять с 5 серверов логи, то больше вреда будет. решение на поверхности господа, упорный труд и желание дает свои плоды www.opennet.ru/base/net/nginx_x_accel_redirect.txt.html

Answer 5

[Влад Животнев]

cat /var/log/nginx-log-от-картинок-с-секциями | grep чтонибудь | wc -l

Answer 6

[TDz]

Специально для всяких каунтеров была директива post_action которая позволяет указать что будет запускаться после завершения запроса. Там можно подключить встроенный перл, мемкеш, фастцги, что угодно для умного подсчёта. Но если запрашивають часто то вешайте специальный лог на картинки в удобном для парсинга формате и его и парсите раз в X минут. Это с точки зрения нагрузки идеальный вариант. Также есть вариант со встроенными переменными, но больно он муторный