Пример:

Вот выдержка из документации:

«В строке so.addVariable(«base_url», «http://www.huyamba.ru/»); параметр «http://www.huyamba.ru/» можно заменить на любой другой URL партнера.»

Очень меня порадовала любовь сотрудников проекта к своей компании. Посмеялся от души.

Upd: Самое интересное что этот домен реально существует. И принадлежит тойже mamba.ru.

1) Ставим vicq клиент. Регистрируем для него UIN. Из примера конфигурационного файла создаем работающий конфиг. Обязательные параметры uin и password.

2) Настраиваем nagios для отсылки сообщений о проблемах:

а) Задаем для своего контакта параметр pager равный номеру вашего ICQ.

б) Задаем 2-е дополнительне комманды в commands.cfg

[code]# ICQ Notification
define command{
command_name notify-host-by-icq
command_line /usr/bin/printf "%b" "msg $CONTACTPAGER$\n***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n.\n" | /usr/local/bin/vicq -c /usr/local/etc/vicq.conf -b -o -t 5
}

define command {
command_name notify-service-by-icq
command_line /usr/bin/printf "msg $CONTACTPAGER$\n***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n.\n" | /usr/local/bin/vicq -c /usr/local/etc/vicq.conf -b -o -t 5
}[/code]

в) В шаблоне описывающем generic-contact задаем следующие параметры:

[code]service_notification_commands notify-service-by-email,notify-service-by-icq
host_notification_commands notify-host-by-email,notify-host-by-icq[/code]

После всех манипуляций — перезагружаем Nagios и «роняем» какой-нибудь сервис. Все должно работать.

Сообщения будут приходить такими:

[code]***** Nagios *****

Notification Type: PROBLEM

Service: AMAVIS
Host: localhost
Address: 127.0.0.1
State: CRITICAL

Date/Time: Sun Nov 2 01:22:37 MSK 2008

Additional Info:

Connection refused[/code]

Кстати, с vicq есть 1 баг при запуске его нагиосом. Так как клиент использует Term::Readline, то возникает ошибка при запуске:

[code]Cannot open /dev/tty for read at ...[/code]

Решается проблема просто, надо подредактировать файл vicq. Перед 1063 строкой вставить следующий кусок кода:

[code]  open (FH, "/dev/tty" )
or eval 'sub Term::ReadLine::findConsole { ("&STDIN", "&STDERR") }';
die $@ if $@;
close (FH);[/code]

Все будет работать без проблем.

Описание работ над проектом: После того, как проект перерос shared хостинг и переехал на отдельный VPS сервер, то встал вопрос в оптимизации как ОС VPS сервера, так и проекта. Вместе с администрацией проекта провели оптимизацию:

1) На уровне БД — оптимизация конфигурации MySQL демона под конфигурацию сервера, кеширование запросов, backup, slow логи. В дальнейшем при помощий explain оптимизировали несколько особо тяжелых запросов.

2) Перевел проект на nginx + fastcgi php5. Также, добавление opcode кешера позволило снизить нагрузку на VPS сервер.

После переезда проекта на выделенный сервер донастроил DNS сервер и почту для домена fanat1k.ru. Почта обязательно с антивирусом и антиспамом.

Результат: После настройки мониторинга за всеми критичными процессами на сервере необходимость в постоянном наблюдении за сервером отпала, так что проект сейчас живет своей жизнью. Судя по статистике hotlog.ru проект очень даже успешно работает, учитывая НЕ топовую конфигурацию сервера, на котором он размещен.

Начнем пожалуй с http://files.desu.ru

Описание проекта: Портал о аниме, Японской культуре и всем, что с этим связано.

В 2007 году у проекта возникли сложности в работе портала. Раздача аниме через http просто «вешала» сервер, судя по статистике LA уходил в 150-160, и через 20-30 минут после запуска WEB сервера ОС сервера уходила в ступор. Соотвественно появилось желание оптимизировать проект, о чем договорились с его администрацией.

Описание работ над проектом: Начнем пожалуй с сервера, оборудование было предоставлено «домашней сетью» с Юга Москвы. Сервер стоял в ДЦ на М9. Судя по конфигурации под проект выделили desktop в 19» корпусе, сетевая карта интегрированная, HDD SATA без RAID массива. OS Gentoo 2007.1, amd64.

После предоставления shell доступа на сервер сделал буквально следующее:

1) Пересобрал Apache2 с поддержкой prefork, до этого был worker. Оптимизировал конфигурацию WEB сервера.

2) Пересобрал PHP5 без тредов, иначе судя по логам Apache2 часто падал под нагрузкой из-за ошибок связанных с работой php скриптов.

3) Изменил схему работы на frontend (nginx) + backend. Это позволило убрать apache2 с раздачи «большой» статики, а также настроить лимиты по отдаче файлов для 1 IP. В последствии написал обвязку к системе лимитов, которая добавляла IP в iptables, если посетитель сайта не понимал правил раздачи установленные на сервере и пытался все равно обойти систему лимитирования количества одновременных коннектов с 1 ip.

4) Оптимизировал MySQL, а именно — включил кеширование и выделили под него побольше памяти. Также увеличил размеры буферов для обработки запросов. Также как обычно включил slow логи, что позволило оптимизировать некоторые запросы к БД и в итоге сказалось на общей производительности проекта в целом.

5) Настроил систему резервирования конфигурации сервера и реализовал ежедневный backup MySQL DB.

Результат: После оптимизации проекта все заработало как часы. Некоторые параметры подгонялись в соотвествии с показаниями статистики сервера и информации в лог файлах, но это заняло всего несколько дней. Под рабочей нагрузкой сервер успевал отдавать под 160 Mbit/s.

Что не успел сделать: В связи с тем, что у владельца сервера изменились интересы, он забрал его и закрыл доступ для проекта. Соотвественно не успели перейти на софтовый RAID массив и нормальную сетевую карту. RAID массив нужен был из-за того, что просто уперлись в IO, а с интегрированной сетевой картой были проблемы в плане производительности.

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