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

Логика циклического цикла счетчика тиков SNMP

Я пытаюсь рассчитать использование ЦП в процентах по протоколу SNMP удаленного агента на основе ssCpuRaw* счетчики тиков. Насколько я понимаю, все они типа COUNTER(32 bit) так что они вернутся к нулю после того, как достигнут своего MAX стоимость.

Агент, за которым я наблюдаю, простаивает около 80% времени, поэтому счетчик простоя в какой-то момент в будущем начнет работать первым, задолго до того, как это сделают другие. Теперь мой вопрос: что происходит с другими счетчиками после срабатывания счетчика простоя? MAX? Достаточно ли умен SNMP, чтобы сбросить другой ssCpuRaw* счетчики тоже? В противном случае соотношение между этими счетчиками было бы ужасно вводящим в заблуждение, делая каждую попытку вычислить процент бесполезной, пока все (!) Оставшиеся счетчики не обернуты вокруг, или я полностью здесь?

Спасибо

Нет, если бы другие счетчики были сброшены, вы потеряете числа, накопленные между последним запросом и переносом.

Подходящий метод для запроса этих счетчиков:

  • оформить запрос GET для sysUptime.0 и значения счетчика в одном пакете, поэтому вы получаете атомарное представление
  • использовать sysUptime.0 объект, чтобы узнать, был ли агент сброшен.
  • вычислить разницу с последним запросом для каждого счетчика отдельно с поправкой на перенос

Ваш запрос должен быть достаточно частым, чтобы вы не пропустили два переполнения подряд, что должно быть достаточно простым. Тест на сброс используется для фильтрации возникающих всплесков, например если значение счетчика изменилось с 3,000,000,000 до 0.

Это означает, что вы не можете интерпретировать данные, собранные после того, как один из счетчиков уже один раз обернулся.