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

как там под капотом построен процесс сбора метрик? запускается 10к процессов и все ходят в инет?

Да все готовое есть. Как классический вариант: собирать через collectd, писать в графит

на вот типа такого https://workaround.org/ispmail/wheezybig-picture/

Грусть

Грусть

почему

как там под капотом построен процесс сбора метрик? запускается 10к процессов и все ходят в инет?

Как в нагиосе сделано - так делать не надо ?

почему

Не вдохновляет)

Да все готовое есть. Как классический вариант: собирать через collectd, писать в графит

collectd умеет в http запросы?

Да, конечно. Он что угодно умеет через плагины

Как в нагиосе сделано - так делать не надо ?

а как надо?

Не вдохновляет)

так это не муза же, это big picture

а как надо?

Он в самой просто имплементации раз в N минут для каждого эндпоинта запускает питонячий скрипт который собирает метрики и вываливает их в stdout, вот так наверное не надо делать если хочешь масштабироваться. А как надо хз, я простой одмин.

Интересно, как этот питонячий скрипт сжует 10к айпишников, там-же пока каждый ответит, пройдет 300ms минимум

Он запускает 10к питонячих скриптов

Он запускает 10к питонячих скриптов

Это как-то больно, наверно.

Нагиос умеет так, как вы хотите. Если напишите плагин, который получит список ip, то этот плагин запустится один раз. Напишите один ip на скрипт - запустит 10к скриптов

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

Вся соль в том, чтобы уложиться в окно интервала, в 2 минуты. Даже не в 2, а в минуту хотябы. Это надо параллелить запросы…

Хотя и для nagios такое можно сделать. Но лучше не использовать nagios для новых проектов в 2к17

Вся соль в том, чтобы уложиться в окно интервала, в 2 минуты. Даже не в 2, а в минуту хотябы. Это надо параллелить запросы…

Фишка в правильно написанном сборщике. Например, через python-плагин для collectd делать все запросы асинхронно, или через пул процессов

Фишка в правильно написанном сборщике. Например, через python-плагин для collectd делать все запросы асинхронно, или через пул процессов

Вот на этом у меня затык.

По умолчанию правда collectd (когда я последний раз проверял) скомпилирован под второй python, так что могут быть проблемы

А что требуется от запроса? Про get и ожидать, что пришло 200? Или нужен какой-то процессинг результата?

А что требуется от запроса? Про get и ожидать, что пришло 200? Или нужен какой-то процессинг результата?

Процессинг результата. Его надо закинуть в редис, а там по pub/sub попадет в nodejs приложуху, а от нее на фронтенд. Так чтобы был realtime update на карте.

Просто json-поле взять? Или ещё сложней?

Вот на этом у меня затык.

Ну выставь таймаут в 2 секунды на каждый запрос, итого за 2 минуты в худшем случае ты обработаешь 60 эндпоинтов. Вот и запусти в лоб 10000/60=167 тредов которые собирают и пишут куда-нибудь метрики.

Просто json-поле взять? Или ещё сложней?

Архитектурно, я себе это представляю так: 1. layer1 —> frontend 2. layer2 —> nodejs app, который общается с базой и хранит все интервалы, алерты и прочее 3. layer3 —> тупые микросервисы умеющие собирать метрики так, как им скажут и засылать по pub/sub в l2. Сам сборщик умеет только слать запросы и что дали в body отправлять в l2. Обработка минимальная, только в один формат привести. 4. layer4 — железка, которую мучаем

Во-первых, для layer2 есть готовые решения, тут можно не велосипедить, если этого ещё не сделано

С другой стороны, при данном описании, может и не имеет смысла использовать готовое решение. Напрограммировать тут - 100 строчек кода, если честно

Ну выставь таймаут в 2 секунды на каждый запрос, итого за 2 минуты в худшем случае ты обработаешь 60 эндпоинтов. Вот и запусти в лоб 10000/60=167 тредов которые собирают и пишут куда-нибудь метрики.

хм… в принципе, отдать эту задачу layer3, хай принятый массив айпишников параллелит как хочет. Да и скейлить можно...

Во-первых, для layer2 есть готовые решения, тут можно не велосипедить, если этого ещё не сделано

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

Значит, стоит написать свой скриптец

10000 запросов за 2 минуты - это 83 запроса в секунду. Тут вообще ничего сложного вроде нет.

С другой стороны, при данном описании, может и не имеет смысла использовать готовое решение. Напрограммировать тут - 100 строчек кода, если честно

Вот и я о том-же. Сам мониторинг простой, но метрики могут по разному собираться. Push/pull варианты. 10к может вырасти в 40к. Лишь бы масштабировалось и не сильно ело ресурсы.

Берёшь любимый язык и ищешь "http-клиент, который умеет параллельно делать запросы и поддерживает keep-alive"

кстати, не понимаю, как тут поможет keep-alive? зачем держать коннект с железкой 2 минуты?

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

Я примерно так представляю: каждый сборщик при конфигурации получает список урлов, который мониторит и куда шлёт результаты. Масштабирование - это просто запуск нескольких таких сборщиков.

Да, так и хочу.

Кстати, по roundrobin раскидать каждому сборщику, который умеет обработать, скажем 3000 точек за раз — норм?

Чтобы были на разных машинках и могли уже обработать 10 сек интервал (задел).

А зачем раунд-робин? Просто делим список всех урлов на количество сборщиков и отдаём каждому сборщику

Для распределения нагрузки. Хотя может и оверхед...

Между чем?

ладно, огромное спасибо, +/- я для себя уяснил, что надо написать

Да не за что!

Между чем?

Сборщиками. Я про Weighted Round Robin, когда в зависимости от мощности машинки, давать разное количетво айпишников. Хотя, прочитав спеку еще раз, я догнал, что затупил. Нафиг он тут не нужен.

Да, мудрить не стоит, я думаю. Нагрузки не огромные ожидаются

Кстати, у меня появилась мысль.

Нет, мысль глупая.

?

?

ладно, огромное спасибо, +/- я для себя уяснил, что надо написать

Ничего писать не надо. Берёшь collectd, у него плагин для HTTP на нормальном C написан, не падает месяцами, тупо работает без всякого питона, мультипоточен по определнию (искаропки).

Он не умеет логику парсинга и отправку результатов в кастомное хранилище. Все равно программировать придеться

Он не умеет логику парсинга и отправку результатов в кастомное хранилище. Все равно программировать придеться

Занятное утверждение. Так что конкретно он не парсит? (почему удивляюсь - потому что достаточно плотно с ним работаю).

Ну стандартный curl-плагин умеет регексп и все такое, curl-json и curl-xml соответственно. А если нужна какая-то логика для обработки? Ну типа в одном поле true, значит сложи два других числовых?

Не уверен, что такое просто реализовать

Не уверен, что такое просто реализовать

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

Да, это то, что я предложил вначале)

И плюс добавится output-плагин для хранилища

Да, это то, что я предложил вначале)

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

Согласен. Я просто не уточнял у автора детали логики, только уточнил, что она есть

ERROR: S client not available

Output-плагин все равно писать.

Согласен. Я просто не уточнял у автора детали логики, только уточнил, что она есть

Ещё и кастомное хранилище? Наверняка ещё более плохое, чем инфлакс?

Скорее всего) но это уже не нам решать?

такое ТЗ стоит отстреливать на подходе к снаряду

Отвечу классикой. Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам

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

verbose_logging в ldap.toml вроде

filters = "ldap:debug" и такую в секции логеров в главном файле

Отвечу классикой. Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам

?

Ещё и кастомное хранилище? Наверняка ещё более плохое, чем инфлакс?

postgresql + influxdb

Здарова ребят! такой вопрос, кто нибудь встречался с instafeed.js?

verbose_logging в ldap.toml вроде

не работает

такое строки, что самое забавное, в исходниках графаны вообще нет

Это из документации

Это из документации

ну я ж её прочитал ?

Ну все, дальше я не знаю))

А ldap:debug помогает?

нет

в этом и проблема

Кто-нибудь когда-нибудь делал libvirtd mutual TLS? Чтобы миграции работали?

в этом и проблема

Остаётся только код смотреть(

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

Коллеги, помогите плиз. Что такое модульное (или модельное) окружение применимо к Vagrant? Ну или хотя бы дивапсу в принципе? Гугл не помогает. И это не про модульное тестирование.

Сканворды разгадываешь?

https://nplus1.ru/material/2017/12/20/SEvNS так, девочки

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

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

кто что думает?

Nemo curat.

в этом и проблема

а чего мутишь? :)