The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

Обеспечение работы системы мониторинга Nagios при помощи Nginx
Web-сервер apache наверное самый лучший web-сервер, но при настройке web-интерфейса для nagios 
можно обойтись и без него, что сейчас и будет описано.

Применительно к FreeBSD:

   portinstall /usr/ports/www/nginx

В /etc/rc.conf.local

   # nginx
   nginx_enable=YES

nginx не может выполнять 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
 
14.10.2008 , Автор: comatoz , Источник: http://opensolution.org.ru/nagios/n...
Ключи: nagios, nginx, web / Лицензия: CC-BY
Раздел:    Корень / Администратору / Сетевые сервисы / WWW, Apache httpd / Редирект, mod_rewrite

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, rusty_angel (?), 13:52, 14/10/2008 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    Зачем городить nginx<->lighttpd<->php, если nginx сам может с php по FastCGI общаться?
     
     
  • 2.2, Gular (ok), 15:16, 14/10/2008 [^] [ответить]    [к модератору]
  • +/
    Правильно. Либо lighttpd использовать один.
    Насколько процесс nginх меньше занимает, чем lighttpd?
     
     
  • 3.3, rusty_angel (?), 15:21, 14/10/2008 [^] [ответить]    [к модератору]
  • +/
    >Правильно. Либо lighttpd использовать один.
    >Насколько процесс nginх меньше занимает, чем lighttpd?

    Не сравнивал. Лайти постепенно превращается (да если честно - уже превратился) в апач с кучей модулей, и он, если мне не изменяет склероз, threaded, поэтому я использую либо nginx либо nginx+apache.

     
     
  • 4.4, одмин (?), 16:16, 14/10/2008 [^] [ответить]    [к модератору]
  • +/
    никогда он не был threaded.
     
     
  • 5.7, rusty_angel (?), 16:43, 14/10/2008 [^] [ответить]    [к модератору]
  • +/
    >никогда он не был threaded.

    Значит ошибаюсь.

     
  • 4.12, User294 (??), 19:46, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >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?

     
  • 3.5, Anton (??), 16:26, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    лайти - глюкалово еще то.
     
     
  • 4.6, rusty_angel (?), 16:42, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >лайти - глюкалово еще то.

    Мы просто готовить его не умеем. Вот в Wikimedia Foundation - умеют.

     
     
  • 5.8, Anton (??), 16:49, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    безотносительно к викимедии, посмотрите на кл-во security updates в Debian дляlighttpd и для nginx.
     
     
  • 6.10, rusty_angel (ok), 17:02, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >безотносительно к викимедии, посмотрите на кл-во security updates в Debian дляlighttpd и
    >для nginx.

    А если помножить эти количества на "долю серверов на рынке"? :)
    Я не защищаю лайти, у самого с ним отношения не сложились: пробовал как-то, и он тёк по-чёрному. Просто объективным быть хочется.

     
     
  • 7.11, Anton (??), 17:41, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    http://survey.netcraft.com/Reports/200809/

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

     
     
  • 8.14, User294 (??), 19:52, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >как реверс-прокси, переходим постепенно на энджинкс.

    Лайт по-моему не особо интересен как реверс-прокси.В этом плане нжинкс явно сильнее.А вот если надо самостоятельный легкий сервер который сможет в разы больше чем апач на том же железе - все с точностью до наоборот, потому что nginx нифига кроме fastcgi не умеет а это порой икается.

     
  • 4.13, User294 (??), 19:49, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >лайти - глюкалово еще то.

    У меня работает как часы на нескольких серверах уже более года.Я что-то делаю не так?

     
     
  • 5.16, Anton (??), 21:38, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    не нагружаете его
     
     
  • 6.18, User294 (??), 23:39, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >не нагружаете его

    Да?Тут как-то сказочники рассказывали про утечки памяти при нагрузке.Ну так вот, я из интереса прогнал тест под нагрузкой с пристрастием - порядка 10 000 000 запросов файлов весом по 10Мб.Двести конекций в параллель, утилиткой http_load из комплекта thttpd (весьма веселый тул который может оперативно и демонстративно отправить в нокаут апача, особенно он на не очень крутой машине, впрочем не только апача - можно доставить веселья любому threaded или fork-based приложению).При этом достигнутая в случае использования локалхоста скорость отгрузки была порядка 9Гбит (весьма заметный процент скорости RAM машины!).Если это не нагрузка - то я пас.Мне как-то больше честное слово, не нужно и в ближайшее время не понадобится(ну не гугл я, не вики и не youtube :D).И что-то я не понял что там должно было работать не так.Память не текла, ничего не падало.Хм.Может быть благородные доны тогда приведут какой-то конкретный пример конфигурации в которой проблемы, версию лайта и прочая?Или под нагрузкой имеется в виду что-то иное?Как минимум статику лайт отгружает тоннами без каких либо проблем по моим наблюдениям.

     
     
  • 7.19, Anton (??), 00:12, 15/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >Да?Тут как-то сказочники рассказывали про утечки памяти при нагрузке.

    Лично фиксил memory-leak. Дальше читать не стал.

     
  • 7.20, Anton (??), 00:38, 15/10/2008 [^] [ответить]    [к модератору]  
  • +/
    дочитал )

    200 параллельных соединений -- это не много, конечно. Надо хотя бы тысячу.

     
  • 7.21, rusty_angel (ok), 00:41, 15/10/2008 [^] [ответить]    [к модератору]  
  • +/
    9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел девять гигабит? Я думал, такие только на лоре встречаются.

     
     
  • 8.22, Anton (??), 01:39, 15/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел
    >девять гигабит? Я думал, такие только на лоре встречаются.

    Я так понял, что это на одном хосте вообще происходило.

     
  • 8.23, User294 (ok), 02:22, 15/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел
    >девять гигабит? Я думал, такие только на лоре встречаются.

    Это был локалхост с 2 ядрами + порядочно оперативы (5Gb).Файло в итоге весьма быстро забуферилось в дисковый кэш а нагрузка от http_load и лайта честно размазалась на 2 ядра, оба жрали примерно поровну CPU. Сетевухи на данную скорость разумеется не было - данные гонялись по локалхосту чтобы посмотреть "а что оно вообще может выжать?" и ускорить по максимуму процесс тестирования на утечки памяти (а вы не заколебетесь ждать пока 10 000 000 запросов 10Мб файлов пропихнутся в реальную сетевуху доступную простым смертным?На гигабите ждать почти вдесятеро дольше в идеальных условиях.А данные сервак 1 фиг одинаково в сокеты пихает - несмотря на синтетичность теста для отлова memleaks он мне кажется ОК).Единственное но - версия была не очень древняя (1.4.18 если не ошибаюсь).А модулей было не особо много.В конце концов меня интересовала именно стабильность и текучесть лайта а не туевой хучи его модулей которые несколько отдельный разговор (текучесть и бажность конкретного модуля это все-таки не текучесть лайта самого по себе, IMHO).Почему 200 конекций?Потому что бОльшее число конекций уже не увеличивало скорость теста а то и делало хуже.В реальной жизни 200 постоянных конекций на сайте еще постараться огрести надо.Это не проблема только для YouTube какого-нибудь да порно-варезных сайтов разве что.

     
     
  • 9.24, rusty_angel (ok), 02:39, 15/10/2008 [^] [ответить]    [к модератору]  
  • +/
    Судя по всему, файлов немного. Не катит, имхо, для тестов. Надо много файлов, разных, плохо кешируемых. Хотя я не знаю, что именно тогда текло (давно было, в каких-то 1.3.х версиях, если не ошибаюсь), может Ваш-то тест и выявил бы тот лик. Сейчас поправили наверняка. Осадок просто остался, а с nginx я лучше, чем с лайти умею обращаться, вот и всё.

    Получить 200 коннектов - не такая уж проблема. Хотя от специфики сильно зависит. Один "мой" (в кавычках - потому что не мой, я его только под нагрузки оптимизировал и чуть-чуть по мелочам доделывал) столько имеет на единственном сервере, а с другой стороны хостинговые серверы с двумя-тремя сотнями сайтов, с которыми я непосредственно по работе вожусь, редко имеют больше  60-80 параллельных коннектов.

     
     
  • 10.27, User294 (??), 22:14, 15/10/2008 [^] [ответить]     [к модератору]  
  • +/
    Штук 20 Цель была сгенерить много запросов т к тогда пипл утверждал что течет ... весь текст скрыт [показать]
     
     
  • 11.28, rusty_angel (ok), 07:56, 16/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >
    >P.S. апача с префорком кстати данный тест выносит в хлам, особенно если
    >файлы не 10 Мб а поменьше.Ему как правило становится очень нехорошо
    >от форка на скорость 200 процессов.А на хилой машине они еще
    >и сжирают всю RAM если админ не ограничил число процессов :D
    >

    Апач тоже надо уметь готовить. В Яху это делать умеют, к примеру. По своему опыту могу сказать, что кроме экстремальных случаев, апач нифига не хуже лайти или nginx. Только процессов больше и top кажется более катастрофическим. Реально нагрузка на железку не сильно отличается.

     
     
  • 12.29, User294 (ok), 08:38, 16/10/2008 [^] [ответить]     [к модератору]  
  • +/
    Угу, обычно эта готовка сводится к тому что на сервер тупо впихивают дофига опер... весь текст скрыт [показать]
     
  • 4.25, Basov E. (?), 16:04, 15/10/2008 [^] [ответить]    [к модератору]  
  • +/
    http://balancer.ru/forum/ работает на lighttpd. Статистику нагрузки можно посмотреть к примеру тут http://www.mapyourvisitors.com/map2537.php
     
     
  • 5.26, Anton (??), 17:55, 15/10/2008 [^] [ответить]    [к модератору]  
  • +/
    речь о высокой нагрузке.
     
  • 2.9, uldus (ok), 16:55, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >Зачем городить nginx<->lighttpd<->php, если nginx сам может с php по FastCGI общаться

    В Nagios нет PHP, там CGI на Си написаны и скомпилированы. Другое дело, что для таких CGI, как в nagios без разницы с точки зрения производительности/расхода памяти на чем их пускать, на по максимуму урезанном apache или на nginx/lighttpd, там же коннектов единицы, keepalive поменьше сделать и все будет ok.

     
     
  • 3.15, User294 (??), 20:03, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >урезанном apache или на nginx/lighttpd, там же коннектов единицы,

    А это от доброжелателей не зависит?А то если оно извне доступно... апачи очень любят когда им на хилой тачке обламывается несколько сот конекций :)

     
     
  • 4.17, uldus (ok), 23:18, 14/10/2008 [^] [ответить]    [к модератору]  
  • +/
    >>урезанном apache или на nginx/lighttpd, там же коннектов единицы,
    >
    >А это от доброжелателей не зависит?А то если оно извне доступно... апачи
    >очень любят когда им на хилой тачке обламывается несколько сот конекций
    >:)

    Кто же систему мониторинга из вне доступной делает, если и делают то с аутентификацией, хитрой точкой входа и лимитом на число соединений.

     
  • 1.30, Df_Yz (ok), 19:18, 10/11/2008 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    А что мешает пустить .cgi через lighttpd?
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:



      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor