nocproject.org

,

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

zi_rus: это как это так?

хз

я застопил классификатор и сделал -f start

все заработало

я офигел

остановил

все

запустил

https://vk.com/rostelecom_rabota

и все начало классифицироваться

а у меня такой вопрос насчёт классификатора... хотя наверное, даже насчёт коррелятора:

бывало у кого, что прилетает сразу штук 200-300 аварий... скажем ping failed? как реагирует коррелятор?

разгребает, как.)

ну да, только вот длает это он минут 15-20

причём (вроде) поднимает алармы долго, закрывает почти сразу... я хочу просто узнать, нормлаьно это или искать затык в системе

lexus-omsk: производительность коррелятора конечна, да

но он разгребает события строго по очереди

не думал, что она настолько конечна :) упал узел агрегации - не часто бывает, но всё же... - и ога, приехали - алармы прилетают, когда уже всё встало

мне интересно сравнить, если у меня на порядок меньше скорость, то имеет смысл свою систему ковырять, а если у всех так - другое дело

перфоманс надо тестить

+р

имеет смысл ковырять

индексы смотреть, локи

сделал морду для правил раскраски интерфейсов

Дим, по поводу старой и больной темы со статусами интерфейсов

может забить и сделать два поля - бинарное - up

|down

а второй - reason

где будут всякие adm down| sfp err| и тд

:)

а reason какого типа?

обычное текстовое

ну можно и choise

choice*

я тут просто нексус ковыряю профиль, у них в кли так и сделали

если текстовое, то с choice

Ethernet VLAN Type Mode Status Reason Speed Por

t

Interface Ch

#

--------------------------------------------------------------------------------

Eth1/1 127 eth access up none 10G(D) --

Eth1/15 127 eth access down Link not connected 1000(D) --

Eth1/36 1 eth access down SFP validation failed 10G(D) --

Eth1/27 1 eth access down SFP not inserted 10G(D) --

и т д

надо список составить вохможных статусов

т е choice-ов

угу

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

dvolodin, графики кгда будут?

dvolodin, дык суть в том, что он справочный

т е хочешь хоть 100 choice-ов делай, на каждого вендора и железо

основная информация - бинарный статус

это как snmp trap с переменной

по которой можно решить что делать дальше

http://www.opennet.ru/opennews/art.shtml?num=40159

да, про си подтверждаю)

не смотря на то, что сишники востребованы порой не меньше

но на курсах до си доживают еденицы)

я вот в свое время был супер-пупер специалистом по Object Pascal. Ну и нафига он мне сейчас?

ну не повезло

ага

а еще супер-пупер специалистом по бейсик. Куча потраченных усилий и времени

меня вот тоже учили на свч технику, там радиолокация\ свч сушики а теперь я говноадмин в ростелекоме

хотя как для меня, то все-таки C++ хуже спроектирован, чем тот же Object Pascal

си быстрее питона, переписывайте низкоуровневые модули в ноке на си

И потеряется совместимость с кучей систем

нок и так можно запустить только на полутора системах

полтора землекопа

e_zombie, не МАИ ли?

сгту

dvolodin, а когда аларм затрагивает несколько мо, может можно в качестве мо писать САЕ, нужные переменные класть внутрь аларма

например упал линк

это авария о двух концах

макфлап

zi_rus: нет, нужно один объект оставить

тоже авария одвух концал

ну а как тогда

два алярма

криво

через жопу

и неправильно

просто root cause надо нормальное

авария одна, а алармов несколько

которое будет их сцеплять

упал порт с одной стороны и упал порт с другой

потому что упал линк

какой тут рут коз

а если мак флап

в аварии надо показать

между какими портами флапает

а тут вообще железок может быть несколько

http://pastebin.com/tmUmb5fE кто скажет мне почему при включённом дебаге "Loading rules" попадает в логи а "%d rules are loaded. %d combos" % нет

dvolodin: NOC-1377

local/collections вычисти

dvolodin: http://pastebin.com/kaB17rVC

и?

откуда дровишки, что можно дропнуть безнаказанно базу монги?

крашится постоянно

ну я откатился на старую БД.

но вот кореллятор теперь крашится на ёжиках

кхм. а не. хуавей.

вернее и на нём

а никто ещё не предлагал сделать диапазон времени для выборки в ФМ ещё и с часами а не только дни?

так

нате вам новую старую фишку

сделал морду для правил классификации интерфейсов

как раз для раскраски

dvolodin, куда смотреть?

inventory > setup > interface classification rules

dvolodin, не оценил, что это и зачем?

и как пользоваться

делаешь правила

селектор, что матчить и какой профиль навешивать

ааа

типа замена моего пируля

да

вполне штатная

все тщетно бьешься чтобы превзойти по юзабельности один маленький пируль :)

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

а то ведь хрен знает как сеть работает

на самом деле эти правила давно уже есть

морды на них не было

dvolodin, в снмп трапе прилетает =19P=98=03 U=00=00

это net или hostname

в ISIS

как декодировать

декодер в классификаторе сделать

там есть уже decode_*

а так - Parameter смотреть, вроде был ISOParameter

zi_rus: сделай issue для декодирования трапа

О. Нашел, где есть interface profile

Вопрос: как его применить к селектору или группе MO ?

Или хотя бы к managed object profile

dvolodin, NOC-1378

dvolodin: Дим, я тебе в личке написал

блин. надо доку. я не могу понять как эксплуатировать класификатор интерфейсов.

а я не могу понять, чем в FM отличаются

"vars__interface": "alarm.vars['interface']",

от

"vars__interface": "alarm.managed_object.profile.root_interface(alarm.vars['interface'])",

короче подождём до завтра. пока всё устаканится и потом будем думать.

e_zombie, ты там в апокалипсис не играй)

_4ePTeHok: поздняк метаться. половина из 600 уже прошилась

_4ePTeHok: ты в иерархии классов noc разбираешься?

что именно?)

там иерархия то

Я подозреваю, что "alarm.vars['interface']", - это то, что написанно в секции "vars" ивенткласса, вызвавшего аларм

А что такое "alarm.managed_object.profile.root_interface(alarm.vars['interface'])", ?

ну логично что алярм имеет данные о МО

а вот чо такое рут_интерфейс..

счас код погляжу

В SA

rom noc.sa.profiles import Profile as NOCProfile

class Profile(NOCProfile):

./sa/profiles/__init__.py ага

это оно?

Dmitry1, я дождался как ты освободился, а мы и 1% задуманного не сделали

>>> Profile().root_interface("Gi 0/1")

'Gi 0/1'

>>> Profile().root_interface("Gi 0/1.15")

'Gi 0/1'

Дим, это вычленение физ интерфейса

из саба

по функции из профиля

для d-link'а и кучи железок - это вычлинение номера свича в стеке

(т е можно переопределить в ./sa./profiles/vendor/os/__init__

как я понимаю - это чтобы при падении саба возвращать реальную физику

склеивается ли в этом случае алярмы в один - хз

если оно неверно работает для твоего профиля - допиши в __init__ профиля

свою реализацию

мда

ладно, а что в root cause означает window ?

наверно временное окно)

там просто этих окон уже

скоро как в виндовсе будет)

есть deduplication_window

combo_window

"'timestamp__gte': alarm.timestamp - datetime.timedelta(seconds=%d)" % self.window,

"'timestamp__lte': alarm.timestamp + datetime.timedelta(seconds=%d)" % self.window

да, это временное окошко

аларм

NOC | Managed Object | Ping Failed

"root_cause": [

{

"name": "Power Failed",

"root__name": "Chassis | PSU | Power Failed",

"window": 30,

30 тут что?

ping failed должен произойти не позже чем через то секунд после power failed ?

там ниже есть еще чо?

в секции рут коса

ниже

"condition": "True",

"match_condition": {

"managed_object": "alarm.managed_object.id"

}

},

откуда взялась константа 30 ?

30 это руками задали

и что оно означает?

ing failed должен произойти не позже чем через 30 секунд после power failed ?

окошко определяется как выше в коде -30 +30

двумя значениями

если на этом расстоянии от текущего алярма будет алярм с поверфейлом - оно сработает

то, что ты выше написал - мне абсолютно непонятно. я не знаю, что означают функции класса datetime и т.п.

там просто конвертация в таймстемп

т.е.

смотри - есть таймстемп твоего алярма

в алярм-классе есть руткос

если через 30 секунд от power filed будет аларм ping failed, то он зачтется как root cause ?

в нем 30 сек окно

если через 30 секунд от power filed будет аларм ping failed, то он зачтется как root cause ?

он будет искать при корреляции не было ли от этого же объекта алярма поверфейл в промежутке от alarm.timestamp -30 до alarm.timestamp +30

тогда условие срабатывает

как оно работает в будущее - даже не спрашивай %)

тогда другой вопрос

у нас по умолчанию стоит ping check в 60 секунд

какое мне там число поставить?

Я не понимаю афромагию, ине хочу ее понимать

э.

я не вижу связи

между одним и другим

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

да?

первый раз

а дальше - как настроишь в профиле интервалы

я имею ввиду ping check в профиле железки, а не интерфейсов

а, надо джоб глянуть

понял мысль?

чтобы для window: можно было поставить что-то типа "alarm.managed_object.бла-бла.ping_check_time"

если уж мы имеем доступ к полям объекта managed_object

оно там по коду не джобом выходит, а активатором.

но сути особо не меняет

ага

alarm.managed_object.object_profile.ping_interval

типа того, да

тогда оно адаптивное станет

но!

в модели ето число

да

попробуй

при возникновении алармкласса оно пытается вычислить переменные

как оно относится к прибитым гвоздями?)

точно

пока оставляю 30, а потом нужно будет давить Диму

даже увеличу окно до 2-х минут

ну, я хз конечно. Но у меня при пропадании питалова железяки не успевают слать поверфейл

т е ценность тут сомнительна имхо

я там еще один eoot cause цепляю