Как вы обрабатываете биллинг пропускной способности на общих серверах в Apache?

Question

Какие решения у вас есть для обработки биллинга полосы пропускания для ваших vhosts в общей среде в apache? Если вы используете разбор журналов, хорошо ли масштабируется ваше решение, когда журналы становятся очень очень большими? Кто-нибудь использует какой-либо модуль для этого?

Answer 1

Если у виртуального хоста нет собственного IP-адреса, нет более простого способа, чем анализ файла журнала. Просто используйте mod_logio для вычисления фактических переданных байтов. mod_logio правильно обрабатывает разорванные соединения, сжатые данные и т. д. Вы должны иметь возможность анализировать журналы в реальном времени, используя конвейерные журналы . Используйте BufferedLogs для дальнейшего масштабирования (просто убедитесь, что анализатор обрабатывает строки, разбитые при правильной буферизации). Парсер должен периодически сохранять данные (как каждую минуту) где-нибудь, просто избегайте проблем с блокировкой, так как синтаксический анализ не должен замедлять httpd. Если httpd-соединения проводят время в L-состоянии в состоянии сервера, вы слишком медлительны. После того, как у вас есть числа, вы можете суммировать их, а затем сохранять данные в биллинговой системе.

Если вы также сохраните журналы выставления счетов в виде файлов, вы можете исправить и перепроверить расчеты трафика в реальном времени. Если вы загрузите httpd, вы можете пропустить некоторые строки. Но, как правило, потеря нескольких сотен запросов является приемлемой, так как она стоит меньше секунды на крупномасштабном сайте.

Существуют модули, которые пытаются обрабатывать и ограничивать пропускную способность, такие как mod_cband и mod_bw. Но они не работают, если у вас есть один и тот же виртуальный хост на нескольких машинах. Я думаю, они будут работать нормально в меньших масштабах.

Если у вас есть IP для каждого хоста, вы можете попробовать методы, основанные на IP, такие как передача журналов брандмауэра в калькулятор трафика. Простой способ - использовать iptables .

Answer 2

Вы можете пойти по пути бедняка и использовать Webalizer или Awstats. Оба из них дадут вам представление о трафике, основанном на журналах доступа, и могут быть выполнены для каждого виртуального хоста. Что касается Awstats, я знаю, что когда вы начинаете ежедневно обрабатывать более 10 ГБ трафика, он начинает потреблять ресурсы. Вы всегда можете это сделать, но тогда вы получите данные на следующей неделе, а не тогда, когда они вам действительно нужны. В прошлом с Webalizer мне приходилось использовать хакеры, чтобы заставить его обрабатывать большие журналы доступа, разбивая журналы на более мелкие части, которыми он мог бы управлять. Он не предоставил столько полезных метрик из того, что я сделал с ним, но мне также никогда не нужно было спасать сервер от него:)

Answer 3

Существуют определенные модули для Apache 1.x и 2.x, которые позволят вам установить максимальную сумму перевода, большинство из них отслеживают, используя файл табло, который генерирует Apache (когда mod_status включен с ExtendedStatus включен) , Когда я искал одну из них, я все же добавил закладку mod_curb , однако она не завершена и в настоящий момент работает только в масштабе сервера, а не на отдельных виртуальных хостах. .

Модули Apache могут быть установлены как исходящие фильтры, так что вы можете написать костюмный модуль, который будет располагаться в конце цепочки, и сложить все исходящие пакеты, используя данные, которые предоставляет APR, затем вы можете добавить их в счетчик для этого конкретного домена / субдомена. После этого у вас есть выбор, что делать с данными.

В качестве конкретных примеров, посмотрите на mod_deflate, который предоставляет Apache, чтобы увидеть, как он находится в конце цепочки и сжимает все, кроме заголовков, которые отправляет сервер. Это должно дать вам хорошее начало.

Что касается обработки на основе журналов, она становится медленнее, чем больше журналов существует. Это просто природа зверя. Когда мы использовали решение на основе журналов, у нас был собственный Perl-скрипт, который запускался каждые 15 минут. В конечном счете, для анализа потребовалось бы больше 15 минут, и, поскольку через некоторое время у нас была правильная блокировка, несколько из этих сценариев perl для обработки журналов работали, все ожидали друг друга. В итоге мы переписали его простым вызовом tail -F, который затем позволил perl анализировать каждый запрос по мере его поступления, хотя он и не был полностью эффективным, он работал. Плюсом этого стало то, что теперь мы можем обновлять статистику трафика практически в реальном времени, чтобы клиенты обновлялись раньше, а не позже, если они выходили за пределы.

Answer 4

Хорошо, что mod_cband был бы хорош, за исключением того, что когда я его использую, max_connections (общее, общее значение для каждого клиента в совокупности) решает ползти вверх, пока не достигнет максимального значения, которое я установил. когда он достигает наивысшего значения, он просто остается там и оставляет всех моих клиентов, получающих постоянную ошибку «503 Сервис временно недоступен».

например, я установил «CbandSpeed ​​1000Mbps 500 1200», и соединения с сервером обходятся до 1200 примерно за 8 часов, а затем остаются там. на этом этапе я подсчитываю общее количество соединений в разделе «Удаленные клиенты» в окне состояния mod_cband и вижу около 50. Я также использовал ps aux и вижу примерно такое же количество (~ 50) открытых http-процессов, что нормально, за исключением того факта, что никто не может получить доступ к сайту вообще из-за ошибок 503.

Есть идеи, что может быть не так, или это можно исправить?

Answer 5

Это может быть легко достигнуто с помощью mod_cband. Мы переписали модуль, чтобы исправить несколько ошибок, обеспечить истинную избыточность при перезапусках и включить статистику FTP и почты.

http://www.howtoforge.com/mod_cband_apache2_bandwidth_quota_throttling

Answer 6

Хотя мы используем IIS, а не apache, мы используем анализ файла журнала для выставления счетов за пропускную способность (и профилирование / анализ пропускной способности). Мы используем пользовательское приложение для загрузки данных, собранных в файлах журналов, с шагом в один час, и действуем при любых необходимых уведомлениях или превышении полосы пропускания.

Загрузчик файлов журнала работает как процесс с низким приоритетом, чтобы не прерывать работу сервера. Даже на серверах с высокой нагрузкой и большим количеством сайтов обработка занимает менее 15 минут, поэтому мы не рассматриваем масштабируемость как проблему с этой методологией.

Возможно, есть лучшие способы сделать это, но этого вполне достаточно для того, что нам нужно. Я с нетерпением жду просмотра других ответов.