The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Раздел полезных советов: Обеспечение работы системы монитори..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Обеспечение работы системы монитори..."  
Сообщение от auto_tips on 14-Окт-08, 13:52 
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


URL: http://opensolution.org.ru/nagios/nginx
Обсуждается: http://www.opennet.ru/tips/info/1795.shtml

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от rusty_angel email on 14-Окт-08, 13:52 
Зачем городить nginx<->lighttpd<->php, если nginx сам может с php по FastCGI общаться?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Gular (ok) on 14-Окт-08, 15:16 
Правильно. Либо lighttpd использовать один.
Насколько процесс nginх меньше занимает, чем lighttpd?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от rusty_angel email on 14-Окт-08, 15:21 
>Правильно. Либо lighttpd использовать один.
>Насколько процесс nginх меньше занимает, чем lighttpd?

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от одмин on 14-Окт-08, 16:16 
никогда он не был threaded.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от rusty_angel email on 14-Окт-08, 16:43 
>никогда он не был threaded.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от User294 (??) on 14-Окт-08, 19:46 
>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?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Anton (??) on 14-Окт-08, 16:26 
лайти - глюкалово еще то.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от rusty_angel email on 14-Окт-08, 16:42 
>лайти - глюкалово еще то.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Anton (??) on 14-Окт-08, 16:49 
безотносительно к викимедии, посмотрите на кл-во security updates в Debian дляlighttpd и для nginx.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от rusty_angel email(ok) on 14-Окт-08, 17:02 
>безотносительно к викимедии, посмотрите на кл-во security updates в Debian дляlighttpd и
>для nginx.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Anton (??) on 14-Окт-08, 17:41 
http://survey.netcraft.com/Reports/200809/

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от User294 (??) on 14-Окт-08, 19:52 
>как реверс-прокси, переходим постепенно на энджинкс.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от User294 (??) on 14-Окт-08, 19:49 
>лайти - глюкалово еще то.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Anton (??) on 14-Окт-08, 21:38 
не нагружаете его
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от User294 (??) on 14-Окт-08, 23:39 
>не нагружаете его

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Anton (??) on 15-Окт-08, 00:12 
>Да?Тут как-то сказочники рассказывали про утечки памяти при нагрузке.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Anton (??) on 15-Окт-08, 00:38 
дочитал )

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от rusty_angel email(ok) on 15-Окт-08, 00:41 
9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел девять гигабит? Я думал, такие только на лоре встречаются.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Anton (??) on 15-Окт-08, 01:39 
>9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел
>девять гигабит? Я думал, такие только на лоре встречаются.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от User294 (ok) on 15-Окт-08, 02:22 
>9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел
>девять гигабит? Я думал, такие только на лоре встречаются.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от rusty_angel email(ok) on 15-Окт-08, 02:39 
Судя по всему, файлов немного. Не катит, имхо, для тестов. Надо много файлов, разных, плохо кешируемых. Хотя я не знаю, что именно тогда текло (давно было, в каких-то 1.3.х версиях, если не ошибаюсь), может Ваш-то тест и выявил бы тот лик. Сейчас поправили наверняка. Осадок просто остался, а с nginx я лучше, чем с лайти умею обращаться, вот и всё.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от User294 (??) on 15-Окт-08, 22:14 
>Судя по всему, файлов немного.

Штук 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от rusty_angel email(ok) on 16-Окт-08, 07:56 
>
>P.S. апача с префорком кстати данный тест выносит в хлам, особенно если
>файлы не 10 Мб а поменьше.Ему как правило становится очень нехорошо
>от форка на скорость 200 процессов.А на хилой машине они еще
>и сжирают всю RAM если админ не ограничил число процессов :D
>

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от User294 (ok) on 16-Окт-08, 08:38 
>Апач тоже надо уметь готовить.

Угу, обычно эта готовка сводится к тому что на сервер тупо впихивают дофига оперативы под зиллионы тредов или процессов апача и хренадцать процессоров.Спасибо, я гайд по оптимизации апача читал - после его прочтения сложилось стойкое ощущение что они борятся с проблемами которых у других изначально нет.Да и то что нагруженные сайты уважают лайт и нжинкс наводит на такие мысли.

>В Яху это делать умеют, к примеру.

Будучи яхой можно позволить себе парк серверов пожирнее, кучу процессоров, оперативки дофигища и прочая.И там даже апач может вольготно форкать свое добро в свое удовольствие.

Но случаи бывают разные.Например, на VDS больше оперативки == больше цена.Или вон та машина - уже есть и оперативки в ней вот столько и баста.Ну и так далее.Так по опыту - если оперативка ограничена, с апачом все сводится к двум вариантам: или неограниченый форкинг или трединг выжирает RAM или, если ограничить число воркеров, как только число соединений растет - все начинает работать медленно и печально.Что в общем то чертовски логично и предсказуемо.С другой стороны, лайт или нжинкс и на такой конфигурации пашут крайне ядрено.Так что завалить их параллельными даунлоадами на такой конфигурации... нуууу... это будет нелегко.Им на доступный объем оперативки как-то пофиг почти из-за особенностей конструкции.

>По своему опыту могу сказать, что кроме экстремальных случаев, апач нифига
>не хуже лайти или nginx.

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

>Только процессов больше и top кажется более катастрофическим.

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

>Реально нагрузка на железку не сильно отличается.

Ну, вообще-то, потребление RAM отличаятся изрядно.В этом злом тесте на 200 конекция и 10M аплоадов лайт обошелся ~4Mb RAM.Я что-то здорово сомневаюсь что апач сможет столько же отгрузить треская столько же RAM.У меня после попытки покрутить его параметры сложилось ощущение что нормально работать он может только на супер-серверах с кучей ядер и дофигища оперативки.Если вдруг что-то меньше то получается tradeoff между тормозами и выжиранием невъ...нного объема оперативки.И кстати на дворе год 2008.Железка?Хм.А вы слово "виртуализация" слышали?А то оно довольно актуально в 2008 году.Удобно, эффективно по ценам, позволяет ряд весьма эффектных и эффективных фокусов типа сохранения состояний или live-миграции ну и все такое :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Basov E. on 15-Окт-08, 16:04 
http://balancer.ru/forum/ работает на lighttpd. Статистику нагрузки можно посмотреть к примеру тут http://www.mapyourvisitors.com/map2537.php
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Anton (??) on 15-Окт-08, 17:55 
речь о высокой нагрузке.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Обеспечение работы системы мониторинга Nagios при помощи Ngi"  
Сообщение от uldus (ok) on 14-Окт-08, 16:55 
>Зачем городить nginx<->lighttpd<->php, если nginx сам может с php по FastCGI общаться

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Обеспечение работы системы мониторинга Nagios при помощи Ngi"  
Сообщение от User294 (??) on 14-Окт-08, 20:03 
>урезанном apache или на nginx/lighttpd, там же коннектов единицы,

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Обеспечение работы системы мониторинга Nagios при помощи Ngi"  
Сообщение от uldus (ok) on 14-Окт-08, 23:18 
>>урезанном apache или на nginx/lighttpd, там же коннектов единицы,
>
>А это от доброжелателей не зависит?А то если оно извне доступно... апачи
>очень любят когда им на хилой тачке обламывается несколько сот конекций
>:)

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."  
Сообщение от Df_Yz (ok) on 10-Ноя-08, 19:18 
А что мешает пустить .cgi через lighttpd?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

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