nocproject.org

zi_rus: а ты еще в Москве?

:)

а как отдебажить авторизацию по лдап?

на циске c2921 ошибка в get_switchport

http://pastebin.com/Grx1ktC2

dvolodin: не, две недели как вернулся

сеть запущена и работает

пользуйтесь

это вы пользуйтесь, мачты вам смонтированы, каналы организованы ;)

хотя посмотрим, мегафон в послежднее время упал ниже плинтуса

остальные двое - не лучше

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

,,

лдап авторизаци использует кто-нибудь?

https://pp.vk.me/c623422/v623422151/33c02/o7yx8DmX-Pk.jpg

e_zombie: какие ногти грязные!

:) такжешь без фотошопа жеж. там ещё волосков море

времени брить её не было

тоесть тебе не понравилась фотка ?

e_zombie: а как же стремление с идеалу, ради искусства

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

а готовые метрики для CPU Load у нас есть?

yum install python-devel

не туда :)

filonov: наверное нет, даже у одного вендора в одном профиле на разных железках это могут быть разные оиды

если запилишь

лол

будет круто

у длинка заебётесь

но делать надо...

длинк пофиг меня больше циска интересует

у ASR9k есть отдельный цпу на каждой линейной карте

а делать всё одно придётся общее решение

Зайдем с другой стороны - есть Custom | SNMP | OID

и как указать собственно OID

собсно берешь и указываешь

там все очевидно

где?

даже я нашел

было б очевидно - я б не спрашивал

freeseacher: конфлю умеет темплейты? (как в mediawiki)

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

авторизацию

openldap или 389 ds?

обнаружил баг - вешай внятный issue в bt

mandriva DS

на центосе??

lf

да

упрлс

пользователи в ноке н удаляются

это дистр такой

на основе сентоса

чего?

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

да, но есть роса линукс

бгг

и Денис Корявов, лол

э?

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

эпичные ошибки делал при пакетировании

впрочем, я за ними не слежу, всё могло измениться в лучшую сторону

zi_rus: я про Metric Sets а не про Metric Config

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

регайся

zi_rus: а ты графану хорошо изучил? всякие там авто-дашборды

ну и вообще изменение дашборда (скриптом)

а то, понимаете ли, хочется, но вникать не желаем-с.-)

а где собственно регистрация?

evyscr: там вроде были шаблонные дашборды

но в детали я пока не вникал

я вообще хочу автодобавление графика в row при появлении метрики

(я про errors на порту)

evyscr: не, и уже год не имею делов с графаной

хотя надо бы

регаться надо на bitbucket?

И таки кто подскажет - как настроить Custom SNMP Oid в MetricSet?

dvolodin: И таки кто подскажет - как настроить Custom SNMP Oid в MetricSet?

dvolodin: а почему в скрипте пишет что делает несколько подсоединений по ssh??

[Cisco.IOS.get_switchport] [192.168.222.1] [ssh] Connecting

[Cisco.IOS.get_portchannel] [192.168.222.1] [ssh] Connecting

teroni804: nice catch

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

NOC-1709

с Custom SNMP Oid я долго боролся, но так и не победил. правда это было в стабильной ветке, а не в develop, но думаю там мало что изменилось в этой части.

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

уже в самом ноке

хех

"стабильная ветка нока" - оксюморон

а что значит "обнулялась"?

значение в ноль или ещё что?

да, значение в ноль

сейчас не помню точно между какими модулями

но на входе метрика ловила значение в 56, писала об этом логи, а в следующем логе было видно как для нее же выставлено значение 0

kokozzi: а это точно был Metric Set?

и еще один NOC-1710

в Metric Set добавлял метрику Custom | SNMP | OID

kokozzi: и куда там ввести OID?

OID я в Metric Config вводил

Metric Config - это совсем другое. ТОгда понятно почему оно у тебя обнулялось

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

если в Metric Set можно добавить Custom | SNMP | OID, но он не связан с Metric Config - то я вообще не вижу способов скормить ему OID

kokozzi: о том и речь

и собственно зачем тогда нужен Metric Config?

kokozzi: для одиночных метрик не привязанных к объектам

окей, но это не объясняет обнуление значений

объясняет. Для Set-а нет источника данных - получаем нули

в итоге - баг или фича?

скорее баг с недофичей

раз заговорили про PM - никто не сталкивался с проблемой, что у свичей Cisco с интерфейсов не собираются ошибки? load при этом собирается

а значения ненулевые?

нулевые

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

а для свичей в графане даже нельзя выбрать пункт errors

ноковская осоюенность: пока нули - метрика не создаётся

да, это багофича

это бага, но с полезным эффектом

так что решили не чинить

интересная особенность, спасибо за информацию

zi_rus: это фича, пока не начинаешь делать дашборд

и вот тогда фича превращается в багу

извиняюсь, что встреваю, давно не смотрел, что там менялось в PM

оно до сих пор оторвано от SA ?

в смысле?

в смысле того, чт одля разных моделей железки могут быть разные OID, а определить железку может только скрипт SA get_version

evyscr: да, я тоже с этим столкнулся, поэтому и начали разбираться. но посмотри на другую сторону, нахуа забивать базу нулями

Dmitry1: с этим все пучком, отлько зависимость оида от железки никто не использовал, но dvolodin что можно

ага

т.е. длинки идут в топку

для меня PM попрежнему бесполезен

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

что запилить ?

1000 custom probes ?

dvolodin: что ему запилить?

по десятку на каждую модель длинка ?

если длинк такое говно, то да

нок тут не поможет

тебе уже ничто не поможет

у нас есть SA, который знает, для какой модели длинка что нужно делать

не знает, тащем-та

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

Dmitry1: он не просто знает, а ты сам лично хурил эти профили чтобы он знал

и с РМ тоже самое

DxS монструозен

захуяришь оиды и он тоже будет знать

root@noc:/usr/local/noc/fm/collections/mibs/DLink # ls | wc -w

117

und?

да, жопа

эта жопа называется длинк

root@noc:/usr/local/noc/fm/collections/mibs/Cisco # ls | wc -w

58

эта жопа называется циско ?

знаешь, у циски на cpu load явно меньше oid'ов

на порядки, я бы сказал

хорошо, специально для тебя

root@noc:/usr/local/noc/fm/collections/mibs/Cisco # ls | grep OLD | wc -w

4

навскидку

и что?

длинк от этого лучше не становится

а то, что стандартные пробы для этиз моделей циско (а список этих моделей знает только SA) идут лесом

которые?

что которые ?

IFMIB'овские?

да

да

стандартные пробы используют стандартные оиды, то что они на циске работают означает лишь то что циска следует стандарту

да прочитай, что я выше написал

лол, ты написал то, что сам не понял

загляни в OLD-CISCO-INTERFACES-MIB.mib

стандартные - это имеено ifmib'овские

и посмотри, какой там стандарт

всё остальное (в данном скопе) - отклонения от стандарта

SA как-то с этим разбирается

хреново, если честно

в нем можно сделать, что если такая-то модель с таким-то IOS - то дергать такой-то OID

как это можно сделать в пробе PM ?

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

ты упарываешься на ненужную тему

мне очень нравился NOC, ровно до версии 0.6.4

и говорить про привязку к sa в этом вопросе - глупо

после этого с него сделали монстра, который ломится на железки, просто так, ничего от них не получая

ну нету у меня такого OID, а NOC будет раз за разом долбить железку

Добрый день. У меня используется CISCO WLC 2504 какой профиль надо выбрать, чтобы железка бэкапилась по ssh? CISCO.IOS не подходит, как и CISCO.AireOS

Кстати, по длинкам

у меня есть еще и циски, и джунипер

и тоже, пришлось с них снимать калочку "is managed", потому как NOC ведет себя абсолютно неадекватно

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

мне тут вероятно могут навесить задачу управления и мониторингом пару тысячами свичей

подскажите, пожалуйста, есть ли более менее вменяемая альтернатива NOC ?

nagios рассматривал, но не подходит

пока присматриваюсь к d-view

dkul: писать свой.

если ни один не подходит .

а из-за чего interface discovery может становиться Suspend?

крешится .

дебаг проходит ?

Крешей нет, дебаг проходит.

самое странное что version inventory тоже Suspend. При том что там жестко вовзращаемые константы которые крешится не могут в принципе1

Я попробовал нарисовать Fake-профиль который гонит во всем кроме интерфейсов по SNMP

filonov: caps discovery?

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

Dmitry1: попробуй zenoss

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

забикс

evyscr: как раз caps вполне отрабатывает

зенос опен сорс не очень

хотя я смотрел его в году 2006-ом

у меня один знакомый заюзал где-то в районе 2010

я сам не вникал

кстати народ, немного в сторону вопрос, тут один товарищ прямо лестно отзывался об initi

evyscr: у тебя не видать неадекватного поведения потому что ты наверно не пытаешься использовать ssh на говнодлинках у которых проца даже на пинги не всегда хватает

там FM или тупая пинговалка ?

filonov: ну, не надо наступать на любимую мозоль Димы

да причем здесь длинки ?

у меня 6509 каталист

и что?

на нем поднят SLB

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

повесь багу на то, что ты считаешь неадекватным поведением

как на сайте пишут

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

silver1: нихерасебефамилия

вполне штатная фича, даже для ентерпрайза, как любит Дима

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

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

вот вопрос, просто мб кто тыкал?

мне нужно, чтобы FM поднимал аларм для опеределенных сообщений, и давил длядругих

у меня весь лог забит таким:

861682: Oct 27 16:52:21.105 EEST: %SLB-6-REAL: Real 10.117.0.15 (VPNFARM) has changed state to MAXCONNS

861683: Oct 27 16:52:22.001 EEST: %SLB-6-REAL: Real 10.117.0.15 (VPNFARM) has changed state to OPERATIONAL

861684: Oct 27 16:52:24.797 EEST: %SLB-6-REAL: Real 10.117.0.15 (VPNFARM) has changed state to MAXCONNS

861685: Oct 27 16:52:31.001 EEST: %SLB-6-REAL: Real 10.117.0.15 (VPNFARM) has changed state to OPERATIONAL

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

а вот если появится надпись %SLB-6-REAL: Real 10.117.0.8 (VPNFARM) has changed state to MAXCONNS

то нужно поднимать аларм

еще немного попахивает троль вопросом, но все же, а кто как смотрит на уменьшение функционала нока?

Dmitry1: блджад, назови уже bug number

как мне это сделать в текущем FM ?

Dmitry1: прислать патч

без bugno тебя не интересует решение

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

silver1: ты смотри миросервисы. девелопу осталось жить в таком виде два месяца

silver1: dvolodin уменьшает число зависимостей, но при этом добавляет в два раза больше новых

evyscr: какой такой баг ?

о, решение не интересно.

баг давно известный в classificationrules все поведение FM прибито гвоздями двухсотками

я смотрю микросервисы, омг, у меня глаза выкалываются как с ansible извращаются

bug no

номер, сестра, номер

silver1: самое время поучаствовать в этой вакханалии

e_zombie: а как быть не-метросексуалам?

нене, я пас. идея в том, чтобы прирезать скажем так 70-80% функционала нока, оставив норм кодовую базу

silver1: unreal

evyscr: задраить люк в танке на два месяца.

e_zombie: дык, я давно

silver1: в теории можно это пробовать сделать после сливания веток.

бгг

evyscr: нету номера. есть проблема, о которой все знают. проблема называется - невозможно управлять поведением FM

evyscr1: почему? мб вообще в новый проект выльется конечно

Dmitry1: нет бага - нет проблемы

аминь

Dmitry1: это из-за работы job'ов но там да - адский замес внутри)

silver1: а что именно ты бы прирезал?

какие нахер джобы ? вы код смотрели ?

filonov: я вот и спрашиваю у вас, что прирезать, потому что я по сути прогер а не сетевик, мне вообще все равно что прирезать

silver1: прирежь extjs

как вам такой код:

см. ткж. pagerless

if a.alarm_class.id in self.handlers:

for h in self.handlers[a.alarm_class.id]:

try:

h(a)

except:

error_report()

Dmitry1: да, там классы алармов дублируются тупо один в один

if r.alarm_class.id in self.triggers:

for t in self.triggers[r.alarm_class.id]:

try:

t.call(a)

except:

error_report()

найдите два различия

Dmitry1: там не только такого много, просто любое место можно открыть и придраться

я не про то

silver1: ты не в теме

а про то, что у нас сейчас есть следующие сущности: handlers, jobs, solutions, pyrule, actions

evyscr: extjs не правильно приготовлен, на манер еще 3 версии, там все в куче просто

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

сейчас добавились еще 4 сущности

которые такие-же, но с перламутровыми пуговицами

никто не знает, что они делают, никто, кроме Димы в них н еразбирается

запускаются они когда хотят и делают что хотят

Dmitry1: собственно я это и имел ввиду, когда писал про джобы, но 1 предложением не передать весь замес

управлять ими не возможно

silver1: ежели ты поправишь баги с extjs - народ тебе проставится

утраиваю

evyscr: какой баг? белый квадрат?

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

особенно мне нравится вот это:

потом след, нужны ли модули inventory и например configuration management?

693 2015-11-03 01:02:24 INFO(6) Safeguard Engine enters NORMAL mode

1692 2015-11-03 01:00:37 INFO(6) SNMP request received from 10.116.0.211 with i

nvalid community string!

1691 2015-11-03 01:00:35 INFO(6) Logout through SSH (Username: mitya,IP: 10.116

.0.211)

1690 2015-11-03 01:00:34 WARN(4) Safeguard Engine enters EXHAUSTED mode

1689 2015-11-03 01:00:10 INFO(6) Successful login through SSH (Username: mitya,

IP: 10.116.0.211)

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

Что он пытается получить от свича по SNMP, если в MO не прописан ни source_ip ни community ?

скучно

ну он сообщение по сислогу не ловил?

от safaguard

нет

safeguard сработал, когда загрузка процессора достигла 90%

я хз, я давно выключил всё, кроме сбора конфигов

я и сбор конфига выключил

Dmitry1: он пытается получить ровно то, что ты сконфигурил. А почему у тебя проц кончается - тебе известно

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

NOC по FM порлучает "config changed" и радостно начинает ломиться на этот же свич

в резвльтате тебя выкидывает со свича, загрузка процессора 100% - начальство ебет тебя в жопу

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

что тут правильного ?

нафига такая автоматизация нужна ?

те кто ходит на говнодлинки по ssh - должны страдать. Тут всеправильно

причем здесть длинк ?

у меня на столе 4 штуки allied telesyn

не хочешь получать конфиги - отключи..

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

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

я хочу, чтобы NOC заходил на устройства когда мне нужно, а не когда ему захочется ?

отключи шедулер

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

отключить трап на падение порта

отключить трап на reboot, start

вопрос - а нафига мне тогда такой FM ?

Dmitry1: а FM к твоих проблемах не имеет ни малейшего отношения

а нафига мне FM без трапов?

filonov: как мне отключить это:

"handlers": [

"noc.fm.handlers.event.audit.log_started",

"noc.fm.handlers.event.discovery.schedule_discovery"

],

"handlers": [

"noc.fm.handlers.event.audit.log_reboot",

"noc.fm.handlers.event.discovery.schedule_discovery"

],

Dmitry1: в РМ это можно сделать. чтобы с длинка дергались другие оиды, я dvolodin проел всю плеш про это, он сказал что можно

"handlers": [

"noc.fm.handlers.event.link.oper_down"

],

почитай в irc log

он даже применры приводил

декораторы видимо

надо использовать

гм. Нок подумал и version_discovery разсуспендил. Теперь бы интерфейсы того

народ, такой вопрос, допустим мы прирезаем job, actioan pyrule и проч и сводим в один механизм, в итоге у нас нах отлетает работа вообще всех модулей. И надо модули нацепить на новый единый механизим

какие модули цеплять в первую очередь?

SA

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

SA - самый главный модуль NOC

только он знает, какие возможности у какой железки

а не PM

root@noc:/usr/local/noc/pm/probes # ls

Cisco __init__.pyc base.pyc generic match.pyc

__init__.py base.py db match.py test

Вот как раз его и надо переделывать в первую очередь

где гвоздями прибиты какие-то куски от Cisco

ты про чтобы он ходил по telnet/ssh , получал интерфейсы, и проч инфу?

что в PM делают пробы от Циски ?

silver1: нет, глянь тот же профиль длинка

где в L2 свичах не пытается искаться информация про PIM, BGP, OSPF и т.п.

вроде была здравая идея про cfpfbilities

понял, надо сделать так, чтобы нок не лез на эти железки за этой инфой? (PIM, BGP, OSPF)

не только

(13:11:30) Dmitry: root@noc:/usr/local/noc/pm/probes # ls

(13:11:30) Dmitry: Cisco __init__.pyc base.pyc generic match.pyc

(13:11:30) Dmitry: __init__.py base.py db match.py test

root@noc:/usr/local/noc/pm/probes/Cisco/IOS # ls

__init__.py __init__.pyc bras.py bras.pyc

у нас получается, что все циски 100% выступают в роли BRAS

кстати, в профиле MO есть такая замечательная вещь, как аттрибуты, куда можно положить информацию, которую потом будет использовать PM, FM, Inventory и т.п.

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

Так для Probe у нас появились Actions, для FM - handlers, для inventory - jobs и solutions

я по этому поводу приводил хорошиц пример

вот кусок кода:

/* First check our stat list for known short names */

for (k = 0; k < NUM_STAT_PROTOCOLS; k++) {

if (proto == statProtos[k].proto)

return(statProtos[k].name);

}

/* Now look in list of all defined protocols */

key.proto = proto;

if ((pn = bsearch(&key, protoNames,

NUM_PROTO_NAMES, sizeof(*pn), ProtoNameCmp)) != NULL)

return(pn->name);

silver1: я бы начал с переделки иерархии классов. Дабы можно было плодить сущности для очень похожих моделей с немного разными фичами

в первом цикле тупо идет сравнение, а во втором - автор решил показать, насколько он крутой

так вот, разных мест в NOC, где автор показывает, насколько он крутой - полно

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

соответсвенно - разработчиков, которые могут чем-то помочь автору - 0

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

мне кажется, таких мест очень много

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

простейший пример

раньше, чтобы добавить/изменить правило FM, достаточно было отредактировать текстовый файл

я уже видел, __init.py__ что может быть пустой или с портянкой

куча текстовых обращений и игр getattr setattr

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

Я таки победил suspend. Хотя и весьма радикально

в результате - за последние года два количество изменения в правилах FM уменьшилось раз в десять

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

да, еще в пробы PM

как по мне - проект развивается в каком-то неизвестном направлении, не применимом в реальной жизни

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

filonov: он еще в suspend укладывал задачи для упавших объектов

чтобы SA не трясти

dvolodin: точно в suspend а не в disable?

вот этого не помню

dvolodin: в любом случае пинговалка не работает у меня

но прикол в другом - interface_discovery все равно fail. Debug-script отрабатывает нормально. Куда смотреть?

silver1: все, что может быть отрезано, уже отрезано в микросервисах

silver1: а ты что скажешь про initi?

dvolodin: а почему в скрипте пишет что делает несколько подсоединений по ssh??

[Cisco.IOS.get_switchport] [192.168.222.1] [ssh] Connecting

[Cisco.IOS.get_portchannel] [192.168.222.1] [ssh] Connecting

teroni: потому что это разные скрипты

teroni: вот это посмотрю

не доолжно

filonov: нет, они одним коннектом пользуются

вот ситуация

сейчас нужно настроить новую железку

я вынужден спрашивать напарника, какой у нас свободный IP есть

у него стоит The Dude

наш IPAM заносит в себя что угодно, но только не IP реальных железок

Приличные люди сначала выделяют адрес в ipam, потом прописывают его на железку

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

наверное, нужно разделить ip discovery для интерфейсов и для arp-кеша в разные виды

первый нужен почти всегда

второй - сильно зависит от условий применения

надо

в микросервисах они как раз попадут - один в box, второй в periodic discovery

dvolodin: а как мне для циски повесить метрики на транк? а не на каждый отдельный из интерфейсов транка

вполне штатная ситуация, когда в подсети выделяется один или несколько диапазонов адресов для DHCP клиентов, а часть адресов - для оборудования

такое умеют даже китайские роутеры

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

filonov: к сожалению, то, что недопустимо, всё равно может присутствовать...

evyscr: Это уже организационная проблема а не техническая

50% Диминых проблем связаны с организационными причинами. От него они не зависят

а жить как-то приходится...

но далеко не все сценарии стоит тащить в NOC

DGS-3627G:admin#show dhcp excluded_address

Command: show dhcp excluded_address

Index Begin_Address End_Address

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

1 10.109.12.1 10.109.12.4

2 10.109.12.6 10.109.12.10

3 10.109.13.1 10.109.13.4

вообще, все сценарии надо тащить в том смысле, чтобы нок, увидев такое, не сходил с ума

4 10.109.13.6 10.109.13.10

5 10.109.14.1 10.109.14.4

6 10.109.14.6 10.109.14.10

7 10.109.15.1 10.109.15.4

8 10.109.15.7 10.109.15.10

(и в трейс не падал)

на свиче где-то 1500-2000 абонентов, подключенных по DHCP

evyscr: тогда мы погрязнем в частностях

в сетях, которые находятся в exluded - оборудование

dvolodin: нет, надо просто задачу разбить на кучу мелких

более перспективный подход -- некая базовая платформа, которая работает для 80% инсталляций

dvolodin: организационные проблемы очень плохо решаются техническими методами. Иногда - вообще не решаются.

и возможность допилки под контретные случаи для оставшихся 20%

у нас ip адреса могут собираться двумя способами - get_interface и get_arp

filonov: моя политика -- я не решаю организационные проблемы техническими методами

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

одно из направлений использования NOC - именно форсирование определенных административных политик на техническом уровне

и контроль за их выполнением

Dmitry1: я и говорю -- два независимых метода ip discovery

они и сейчас независимы

dvolodin: и это правильно

только ip discovery на интерфейсах включается только если включен общий ip discovery

также, два независимых метода собирания MAC адресов

который тянет get_mac

MAC'и интерфейсов и так укладваются в базу

в MAC DB они не нужны, я уже говорил почему

итого - в микросервисах я разделяю ip discovery отдельно для box, отдельно для periodic

согласен, что давно уже пора

тогда нужно завести базу macdb2, гду будет такой же поиск, как и в базе macdb, и куда будут укладываться mac адреса ecnhjqcnd

устройств

зачем

если они уже лежат в интерфейсах

:)

и эти MAC'и, кстати, анализирует discovery

lldp, например

у нас нету возможности просмотра и поиска по MAC адресу, как в таблице macdb

а что мешает ее сделать?

глобальный поиск, кстати, ищет

я же и говорю, сделат таблицу macdb2, по внешнему виду 100% совпадающую с macdb, но содержащую MAC адреса устройств

Dmitry1: а зачем тебе две одинаковых таблицы?

наоборот, мне нужна только таблица с MAC адресами устройств

dvolodin: выше отписал про инити

MAC адреса клиентского оборудования меня не интересуют

хотя две таблицы это лучше, чем одна

стандартная ситуация

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

часть абонентов подключена через wifi

китайские wifi роутеры не умеют vlan, поэтому их MAC адреса в одном влане с абонентами

а иногда, как я выше приводил, еще и в одной подсети с абонентами

по статистике, если Дима хочет, чтобы NOC заводился на 80% инсталляций

то таких провайдеров на 500 абонентов в 1000 раз больше, чем крупных, типа Ростелекома

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

dvolodin: выпилено то будет, а вот нормально зарефакторено - нет

Dmitry1: у ростелекома абонентов больше, чем у 500 мелких операторов

silver1: почему?

dvolodin: и толку ? вот купил ростелеком сетку в каком-то городе, а там 20 тысяч абонентов на длинках

и что теперь ?

В РТ запрещено покупать сети

уже года три как

и правильно

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

dvolodin: Дим, я не прошу все выкидывать. Я прошу только возможность управления всеми потрохами

silver1: с какой целью рефакторинг?

из-зп прибитых гвоздями хандлеров меня чуть не оштрафовали на деньги

чуть не считается

опять же -- часть твоих проблем решается в микросервисах

Дим, когда крадут субмагистральный коммутатор, то время замены его идет на секунды, И некогда в это время лазить в админку NOC и выключать/включать какие-то вещи

опять организационная проблема

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

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

как тебе помешают job'ы на сворованные коммутаторы?

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

dvolodin: с целью того, ликвидации технеческого долга

?

рефакторинг какой ветки?

dvolodin:* с целью ликвидации технического долга

и каких модулей

всего проекта, целиком

dvolodin: лови программиста в свои тенета, пока не ушёл

а смысл мероприятия, если не сеерет?

поддержка проекта

понижение порога вхождения

учёт регрессий

ликвидация явных ошибок

смысл в том, что если охота дальше заниматься 1 му, то окей

примерно 170k строк кода с огромным количеством логики внутри

и я про это первый раз слышу

да еще про initi спрашивает ;)

пока ценность имеют только профили SA и правила FM

это то, что привлекает народ

мне уже даже интерсно :)

уже готовая база для более 40 вендоров

это самя сильная часть NOC

70 вендоров

:)

dvolodin: ты уже сделал отслеживание результата выполнения операций в монге?

slowops?

если уменьшить количество вендоров до одного, то никакой PM, IPAM и Inventory не нужен

монга сама их писать умеет

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

(из алярмов, ай мин)

evyscr: они точно не трутся как дубликаты?

и их не вытирает fm.archive?

ояе^Hзнаю?

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

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

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

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

(на сейчас)

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

silver1: и каков результат ?

silver1: NOC-1651

teroni: да, я облажался

дочерние скрипты открывают свой коннект

сейчас поправлю

:)

dvolodin: я тебе так сразу и сказал :)

silver1: ping

filonov: не сомневаюсь

dvolodin: а скажи, навскидку, будет ли в микросервисах в активаторе разделение на те же ping, telnet, snmp, ssh ?

???

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

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

Dmitry1: почему?

опять же, если у MO нет ssh, зачем нам совершать лишние телодвижения ?

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

и делает все

пингует

телнетится

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

счетчики дергает

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

22468 noc 55 52 0 696M 356M uwait 1 267.8H 104.00% python2.7

22464 root 1 76 0 134M 83836K select 3 243:02 45.17% python2.7

10813 noc 1 100 0 102M 43524K CPU0 0 0:02 18.36% python2.7

22465 noc 1 46 0 171M 105M select 1 435:10 2.49% python2.7

22469 noc 1 45 0 291M 219M select 1 314:51 2.10% python2.7

22463 noc 1 45 0 133M 67156K select 1 385:59 1.37% python2.7

./noc ctl status

activator-default:activator-default-00 RUNNING pid 16912, uptime 0:12:19

classifier-default RUNNING pid 24810, uptime 4 days, 16:48:40

correlator RUNNING pid 24811, uptime 4 days, 16:48:40

discovery-default RUNNING pid 8055, uptime 3 days, 1:09:31

fmwriter-default RUNNING pid 24796, uptime 4 days, 16:48:40

omap RUNNING pid 24805, uptime 4 days, 16:48:40

ping-default RUNNING pid 24800, uptime 4 days, 16:48:40

probe-default RUNNING pid 24815, uptime 4 days, 16:48:40

probeconf-default RUNNING pid 24797, uptime 4 days, 16:48:40

sae RUNNING pid 24813, uptime 4 days, 16:48:40

scheduler RUNNING pid 24814, uptime 4 days, 16:48:40

syslogcollector-default RUNNING pid 24806, uptime 4 days, 16:48:40

trapcollector-default RUNNING pid 24799, uptime 4 days, 16:48:40

web RUNNING pid 28947, uptime 4 days, 4:47:16

ага, т.е. уже пинг и активатор - это разные процессы

Dmitry1: это ты нок так доканал

Dmitry1: и коллекторы syslog/snmp trap тоже отдельные

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

уже лучше

а по FM

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

эм

они и сейчас разделены, не?

у нас сейчас классификатор занимается кучей разного

хандлеры, триггеры, disposition

кореллятор так само

ох, ну так формулируй однозначно

формулирую

сказал так, что предлагаешь отделить классификатор от коррелятора

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

в нее всунуть триггеры, хандлеры и т.п.

у кореллятора так само

классификатор долден только распознать syslog или trap, а дальше отправить его по цепочке

50-80% ивентов "умрут" еще на этапе классификатора как "unknown" или просто "информационные"

кореллятор тоже не должен делать что-то типа "actions", а передать это на следующую инствнцию

например

у нас пришел ивент "CRIT(2) Port <1:25> SFP RX power exceeded the low alarm threshold "

в алармклассе мы хотим показать вывод команды "show ddm ports 25 status"

эту команду должен запускать не кореллятор

нет, так не будет

классификатор тоже в пуле со своими железками

повторюсь

задача классификатора -- предварительная обработка событий и выделение потенциально аварийных

(15:33:45) Dmitry: 50-80% ивентов "умрут" еще на этапе классификатора как "unknown" или просто "информационные"

вот

задача коррелятора -- определение, что событие действительно аварийное и проведение RCA

а "потенциально аварийные", а заодно те, для которых нужен iventtrigger, handler кто обрабатывать будет ?

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

этим ты наполовину снизишь нагрузку на обработчики

классификатор вообще не должен знать о таких вещах, как eventtrigger, handler и т.п.

ему хватает того, что он парсит мибы, коллекции и т.п.

ну почему же

eventtrigger -- реакция на приход события

равно как и handler

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

да нет, не стоит

Дим, не лепи монстра

handler'ы легковесны

не лепи сущностей сверх меры

:)

нисейчас никто кроме тебя не разбирается кв классификаторе и корелляторе

классификатор работает с событиями, коррелятор с авариями

ты предлагаешь сделать еще один обработчик

да

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

который будет посредине

и считаешь, что после этого со всеми этими тремя монстрами все сразу разберутся

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

https://pp.vk.me/c623422/v623422151/33bf8/3GmCO55X9is.jpg

dvolodin: почему ? классификатор упростится до минимума

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

Dmitry1: код запуска триггеров и handler'ов в классификаторе - 10 строчек

:)

да ?

функция load_triggers - 20 строчек

и содержала в себе баг, хехе

load_link_actions

кстати вопрос, а зачем было делать два scheduler'a в виде legacy, если есть celery?

load_handlers

resolve_handlers

продолжать ?

кусочек письки!

https://www.instagram.com/p/9_KR8qzQ0M/ теперь 3 компа и один ноут ))))

Из всего - реально работать должны следующие условия:

if rule is None:

if rule.to_drop:

if rule.is_unknown_syslog:

и добавить условие, что обработка ушла следующему демону

silver1: из celery плохой scheduler

точнее, celery вообще не scheduler

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

dvolodin: а что насчет регулярных и отложенных тасков?

ну смотри

scheduler NOC'а цепляется за монгу и ему ничего не надо

для celery - нужен эрланг, кролик, сами процессы celery

что выпилить из нока? :)

http://forum.nag.ru/forum/index.php?showtopic=47185&view=findpost&p=1198908

поставил и забыл

причем во flower можно посмотреть как таск упал

а в скеджулере

я два дня прокопался

почему wipe кривой

потом батюшки очепятка в апи

и он просто игнорился

dvolodin: я все-таки мечтаю, чтобы NOC научился как-то работать с ивентами, а не тупо поднимать по ним алармы

сделай обработку в post save

=)

поэтому логику работы с уже распарсенными ивентами предлагаю вынести в отдельный демон

их и так коллектор, классификатор, который как раз работает с ивентами и коррелятор

тогда классификатор 100% не будет лезть в базу

а промежуточный демон - в зависимости от настроек

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

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

ох

Dmitry1: классификатор занимается обогащением событий

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

как ему не лезть в базу?

у нас при обработке ивента происходят следующие события

chaotism: для этого нужен эрланг и кролик?

1 - определить, какому ивентклассу принадлежит событие

2 - вытащить из ивента переменные

или просто нормальная морда для просмотра статусов job'а?

3 - отдать их вышестоящему демону

зачем туда засовывать триггеры, хандлеры и т.п. ?

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

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

chaotism: оно есть в репах сентоси?

chaotism: и в установке тоже

postgis нам в свое время крови вылакал ведро

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

не вспоминайте про постгис

умоляю

и его выпилили при первой же возможности, как spatial index появлился в монге

Dmitry1: а профит?

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

chaotism: не совсем

профит - классификатор никогда не лезет в базу. 10%

100%

10%

Ж)

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

для этого, о чем я говорил вчера

я когда копался почему, пинги на карте имеют, отклонения по времени, просмотрел путь от sa до отрисовки

передача через job -- рудимент

job уже deprecated?

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

я не успеваю за полетом мысли

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

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

dvolodin: т.е. ты предлагаешь ивенттриггеры и хандлеры засунуть в кореллятор ?

начиная от простановки флажка - to_dispose в active event

да

и постоянного сканирования событий

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

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

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

он ничего не должен знать ни о каких RPC

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

собственно суть такая

убить коллекции noc.events.new и noc.events.failed

fmwriter пусть пишет события сразу с классом New

и классификатор выбирает их по классу

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

dvolodin: тогда уж подумай, как сохранить бывший mo. Иметь его интерфейсы, но выбросить их из discovery

evyscr: ?

объединили две железки в стек

neighbor discovery накрылся, вестимо

и?

зафонтанировали идеями что-то

хочу сохранить историю mo

хоть форум назад поднимай

поздно

TSergey уже ушёл

dvolodin: в noc/fm/models eventclass.py имеет размер больше, чем alarmclass.py

хотя должно быть наоборот

доебался до размера

zi_rus: я имею ввиду, что классификатор выполняет работы больше, чем кореллятор

а должно быть наоборот

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

микросервисы на вас плохо влияют

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

надо больше демонов

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

зачем эта порнография

zi_rus: горизонтальной масштабирование

коррелятор без классификатора нахрене не нужен

dvolodin: 10 одинаковых демонов

если хочешь

просто есть же зависимости

zi_rus: нет, тут конвееризация обработки

и потери производительности на переходах

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

да, именно

смотри

пусть у нас overhead на RPC - 10%

и одно ядро

народ, я с деревни, я вот не понимаю в чем цимес noc-tower? почему это киллер фича?

silver1: этого никто не знает

и не только об этом

ты еще workflow не видел

свой ansible-tower?

silver1: в микросервисах много процессов и их правильно нужно настроить

и они расчитаны на большое количество нод

на первом этапе мне нужно, чтобы он спокойно переварил сотню нод

в общем создать себе проблему, а потом героически ее решить

а то еще подумают что бездельник

и уволят

первая проблема, которая возникает - service discovery

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

и готовит статический файл конфига

и настраивает supervisord на нодах

сервисы после запуска сцепляются в нужную топологию

если не будет башни, то нужен либо свой механизм service discovery

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

либо встраивать его в демоны

Dmitry1: лолъ. Ты (как и я) не вписался в рынок

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

Dmitry1: твоя проблема никого не бодает,

Дим, одна нода едва тянет средний региональный филиал РТ

запаса почти нет

дане важно

итого первая задача башни - статичный service discovery

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

дальше -- уперлась нода в полку - добавляешь еще одну и скидываешь на нее часть сервисов

руками -- очень муторно

в башне выкладка делается в несколько кликов

т.е Нок у нас мониторит условно средний региональный филиал, и когда одна нода не справляется, нам надо раскатывать вторую?

silver1: не совсем так

смотри

часть сервисов работают на уровне РФ

часть - на уровне макрорегионов

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

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

ну и плюс в RPC встроен балансирощик

да, у меня схема есть

я же и говорю, где-то 50% ивентов требуют дополнительной обработки

а можно глянуть плз

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

да, сейчас выложу

dvolodin: так, это понял. (еще схему гляну) и готов дальше понимать в чем замысел noc-tower помимо того, что уже обсудили

второй ее замысел -- мониторинг NOC

:)

чтобы в одном месте все видеть

понял, а в ноке что мониторим?

а я-то, по серости, думал, что надо оптимизацией кода заниматься...

silver1: я себя тоже считаю программистом, но гланув на потроха NOC. прослезился, и понял, что ничего в этом не понимаю

evyscr: мне вот тоже так кажется

https://www.dropbox.com/home?preview=NOC.pdf

Dmitry1: да там ада много

silver1: каждый сервис содержит встроенный мониторинг, доступный по URL /mon/

или я в объектно ориентированном программировании ничего не понимаю, или это какая-то специфика NOC

both

с последним коммитом в девелоп http://imgur.com/e5N7936

забавно

а у меня без него недосчитывает

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

silver1: открылась схема?

dvolodin: не вижу по ссылке, у меня просто в домашную папку

https://www.dropbox.com/s/qknax40s1zc9uqb/NOC.pdf?dl=0

вот так

e_zombie: слышь, тебя спрашиваю же

насколько я читал Кнутта, так ООП специально создано, чтобы избавиться от записей вида "alarm.managed_object.object_profile.down_severity"

чё на ?

17:37:55 < evyscr> локальные патчи есть?

парчей нет. есть наброски для профилей .

Dmitry1: кнут не писал про ООП

для дсламов хуавеев

:)

ну не знаю

ООП 70-х, это smalltalk

e_zombie: тогда надо смотреть в монгу

для SA как-то получилось все методы засунуть в объект NOCProfile ?

и как итог - куча контрибуторов

и то, у нас два обхекта NOCProfile и NOCScript

и народ теряется

давайте добавим монады?

опять же, хорошо документированные интерфейсы с примерами

ты предлагаешь объединить классы Кошка и Собака в мегакласс Котопес

я не против, но где же жопа?

да, потому как у них 99% общего

да

под систему с нодами и портами docker

в твоей логике у них общее - отсутсвие жопы

я уже пару лет предлагал объединить в один класс хандлер, триггер, джоб, солюшн

и у нас появилась еще пятая сущность - action

я же писал, что криво сейчас

хандлеры запускаются только из FM

actions только из PM

джобы только из Inventory

хотя 90% кода там общего

e_zombie: сделай 'hg status fm/apps/reportoutages/views.py'

и панельку управления тогда прийдется писать одну, а не пять штук

[root@nocproject noc]# hg status fm/apps/reportoutages/views.py

Not trusting file /opt/noc/.hg/hgrc from untrusted user noc, group noc

Not trusting file /opt/noc/.hg/hgrc from untrusted user noc, group noc

[root@nocproject noc]#

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

а петон какой?

dvolodin: расскажи, в чем я не прав

Для FM у нас тогда вызов disposition, handlers или pyrule будет абсолютно прозрачным

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

и IPAM

e_zombie: ещё в монге сделай db.noc.fm.outages.find({"object": ID}), где ID - id верхнего mo

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

я же предлагал с самого начала разработать механизм RPC

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

> db.noc.fm.outages.find({"object": 91140})

{ "_id" : ObjectId("553ab925989fcf30b9dc7b00"), "object" : 91140, "start" : ISODate("2015-04-25T00:44:05.671Z"), "stop" : ISODate("2015-04-25T01:13:21.428Z") }

{ "_id" : ObjectId("553ac2c8989fcf30b9dcca3d"), "object" : 91140, "start" : ISODate("2015-04-25T01:25:12.019Z"), "stop" : ISODate("2015-04-25T03:45:18.834Z") }

{ "_id" : ObjectId("553ae441989fcf30b9dd9671"), "object" : 91140, "start" : ISODate("2015-04-25T03:48:01.351Z"), "stop" : ISODate("2015-04-25T05:00:14.444Z") }

{ "_id" : ObjectId("553af6ee989fcf30b9de5dad"), "object" : 91140, "start" : ISODate("2015-04-25T05:07:42.057Z"), "stop" : ISODate("2015-04-25T05:20:05.247Z") }

и тд

{ "_id" : ObjectId("56136a5c989fcf36ab9f3e85"), "object" : 91140, "start" : ISODate("2015-10-06T09:29:48.477Z") }

вот подозрительная запись

dvolodin: теперь ты пытаешься изобрести новый механизм в PM, называя его action

{ "_id" : ObjectId("558abfe1989fcf2afa38ed2a"), "object" : 91140, "start" : ISODate("2015-06-24T17:34:09.592Z"), "stop" : ISODate("2015-06-24T17:36:26.934Z") }

{ "_id" : ObjectId("558b9002989fcf2afa3fb93f"), "object" : 91140, "start" : ISODate("2015-06-25T08:22:10.284Z"), "stop" : ISODate("2015-06-25T08:23:52Z") }

{ "_id" : ObjectId("558bb13c989fcf1cde7a8076"), "object" : 91140, "start" : ISODate("2015-06-25T10:43:56.800Z"), "stop" : ISODate("2015-06-25T10:45:23.756Z") }

evyscr: http://pastebin.com/kLVwLErM

это не всё

хотя это все тот же RPC

вот тебя унесло

action -- типизированный сниппет

точнее -- возможность дать группе сниппетов осмысленное название

а хандлер ?

а пируле ?

а джоб ?

а солюшн ?

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

те же яйца, только сбоку

handler - хочешь, назови его плагином

у меня дебильный вопрос: почему я не могу вызвать action из FM, а только из PM ?

а ханлер только из FM, но не могу из PM ?

e_zombie: по идее, у тебя там могут быть две незакрытые записи

у меня аварий по этой железке нету.

И еесли уж

(16:56:32) dvolodin: action -- типизированный сниппет

(16:56:57) dvolodin: точнее -- возможность дать группе сниппетов осмысленное название

(16:57:32) dvolodin: и выбирать правильный вариант команд для достижения одного и того же результата для разных железок

что он делает в PM, а не SA ?

походу ещё одно добавление в noc fix на проверку валидности этой таблицы.

я реально, столько не выпью, чтобы понять эту логику

где ты увидел action в pm?

он в SA

:)

evyscr: ха. а оно в дауне.

сорри

e_zombie: сделай db.noc.fm.outages.find({"object": 91140, "stop": null})

> db.noc.fm.outages.find({"object": 91140, "stop": null})

{ "_id" : ObjectId("55781d8c989fcf06501827e8"), "object" : 91140, "start" : ISODate("2015-06-10T14:20:44.686Z") }

{ "_id" : ObjectId("56136a5c989fcf36ab9f3e85"), "object" : 91140, "start" : ISODate("2015-10-06T09:29:48.477Z") }

>

ну вот

я имел ввиду, зачем в action писать {% ifequal address.afi "4" %}

ping {% if vrf %}vrf {{vrf.name}} {% endif %} {{address.address}}

{% else %}

ping6 {% if vrf %}vrf {{vrf.name}} {% endif %} {{address.address}}

{% endifequal %}

алярвы в архиве с дауном этой железки. уже как 28 дней

e_zombie: патч правильный, данные в таблице поломаны

Dmitry1: зачем есть шаблоны, когда можно кодом сгенерить строки

если у нас есть скртипт sa/profiles/Cisco/IOS/ping.py

cgi рулит

evyscr: значит это надо в noc fix вкрчивать

а хрен его знает, как его правильно фиксить

надо придумывать какой-то "stop" date

я имел ввиду "action command", который зачем то дублирует скрипты SA, но при этом теряет 90% их функционала

на 1 секунду больше и всё

там нет stop'а?

или что?

да

в двух записях

то есть не null, а посто нет?

угу

{ "_id" : ObjectId("56136a5c989fcf36ab9f3e85"), "object" : 91140, "start" : ISODate("2015-10-06T09:29:48.477Z") }

null - это аналог $exists: false

dvolodin: смотри, сам "action" в SA вроде как нормально задуман. Есть скрипт, есть переменные, которые ему передаются

точнее, включает в себя

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

добавить еще возможность принимать переменные

и готовая обертка для хандлеров, джобов, солюшенов, триггеров

e_zombie: не, ребуты были пофикшены раньше

я ж возмущался-)

dvolodin: как тебе такой вариант ?

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

А вместо "action command" будешь запускать реальные триггеры, хандлеры и т.а.

это много где вылезти может .

придётся-придётся

e_zombie: в общем, если ты сдавал отчёты руководству - ты его слегка обманывал

всем охуй (с)

тож верно

здесь на них только я смотрю иногда

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

блин, потратил три часа времени, но Дима остался при своем мнении

мысль вечна.

вернее идея.

e_zombie: давай пиписьки пость

... и достал бутыль горилки

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

но специально для тебя повторю

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

https://pp.vk.me/c623422/v623422151/33c02/o7yx8DmX-Pk.jpg

https://pp.vk.me/c623422/v623422151/33bf8/3GmCO55X9is.jpg

Dmitry1: это можно доказать только деньгами

ну и экслюзив https://pp.vk.me/c623422/v623422151/33ae8/UpoxkllpKwI.jpg

Ааааа ! волосатая !!!!

ну и если не видел https://pp.vk.me/c629313/v629313151/20608/2U2xx4W8hRw.jpg

спакуха. это без ретуши.

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

evyscr: народ готов платить, но их отпугивает то, что им прийдется кроме всего прочего у себя содержать на полную ставку программиста на питоне, а также специалиста по mongodb и postgresql

одного программера достаточно .

питон + js

не так уж и большой объём работ

т.е. ты предлагаешь провайдеру на 500 абонентов нанимать себе на полный день программиста на питоне ?

платить dvolodin напрямую

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

e_zombie: потому как в том же FM чуть ли не в зависимости от фазы луны должна быть разная реакция на события

А у димы один ответ - пишите хандлеры и солюшены на питоне

не хотите писать - заплатите тому, кто напишет

начиная с определённой суммы dvolodin, подозреваю, выполнит любые пожелания

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

это даже не питон, а regexp

у меня вполне успешно живёт в ignore event rules

какой регексп ? прям в хандоере ? а ничего, что хандлер написан на питоне ?

"подавить событие" && "хэндлер"?

да

а еще какой-то способ есть ?

написать pyrule на том же питоне ?

или написать солюшн на том же питоне