SNMP - значение загрузки процессора ЦП, не соответствующее действительности
Попытка построить график нагрузки процессора на моем сервере со следующим оборудованием: ProLiant DL360p Gen8 (такое же поведение на ProLiant DL360 G7).
На машине работает VMWare ESXi5.1
Чтобы создать скачок ЦП, я запускаю dd if=/dev/zero of=/dev/null, и я знаю, что ЦП перегружен, потому что я вижу соответствующий всплеск на графиках, отображаемых в vCenter.
Однако запуск этого snmpwalk:
snmpwalk -v 1 -c ******** 192.168.MY_IP 1.3.6.1.2.1.25.3.3.1.2
Показывает следующие результаты:
iso.3.6.1.2.1.25.3.3.1.2.1 = INTEGER: 3
iso.3.6.1.2.1.25.3.3.1.2.2 = INTEGER: 2
iso.3.6.1.2.1.25.3.3.1.2.3 = INTEGER: 2
iso.3.6.1.2.1.25.3.3.1.2.4 = INTEGER: 3
Разве я не смотрю в нужную MIB? Следует ли мне умножать их на константу?
Кстати, с помощью HP Agentless Monitoring я смог получить некоторую статистику ЦП, но не то, что я ищу, по крайней мере, ничего, что я не мог найти, пробираясь через эти MIB.
Попробуйте использовать полезность стресса генерировать нагрузку в Linux, пожалуйста. Он очень подробный и имеет больше смысла, чем то, что вы делаете.
Я вижу, что вы создаете однопоточную нагрузку ввода-вывода на виртуальной машине с 4 процессорами. График ЦП, который вы вставили из клиента vSphere, показывает нагрузку 25%, потому что вы напрягаете только одну из четыре ЦП назначен виртуальной машине.
Скачать стресс (который доступен для большинства дистрибутивов Linux) и попробуйте с некоторыми конкретными параметрами ...
Например, просто запустить на виртуальной машине с 4 процессорами следующее:
# stress -c 4
stress: info: [594013] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
дает ...
Vmware не собирает эту информацию, и на самом деле нет хорошего способа сделать это. Проблема в том, что у него нет способа узнать, когда вы собираетесь спросить, поэтому для того, чтобы это сработало, ему пришлось бы всегда иметь среднее значение за последние шестьдесят секунд. Поскольку вы можете спросить время от времени, а затем спросить секунду спустя, ему придется правильно подсчитать процессорное время сорок секунд назад для обоих интервалов. Это действительно уродливая и сложная вещь.
Поддержка этого увеличила бы стоимость, поскольку агенту SNMP пришлось бы постоянно проверять использование ЦП и обновлять несколько интервалов, выполняемых одновременно.