Web-сервер apache наверное самый лучший web-сервер, но при настройке web-интерфейса для nagios
можно обойтись и без него, что сейчас и будет описано.Применительно к FreeBSD:
portinstall /usr/ports/www/nginx
В /etc/rc.conf.local
# nginx
nginx_enable=YESnginx не может выполнять php и cgi скрипты. Для этого можно использовать backend серверы.
Схема получается следующая:
mini_httpd
---*.cgi---> 192.168.0.200:1081
/
nginx / lighttpd
192.168.0.200:80------*.php---> 192.168.0.200:1082
\
\ Каталог
---*.html--> /usr/local/www/...В этой схеме nginx слущает на порту запросы, производит авторизацию, статические файлы отдает сам,
cgi-скрипты перенаправляет к запущенному на внутреннем порту 127.0.0.1:1081
mini_httpd (/usr/ports/www/mini_httpd), который в свою очередь и выполняет эти скрипты.Схема может показатся сложной, но в моём случае переход на нее оправдался:
опрос nagios производится 1 раз в минуту из Firefox (спец.плагин), и машина с nagios
испытывала некоторые трудности с производительностью. После запуска данной схемы
нагрузка на машину значительно снизилась.Если используется pnp4nagios (http://www.pnp4nagios.org/pnp/install) для построения графиков
производительности сервисов, то выполнение php-скриптов возможно с помощью запущенного
на внутреннем порту 127.0.0.1:1082 lighttpd (/usr/ports/www/lighttpd).Конфигурационные файлы nginx хранятся по умолчанию в /usr/local/etc/nginx/.
/usr/local/etc/nginx/nginx.conf
user www www;
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /var/run//nginx.pid;
worker_rlimit_nofile 8192;events {
worker_connections 4096;
}http {
include mime.types;
include proxy.conf;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] $status '
'"$request" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
server_names_hash_bucket_size 128; # this seems to be required for some vhosts## интранет
server {
listen 192.168.0.200:80;
server_name 192.168.0.200 ns.contora.local;
access_log /var/log/nginx/access.log;
include nagios.conf;
include nagios-pnp.conf;location / {
root /usr/local/www/apache22/data/;
}
include error-pages.conf;
}
}
/usr/local/etc/nginx/nagios.conf
location /nagios/ {
auth_basic "Nagios ";
auth_basic_user_file /usr/local/www/nagios/.htpasswd;
alias /usr/local/www/nagios/;
}location /nagios/cgi-bin/ {
auth_basic "Nagios ";
auth_basic_user_file /usr/local/www/nagios/.htpasswd;proxy_pass http://localhost:1081;
proxy_redirect http://localhost:1081/nagios/cgi-bin/ /nagios/cgi-bin/;set $referer $http_referer;
proxy_set_header Referer $referer;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host localhost:1081;
proxy_set_header REQUEST_METHOD $request_method;
proxy_set_header REMOTE_USER $remote_user;
proxy_set_header REMOTE_ADDR $remote_addr;
proxy_set_header SERVER_NAME localhost;
proxy_set_header SERVER_PORT 1081;
proxy_set_header HTTP_COOKIE $http_cookie;
}
/usr/local/etc/nginx/nagios-pnp.conf
location ~* /pnp/.*\.php$ {
root /usr/local/share/;
fastcgi_pass 127.0.0.1:1082;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/local/nagios/share/$fastcgi_script_name;
include fastcgi_params;
}
location ~* /pnp/ {
root /usr/local/nagios/share/;
index index.php index.html index.htm;
}
/usr/local/etc/nginx/error-pages.conf
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/local/www/nginx-dist;
}
error_page 401 /401.html;
location = /401.html {
root /usr/local/www/nginx-dist;
}
error_page 404 /404.html;
location = /404.html {
root /usr/local/www/nginx-dist;
}Ссылки:
http://sysoev.ru/nginx/
http://www.lighttpd.net/
http://www.acme.com/software/mini_httpd/
http://www.lissyara.su/?id=1532
URL: http://opensolution.org.ru/nagios/nginx
Обсуждается: https://www.opennet.ru/tips/info/1795.shtml
Зачем городить nginx<->lighttpd<->php, если nginx сам может с php по FastCGI общаться?
Правильно. Либо lighttpd использовать один.
Насколько процесс nginх меньше занимает, чем lighttpd?
>Правильно. Либо lighttpd использовать один.
>Насколько процесс nginх меньше занимает, чем lighttpd?Не сравнивал. Лайти постепенно превращается (да если честно - уже превратился) в апач с кучей модулей, и он, если мне не изменяет склероз, threaded, поэтому я использую либо nginx либо nginx+apache.
никогда он не был threaded.
>никогда он не был threaded.Значит ошибаюсь.
>threaded, поэтому я использую либо nginx либо nginx+apache.Лайт не запускает по треду на юзера - какой он нафиг threaded? В нем есть несколько тредов для разных операций.И только.А то так и nginx можно обозвать форкающим - он же может несколько worker-процессов форкнуть.А то что один процесс обслуживает ораву народа можно и не уточнять :)
P.S. схема предложенная тут - оверкилл.Вижу следующие тупняки:
1) PHP можно выполнять через fast-cgi которое nginx умеет.Более того, только через фаст его и надо цеплять т.к. через просто cgi - тормознуто и отстойно.
2) lighttpd если уж его вкорячили умеет и fast-cgi и просто cgi.Если уж CGI натурально надо.А надо оно обычно только для совместимости с старьем которого в другом виде нет.CGI пользоват не стоит потому что его логика работы тормозная по определению (форк процесса для обслуживания запроса).Итого: зачем 3 сервера если можно обойтись одним (все спихнуть на один lighttpd) или, если его буферинг вывода от CGI напрягает (если вы будете таким макаром стримить исошку - памяти выжрется немеряно, что логично) - как максимум, двумя серверами?А нафиг три?Вам не влом будет поддерживать весь зоопарк?Следить за обновлениями, дырами, etc?
лайти - глюкалово еще то.
>лайти - глюкалово еще то.Мы просто готовить его не умеем. Вот в Wikimedia Foundation - умеют.
безотносительно к викимедии, посмотрите на кл-во security updates в Debian дляlighttpd и для nginx.
>безотносительно к викимедии, посмотрите на кл-во security updates в Debian дляlighttpd и
>для nginx.А если помножить эти количества на "долю серверов на рынке"? :)
Я не защищаю лайти, у самого с ним отношения не сложились: пробовал как-то, и он тёк по-чёрному. Просто объективным быть хочется.
http://survey.netcraft.com/Reports/200809/А мы задолбались с этим лайтим уже. По историческим причинам его используем как реверс-прокси, переходим постепенно на энджинкс.
>как реверс-прокси, переходим постепенно на энджинкс.Лайт по-моему не особо интересен как реверс-прокси.В этом плане нжинкс явно сильнее.А вот если надо самостоятельный легкий сервер который сможет в разы больше чем апач на том же железе - все с точностью до наоборот, потому что nginx нифига кроме fastcgi не умеет а это порой икается.
>лайти - глюкалово еще то.У меня работает как часы на нескольких серверах уже более года.Я что-то делаю не так?
не нагружаете его
>не нагружаете егоДа?Тут как-то сказочники рассказывали про утечки памяти при нагрузке.Ну так вот, я из интереса прогнал тест под нагрузкой с пристрастием - порядка 10 000 000 запросов файлов весом по 10Мб.Двести конекций в параллель, утилиткой http_load из комплекта thttpd (весьма веселый тул который может оперативно и демонстративно отправить в нокаут апача, особенно он на не очень крутой машине, впрочем не только апача - можно доставить веселья любому threaded или fork-based приложению).При этом достигнутая в случае использования локалхоста скорость отгрузки была порядка 9Гбит (весьма заметный процент скорости RAM машины!).Если это не нагрузка - то я пас.Мне как-то больше честное слово, не нужно и в ближайшее время не понадобится(ну не гугл я, не вики и не youtube :D).И что-то я не понял что там должно было работать не так.Память не текла, ничего не падало.Хм.Может быть благородные доны тогда приведут какой-то конкретный пример конфигурации в которой проблемы, версию лайта и прочая?Или под нагрузкой имеется в виду что-то иное?Как минимум статику лайт отгружает тоннами без каких либо проблем по моим наблюдениям.
>Да?Тут как-то сказочники рассказывали про утечки памяти при нагрузке.Лично фиксил memory-leak. Дальше читать не стал.
дочитал )200 параллельных соединений -- это не много, конечно. Надо хотя бы тысячу.
9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел девять гигабит? Я думал, такие только на лоре встречаются.
>9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел
>девять гигабит? Я думал, такие только на лоре встречаются.Я так понял, что это на одном хосте вообще происходило.
>9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел
>девять гигабит? Я думал, такие только на лоре встречаются.Это был локалхост с 2 ядрами + порядочно оперативы (5Gb).Файло в итоге весьма быстро забуферилось в дисковый кэш а нагрузка от http_load и лайта честно размазалась на 2 ядра, оба жрали примерно поровну CPU. Сетевухи на данную скорость разумеется не было - данные гонялись по локалхосту чтобы посмотреть "а что оно вообще может выжать?" и ускорить по максимуму процесс тестирования на утечки памяти (а вы не заколебетесь ждать пока 10 000 000 запросов 10Мб файлов пропихнутся в реальную сетевуху доступную простым смертным?На гигабите ждать почти вдесятеро дольше в идеальных условиях.А данные сервак 1 фиг одинаково в сокеты пихает - несмотря на синтетичность теста для отлова memleaks он мне кажется ОК).Единственное но - версия была не очень древняя (1.4.18 если не ошибаюсь).А модулей было не особо много.В конце концов меня интересовала именно стабильность и текучесть лайта а не туевой хучи его модулей которые несколько отдельный разговор (текучесть и бажность конкретного модуля это все-таки не текучесть лайта самого по себе, IMHO).Почему 200 конекций?Потому что бОльшее число конекций уже не увеличивало скорость теста а то и делало хуже.В реальной жизни 200 постоянных конекций на сайте еще постараться огрести надо.Это не проблема только для YouTube какого-нибудь да порно-варезных сайтов разве что.
Судя по всему, файлов немного. Не катит, имхо, для тестов. Надо много файлов, разных, плохо кешируемых. Хотя я не знаю, что именно тогда текло (давно было, в каких-то 1.3.х версиях, если не ошибаюсь), может Ваш-то тест и выявил бы тот лик. Сейчас поправили наверняка. Осадок просто остался, а с nginx я лучше, чем с лайти умею обращаться, вот и всё.Получить 200 коннектов - не такая уж проблема. Хотя от специфики сильно зависит. Один "мой" (в кавычках - потому что не мой, я его только под нагрузки оптимизировал и чуть-чуть по мелочам доделывал) столько имеет на единственном сервере, а с другой стороны хостинговые серверы с двумя-тремя сотнями сайтов, с которыми я непосредственно по работе вожусь, редко имеют больше 60-80 параллельных коннектов.
>Судя по всему, файлов немного.Штук 20. Цель была сгенерить много запросов т.к. тогда пипл утверждал что течет на каждый запрос - вот это и хотелось проверить.Проверил.Для как минимум базовой части сервака и несложного набора модулей и свежей на момент тестов версии 1.4.18 - не подтвердилось.
>Не катит, имхо, для тестов.
Тесты бывают разные.Если цель теста - посмотреть как сервак поведет себя на большом числе запросов и не потечет ли память - по-моему, мой тест вполне адекватен.Как минимум, гипотеза что lihgttpd сам по себе смущает большое число запросов - не подтверждается.Может быть тек какой-то модуль или при каких-то настройках или при специфичных запросах?Или сто лет починено, поскольку при раздаче файла вики и ютубом они должны были бы мягко говоря заметить саму по себе утечку памяти на отгрузке файла - при их объемах отгрузки она должна быть ДИКАЯ :)
>Надо много файлов,
Кому надо?Зачем?И что это даст?Не вижу почему если память не течет на 20 файлах то вдруг потечет на 200 или 2000 или сколько там еще?Я где-то не прав?Что изменится?
>разных, плохо кешируемых.
Плохо кешируемых?А что это даст для такого теста?Кроме тормозов.Ну, скорость проведения теста замедлится в несколько раз.А что от этого изменится в условиях работы программы?В конечном итоге файл читает система по системному вызову.Попало оно в дисковый кэш или нет лайт вообще по идее не знает - его дело маленькое, нужные системные вызовы дернуть.А попало оно там в кэш или нет - вообще не его дело в общем случае.
>Хотя я не знаю, что именно тогда
>текло (давно было, в каких-то 1.3.х версиях, если не ошибаюсь), может
>Ваш-то тест и выявил бы тот лик.1.3.x я не использовал.Начал его юзать эээ ... с версии 1.4.13, чтоли.А тестил лик на 1.4.18 - что-то не натестилось нифига.Недавно они кстати прибили забавный лик при duplicate хидерах в HTTP запросе, кажись.Но это уже экзотика.
>Сейчас поправили наверняка. Осадок
>просто остался, а с nginx я лучше, чем с лайти умею
>обращаться, вот и всё.Судя по списку рассылки в нжинксе тоже есть много разных интересных багов и еще больше разных интересных багов поправлено :-).Почему-то у народа часто и красочно падают воркеры например.Я правда такого не встречал(но если честно то особо и не злобствовал - специальных краш-тестов не проводил).Правда я больше лайт юзаю, т.к. в моих конфигурациях никаких граблей у меня нет.
>Получить 200 коннектов - не такая уж проблема. Хотя от специфики сильно
>зависит.Хм.Для обычного сайта простого смертного это подразумевает популярность здорово выше средней.Для такого как правило надо как попасть на слэшдот или что-то типа того.
>а с другой стороны хостинговые серверы с двумя-тремя сотнями сайтов,
>с которыми я непосредственно по работе вожусь, редко
>имеют больше 60-80 параллельных коннектов.Ну вот и я о чем.
P.S. апача с префорком кстати данный тест выносит в хлам, особенно если файлы не 10 Мб а поменьше.Ему как правило становится очень нехорошо от форка на скорость 200 процессов.А на хилой машине они еще и сжирают всю RAM если админ не ограничил число процессов :D
>
>P.S. апача с префорком кстати данный тест выносит в хлам, особенно если
>файлы не 10 Мб а поменьше.Ему как правило становится очень нехорошо
>от форка на скорость 200 процессов.А на хилой машине они еще
>и сжирают всю RAM если админ не ограничил число процессов :D
>Апач тоже надо уметь готовить. В Яху это делать умеют, к примеру. По своему опыту могу сказать, что кроме экстремальных случаев, апач нифига не хуже лайти или nginx. Только процессов больше и top кажется более катастрофическим. Реально нагрузка на железку не сильно отличается.
>Апач тоже надо уметь готовить.Угу, обычно эта готовка сводится к тому что на сервер тупо впихивают дофига оперативы под зиллионы тредов или процессов апача и хренадцать процессоров.Спасибо, я гайд по оптимизации апача читал - после его прочтения сложилось стойкое ощущение что они борятся с проблемами которых у других изначально нет.Да и то что нагруженные сайты уважают лайт и нжинкс наводит на такие мысли.
>В Яху это делать умеют, к примеру.
Будучи яхой можно позволить себе парк серверов пожирнее, кучу процессоров, оперативки дофигища и прочая.И там даже апач может вольготно форкать свое добро в свое удовольствие.
Но случаи бывают разные.Например, на VDS больше оперативки == больше цена.Или вон та машина - уже есть и оперативки в ней вот столько и баста.Ну и так далее.Так по опыту - если оперативка ограничена, с апачом все сводится к двум вариантам: или неограниченый форкинг или трединг выжирает RAM или, если ограничить число воркеров, как только число соединений растет - все начинает работать медленно и печально.Что в общем то чертовски логично и предсказуемо.С другой стороны, лайт или нжинкс и на такой конфигурации пашут крайне ядрено.Так что завалить их параллельными даунлоадами на такой конфигурации... нуууу... это будет нелегко.Им на доступный объем оперативки как-то пофиг почти из-за особенностей конструкции.
>По своему опыту могу сказать, что кроме экстремальных случаев, апач нифига
>не хуже лайти или nginx.Смотря что считать за экстремальный случай.Видел дофига случаев когда замена апача на лайт или нжинкс буквально вдыхала в хилый и медленный сервак новую жизнь - он после этого становится уже ни разу не хилый и не медленный.А если вы корпорация яху - конечно фигня вопрос - ставим побольше серваков понавороченнее да и все дела.Только вот такой подход для простых смертных зачастую не катит потому что для этого требуется толстый кошелек.
>Только процессов больше и top кажется более катастрофическим.
Ага, а оперативка тоннами случайно не жрется заодно?Или это только кажется?На отдаче статики в большинстве случаев лайт и нжинкс вообще апача обидят с неприятным для него счетом, имхо :).А то у неподготовленных админов с не очень крутыми серверами апач если туда пустить http_load своими сотнями процессов выжирает оперативку и ставит систему колом.Внушительное зрелище :).Можно конечно настройками число воркеров урезать.Но тогда начнет тормозить отгрузка контента юзерам.
>Реально нагрузка на железку не сильно отличается.
Ну, вообще-то, потребление RAM отличаятся изрядно.В этом злом тесте на 200 конекция и 10M аплоадов лайт обошелся ~4Mb RAM.Я что-то здорово сомневаюсь что апач сможет столько же отгрузить треская столько же RAM.У меня после попытки покрутить его параметры сложилось ощущение что нормально работать он может только на супер-серверах с кучей ядер и дофигища оперативки.Если вдруг что-то меньше то получается tradeoff между тормозами и выжиранием невъ...нного объема оперативки.И кстати на дворе год 2008.Железка?Хм.А вы слово "виртуализация" слышали?А то оно довольно актуально в 2008 году.Удобно, эффективно по ценам, позволяет ряд весьма эффектных и эффективных фокусов типа сохранения состояний или live-миграции ну и все такое :)
http://balancer.ru/forum/ работает на lighttpd. Статистику нагрузки можно посмотреть к примеру тут http://www.mapyourvisitors.com/map2537.php
речь о высокой нагрузке.
>Зачем городить nginx<->lighttpd<->php, если nginx сам может с php по FastCGI общатьсяВ Nagios нет PHP, там CGI на Си написаны и скомпилированы. Другое дело, что для таких CGI, как в nagios без разницы с точки зрения производительности/расхода памяти на чем их пускать, на по максимуму урезанном apache или на nginx/lighttpd, там же коннектов единицы, keepalive поменьше сделать и все будет ok.
>урезанном apache или на nginx/lighttpd, там же коннектов единицы,А это от доброжелателей не зависит?А то если оно извне доступно... апачи очень любят когда им на хилой тачке обламывается несколько сот конекций :)
>>урезанном apache или на nginx/lighttpd, там же коннектов единицы,
>
>А это от доброжелателей не зависит?А то если оно извне доступно... апачи
>очень любят когда им на хилой тачке обламывается несколько сот конекций
>:)Кто же систему мониторинга из вне доступной делает, если и делают то с аутентификацией, хитрой точкой входа и лимитом на число соединений.
А что мешает пустить .cgi через lighttpd?