Мониторинг nginx

[Stabr]

Может подскажите идейку как это можно делать. Есть задача мониторить состояние фермы seed серверов, которые раздают клиент довольно популярной игры. Раздают они как торрент-трекером, так и через http-сидирование, которое у нас поднято под nginx.

Обычное состояние этих машин "я аццки занят, гигабит сетки забит, диски трещат, залогиниться удается не с первой попытки (пофиг, QoS не настраиваем, паппет срабатывает через 3-4 цикла)".
Все что реально нужно - мониторится, кроме состояния nginx.

nginx_status если дергать с локалхоста курлом выдает
(52) Empty reply from server 19 раз из 20
На 20ый изволит сообщить "мужик, не видишь - я работаю, 1000 коннектов у меня активных - отвали"

Дергается это все юзер-агентом для Заббикса. Понятно что можно просто мониторить запущенность nginx, но это не показатель его работоспособности, задачи именно рисовать число коннектов и если оно падает до нуля - алертить в Заббикс. Дергать 20 раз, потом отрабатывать в Заббиксе максимальное за 10 минут наверное можно, но это ущербный путь.
Второй веб-сервер не предлагать, там он и так уже стоит - для синхронизации сидбоксов используется как раз как вариант своеобразного QoS.
Демон httpdstatus для nginx используем, но у него всего 5 состояний (LOW, NORMAL, HIGH, ULTRA, UNREACHABLE) и последнее может означать что угодно.

Короче, ищу какой-то вариант QoS для nginx_status.

 

[someone]

Вы бы настроили нжинкс сначала, Особо обратите внимание на
worker_processes
worker_connections
worker_rlimit_nofile
и тд.

а лучше дайте ваш конфиг сюда.
И укажите конфигурацию сервера по железу.

 

[Stabr]

Вы бы настроили нжинкс сначала, Особо обратите внимание на
worker_processes
worker_connections
worker_rlimit_nofile
и тд.

а лучше дайте ваш конфиг сюда.
И укажите конфигурацию сервера по железу.

Ну какой конфиг, какой сервер?
Cначала пиши - потом читай

Настройки разные. Как и железо, в принципе. Я писал выше - это ферма серверов, в разных ДЦ, в разных странах. Примерно их штук 30, средний конфиг: 8-12-ядерный Xeon, 24-32Gb ram, софтовый Raid1 на sata дисках, но бывают отклонения в большую или меньшую сторону. Каналы тоже от 10 мегабит до гигабита.

Задача не подобрать оптимальный конфиг, а мониторить в условиях выжранных коннектов. В общем случае оно выставляется так, чтобы соответствовать ширине канала для данного сервера, потому что если скорости у клиента недостаточно - он переключается на CDN, чего мы в общем случае хотим избежать. Ну то есть грубо число коннектов должно соответствовать числу клиентов, качающих с максимальной скоростью и не более того. Если клиентов слишком много на данную толщину канала (завысить число коннектов в n раз и набрать лишних в результате), то они будут качать с меньшей скоростью и в результате переключаться на CDN.

На вопрос "почему сразу все не в CDN" - отвечу, он тоже в схеме есть, но своими раздавать серверами дешевле выходит, поэтому мы предпочитаем чтобы сначала отработали свои, с загрузкой канала пропускания на 100%. В общем случае у нас в заббиксе график по полосе пропускания - это полка.

 

[someone]

Сначала пиши потом читай ? нуну...

Если хотите скушат слона - кушайте его кусочками.

Потому сначала надо видеть конфиг и знать железо (и даже чиспсет сетевухи) того сервера откуда конфиг.
А в идеале и сведения о твиках (если они были) sysctl/сетевого стека.

Иначе вопрос воспринимается как очень сумбурный призыв о помощи, без какой либо конкретики. Как на деревню дедушке.

PS: "выжраные конекты" для нжинкса - уже странно звучит.

 

[100matolog]

А действительно - увеличить количество коннекшенов для nginx? И какая ОС используется на серверах? если BSD то можно тюнить sysctl.conf в направлении количества kern.maxfiles, kern.ipc.maxsockets, kern.ipc.somaxconn

 

[Stabr]

А действительно - увеличить количество коннекшенов для nginx? И какая ОС используется на серверах? если BSD то можно тюнить sysctl.conf в направлении количества kern.maxfiles, kern.ipc.maxsockets, kern.ipc.somaxconn

Центось везде, 6.5ая. Число коннектов увеличить нельзя - результатом станет падение скорости на одного клиента и уход на CDN. Для теста так делали, все классно мониторится, но трафик CDN возрос.

 

[100matolog]

центос - плохой выбор в качестве серверной оси. лучше бы дебиан или опенсьюзи. касательно

станет падение скорости на одного клиента и уход на CDN

- почему вы так уверены? скорость отдачи не должна падать если вы принудительно ее не шейпите.

 

[Stabr]

центос - плохой выбор в качестве серверной оси. лучше бы дебиан или опенсьюзи.

Офигеть, RedHat попал.

Мда, пожалуй на остальное и отвечать смысла нет. Это специфика нашего торрент-клиента.