Назад | Перейти на главную страницу

Как SNMP влияет на использование ЦП в Linux?

Будет ли в конечном итоге вызов SNMP для получения информации об использовании ЦП для Linux просто читать файл / proc / stat?

Вздох1. К счастью, вам не нужно /proc/stat

man 5 proc:

/proc/loadavg

Первые три поля в этом файле представляют собой средние значения загрузки, указывающие количество заданий в очереди выполнения (состояние R) или ожидающих ввода-вывода диска (состояние D), усредненные за 1, 5 и 15 минут. Они совпадают с числами средней загрузки, предоставленными uptime (1) и другими программами. Четвертое поле состоит из двух чисел, разделенных косой чертой (/). Первый из них - это количество выполняемых в настоящее время объектов планирования ядра (процессов, потоков). Значение после косой черты - это количество объектов планирования ядра, которые в настоящее время существуют в системе. Пятое поле - это PID процесса, который был создан в системе последним.

Но вам, вероятно, нужно проконсультироваться с источником для http://www.net-snmp.org/ чтобы определить, что они на самом деле используют:

net-snmp-5.7.3 / агент / mibgroup / ucd-snmp / loadave.c:

#elif defined(linux)
{
    FILE           *in = fopen("/proc/loadavg", "r");
    if (!in) {
        NETSNMP_LOGONCE((LOG_ERR, "snmpd: cannot open /proc/loadavg\n"));
        return (-1);
    }

Сноска 1. Иногда вы действительно не можете выбрать, с кем работать.

В ответ на ваши комментарии, снова вздох. Поскольку только ядро ​​осведомлено о том, что на самом деле делает, любой мониторинг, так или иначе, должен будет взаимодействовать с ядром для получения такой информации. Общий интерфейс для взаимодействия с ядром: /proc/ хотя можно придумать и другие методы (auditd и kerneltap приходить на ум). Но вряд ли они «легче» ....

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

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

У HBrujin есть ответ на ваш прямой вопрос, но реальная проблема, решаемая здесь, требует дополнительного обсуждения.

Как вы, наверное, уже поняли из комментариев, большинство людей недоумевают по поводу отношения вашего коллеги. Это потому, что опрос /proc для системной информации достаточно повсеместно. Избегая прямого вызова библиотеки для опроса ядра (с использованием скомпилированного языка), единственный способ узнать состояние ядра - опросить его из /proc или /sys.

Большая часть автоматизации системы достигается с помощью сценариев на языках более высокого уровня. Некоторые из них предоставляют обертки библиотеки, которые обходят необходимость чтения информации из /proc, но сценарии оболочки просто не работают и не могут. Это прямо противоречит позиции вашего коллеги, указанной в комментарии выше. "возражение обычно читается из / proc".

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