где можно - снмп, где нельзя - кли

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

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

get_capabilities, get_metrics

там сбор и формирование вынесены в отдельные функции

вот как-то так делать имеет смысл

Короче. у меня 99% оборудования - это D-Link и Juniper

С текущим дизайном шедулера я эти железки в NOC ззавести не могу

а у зомби это линксовые сервера

Задно с "прибитыми гвоздями" задачами FM

ты и тут решил этот срачь поднять

осталось штук 5 цисок

*срач

какой срач ?

про фм

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

и где ты в FM увидел прибитые гвоздями задачи?

У меня 70% джун, почти все модыли EX, ни разу железка не отвалилась из-за нока.

Что скрипты кривые есть, это да. Так профили тоже кривые..

ты просто не потерял ещё девственность

что то всегда случается впервые

    "handlers": [         "noc.fm.handlers.event.discovery.schedule_discovery",         "noc.fm.handlers.event.audit.log_config_changed"     ],

что то всегда случается впервые

ну бордер от wr отвалился на пару сек, было впервые

блять. почините

TASK [nsqd : include nsqd os specific tasks] 05:04 fatal: [noc2nost]: FAILED! => {"failed": true, "reason": "ERROR! the file_name '/opt/tower/var/tower/playbooks/noc2noc/ansible/os/CentOS/main.yml' does not exist, or is not readable"}

и что тебя смущает?

Это же не значит, что cisco говно и нок говно

То, что я не могу управлять этим

Для L2 коммутаторов мне не нужно собирать get_interfaces и т.п.

не собирай

это настраивается

Как ?

галочка interface на вкладке box discovery в managed object profile

Как, бля, настроить, чтобы он ОДИН РАЗ собрал get_interfaces, а потом не собирал ?

поставить rancid

:)

Не смешно

и пускать его руками

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

на L2 ?

на L2 особенно

особенно на клиентских

Они меняются раз в пару лет. И я вполне могу запустить вручную там все

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

Потому как во время настройки несколько раз сделали "save"

это плохо?

это плохо

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

а не проблема ли это конкретно этого свитча и его настроек а не нока.

по факту да.

2. NOC затер всю инвентори старого свича, в результате не смогли в заявлении в милицию написать серийныые номера свича и SFP

достань из бакапа.

ну приделают gridfs для инвентори - делов то.

ещё одна киллер фича.

и скристят его с 1С

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

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

не трахай мозг и не убивай время разработчика.

короче,, микросервисы в плане поведения ничем не отличаются от devlop ветки

киллер-фича -- нормально организованый рабочий процесс

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

или оставь только config

это ваши влажные фантазии если это в РТ

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

запускаешь box один раз и снимаешь с него галочки

когда понадобится - опять поставишь

т.е. мне на каждый MO нужно создавать свой MO Profile ?

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

Должна быть галочка "запуск вручную"

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

ручное управление называется rancid

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

т.е. я коммитил в NOC несколько лет для того, чтобы в итоге его снести и поставить rancid ?

все плюшки, которые дает NOC, не совместимы с ручным запуском

scheduler работает в очень жестких временных рамках

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

там каждая лишняя проверка - жопа

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

ок

тогда давай такой вариант

Вот вам и телеграм, отвалился :)

кто?

Вот вам и телеграм, отвалился :)

привалился

а оптимизации там по сравнению с develop - очень большие

там где develop делал по 200 запросов в монгу в секунду, микросервисы сделают 50

так что самое разумное - дать ему работать, как работает

тут разве что в самом MO в настройке сделать галочку enable_discovery

чтобы можно было отключить discovery на конкретном MO

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

при поднятой - создается в штатном режиме

как-то так

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

теоретически, его еще можно с РНР скрестить

добавление галочки enable_discovery на MO scheduler тормозить не должна

он ее вообще не обрабатывает

А чем плоха идея с двумя boolean переменными ?

@dvolodin а разве вопрос того когда в следующий раз идти на железяку не вопрос sheduler ?

идея такая