Или даже nginx, а не hap

Основание для балансировки какое?

RR + Check

Ну, флаг в руки. Это больше к @freeseacher вопрос

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

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

Нет

Да, уже выяснили )

спасибо за помощь

https://kb.nocproject.org/pages/viewpage.action?pageId=29982910

Попытка изобразить схему

Может, будет полезна

По этой схеме дисковери ждёт http ответ от Активатора, а потом уже публикует ответ в nsq d

По этой схеме дисковери ждёт http ответ от Активатора, а потом уже публикует ответ в nsq d

Так и есть

а дисковерер мултитредный?

а дисковерер мултитредный?

Обязательно

Выполняемая Задача занимает 1 тред

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

Да

Понятно, почему нужно иметь несколько дисковереров

Понятно, почему нужно иметь несколько дисковереров

Несколько потоков

Внутри дискавери

агга

Это тоже

Схема оч. годная. Спасибо

Схема оч. годная. Спасибо

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

Почему забанили? Потому что логики выполнения команд не отображено? Типа кто команды отдаёт на поллгинг и активацию?

Почему забанили? Потому что логики выполнения команд не отображено? Типа кто команды отдаёт на поллгинг и активацию?

Иконки вводят в заблуждение

Не кавайные

))

Понятно, почему нужно иметь несколько дисковереров

Там есть слоты. Если больше одного дискавери то появляются больше одного слота

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

"NodeMeta": { "consul-network-segment": "" }, видимо балансировка возможно по нетворк сегментам из НОКа

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

А по какому принципу?

математическому?

Да

Блин крутую схему придумали Оч. крутую!

Прям пищу )

Деление без остатка по id объекта

В принципе, можно более интеллектуальную схему распределения накрутить. Но какой-то существенный профит с нее не проглядывается

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

Ибо дискавери туда смотрит

Мне кажется самое тормознутое это поллинг

Особенно если это SSH

пойду посниферю что активатору по http отдают)

пойду посниферю что активатору по http отдают)

Это можно в дебаге дискавери увидеть

Так, { "metric": "Interface | Load | In", "id": 0 }, Запрос понятен Ответ тоже

Вопрос... откуда автиватор берёт инфу об этом "Interface | Load | In" Видимо в монге

'./noc discovery --debug'

Оттуда и берёт OID

Оттуда и берёт OID

Oid считается на активаторе

Да, из монго?

Да, из монго?

Активатор отвязан от бд

Он туда не ходит

А как тогда ?

В статье расписывал, вроде как

Ближе к концу

Это запрос

За формирование списка OIDов для съёма отвечает генератор. Для объяснения ему что к чему необходимо написать конфигурацию.

Из статьи

Генераторы для интерфейсов надо искать в generic

Там их конфиг

Т.е. для активатора он прекомпелирован?

Я вижу из запроса json с тем, что нужно опросить

Но, пока, не могу понять откуда активатор возьмёт OID Где их взять в коде - понятно, а как про инх узнает активатор ...

Что понимается под прекомпиляцией?

Но, пока, не могу понять откуда активатор возьмёт OID Где их взять в коде - понятно, а как про инх узнает активатор ...

В конце статьи

Про генераторы и их конфиги

Простите, всё равно не понял... Если я правильно прочитал статью, то "metrics": [ { "metric": "Interface | Load | In", "id": 0 }, { "metric": "Interface | Load | Out", "id": 1 }, { "metric": "Ping | Attempts", "id": 2 }, { "metric": "SLA | ICMP RTT", "id": 3 }, metric это ссылка на генератор. Но откуда активатор узнаёт OID для это метрики, если он ничего не знает о базе?

puzzled (

Простите, всё равно не понял... Если я правильно прочитал статью, то "metrics": [ { "metric": "Interface | Load | In", "id": 0 }, { "metric": "Interface | Load | Out", "id": 1 }, { "metric": "Ping | Attempts", "id": 2 }, { "metric": "SLA | ICMP RTT", "id": 3 }, metric это ссылка на генератор. Но откуда активатор узнаёт OID для это метрики, если он ничего не знает о базе?

Нет. Это ссылка на конфиг

В конфиге указано что делать дальше

Хорошо Я создал генератором новый тип и аквтиватор у меня на другой ноде. Как активатор узнает OID ?

нужно делать синхронизацию ?

noc sync которая?

{ "$metric": "CPU | Usage", "$type": "oid", "oid": "1.3.6.1.4.1.8886.1.1.1.4.1.0" }

Этот кусок о чем-нибудь говорит?

Да о многом

Да о многом

Например

"$metric": "CPU | Usage", Будет в запросе от дискавери к активатору

Либо кто-то плохо пишет статьи, либо кто-то читаем между строк :)

да тут вопрос арихитектурный

С точкни зрения юзера всё понятно

С точкни зрения юзера всё понятно

Большая часть статьи не для юзеров

"metrics": [ { "metric": "CPU | Usage", "id": 0 },

Вот так будет выглядить запрос к Активатору

Где же он возьмёт "$metric": "CPU | Usage", == "$metric": "CPU | Usage", Если он отвязан от базы? Из какого конфига?

https://kb.nocproject.org/pages/viewpage.action?pageId=22970696

Раздел Генераторы

В конце

Конфиги лежат в профилях

Папочка snmp_metrics

Это понятно ) Как новая метрика появится в этой папке ВСЕХ активаторов??

Если я её создал... как она туда попадёт?

Это понятно ) Как новая метрика появится в этой папке ВСЕХ активаторов??

Деплой

вот!

Ура )

Или руками