nocproject.org
04:27
05:02
dvolodin: привет
05:02
05:02
Задача подзадержалась
05:03
и два активатора даже киллом не снимались
05:03
ребутнул виртуалку
05:03
видимо потом разбежалось
05:03
еще был файлик крэша
05:04
периодически обновляемый
05:07
05:07
вот такой патчик должен помочь
05:09
кстати советую его всем, у кого ReduceTask.DoesNotExist в SAE вылезает
05:10
Брювет! Что свежего запилили в NOC?
05:10
dvolodin: ты его будешь в патчи добавлять?
05:11
у меня почему-то пасти закрыт
05:11
и не умею я ставить патчи вот так отдельно
05:12
hg import -f --no-commit <путь к патчу>
05:13
запускать в /opt/noc ?
05:31
У кого есть в эксплуатации Huawei S2300/S3300/S5300 ?
05:32
dvolodin, ты можешь объяснить что ты делаешь?
05:32
треш какой-то в коммитах
05:32
то пулы, то ofm
05:33
crm какой-то получается
05:33
а графики рисовать так и не умеет
05:33
где в коммитах ofm :)
05:35
не путай CRM и OFM/OMS
05:35
второе -- исполнительный механизм для первого
05:35
ss_: есть 93/53/23хх
05:36
In-nick, QoS на них поднимали?
05:36
да по-моему все в кучу, тебя видимо кто-то очень вежливо попросил...
05:37
по-моему все весьма последовательно
05:38
прикручиваем к физическому inventory проверку техвозможности, сервисы и обработку заказов
05:38
Жаль, QoS уже надо поднимать, ТВ + 100 мег тариф сыпет ТВ
05:40
привязка портов к клиентам нужна?
05:40
не клиентам а сервисам
05:40
вернее сервисов к портам
05:41
есть порт, есть список сервисов на нем
05:44
к сервисам клиентов
05:44
или к внутренним
05:44
вот это все в OFM и есть
05:46
что тебя смущает?
05:46
там же -- автоматическое выделение и бронирование ресурсов
05:48
меня смущает что это не первоочередная задача нока
05:51
если нок OSS, то мне кажется что для него важнее было бы уметь более приземленные вещи типа постройки графиков (с некоторыми плюшками), автодискавери железок, из продвинутого работа с бридж-доментами
05:52
это простое и пригодилось бы всем
05:52
твои сервисы не нужны корпоратам
05:52
мелким шпдшникам тоже
05:53
а у крупных свои системы в работе
05:54
вряд ли e_zombie1 или freeseacher начнут нок в таком контексте использовать
05:54
такое мое мнение
05:55
спакуха. у нас такого нет и не надо.
05:55
на пинговалки хватит за глаза
05:55
e_zombie1: у вас такое есть, но кривое и вы не умеете им пользоваться ;)
05:55
только ядро и часть агрегации. доступа там нету.
05:56
ионикс такой ионикс
05:56
какой в пизду аргус?
05:56
lol what?
05:57
не шути так. я от празников не отошёл ещё
05:57
торопись
05:57
спереди следующий
05:58
я больше не выспался.
05:58
на след поеду к родителям там и отосплюсь
05:59
вы там георгиевские ленточки на хуавеи и джуниперы уже повязали?)
05:59
с табличкой - "трофейный")
06:00
ээээээ? кто упоролся? я не
06:00
вяжет Юг, а не Волга
06:00
;)
06:01
ну вот, как я и говорил
06:01
вы чо, а вдруг трафик фашистский будет
06:01
"тебе это надо? - нет"
06:01
а то и того хуже - бендеровский(шепотом)
06:01
Я готов поспорить, что Juniper'у резко сделают плохо
06:01
" a тебе это надо? - нет"
06:01
ye hfp yflj pyfxbn yflj
06:02
ну раз надо, значит надо
06:02
zi_rus, у тя хуявей есть?
06:02
нет
06:02
а нет
06:02
есть дслам
06:02
один
06:02
или два
06:03
мне доступ нужен FTTB
06:03
)
06:03
у ufir есть
06:03
но он бухает.)
06:05
Huawei S2326TP-EI Huawei S5328C-EI-24S
06:10
ss_: у меня вот такое стоит на доступе и агрегации
06:11
e_zombie1, а QoS Поднимали на них?
06:12
вроде ебались с этим для айпитивишного трафа, но подробностей не знаю.
06:12
e_zombie1, в конфиге есть что нить?
06:14
а скажи что в конфиге искать а
06:14
trafic classificer
06:14
traffic classifier traffic behavior
06:15
traffic policy
06:15
qos local-precedence-queue-map
06:15
и acl завязяные на эти правила
06:15
local-precedence-queue-map нету нигде
06:16
счас спрошу тех кто работал с этим
06:16
qos начинается
06:17
что то я мучал мучал, даю иперфом 100 мегабит и ТВ мрет
06:54
ss_: у нас тут в районе свет дёрнули поэтому чуть позднее дам что у нас строили
06:54
e_zombie, ок, подожду
07:25
e_zombie, спасибо, изучу сейчас
07:26
у вас сразу идет трафик маркированый?
07:26
if-match ip-precedence 4
07:26
if-match ip-precedence 5
07:27
это приоритет СИП и ТВ над прочими видами трафика
07:27
> это приоритет СИП и ТВ над прочими видами трафика
07:27
хм а как вы сип то выделяете из трафика?
07:28
он по идее в отдельной влан
07:28
traffic classifier идет как бы выделение трафика
07:29
там либо Ацл либо влан либо мак либо еще чего нить
07:29
а далее уже работаем с ним
07:29
сейчас потестим
07:29
traffic classifier VIDEO operator and
07:29
if-match vlan-id 1611
07:29
if-match source-mac e427-7100-0000 ffff-ff00-0000
07:29
traffic classifier default operator and
07:29
if-match any
07:29
#
07:30
как то так я делал
07:34
(11:35:31) -•vintage!•-: :-)уже идет маркированый по сети
07:35
e_zombie, хорошо вам, у меня нет, надо с агрегации маркировать и до доступа все пропускать и на доступе от абонента переделывать
07:35
я подозреваю что мы его гдето сами на ядре маркируем
07:36
ну комерсы нагнут кого угодно если у клиентов рассыпается картинка
07:36
КЭП
07:36
у нас не нагибают, пока не нагнут хер кто шевельнется
07:40
"Failed to save!
07:40
{"status": false, "message": "Integrity error"}"
07:41
об чем это? при сохранении МО
07:41
ну найди 10 знакомых которые позвонят в ТП и скажут что у них рассыпается. вот тебе массовая проблема и под шумок сделаешь.
07:42
e_zombie, фиг заставишь их шевелитья
07:42
ну тогда сделай так чтобы была массовая.
07:43
и напиши письмо что надо маркировать трафик на сети и бла бла бла.
07:43
у нас было почти так.
07:43
просто заебала тех поддержка инцидентами и это дошло до начальства.
07:43
и только тогда "мозг" соизволил поднять попу и заняться решением.
07:45
TSergey: нельзя просто так взять и сохранить новую железку сразу с атрибутами
07:45
надо сначала сохранить железку без атрибутов, а потом сохранить ее с атрибутами
07:45
у меня было именно так
07:45
причем железку оно сохраняло
07:46
и ошибку выдавало
07:46
так ругаестя при сохранении с минимумом, на который показывает сам НОК, выделяя поля красным
07:46
не, не сохраняет
07:46
аааа
07:47
точно, она есть
07:53
mikevlz: спасиб
10:02
строчку с самим сообщением об ошибке не скопировал в пасту
10:26
в адресной базе сделал кнопочку для быстрого прописывания подъездов и квартир
10:26
в Building
10:27
и сделал в API метод Building.fill_entrances(), если кто импорт будет делать
10:28
все уже разобрался в чем проблема
10:33
а для чего коллектор нужен таки? где то уже обсуждалось?
10:54
TSergey: патч для SAE работает?
10:56
не пробовал, меня на пасти не пускает
10:56
говорит что ресурс вреестре
10:57
дома зебиру, завтра попробую
10:57
*качну
11:12
гг
11:12
уже паста в реестре
11:19
закоммитил в feature/ofm
11:19
11:21
давайте пройдемся
11:22
Subsciber -- это клиент
11:22
они бъются на категории SubscriberCategory
11:23
У услуг можно указывать, для каких категорий абонентов они применимы
11:23
далее
11:23
Operator -- это контора, которая оказывает услуги
11:23
если их несколько
11:24
если есть разделение услуг по разным конторам
11:25
OrderFlow -- это сама схема движения заявки
11:25
она - же -- заказ
11:25
она же - услуга
11:25
бывает одного из двух типов -- заказ, если это новая услуга
11:26
или трабл, если это трабл для уже реализованой услуги
11:26
direction -- это выбор, в какую сторону смотрит услуга
11:26
customer facing -- продаем ее клиентам
11:27
self, она же научно resource facing service -- внутренний сервис
11:27
иногда может быть и так и так
11:27
далее
11:27
заявки объединяются в деревья
11:27
то есть у заявки может быть родитель
11:28
что позволяет строить иерархию сервисов
11:28
например, может быть заявка -- Интернет для физиков
11:28
и у нее могут быть дочерние заявки типов IPTV и VoIP
11:29
чтобы не цеплять что попало к чему попало - OrderFlow.parent_order_flow содержит имена схем, которые могут быть родителем для данного типа
11:30
заявка может быть привязана к адресу оказания услуги или не привязана
11:30
address_requirements позволяет указать, требуется ли адрес или нет
11:30
далее начинается самое интересное
11:31
схема движения состоит из этапов
11:31
там задается список из OrderStage
11:31
начальный этап по умолчанию задается в start
11:32
не обязательно создавать заявку непосредственно со стартогого этапа, возможно и на других этапах
11:32
тут отдельную портянку надо писать)
11:32
далее в схеме -- resources -- ресурсы, которые могут быть задействованы на заявке
11:32
скажем, для доступа в интернет -- порт и ip-адрес
11:33
про ресурсы дальше расскажу
11:33
subscriber_categories -- позволяет ограничить создание заявки только на определенные категории абонентов
11:34
например, услуга "Поцелуй монтажника" может быть доступна только для VIP
11:34
attrs -- описание параметров заявки
11:34
вместе они будут составлять контекст
11:35
который будет хранить все внутренее состояние
11:35
on_start -- список функций которые должны быть выполнены при создании заявки, обычно они смотрят в solution'ы
11:35
там можно свою произвольную логику реализовывать
11:36
OrderStage достаточно прост
11:36
в нем указывается название этапа машинное и человеческое
11:36
признак -- может ли данный этап в принципе быть стартовым
11:37
op_status -- текущее состояние заявки -- "DELIVERED" -- услуга реализована и оказывается
11:37
"TERMINATED" -- отключили нафиг
11:38
TEMPORARY SYSPENDED -- блокировка (финансовая, добровольная, и так далее)
11:38
нет
11:38
бабки должен
11:38
нене, я мею ввиду для нее статус будет?
11:38
нет, не будет, будет активный трабл
11:39
то есть она будет delivered, но на нее будет активный трабл
11:39
и сразу - на TEMPORARY SYSPENDED надо уточняющий код
11:39
как раз чтобы с билингом вязать
11:39
ты записывай замечания
11:39
потом пачкой их пройдемся
11:39
что, наконец-то будет сто-то полезное с workflow ?
11:40
Dmitry1, ты зацени там..
11:40
если у нас заявка на этапе, то этап определяет, оказывается услуга или нет
11:40
далее, у этапа есть переходы на другие этапы
11:41
без них тоскливо
11:41
они называются OrderPass
11:41
"с этапа на этап, ветер северный" ()
11:41
то есть у этапа ограниченый набор переходов
11:41
типа того
11:41
Дим. Идея такая: подключается новый корпоратив. Ему нужно прокинуть vlan, дать IP и т.п.
11:41
Эти задачи описываются в workflow или project
11:41
on_enter, on_before_leave, on_leave -- обработчики событий из solutions
11:42
со своей логикой
11:42
и по мере их исполнения видно, на каком мы сейчас этапе
11:42
Dmitry1, он гораздо круче сделал.
11:42
notification group -- кому свистеть, что заявка упала на этап
11:42
notification channel -- это отдельная сущность
11:42
фактически, это внешняя система
11:42
зачем курче, если уже есть project и workflow ?
11:42
который мы шлем уведомления, что заявка шлепнулась на какой-то этап
11:43
например, в CRM ключевые этапы отдаем
11:43
Dmitry1, пусть договорит, логом потом все кучнее будет.
11:43
и в workflow мы можем строить диаграмму исполнения каких-то действий
11:43
OrderPass -- они тоже непростые
11:43
у перехода есть имя
11:44
оно же -- событие, при котором происходит переход
11:44
то есть если заявка ловит событие, она переходит по соответсвующему переходу
11:44
может быть несколько переходов между одной парой этапов
11:44
с разными именами
11:45
next_stage -- название этапа, на которое будет осуществляться переход
11:45
dvolodin: Дим, как это бцдет увязываться с workflow ?
11:45
on_before_pass и on_pass -- обработчики из solutions
11:45
is_manual -- признак, что переход может быть активирован оператором вручную
11:46
скажем, как признак согласования
11:46
то есть вот такая вот схема движения
11:46
общая суть пока понятна?
11:46
далее самое интересное
11:46
ресурсы
11:47
dvolodin: Смотри: у меня задача. Обновить firmware на устройстве. Я создаю задачу, которая будет мне проверять аттрибут MO "firmware". И переодически заглядываю в эту задачу, чтобы узнать, прошивка обновилась или нет
11:47
ресурс -- некая абстрактная фигня, которая может быть пришлепнута к заявке
11:47
Dmitry1: не торопись
11:47
итак, что такое ресурс
11:48
на самом деле -- это питоновский класс с определенным интерфейсом и определенным функциоаналом
11:48
базовые лежат в ofm/resources
11:49
более интересный пример -- solutions/noc/default/resources/staticippool.py
11:49
ресурсы можно как назначать руками, так и дергать из пулов
11:49
для пулов есть такая настройка, как ResourceAllocator
11:50
это некая фигня, которая выделяет ресурсы по запросу
11:50
выделение может происходить в несколько фаз
11:50
вот крайний сценарий
11:50
подклчюение телефонии
11:51
шаг 1. CRM запрашивает у NOC 5 свободных номеров для того, чтобы предложить клиенту
11:52
эта операция называется OFFER и реализуется функцией get_offer в обработчике ресурса
11:52
NOC при этом на время резервирует эти номера, чтобы не предложить их дуриком другому клиенту
11:53
шаг 2. Оператор согласовывает с клиентом номер телефона, CRM производит бронирование
11:53
статус offered снимается со всех номеров, кроме выбранного
11:53
Т.е. ко мне подходит клиент, и говорит: "выдели мне блок адресов". Я в заявке пишу "хочу выделить блок из 256 адресов" и оно мне автоматом засунет это в IPAM как PLANNED ?
11:54
при запросе предложения на шаге 1 NOC возврашает идентификатор транзакции
11:54
Dmitry1: в OFFERED
11:54
резервирование осуществляется по нему же
11:54
ресурс пока еще не привязан к заказу, но уже зажат на какое-то время
11:55
далее, CRM победно выдает нам заказ
11:55
В Main -> Setup -> Resource States такого не нашел
11:55
первым делом NOC фиксирует зарезервированые ресурсы
11:56
то есть то, что было в OFFER без заказа становится в RESERVED с заказом
11:56
то есть оно уже зарезервировано за конкретным заказом и будет жить, пока заказ не перейдет на стадию TERMINATED
11:57
далее, NOC может на каком-то этапе запустить активацию ресурса
11:58
я пока не сделал привязки, но думаю, что это можно сделать либо в OrderStage, указать ресурс, который активируется на этапе
11:58
тогда этап будет полностью автоматическим
11:59
либо в OrderResource указать список этапов, на которых происходит активация
11:59
то же и с деактивацией
11:59
активация и деактивация -- еще две функции в обработчике ресурса
12:00
возможен вариант когда в заказе не указывается конкретный ресурс, но он автоматом выбирается NOC'ом на основании текущего контекста
12:00
вот это как раз делает ResourceAllocator
12:01
привязки пока нет, но опять же думаю, что это будет в OrderStage
12:02
события для переходов, скажем, ok, temp_fail, fail
12:02
объекты в базе также связаны с полем resource
12:02
оно есть в репо у объектов ipam
12:03
то есть я могу по address посмотреть ресурс
12:03
если он есть, то посмотреть заказ (услугу) и абонента
12:03
и статус
12:04
есть еще такой странный вид ресурса, как динамический пул
12:04
это как раз к IPPool
12:04
можно привязать заявку к пулу
12:04
dvolodin: ты уже нашел человека на полный рабочий день? Слишком большие планы на будущее, при том, что у нас сейчас не работают нормально FM и IPAM
12:05
то есть фактически сказать, что этот клиент будет получать какой-то адрес из пула, без указания, какой именно
12:05
это позволит отслеживать переподписку на динамических пулах
12:05
и, например, поднимать alarm'ы в случае необходимости расширения
12:06
для выделения портов тоже уже готов алгоритм
12:06
в inventory появилась такая штука, как Coverage
12:07
условно -- это обещание дотянуться от порта до нужного места в штатном порядке и за обозримое время
12:08
с одной стороны в coverage пихаются порты с указанием доступных технологий
12:08
с другой - контейнеры inventory и здания/подъезды
12:09
покрытие каскадируется
12:09
то есть если нет явного своего -- смотрим у родителя
12:09
возможно запрещение покрытия на каком-то уровне
12:09
Дим, Дим, Дим. Остановись! То, что ты предлагаешь, это Enterprise уровень и выше. Будь ближе к людям. :)
12:09
скажем -- в здании покрытие есть, а в конкретном подъезде -- нет
12:10
или в автозале есть, но в данном ряду стоек - нет
12:10
у связок объекта с покрытием есть приоритет
12:10
то есть можно задавать предпочтения
12:10
скажем -- подключаем сервера в этой стойке со стоечного свича
12:11
Какие автозалы? Какие стойки? Макстимум - чердак или щиток в подъезде
12:11
нет портов -- из свича в соседней стойке
12:11
в зданиях
12:11
скажем в этих подъездах подключаем с таких-то свичей
12:11
закончились порты -- тянем из соседнего подъезда
12:12
для FTTB покрытие -- считай подъезды, до которых можно дотянуться со свича
12:12
в одном покрытии может быть несколько свичей задействовано
12:13
можно делать покрытия технологические
12:13
скажем одно -- для интернета, второе для КТВ/ЦТВ/DOCSIS
12:13
третье для телефонии/xDSL
12:13
dvolodin: Не пожалею денег тебе на билет, чтобы ты приехал к нам в город и посмотрел, как это все выглядит
12:13
Dmitry1, я думаю это реально упростить под твои реалии.
12:14
в целом концепция такая, если есть дополнения, давайте обсуждать
12:14
_4ePTeHok, я тоже так думаю, херня какая-то
12:15
Dmitry1: поверь, я немало видал :) еще с начала двухтысячных. и объекты в Богом забытых болотах, нафаршированные зарином, у меня тоже были
12:15
;)
12:15
как раз наоборот
12:15
мега
12:15
У нас 99.99% работы - это ошибки на портах, переключение дуплекс/полудуплекс, переключение 10/100, неверно написанные ACL/vlan
12:15
но порог вхождения поднялся на несколько порядков по экспоненте.
12:15
дим, у вас тоже есть процесс подключения и процесс техобслуживания
12:16
и вот в этом без бочки этилосодержащего точно не разобраться)
12:16
пойду лог сохраню чтоли.
12:16
вот неверных ACL/VLAN как раз быть не должно
12:16
dvolodin, вот именно, и это не задача нока
12:16
да, в качестве бонуса
12:16
это валидаторы должны делать
12:16
а ты сюда тянешь то чем занимается планнинг и ПМ
12:16
будет дальнейшее развитие сниппетов
12:16
блять
12:17
а графики будут развиваться или хуй на них?
12:17
скажем в заявке "настройка порта" -- будут сниппеты на каждую модель оборудования
12:17
просто как шаблоны с командами
12:17
NOC будет их на лету подхватывать и выполнять
12:17
шаблоны с командами можно и самому наделать, секндное дело
12:17
просто при этом еще будет смотреть, что за жалезка
12:17
zi_rus: да
12:18
просто сделать типа унифицированного подхода
12:18
dvolodin: Дим, ты когда-нибудь реального монтажника вживую видел?
12:19
У нас был реальный случай, когда ему сказали включи витую пару в первый порт, а свич был перевернут с ног на голову, и он включил витую пару в последний порт
12:19
скажем файлы по пути <solution>/snippets/<схема движения>/Cisco/2950/setup_port.txt
12:20
Dmitry1: у нас есть определенное количество монтажников :)
12:20
12:20
Какие сниппеты тут помогут?
12:21
простые
12:21
если долбоеб воктнет клиента не в тот порт, то подключения не состоится, оно не будет засчитано и он пойдет мимо денег
12:21
помогает, кстати
12:22
монтажники не в штате, а на ГПХ
12:22
не устраивает его работа, он садится на МПХ
12:22
рулит этой кодлой наш внутренний софт, зарплату им же считает он
12:22
dvolodin, у нас новая схема включения, на доступе q-in-q тянется до ASR9k, она работает как брас фактически, хотя это ядро, а значит чтобы настроить сервис, надо 1) найти порт на доступе, подписать и поднять 2) найти все РЕ куда приходит это кольцо, 3) прописать порт
12:22
ы 4) настроить точку терминации на одной из РЕ. ХУЙ ты это унифицируешь. А сейчас новая тема идет с мплс на доступе, там я вообще даже не знаю как настраивать, еще не пробовали, но первые мысли вызавают шок
12:23
полагается, что определенное представление о процессе я имею
12:23
zi_rus: а в чем проблема
12:23
у тебя у заявки будет 2 ресурса -- BRAS
12:23
проблема в том что сниппет даже расширеный, предполагает настройку порта
12:23
делаешь termination group пихаешь в него BRAS и свичи доступа
12:24
развивай мысль
12:24
чего кому пихаешь?
12:24
итого у тебя у абонента -- 2 BRAS, порт доступа, динамический адрес
12:24
так?
12:25
1. делается через Coverage, порт ты найдешь
12:25
статический адрес на BVI
12:25
ok
12:25
2 BRAS, порт доступа, статический IP
12:25
так?
12:26
порт я уже сказал как находится, через coverage
12:26
BRAS'ы находятся через termination group
12:26
как связь строится?
12:26
статический ip -- staticippool, он привязан к termination group
12:26
создаешь termination group на пару BRAS'ов
12:27
в managed object'ах BRAS'ов прописываешь его как termination group
12:27
в managed object'ах свичей доступа -- как service terminator
12:27
вот тебе и связка
12:28
выделяем порт, смотрим на свич, по service terminator находим BRAS'ы
12:28
dvolodin, свич привязан к порту браса это принципиально
12:29
допустим, что мы сделаем ссылку на termination group на interface
12:30
что нам мешает?
12:30
Пока NOC этого не научится, то 99% администраторам он бесполезен
12:30
тогда для termination group будет либо BRAS целиком либо его LAG
12:30
dvolodin, нам мешает идиотизм всей системы, я тоже самое делаю через vc domain и мне нужны новые сущности чтобы реализовать свои хотелки уже сейчас
12:30
ты плодишь сущности
12:30
дико и без надобности
12:31
ну хочешь делать через vc domain - делай
12:31
полностью согласен с zi_rus
12:31
нужно поближе к оборудованию
12:31
просто в аллокаторе ресурсов будешь использовать не termination group, а vc domain
12:31
мы до сих пор не умеем смотреть ошибки на портах, статус и настройки портов
12:32
анализировать DOM и диагностику кабеля
12:32
Толку мне того, что в FM постоянно пишет Link Down. Я хочу знать, почему он падает !
12:32
Дим, ну сделай, кто не дает?
12:34
zi_rus: по интерфейсу BRAS возможен такой вариант
12:35
по свичу определяем termination group, находим BRAS'ы
12:35
по VC Domain'у свича доступа находим конкретный LAG BRAS'а
12:35
чем тебе не алгоритм?
12:36
брас можно найти по vc domain без termination group
12:36
можно
12:36
но там возможны и исключения
12:36
смотри
12:36
у тебя vc domain
12:36
в нем 300 портов
12:37
как ты найдешь BRAS?
12:37
с termination group -- просто по роли
12:37
вот как я это делаю
12:38
for i in Interface.objects.filter(vc_domain=vcd.id).order_by("managed_object"):
12:38
ну а теперь представь, что эта портянка разваливается на несколько маленьких скриптов
12:38
которые, к тому же, за тебя уже написали
12:38
и несколько сниппетов
12:39
НЕ РЕАЛЬНО, дебажить почему оно не работает придется дольше чем писать самому
12:40
буквально будет -- выделить порт, выделить адрес, конфиг для порта, конфиг для BRAS
12:40
дебажить, почему не работает портянка сложнее, чем дебажить, почему не работает скрипт
12:41
до сих пор, нок не научился автоматически находить новые свичи, автоматически ПЕРЕстраивать изменившиеся линки, автоматически связывать свичи в общий vc_domain согласно разделению на Л3
12:41
все надо делать руками
12:42
теперь terminantion group еще вести руками
12:42
мы уже свои костыли придумали чтобы профили на порты вешать, нок и этого не может
12:42
12:42
./noc notebook рулит
12:42
:)
12:43
у noc есть вполне уже штатный механизм покраски через solution'ы
12:43
а профили нужны - по ним определяется какие порты можно выделять
12:44
у нока механизм покраски через солюшены уёбищен по своей сути
12:44
он не в состоянии отслеживать статусы портов
12:44
уже обсуждали
12:44
то что ты там выдумал, к реальной жизни вообще отношения не имеет
12:44
пользы никакой
12:45
только еще одна сущность
12:45
то что можно было бы сделать пирулем, ты сделал костылем
12:45
ЗАЧЕМ?
12:45
какие именно статусы он не отслеживает?
12:46
у него весь конфиг интерфейса на входе
12:46
что ему еще надо-то?
12:46
он вызывается только в момент обнаружения порта ТОЧКА, если порт попал в инвентори все, алес, капут
12:46
прохода солюшена по нему больше не будет
12:47
появился линк на порту солюшен не будет вызван
12:47
пропал линк - тоже
12:48
это уже к фм
12:48
и джобам
12:48
вызов солюшена кстати из джоба сделать думаю не проблема
12:49
это ко всему. в нок прикручивают хуйню за хуйней, никто этим не пользуется, а важные фичи в зародышевом состоянии
12:49
воу воу, палекче
12:49
вон со статусами портов до сих пор не определились
12:50
то, что Дима с офм сделал - это действительно нужные вещи.
12:50
Но есть правда и в том, что о многих вещах низовых забыли
12:50
кому нужные? вас видимо двое кому это надо
12:50
давай не будем ругаться?
12:51
в нок очень много ручной работы по обслуживанию самого нока, он не может жить сам по себе
12:51
любая система не будет жить сама по себе
12:51
тот же билинг ручками операторы крутят
12:51
автодискавери и автоперелинковка нужны
12:51
и сервисы и связки и периоды заводят
12:51
составь список чего нужно
12:51
другие добавят
12:52
без Димы не обойтись, потому что в концепцию вписать любую реализацию только он сможет органично
12:52
некоторые вещи, которые нужны - на деле реализовать легко в рамках имеющшихся механизмов
12:53
список есть, полистай багтрекер
12:53
вопрос в том, что должен быть базис, подтвержденный Димой
12:53
вот те же статусы портов
12:53
их давно не проблема с дискавери тащить, причем и ощтбки и счетчики
12:53
zi_rus: ты не прав
12:54
покраска в любом случае осуществляется если порт еще не покрашен
12:54
видимо не я один раз меня поддерживают
12:54
Кроме того, обязательно нужна реакция на то, если порт стает в скорость меньшую, чем на самом порту, или в полудуплекс
12:54
Это явно проблема в соединении
12:54
Dmitry1, это все в интерфейс и статусы упирается
12:54
а разве это в FM не генерит аварию ?
12:54
определитесь уже со статусами
12:54
и оно размотается как клубок
12:55
со статусами остановились на том, что они нужны, но не смогли договориться, как они нужны
12:55
они нужны хотя бы в справочных целях
12:55
потом =- опять же для активизации услуг может пригодится
12:56
у нас скажем услуга начинает тарифицироватся с момента первого трафика
12:56
50 1000BASE-T Link Up Pair 1 Short at 43M -
12:56
Pair 2 OK at 39M
12:56
Pair 3 Unknown at 0M
12:56
Pair 4 Short at 43M
12:56
Dmitry1, Дима, не надо аварии показывтаь
12:56
повторю = статусы.
12:56
Вот авария два: Port 11 link up, 100Mbps HALF duplex
12:56
список статусов и как их ложить в модель
12:56
Dmitry1, это для тебя авария, а мне посрать
12:57
коллеги, я тоже могу много всякого хлама накопипастить
12:57
но дело это не изменит
12:57
повторю вопрос
12:57
"Как должен выглядеть интерфейс IGetInterfaceOperStatus
12:57
?"
12:58
speed duplex link line protocol
12:58
dvolodin: Дим, на десяток CORE железок, для которых ты пишешь NOC, обычно присутствует еще пара тысяч ACCESSS железок, для которых NOC бесполезен
12:58
Dmitry1, у меня акцесс весь в ноке.
12:58
ты не прав.
12:59
предложенная концепция как раз связывает в логическом плане ядро и акцесс до порта и клиента.
12:59
с услугой
12:59
и заявками со стороны конторы
13:00
dvolodin: про статус уже давно придумали, например d-link
13:00
Port : 24
13:00
--------------------
13:00
Auto Negotiation : Enabled
13:00
Capability Bits : 10M_Half,10M_Full,100M_Half,100M_Full,1000M_Full
13:00
Capbility Advertised Bits : 10M_Half,10M_Full,100M_Half,100M_Full,1000M_Full
13:00
Capbility Received Bits : 10M_Half,10M_Full,100M_Half,100M_Full,1000M_Full
13:00
Все сразу четко видно. Что мы хотим, и что получаем от соседа
13:01
и в другой табличке
13:01
Port Port Settings Connection Address
13:01
State Speed/Duplex/FlowCtrl Speed/Duplex/FlowCtrl Learning
13:01
------- -------- --------------------- ---------------------- ---------
13:01
1 Enabled Auto/Disabled 1000M/Full/None Enabled
13:02
я бы счетчики включал сразу в этот же интерфейс
13:03
чтобы не дергать лишний раз железяку
13:03
_4ePTeHok: сейчас такая ситуация, что с NOC кроме меня никто работать просто не сможет. Для того, чтобы отдать его на уровень ниже, нужно чтобы он смог выдать информацию, которая нужна обычным монтажникам и операторам: ошибки на порту, длина кабеля, мощность
13:04
я понимаю
13:04
я ж тебе и объяснил - что определимся с интерфейсом по этим данным - а дальше не проблема в имеющшееся впихнуть
13:05
те же светчики и скорости в панель L2 штм-штеукафсуы
13:05
cxtnxbrb*
13:05
Кроме того, если у двух железяк есть SFP порты, а их соединили между собой медью из-за лени монтажников, то об этом NOC должен аж кричать!
13:05
counters*
13:05
не у всех
13:05
у нас допустим в одном ящике экономят сфп
13:05
короткий патч дешевле
13:06
Потому как после грозы начинаются разборки, почему погорели порты, хотя была возможность соединить оборудование оптикой
13:06
это частные случаи
13:06
отконфигурируешь под себя триггер
13:06
Гроза - частные случаи?
13:06
они и по оптике отлично горят
13:06
это в солюшенах сделать можно
13:06
а еще и дверцу выносят.
13:06
_4ePTeHok: или ты живешь в тропиках, где есть сезон дождей ? :)
13:06
там правда медюк был.
13:07
Дима, ну не утрируй
13:07
частный случай - это запрещать включение по другому медиатипу.
13:07
Гроза - это головная боль всех провайдеров
13:07
я тебе пример привел
13:07
петля в подвале из патча в 25 см погоды там не сделает
13:07
это - частный случай
13:08
и должен реализовыватся в специфичном солюшене
13:08
а такое:
13:08
1 100BASE-T Link Down Pair 2 Open at 60M -
13:08
Pair 3 Open at 60M
13:09
готовый грозоприемние
13:09
ты думаешь замкнутый - он не будет контуром?)
13:09
ну бред же.
13:10
Как показала практика, зачастую горят порты, у которых просто болтаются куски кабеля
13:10
давайте уже сконцентрируемся на том, на чем Диму спугнули
13:10
будут у тебя в базе статусы портов и диагностики - ты такие места выловишь в 5 минут
13:10
очередной раз заметил странную закономерность
13:10
я не только об этом
13:10
хоть с мейловым нотификейшеном, хоть с табличкой и сиреной
13:11
когда кто-то громкогласно заявляет, что в NOC чего-то нет, на вопрос, а как оно должно выглядеть как-то тушуется
13:11
тот же FM бесполезен без дополнительной информации. И если Дима для BGP Down сделал выборку из базы Peer, то для остальных алармов у нас вообще ничего не происходит
13:12
dvolodin, я лично думаю, что после get_interfaces должен запускаться дискавери статусов и счетчиков порта.
13:12
а при доп. настройке - и джоб диагностики линка
13:12
(при первом включении услуги или как там дальше - это уже вопрос)
13:13
dvolodin, тебе сказали как, чего ещ надо?
13:13
разделить их в два скрипта или все в одном(статус + счетчик) это как удобнее
13:14
складывать в бд, хранить историю переходов состояний статуса(по профилю интерфейса добавить галку сохранять историю = и что именно - статус дуплекс и т д), на проблемных линках оно может активизироваться для мониторинга переходов
13:15
Кто мешает добавить к уже существующим интерфейсам переменную error, которая будет сигнализировать о каких-то неполадках
13:16
история позволит и репорт делать по аптайму портов
13:16
(касательно магистральных например)
13:16
вы хотете класть в базу состояние порта доступа, я правильно понял ?
13:17
выборку из ФМ по порту
13:17
нет
13:17
freeseacher, по профилю коррелировать
13:17
т е бывают случаи когда и на доступе надо
13:17
вип-ментура и т д
13:17
контроль сла типа
13:17
нестабильный порт у клиента(то 10 то 100мб)
13:18
например, на доступе абсолютно пофиг состояние порта, но если он сильно часто падает, то это проблемы с физикой
13:18
частое падение - это к фм
13:18
а вот то чего оно не отловит - уже в дискавери
13:18
ну или подстраховывать(как мы давно хотели со статусами)
13:18
мне не нужно поднимать аларм на падение, а нужно, если падение порта произошло 10 раз за минуту
13:19
это тебе дискавери не поможет
13:19
это еще раз - механизм фм надо пилить
13:19
(если оно уже не умеет)
13:19
согласен с _4ePTeHok
13:20
снимать постоянно моментальные значения - зло.
13:20
даже наши "автоматизаторы" делали это через сислог
13:20
расширять механизм FM с помощью "предустановленных" pyrule, когда pyrule, и только она будет решать, поднимать аларм, или нет
13:21
"noc.fm.handlers.event.link.oper_down"
13:21
если cat 10.239.2.2| grep Down | awk '{print $5}' | wc -l больше 10 значит бида
13:21
dvolodin, солюшен может работать в фм - определять логику поднимать алярм или нет?
13:21
в описании класса Link Down
13:21
надо посмотреть на порт
13:22
dvolodin: Я в eventtriggers не вижу этого
13:22
он как раз щелкает InterfaceStatus
13:22
дим, посмотри описание eventclass'а
13:22
_4ePTeHok: да, может
13:23
В NOC "из-коробки" ничего этого нету
13:23
и для этого они тоже нужны были
13:23
дим, оно из коробки такое, ты о чем
13:23
я сейчас скажу жутко неприличную вешь
13:23
Dmitry1, там был сбой
13:23
когда они похерились все
13:23
все хандлеры
13:23
у мен ятакое тоде было
13:23
но без описания механизмов - пользоваться ими не получится
13:23
dvolodin, вот те же хендлеры
13:23
солюшены
13:23
ни одной доки нет
13:24
и бог с ним с основной докой
13:24
но даже роясь в коде - я далеко не всегда могу понять как оно с чем
13:24
Я представляю себе FM как набор триггеров (event, alarm), которые я могу включать/отключать и изменять логику работы FM
13:25
по таким вещам описание должно быть на уровне логики работы хотя бы
13:25
схема даже
13:25
больше не надо
13:26
это необходимо для девелоперов низового уровня
13:26
Я уже пол-года прошу перенести в alarmtrigger запуск джоба check_link при аларме Link Down
13:26
которые нарастят как раз встроенные логические схемы
13:26
Чтобы можно было его включать/отключать щелчком мыши
13:26
сильно упрощающие жизнь
13:26
Dmitry1, имхо - место галки в профиле интерфейса
13:28
в общем к нашим баранам
13:28
_4ePTeHok: Желаю тебе поработать с D-Link DGS-3126, где при настройке vlan на интерфейсе вместо include есть только exclude
13:28
это ровным счетом ничего не меняет.
13:28
_4ePTeHok: на самом деле все достаточно просто
13:29
И прописывание vlan 10 выглядит как exlude 1-9,11-4094
13:29
нужно будет в __init__.py solution'а подписываться на event'ы и алармы
13:29
тогда будут дергаться функции из solution'а
13:31
мое предложение. Утверждаем статусы портов и делаем два интерфейса - get_oper_status/get_err_counters
13:31
прилепляем это к дискавери(на основе результатов get_interfaces)
13:32
храним в бд, выводим в tab L2 inv-interfaces
13:32
навешиваем логику
13:32
генерация ивентов\через солюшен или еще как
13:33
Нафига мне get_status, если я не вижу, есть проблема с портом, или нету ?
13:33
Dmitry1: чота мне это подозрительно напоминает тврочество нашего xcme
13:33
на основе состояния портов
13:33
Как ты навесишь логику ?
13:33
Если скрипт индивидуальный для каждой железки?
13:34
Послушай меня 5 минут
13:34
ты только что выл, что по счетчикам ошибок надо уметь
13:34
и по раскрытым парам витухи(из диагностики)
13:34
Смотри внимательно
13:34
я делаю диагностику кабеля
13:34
вот тебе один пример:
13:34
10 100BASE-T Link Down Pair 2 Open at 22M -
13:34
Pair 3 Open at 23M
13:34
А вот то же, нос другого свича
13:35
10 100BASE-T Link Down Pair 1 Short
13:35
Link Down Pair 2 Open at 22M -
13:35
Pair 3 Open at 23M
13:35
Pair 4 Short
13:36
т.е. оно на 100M тупо говорит, что первая и четвертая пара закорочены. И для ЭТОЙ ЖЕЛЕЗКИ ЭТО НОРМАЛЬНО !
13:36
Другой тебе пример
13:36
ты сейчас пытаешься что мне объяснить, что все тлен?)
13:37
нормально - ну и путь
13:37
тебе ненормальное надо отлавливать
13:37
Что решение о том, ошибка это или нет, нужно принимать ВНУТРИ скрипта
13:37
Индивидуально для каждой жеоезки
13:38
Дима. интерфейс должен отдавать сырые данные.
13:38
логика будет в солюшене
13:38
который ты на свой вкус и цвет раскрасишь хоть для всех длинков вмире.
13:38
Ты хочешь, чтобы в солюшене я написал условие для разных железок?
13:38
да, потому что он - индивидуален
13:39
а скрипт - нет
13:39
интерфейс*
13:39
интерфейс - это обобщение
13:39
Скрипт индивидуален для каждой железки. Интерфейс общий для всех железок
13:39
по определению
13:39
и более того = солюшен как я понял(Дима поправит) - можно даже в скрипт притянуть
13:40
Ты предлагаешь забить мне на ошибки в скрипте, привязанном к железка, получить сырые данные, а потом писать солюшн, который опять опустится до уровня железки?
13:40
в скрипт не подтянешь
13:40
и вы не туда опять уехали
13:41
дима хочет операторскую консолю
13:41
Я уже писал про get_dom_status
13:41
чтобы гоблин тыкнулся и видел там диагностику
13:41
ну себе - императорскую, да
13:41
у нас есть очень неплохая консоль
13:41
Этот интерфейс ничего не отдает. Даже если у меня нафиг сгорит gbic, я не увижу в чем проблема
13:41
как раз и железку можно найти, и клиента, и порты посмотреть
13:41
и кто на каком порту
13:42
после привязки к ресурсам уже вполне возможно
13:42
только это как-бы абсолютно отдельное приложение
13:42
даже не в рамках desktop'а общего, а вообще
13:43
давайте про get_dom_status
13:43
например, применимо для циски
13:43
дайте закончить уже)
13:43
читаем внимательно
13:43
++ : high alarm, + : high warning, - : low warning, -- : low alarm.
13:44
где можно посмотреть в IGetDOMStatus о том, что у меня накрылся SFP модуль?
13:44
dvolodin, к тому что я выше писал про статусы и интерфейсы - каково твое видение?
13:45
начали с того, что я изложил общую концепцию OFM и спросил комментарии
13:45
императорская консоль, конечно, тоже комментарий
13:45
это не дело 2 минут..
13:45
не двух, я потому и закоммитил в бранч, на покурить
13:45
можно кстати как то накатить апдейт с другой ветки оставаясь в девелопе?
13:46
адресная база именно для этого создавалась
13:46
_4ePTeHok: можно, конечно, diff сделать и применить
13:46
но не советую
13:46
по идеологии оно красиво
13:46
там пока только модельки и кое-какая логика python'овская
13:46
только надо примерить к процессам в компании
13:47
один коммент я сразу дал - статусы надо более глубокие
13:47
а точнее - персонифицированные к компании
13:47
статусы для блокировки?
13:47
не
13:47
там еще категории завершения будут
13:47
для раскраски заявок
13:47
у нас бывают такие экзотические объяснения почему подключение не состоялось
13:47
типа - нет доступа, монтажник не пришел, и так далее
13:47
типа "председатель дома - пидорас"
13:48
"бабка штурмовала с криком -фашисты"
13:48
"+облучают"
13:48
а по серьезному - разное бывает
13:48
это от билинга зависит
13:49
скажем купил клиент услугу телефонии с общего счета на мес(период тарификации со дня включения), а за интернет- по календарному месяцу с 1 по 1. Денег не хватило - ушел в блок
13:49
девочке на техподдержке нужен сразу статус определенный
13:50
а не "нет денег"
13:50
это все в логику билинговых процессов упирается
13:50
оставить возможность добавлять свои под-статусы с кодами из билинга
13:50
имхо.
13:51
а уже по api с билингом выставлять.
13:52
про остальное сложно говорить пока, надо тестить где что хватает, где нет.
13:52
ДАй время.
13:54
_4ePTeHok: а операторская консоль в любом случае должна быть и с биллингом интегрирована
13:54
Народ, а как PM работает? Где-то об этом написано? Нужно время от времени мониторить некоторые сервисы, и в зависимости от их работы генерировать ивенты/алармы
13:55
у меня он скорее не работает
13:55
У меня тоже не работает
13:55
да и не так много там проб сделано, чтоб вот так вот взять и запустить
13:56
там проблема с очередью запуска демонов есть вроде
13:56
это раз
13:56
У меня только default проба
13:56
два - для однотипных проб могут генерироваться одинаковые имена, что недопустимо
13:56
ну и три - там выбирать вообще нечего
13:58
вобщем, если на дефолтной пробе не генерирует нифига - попробуй прибить демонов Pm_writer и Pmprobe
13:58
ланчер перезапустит
13:58
если после этого начало генерировать и сохранять значения - надо в код демонов этих воткнуть задержку запуска
13:58
костыль, да...
13:58
dvolodin, это да. но нок в данном случае должен показать заявку, алярмы, статус и счетчики точки терминации сервисов клиента.
13:58
со своей стороны
13:59
интерфейс давайте :)
13:59
Есть возможность как-то цеплять пробы к MO ? Например, мне нужно мониторить DNS, radius, mysql
13:59
обсудим, и делайте скрипты, блин
13:59
давай с портами да
13:59
=)
13:59
я выше предложил
13:59
конкретику
13:59
class BlaBlaBla(Interface):
13:59
:)
13:59
и так далее
14:01
dvolodin: Дим, можешь сделать JSON интерфейс к пробам ?
14:03
в каком каталоге?
14:14
испугался...
Share this page
Share this page:
About
Forum
Blogs
NOC Docs
Downloads
KB
Issues
Code
CI
Registration
