nocproject.org

freeseacher, спасибо, заработала kb

упс... кажись не ту ветку закрыл - хотел в своём repo, а получилось - develop

dvolodin heelep! Пытался свой pull-request замержить а вмеcто этого закрыл develop... можно починить обратно?

lexus-omsk, баловник

:)

крыжик назывался close source branch, что никак не ассоциировалось у меня с develop в общем репо

он при следующем коммите дожен переоткрыться

https://www.evernote.com/l/ADnjFW72gGFBt4uGlsm8OErLO3UC30oz14U

вот, очередные заметки на полях шляпы

.

lexus-omsk: ну да, ему пофиг, где его закрывать

dvolodin, у меня вопрос, почему ты аларм сделал уровня критикал по dying gasp?

ну так оно подохло

как тебе сказать, я тут предлагал другую идеологию

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

подохло это уровень MAJOR

,,

если может подохнуть, то MINOR

падение протоколов - это WARNING

всякий мусор типа конфилкта адресов или макфлапов - ШТАЩ

INFO

dvolodin, в критикал предполагается совать только если подохла большая железка и утащила за собой много всего остального

может быть, да

на самом деле ревизию нужно провести alarmclass'ов

Когда-то давно, на форуме, был топик с алгоритмами для FM.

Преимущественно основаных на анализе топологии сети как графа.

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

dvolodin, ну я частично просмотрел NOC-1490

Для снижения нагрузки FM при обработки аварий, предлагается создать дополнительное поле в sa_managedobjects где хранить данные касающиеся объекта в сетевой топологии, например:

список путей от объекта к ядру сети или шлюзу, прочие требующие значительных вычеслительных ресурсов.

Данные обновлять переодически после дискавери топологии.

xetle: там и так есть два поля нужных

Какие?

termination_group и service_terminator

А да пропустил, надо ещё путь (маршрут) к этому брасу хранить, ибо его вичесление ресурсоёмко.

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

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

В списке журнала в идеале должны быть только правильноотсортированные кореневые аварии.

оно так и есть

я вот что думаю

Раскрыв кореневую аварию, причину, увидем все связные с ней аварии..

xetle: это есть все

тут явно нужно поиграться со склейкой ping failed + ping failed и ping failed + link down

хендлеров нет... их должно быть много.......

много - понятие более чем относительное

собственно вот что нужно

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

если она есть, конечно

ядро понятие растяжимое

причем с указанием интерфейса

zi_rus_: я знаю

Приветы

нужна табличка вида

managed object, root object, root object's interface

нужно л2 и л3 топологию учитывать

zi_rus_: не нужно, не будет такое работать

Если звезда, то всё просто, а если нет..

да, наверное не нужно

тут правила заполнения вот такие вот

если одна железка упирается в другую строго в один интерфейс - пишется в базу обе железки и интерфейс на корневой железки, от которой эта железка зависит

если она упирается ему в два и более интерфейса -- пишется только железка

без интерфейса

кольца свичей у нас приходят на две разных РЕ

тогда ping failed + ping failed коррелируются тривиально -- просто уводим одну аварию под другую по таблице связей

zi_rus_: в таком случае у тебя нет единственной железки

да

link down + ping failed коррелируются как раз по рутовому интерфейсу

то есть упал линк -- подводим под него все ping failed, которые доступны через этот интерфейс

а вот в этом не уверен

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

если мы не получили dying gasp то не знаем, линк даун является причиной или он следствие

ну и трактуй как упавший линк

Для того чтобы учесть кольцевую топологию надо хранить в базе и обновлять список ВСЕХ путей от каждого объекта к ядру, брасу, ...

не надо

это сильно следующий шаг

У меня в сети со строго кольцевой топологией получается точно определить причину: оптика, трасивер, питание или подвисание и послать на объеект соотведствующую ремонтную бригаду.

в большинстве случаев нужно отсеять мусор, связанный с падением колец и коммутаторов доступа

В топологии звезда точно причину определить не удастся.

вот именно

dvolodin: а что если кроме "быстрых" хендлеров добавить ещё один механизм который не в режиме реального времени будет обрабатывать аварии...

одно другому не мешает

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

тут такой еще момент

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

потому как долго просчитывают все последствия

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

А куда форум делся? Там была тема с описанием около десятка алгоритмов для FM. По ним бы хендлеры написать...

Там же на форуме были темы с пирулями которые меняли приоритеты алярмов... Ещё до "интерфейс профиль" они закрывали алярмы на клиентских портах, а на аплинках подымали приоритет - почти готовые хендлеры...

это есть в профилях все

Да теперь автоматом в профилях. Но как пример хотелось глянуть.

xetle, про форум ты freeseacher поругай, ему это все уже успели припомнить

freeseacher: а почему форум закрыли? Да им не пользовался никто.. Что много спама было или взломал кто?

да кому лишние описания нужны

только хлопоты

[сарказм]

xetle, zi_rus_ вопросы и ответы зато открыты

и никуда не делись

я уже говорил

формат вопросов неудобен

zi_rus_: присоединяюсь

что не так с форматом stackoverflow?

этасамая

а гугл ни с кем больше не воюет?

чет у меня на ns он как-то странно реагирует

на ns команда host plus.google.com 8.8.8.8 отвечает servfail, на клиенте та же команда возвращает адреса

[root@iz-wpc boot]# host plus.google.com 8.8.8.8

Using domain server:

Name: 8.8.8.8

Address: 8.8.8.8#53

Aliases:

plus.google.com has address 173.194.71.102

plus.google.com has address 173.194.71.100

plus.google.com has address 173.194.71.138

plus.google.com has address 173.194.71.101

дык говорю же, что серверам отвечает servfail, клиентам(не всем) отдает нормально

если 8.8.4.4 с серверов спросить - все ок

dvolodin, у меня очередной Мо в дискавери пишет дефферед

и что с ним делать?

кстати такая же ситуация была с объектами, которые долго были unmanaged, включил их, а не идёт discovery до перезапуска noc

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

а они продолжают появляться

то есть после установки галочки is_managed задачи уходят в deferred?

или не выходят из него?

у меня это с объектами по которым ping failed

был и вернулся

да, у меня тоже не пинговались, потом я снял managed, а как починили доступы - вернул, пинг пошёл, алармы ушли, а discovery не пошёл

e_zombie: а Dmitry1 при чем?

sed 's/: / : /'

:)

e_zombie, сделай локалый патч то

в апстриме кроме тебя он никому не нужен

а где можно посмотреть условия выполнения например Event class temperature out of range ?

тоесть в каких условиях используются переменные min max threshold

задача .

посмотреть на коммутаторах наличие свободного места .

через штатный механизм cli-coomands

запускаем

@@@ fsw-1-7dinamovsprzd-49-96-sar: OK

> dir

-rwx 255 boot.conf

-rwx 96 mantest.log

-rwx 6.5M nos.img

-rwx 232.3K nos.img.ecc

-rwx 2.4K startup.cfg

-rwx 19.3K startup99143.cfg

-rwx 2.7K vendor.cfg.ecc

Drive : flash:

Size:14.4M Used:6.8M Avaliable:7.6M Use:47%

получаем .

и вперёд ебаться .

1. отделять хостнейм.

2. лезть ручками в адрессный план чтобы "мартышка" могла зайти на коммутатор и разобраться с ним.

если кто то типа freeseacher думает что все инженера знают пейтон и это нахуй не надо - пусть встаёт под лучи. у меня они до четверга утра.

найти место в котором выставляется твоеточие и въебенить перед ним проблел может уверен даже половина твоих(светловолосых) моделей. не то что бы инженер/сервачник

я не собираюсь поддерживать форки

и плодить

хуиту

ну какие форки то ?

кто же тебя просит поддерживать хуиту. и форки особенно.

сделай cd /opt/noc; hg diff

внесение изменений в код без апстрима - пложение форков и идиотизм.

я праивльно понимаю что у тя нет ни единого изменения ?

ванильный нок ?

это не форк

а кастомизация

ты правильно понимаеш. кроме профиля qsw.2800

почему ?

e_zombie, почему у тя нет изменений ?

что с тобой не так ?

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

аа

это видимо после новогодних праздников

ну ок.

как то так. а сейчас перешивка 1500 кютечей на 6.х ветку с 7. ибо глючная.

а шестой на них нет?

есть

я при перепрошивке длинков прежнюю оставляю

только мы перешили их на семёрку

это видимо что-то глобальнее чем на длинке

нехило вы протестировали, а я так и сижу на 6.3.100.62, в принципе устраивает, кроме диффов конфигов после каждой перезагрузки

ну тут политические игрища.

TSergey там нельзя предыдущую оставить, флэшка впритык

вот оно что

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

Size:14.4M Used:7.4M Avaliable:7.0M Use:52%

Size:6.7M Used:6.6M Avaliable:120.0K Use:98%

Size:6.7M Used:6.6M Avaliable:124.0K Use:98%

Size:6.7M Used:6.6M Avaliable:138.0K Use:98%

[root@nocproject qtech-fashbootrom-20141222]# grep "Size:6.7M Used:6.6M Avaliable:138.0K Use:98%" out.work.txt | wc -l

1

[root@nocproject qtech-fashbootrom-20141222]# grep "Avaliable:1" out.work.txt | wc -l

13

[root@nocproject qtech-fashbootrom-20141222]# grep "Avaliable:7.0" out.work.txt | wc -l

20

[root@nocproject qtech-fashbootrom-20141222]# grep "Avaliable:7.1" out.work.txt | wc -l

1

[root@nocproject qtech-fashbootrom-20141222]# grep "Avaliable:7.2" out.work.txt | wc -l

2

[root@nocproject qtech-fashbootrom-20141222]# grep "Avaliable:7.3" out.work.txt | wc -l

0

за такие стройки надо руки отрывать

dvolodin, ты веришь про пинг файлед?

явно какая-то бага

zi_rus_: а что у тебя с пингам?

что-что

ping failed

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

у меня когда рестартишь нок и оно начинает пинговать все 11 000 хостов часть не пропинговывается и потом висит вечно что недоступен

хотя железка живая

хотя вот выбираю руками хосты - теория не подтверждается.

freeseacher: на http://kb.nocproject.org/ снова убил ссылки на код?

https://pp.vk.me/c622419/v622419141/1036f/e-GPMqb80wM.jpg

http://www.obeschania.ru/landing/v4/?utm_source=vh_2exp_3&utm_medium=vk&utm_term=vh&utm_content=12&utm_campaign=skype#skype

dvolodin, переоткрыл NOC-1010 - NOC-1010

зачем отдельный класс?

может кому поможет? нашел недокументированную фичу по ограничению лог файлов

logsize = 5000000

logfiles = 5

боян

по отдельности не работает. обязательно надо оба параметра

main]

logfile = /var/noc/log/noc-sae.log

loglevel = info

logsize = 102400000

logfiles = 9

а фигли все молчали, когда я спрашивал?

syslog_host =

типа оба параметра надо?

обязательно

аааа

делай багу.

логично вроде. какая же это бага?

2 месяца вручную логи удалял

for i in $(ls ${S}/etc/*.defaults); do sed -i 's/logfiles = 0/logfiles = 9/' $i; done

for i in $(ls ${S}/etc/*.defaults); do sed -i 's/logsize = 0/logsize = 1000000/' $i; done

Там 1 метра логов вполне хватает..

если info то мало

Не мало, даже с трейсами хватает...

http://i64.fastpic.ru/big/2014/1222/96/e6bd33f6870cf20d21715a5b76023a96.png

dvolodin, потому что event class это конкрентое событие, он определяет что произошло независимо от того что пишет железка, RFI dying gasp это одно событие, а RFI remote client shutdown - это совсем другое и смешивать их в одном классе я считаю неправильным, у них общее

только то что для индикации используется один протокол - ОАМ

это ника не основание объединять их одним классом

zi_rus_: ты в disposition можешь сделать в condition проверку, что тебе интересен только dying gasp

я понял что могу

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

и поднимать разные аварии

ты нарушаешь самою концепцию и подставляешь к результату костыли. занахера?

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

а что с тем классом, который я делал?

dvolodin, удалить или переделать. его делал второй Дмитрий когда я его пинал, но у него нездоровое желание пихать кучу разнородных событий в один класс. Вершиной мастерства для него видимо стало бы когда он сделал бы правило ",*"

dvolodin, также надо убрать правило кллассификации /opt/noc/fm/collections/eventclassificationrules/Cisco/IOS/Network/OAM/Client_Recieved_Remote_Failure_SYSLOG_.json

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

опечаток у тебя, как у школьника, блин

ладно, попозже займусь

там в condition можно писать так же, как и в managed_object

чтобы определить - поднимать аларм, или нет

да отвлекают потому что

и ты так и не сдалал создание классов из веба

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

влепил альтернативно одаренную навигацию

опять глюков добавил

каких именно?

а бывает иначе?

ты, кстати, привязку gying gasp к питалову на другой стороне линка проверил?

dvolodin, в смысле?

то что dying-gasp прилетает из-за питания? да, это проверено неоднократно

обнаружил что вроде починили таймзону =)

zi_rus: NOC-1502

e_zombie, мои тебе соболезнования. а что ты от меня хочешь?

покажи какой промп правильный будет. я пробовал от хуавея взять вроде работало но это не факт что правильно и оптимально

опять же коммитить я не могу

в душ не ебу какой правильный будет, и я тоже не могу ничего коммитить

ну знач будем как всегда

как нибудь

можно ли в темплейте сослаться на переменную из classification rule или как мне значение достать из snmp trap ?

попробовал {{ alarm.vars.level }} - пусто

level - название переменной из snmp trap

как вообще в темплейтах сослаться на какую нибудь переменную из аларма

как-то можно

о как , а вот такую штуку как сделать

NOC-673 ?

{{alarm.vars.name}}

dvolodin: так я так и указывал

{{ alarm.vars.level }}

или без пробелов?

без разниув

хм, тогда почему то пусто

если я в classification rule создаю свою vars - level например

он в alarm попадает вообще?

да, только я его завожу в виде патерна ^(?P<level>[013])$

аларм создается, письмо приходит а внутри конструкция {{ alarm.vars.level }} пустая

ps: в json переменной level нет