nocproject.org

zi_home: ну чего, отпустило?

dvolodin, нет, пики повторились, сообщений в логах нет

давай-ка тогда залогируем еще переполнения

dvolodin, стой

я похоже дифф забыл накатить

http://pastebin.com/Erb6bRPg

накатил

вот тогда тебе дифф

добавь там сообщение counter wrap :)

новый дифф скопировал, сейчас накачу

накатил

dvolodin, ты тут?

набегами

смотри

noc-probe.3.log:2014-10-25 13:45:53,220 [noc.pm.probe.metric] Possible counter stepback for object.bb-vitus.interface.gi0-1-0-13.interface.load.in: 1671558178204 -> 815900060

noc-probe.3.log:2014-10-25 13:45:53,221 [noc.pm.probe.metric] Possible counter stepback for object.bb-vitus.interface.gi0-1-0-13.interface.load.out: 5812409626568 -> 1318875080

что интересно этот 13 порт с утра выключен

а на графике пик

но по времени в точке на +1 час от этого сообщения

http://i66.fastpic.ru/big/2014/1025/9b/52b890dc296af318838805bb9fedfa9b.png

время на сервере и на грфиках правильное

dvolodin, хотя, судя по другим графикам, фикс работает, пиков нет в точках по которым появились сообщения в логе

надо еще наблюдать

и опять же, это все про одиночные пики

но факт медицинский

счетчик дергается назад

да

причем не с нуля, а черти откуда

причем на всех железках без разбору

и ме3400 и 2960 и ASR9k

причем только на IOS?

ytn

нет

ASR9k это IOS XR

про дсламы пока сообщений не было, но у меня их только 10%

zi_home: дерготня счетчиков может быть связана с link up/link down?

dvolodin, нет, про клиентские линки ничего не скажу, но сетевые точно стабильны, но самое интересное вон про тот линк что я тебе в начале написал, 13 порт сегодня в 9 утра погасили, там вообще не было трафика

и он соответственно точно не дергался

zi_home: графики причесались?

dvolodin, как тебе сказать, пока новых пиков на тех графиках что я наблюдаю, у меня нет

но я и десяти графиков не создал

ты же свои будешь пилить

разворачиваться широко на графане не вижу смысла в такой ситуации

откаты счетчиков новые были?

да

noc-probe.7.log:2014-10-25 17:17:53,171 [noc.pm.probe.metric] Possible counter stepback for object.isam-beketova13.interface.enet1.interface.load.in: 2141498080 -> 6501945

смотри-ка

даже на дсламе произошло

а вот тут целая пачка

noc-probe.4.log:2014-10-25 17:29:17,827 [noc.pm.probe.metric] Possible counter stepback for object.bb-mkazakova.interface.gi0-0-1-1.interface.load.in: 211365203456 -> 1579647355

noc-probe.4.log:2014-10-25 17:29:17,828 [noc.pm.probe.metric] Possible counter stepback for object.bb-mkazakova.interface.gi0-0-1-1.interface.load.out: 445791382470 -> 370925961

noc-probe.4.log:2014-10-25 17:44:18,151 [noc.pm.probe.metric] Possible counter stepback for object.bb-mkazakova.interface.gi0-0-1-1.interface.load.in: 4002457275 -> 189448738

noc-probe.4.log:2014-10-25 17:46:48,239 [noc.pm.probe.metric] Possible counter stepback for object.bb-mkazakova.interface.gi0-0-1-1.interface.load.out: 3890791385 -> 90290536

noc-probe.4.log:2014-10-25 18:06:48,464 [noc.pm.probe.metric] Possible counter stepback for object.bb-mkazakova.interface.gi0-0-1-1.interface.load.in: 3837979918 -> 3336148

noc-probe.4.log:2014-10-25 18:06:48,465 [noc.pm.probe.metric] Possible counter stepback for object.bb-mkazakova.interface.gi0-0-1-1.interface.load.out: 3916742044 -> 184225014

noc-probe.4.log:2014-10-25 18:26:48,299 [noc.pm.probe.metric] Possible counter stepback for object.bb-mkazakova.interface.gi0-0-1-1.interface.load.out: 3881977635 -> 98896568

о

насчет твоих DSLAM'ов

а не кажется ли тебе, что у них COUNTER не только 32-битный, но еще и со знаком

;)

>>> "%x" % 2141498080

'7fa4aae0'

хм

не задумывался

так и есть

:)

наркоманы алкателевские

ему 5 мегабайт оставалось до 0x7FFFFFFF

а может он перешел эти 5 мегабайт за период опроса

5 перешел и 6 еще добрал

11 мегов в минуту

чуть больше мегабита

я в это верю

за 3 минуты

ну тем более

ехидно назовем это 31-битными счетчиками :)

bb-* -- это у тебя BRAS'ы?

нет

backbone

dvolodin,

2014-10-25 20:26:47,547 [noc.pm.probes.generic.network.snmp_interface] [9113d0e0-745a-55e0-b75a-fad1831cd9f4] Disabling missed oid 1.3.6.1.2.1.31.1.1.1.6.10102

2014-10-25 20:26:47,549 [noc.pm.probes.generic.network.snmp_interface] [9113d0e0-745a-55e0-b75a-fad1831cd9f4] Disabling missed oid 1.3.6.1.2.1.31.1.1.1.10.10102

2014-10-25 20:26:47,550 [noc.pm.probes.generic.network.snmp_interface] [9113d0e0-745a-55e0-b75a-fad1831cd9f4] No valid OIDs to poll

как по uuid посмотреть что это за метрика

в probeconfig

./noc probeconfig --list --uuid=XXXX

dvolodin, у менялоги просто завалены сообщениями No valid OIDs to poll, при том что у меня почти все циски, а оиды все стандартные, мне кажется это подозрительным

zi_home: ACL, SNMP community

ну и подебажить надо

все в порядке

дернул выборочно, даже графики для некоторых построены

а некоторые uuid вообще не находит в конфиге

ну ладно, с этми потом разберемся, пока что про пики

dvolodin, а вот по поводу провалов, вот сейчас опять случился

http://pastebin.com/dE6C2V2G

в течение часа одни степбеки

теперь первого пика нет

а второй есть

кстати

а у нас не получается, что на этих железках нет 64-битных счетчиков?

ну это одна железка

и

IF-MIB::ifHCInOctets.47 = Counter64: 323009794106236

64-битные счетчики есть

хотя что думает по этому поводу нок - это второй вопрос

возможно он откатывается на 32 битные счетчики, а через час конфиг перестраивается и он возвращается на 64

а на 32-битные он откатывается если не смог получить результат 64-битных

и возможно это связано с той же проблемой No valid OIDs to poll

может быть у меня где-то в сервере затык

не все запросы проходят

ну да

это оттуда же

не отдали 64-битный счетчик -- ушли на 32-битный

это же виртуалка

не отдали 32-битный -- no oids to poll

может блидж не выдерживает такой поток

хм

может у тебя где-то udp режется по объему?

в явном виде нигде

думается мне нужен тюнинг хостовой системы

кстати может быть все эти переходы как раз и связаны вот с чем

начали опрашивать 64 бита

он заткнулся и мы отдали результат в 32 бита

да, я про это и говорю

по цифрам похоже

алгоритм, похоже, нужно дорабатывать

хм

после того, как нащупали работающие oid'ы -- оставаться на них

я думаю это мне сервер надо доработать

чтобы потерь запросов не было

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

по логике вещей -- за первый заход нащупываем правильные oid'ы

до сервера с ноком 18% потерь пингами

а хотя нет

хм

на быстрых пингах потери

до хоста потерь нет

до другой виртуалки тоже норм

надо фряху тюнить