Короче нифига. Поменял, задеплоил. запустил дискавери. Хрен там - в логах тишина, в SA->Monitor->Pools пусто, в Scripts тоже

@dvolodin что логично, для системы это просто данные и она их заводит под новым событием с новым ID

Короче нифига. Поменял, задеплоил. запустил дискавери. Хрен там - в логах тишина, в SA->Monitor->Pools пусто, в Scripts тоже

они сломаны нафиг.

в угоду мониторингу через телеграф

хзех

хорошо, а как понять, нок ваще живой?

я смотрю на мониторинг в телеграфе

я смотрю на мониторинг в телеграфе

Как посмотреть мониторинг в телеграе?

мои слова, птица! (с)

берешь графану. настравливаешь ее на инфлукс. на базу телеграф

события точно разные?

и видишь там 100500 данных для графиков

попродробнее можно?

Есть 2 лог коллектора, несколько железок для теста шлют на оба коллектора логи, события дублируются.

Событие одно и то же, ID Разный

эм

573b15d4cc044b2f65acb51c 573b15d4cc044b2f65acb51c

а как это должно работь ?

Событие одно и то же, ID Разный

Ладно, класс событий

берешь графану. настравливаешь ее на инфлукс. на базу телеграф

Это ты щас с кем разговаривал?)

с Ильей

Сейча скрин кину, мисмач копипаст

так, народ, кто там пишет документацию. присылайте мне ссылки. буду править основную

Dmitry ссылки на то, что написали?

@somovis а что делает одно и то же событие на разных коллекторах?

а как это должно работь ?

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

так дело не в коллекторах, а в настройках логгирования

сам же сказал - писать туда и туда

Ну да

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

@somovis а что делает одно и то же событие на разных коллекторах?

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

не считать же хэш от полей

Поэтому 2 коллектора

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

берут несколько полей и склеивают их

Поэтому 2 коллектора

ахереть.

например IP | интерфейс | ....

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

а не плавающий ip нет ?

ну) это одна из проблем такого подхода

ахереть.

Хочешь сказать не логично?

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

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

а другими способами

например делать выносные syslog серверы и балансировать их

я делал rsyslog - он умеет делать буфер

и сохранять там события, при потере связи

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

необходим резервный канал

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

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

необходим резервный канал

есть канал

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

да, Илья как ?

Железка сдохла

по питанию бордер упал

вариантов много

Ну сеть пока сойдется через резерв

tckb ecgttn

если успеет

какой такой резолв ?

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

при чем тут anycast ?

да это я о своем подумал

а. ок.

но вообще в его идее что-то есть

виртуалка с активатором/коллектором может сдохнуть?

Есть, точно есть.

может как и все другое

вопрос где он это берет ?

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

Нет идей

NOC умеет дедупликацию

@dvolodin расскажи

слишком садистскую

нет. идея с хешем выглядит интересной.

только что включать в хеш

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

интересной, но сколько же на неё ресурсов надо

вот допустим прилетел тебе "10:23 Fan down"

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

http://puu.sh/oV8sg/d493607502.png

Виктор, спасибо, только две железяки.

разные

?

Не берите этот рисунок всерьез

не удержался просто

:)

а вообще

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

а почему он будет идентичным ?

не... это очень плохой вариант. Он такой разный бывает особенно когда железка только включилась

у двух сообщений с одной железки на разные коллекторы?

да

хотя.... если события с одной железки!

это вариант

Может делать чек ноды?

потому что железка таймстампит

почему они разными должны быть

это две копии отправленные в разные дестинейшены

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