проблема со скоростью esxi nagios

Я пытаюсь добавить свои серверы esxi (у меня их 3) в мониторинг nagios. Я использую Perl SDK и скрипт, как описано в различных местах в Интернете, последний скрипт находится здесь: http://git.op5.org/git/?p=nagios/op5plugins.git;a=blob_plain;f=check_esx3.pl;hb=HEAD

Я обновил свои два блока esxi4 до 4.1u1 (4.1.0, 348481)

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

Я отследил команду perl с помощью DProf

    /usr/bin/perl -d:DProf /usr/lib/nagios/plugins/check_esxi -H HOSTNAME -u nagios -p PASSWORD -l cpu -s usage -w 85 -c 95

и я получаю следующий вывод (через dproff)

     Total Elapsed Time = 6.634312 Seconds
       User+System Time = 5.154312 Seconds
     Exclusive Times
     %Time ExclSec CumulS #Calls sec/call Csec/c  Name
     44.1   2.276  4.339      2   1.1380 2.1695  Vim::login
     12.9   0.667  1.638   4254   0.0002 0.0004  Class::MethodMaker::Engine::create_methods
     8.91   0.459  0.588   4254   0.0001 0.0001  Class::MethodMaker::scalar::scal0000
     5.18   0.267  0.304   4254   0.0001 0.0001  Class::MethodMaker::Engine::install_methods
     3.20   0.165  0.165  26005   0.0000 0.0000  XML::LibXML::Node::nodeName
     2.50   0.129  0.129   4254   0.0000 0.0000  Class::MethodMaker::Engine::check_opts
     2.41   0.124  0.594    925   0.0001 0.0006  ComplexType::deserialize
     1.92   0.099  0.091   1561   0.0001 0.0001  Class::MethodMaker::Engine::_find_target_class
     1.40   0.072  0.072   3326   0.0000 0.0000  XML::LibXML::Node::textContent
     1.36   0.070  0.336   5816   0.0000 0.0001  XML::LibXML::Element::getChildrenByTagName
     1.14   0.059  0.068   4254   0.0000 0.0000  Class::MethodMaker::OptExt::encode
     1.07   0.055  0.055   5816   0.0000 0.0000  XML::LibXML::Node::_childNodes
     1.05   0.054  1.820   1561   0.0000 0.0012  Class::MethodMaker::Engine::import
     0.97   0.050  0.050      1   0.0500 0.0500  utf8::AUTOLOAD
     0.97   0.050  0.205     25   0.0020 0.0082  main::BEGIN

Поскольку я запускаю 4.1, я включил SSH и подключился к консоли. Это то, что я вижу в / var / log / messages (это esxi4, поэтому журнала vkernel нет)

    [2011-09-05 22:53:36.543 51E40B90 verbose 'Proxysvc Req06598'] New proxy client SSL(TCP(local=192.168.99.101:57617, peer=192.168.99.22:443))
    [2011-09-05 22:53:43.091 52081B90 verbose 'Proxysvc Req06599'] New proxy client SSL(TCP(local=192.168.99.101:57652, peer=192.168.99.22:443))
    [2011-09-05 22:53:43.136 51E81B90 info 'Vimsvc'] [Auth]: User nagios
    [2011-09-05 22:53:43.137 51E81B90 info 'ha-eventmgr'] Event 4814 : User nagios@192.168.99.101 logged in
    [2011-09-05 22:53:44.429 52081B90 verbose 'App'] CloseSession called for session id=5260ca10-fdc9-3a26-4d0c-45be7792c716
    [2011-09-05 22:53:44.430 52081B90 info 'ha-eventmgr'] Event 4815 : User nagios logged out

Обратите внимание на два входа в систему, разделенных примерно 7 секундами - второй выполняет проверку быстро.

Кстати, я также регулярно вижу два из них в журнале, но я думаю, что это не связано

     [2011-09-05 22:53:40.031 51AD1B90 verbose 'Statssvc'] HostCtl exception Unable to complete Sysinfo operation.  Please see the VMkernel log file for more details.

Я также заметил, что вход на сервер через vsphere довольно медленный, примерно за 3-4 секунды до начала загрузки. Это могло быть не связано. Сервер esxi не испытывает большой нагрузки, хотя на нем установлены iscsi lun и, возможно, около 6-7 активных виртуальных машин. Я проверил (и увеличил) выделение ресурсов для хоста, а также проверил esxtop (без результатов) при выполнении команды проверки.

Эта задержка является проблемой, потому что процессы perl из nagios работают со 100% ЦП, пока они пытаются подключиться, и это происходит на всех трех моих серверах esxi. По мере того, как nagios выполняет все больше и больше проверок, центральный процессор сервера мониторинга и средние значения нагрузки зашкаливают, поскольку все процессы ждут ответа. Это только усугубляет проблему задержки и приводит к тайм-ауту всех проверок.

Друг, который также запускает nagios, тот же сценарий мониторинга и такое же обновление esxi, может выполнить ту же проверку, и она завершится менее чем за секунду, тогда как для меня это занимает до 10 секунд (как вы можете видеть в выводе dproff)

Сообщите мне, есть ли дополнительная информация, которую я могу предоставить для диагностики этой проблемы. Хосты были перезагружены (с обновлением 4.1) прошлой ночью.

Заранее спасибо,

Гарет

--edit1: добавлено общее время вывода proff и сделана команда проверки perl как цитата блока

--edit2:

Я активно диагностирую это с момента публикации. Я обнаружил, что сервер nagios моих друзей - это машина x64, поэтому я установил новую виртуальную машину ubuntu 10.4 x64 (на другом хосте, заметьте) .После установки всего необходимого для проверок esxi (требовалось много модулей cpan) я может рассчитать время проверки этой новой установки, а проверка ЦП завершится примерно через 2 секунды.

Это указывает на то, что проблема связана с сервером nagios или perl, а не с серверами VMWare esxi.

Я убедился, что

1. инструменты vmware установлены
2. все модули cpan, которые мне пришлось установить на тестовом сервере, обновлены на рабочем сервере
3. производственный сервер - это aptitude update && aptitude upgrade 'd
4. обратный DNS (как показано ниже) работает
5. переадресация DN (как показано ниже) работает
6. протестирован с прямым IP, без имени хоста
7. Остановил сервер nagios, поэтому LA упадет до 0,01 перед выполнением моих тестов
8. Изменен драйвер vmware nic с гибкого (хост - esxi3.5) на расширенный vmxnet
9. Увеличено количество виртуальных ЦП с 1 до 2.

Я не могу перенести nagios на новую машину x64, она не работает на нашем управляющем vm-сервере (который содержит это поле мониторинга и несколько промежуточных узлов)

32-битный блок (с которого я изначально начал и профилированный выше) все еще требует 8-10 секунд 100% ЦП для завершения проверки ЦП.

Я понял, что диск - это виртуальный диск, установленный на iSCSI lun для этого сервера, и это несколько замедляет дисковый ввод-вывод, но я не ожидал, что запрос к удаленному серверу будет большой операцией ввода-вывода диска.