Пиковый сбор данных.

https://www.zabbix.com/documentation/2.0/manual/appendix/items/activepassive

А если машины будут лить готовый файлик в строго отведённое место. А у тебя будет скрипт, который по таким местам будет прогуливаться и заливать данные последовательно.

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

Для синхронизации предлагаю простое условие: машина заливает файл за секунды, а скрипт обрабатывает только файлы, изменённые более минуты назад.

Ну или даже проще - 3000 sqlite баз, из которых скрипт забирает свежие данные (вроде там всё нормально с блокировкаи)

Сразу захотелось решить прямо - и просто инсертить в базу мускула,

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

а потом сохранять на диске в нормальную таблицу

Активные сессии похожи на то что нужно, но вот это будет работать при условии заведомо ожидаемых нод.
А тут проблема в том, что эти машинки плавающие. И могут появляться в разных местах, только после сообщать кто они, и на базе этого процессор запишет алиас на «кто""где», и отработает, на это время, мониторинг по этому «адресу», после чего, если нужно, забудет о нём.

Ну суть то первого предложения - снова же может упереться (неожиданно при чём) в прерывания самой ОС, к примеру (если я правильно выражаюсь). Такое проявляется только на больших объёмах. потому редко ожидаемо.
Второй, с муслайтом - пока, увы, не вариант.

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

Дело больше не в самой базе или ресурсах, а конфигурации сервака, где она живёт. Потому это, к сожалению, не вариант на данный момент. Уже смотрели тоже на подобное.

Нагрузку в 3000 соединений ИМХО выдержит и первый пенёк.

что-то вы там неправильно делаете

zabbix и zabbix прокси может мониторить все, что можно заскриптовать.

Ресурс физический и логический - разное дело.
Серваки у нас дай скотче. Проблема именно в системных процессах, трэдах и прерываниях.

Это правда. Эту штуку получили уже заведомо дефектной, увы.
Но суть в невозможности останавливать эту систему, ибо всё завязано на большие деньги.

задумался делать это через ssh

плохая идея. Там на установку соединения куча времени сжирается, процессорного и реального. Если нужно шифрование, то лучше данные предварительно зашифровать, а расшифровывать потом постепенно

как обычно, софт считающий деньги - редкостно говёного качества? )

плохая идея. Там на установку соединения куча времени сжирается, процессорного и реального. Если нужно шифрование, то лучше данные предварительно зашифровать, а расшифровывать потом постепенно

Вот, важная информация, спасибо. А по-поводу шифрования - в данном случае будут ходить данные, что можно не прятать, потому это не критично.

И где загрузка? Прогуливаться скриптом раз в 10 сек (к примеру) на 100 отчетов (к примеру).

Можно же регулировать.

А машинки пускай льют следующий файл, если предыдущий не обработан (сиречь не удалён).

как обычно, софт считающий деньги - редкостно говёного качества? )

Тут не только считают. И да, некоторые вещи сделаны так - что волосы дыбом. Что можем - переделываем по красоте, но есть моменты которые тупо нельзя побороть в силу туголобых ответственных и «интерпрайзности».

Одновременно, в одну секунду, 3000 файлов. Вот проблема. Пре и постобработка - это плевать. Горлышко бутылки в 3000 в одну секунду, при том, что ничего нельзя потерять.

Пре и постобработка - это плевать

Пусть ошибки обрабатывают ноды - отвалилась из-за перегрузки: sleep $(($RANDOM/1000))

Итого нужен путь monitor <- node

Фиговый вариант, у вас случаем не бот-сеть? :)

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

Одновременно 1000 коннектов ты хочешь сказать? См. ниже, в случае последовательной обработки будет один коннект, одна открытая сессия с одним/двумя подготовленными транзакциями. При этом комит в БД можно делать через 100/1000, а не как у вас (как я понял) один коннект/тред - одна транзакция - один коммит. Выйгрыш будет от снижения транзакций, но не фантастический.

Вообще 1000 записей в БД это не так много. Хотя, ты не указал объемы: кол-во таблиц, кол-во параметров, сколько процедур выполняется за раз или просто insert/update.

Тыкнув пальцем в небо - задумался делать это через ssh.

Просядет как канал, так и cpu, если сервак с мониторингом один. Поэтому грамотный вариант это сбор статистики и сжатие. При этом лучше вместо ssh использовать scp, т.е. по началу кидать просто файлы. Можно организовать через rsync.

а сколько байт в одной порции данных, посылаемой с одного компьютера?

В идеале наименее ресурсозатратным будет отсылать один UDP пакет с каждого компа, принимающий сервер это всё моментально переварит

ибо машины за натом, и плюс доступ только поверх впн"а

а где и как обрабатываются входящие VPN соединения? Узкое место вполне может быть тут

Просядет как канал, так и cpu, если сервак с мониторингом один. Поэтому грамотный вариант это сбор статистики и сжатие. При этом лучше вместо ssh использовать scp

в чем разница? Протокол один и тот же

Подозреваю, что если 3000 машин одновременно ломанутся на этот сервер, он превратится в тыкву, а клиенты отвалятся по таймауту раньше, чем смогут залогиниться )

Фиговый вариант, у вас случаем не бот-сеть? :)

Нет, но могу сделать одним апдейтом :)

Одновременно 1000 коннектов ты хочешь сказать?

Да, на больше даёт отказ.

Вообще 1000 записей в БД это не так много

Да в том то и дело, большие проекты тянут от 100000, после уже начинаю думать про, к примеру, гибрид *sql и nosql баз.
А тут проблема в самой среде, где она живёт. Может и стоит поднять альтернативу и проверить. Что-то я не задумался о такой очевидности...

При этом лучше вместо ssh использовать scp, т.е. по началу кидать просто файлы. Можно организовать через rsync

Да, вариант как и у товарища ziemin'a. Но я боюсь решать без бенчмарков, хотя бы. Нужно будет быстро наваять хоть наколенный.

но вот это будет работать при условии заведомо ожидаемых нод.

Откуда я знаю, возьмите да проверьте.

а где и как обрабатываются входящие VPN соединения?

Циски с впн-серваками.

В идеале наименее ресурсозатратным будет отсылать один UDP пакет с каждого компа, принимающий сервер это всё моментально переварит

UDP подразумевает возможность потерять - а это чревато, в моём случае.

в чем разница? Протокол один и тот же

А ведь не сказано, что будет выполнятся по ssh. Можно и шел-скрипты пускать, тогда cpu будет съедено на выполнение их (3000 одновременных процессов). При scp протокол tcp сделает свое дело - будут какие-то задержки на заливку, но не более.

Подозреваю, что если 3000 машин одновременно ломанутся на этот сервер, он превратится в тыкву, а клиенты отвалятся по таймауту раньше, чем смогут залогиниться )

Нет. Считаем, что канал выдержит, вопрос встанет иначе: нагрузка io, нагрузка cpu. Сбрасываем вес io wait в надежде, что спасет дисковый кэш в несколько гигов. Остается cpu, но даже при больших нагрузках таймаутов не будет, пока не будет реальных блокировок, скажем те же дисковые операции или нереальные мегарасчеты в несколько потоков.

Да, на больше даёт отказ.

ulimit -Ha показывает то, что доктор прописал?

scp как будто не поверх ssh работает

Нет. Считаем, что канал выдержит, вопрос встанет иначе: нагрузка io, нагрузка cpu.

в первую очередь всё упрётся в CPU, т.к. там много криптографических вычислений, Диффи-Хеллман и всё такое. Ну и плюс задержка из-за кучи запросов-ответов, которые по протоколу полагаются

Городить велосипед для мониторинга - плохо. Если «велосипед» является неизбежностью в данных условиях, это в 95% значит что условия тоже являются велосипедом.

Поэтому надо стараться привести инфраструктуру к такому виду, чтобы она была manageable, тем более - когда речь о 3k машин.
Будут траблы в своем велосипеде - замучаетесь исправлять, да и инструменты вменяемого управления тоже придется «изобретать».

Что касается нагрузки - то на 3k машин может быть до 3k серверов мониторинга - масштабирование идеальное. Так что тут не вижу проблемы абсолютно.

Слишком много теории. Либо шапку топа в студию с сервера мониторинга/сервера БД, либо тебе никто не поможет и будет куча теории.

Шапка включает в себя load average, кол-во процессов, кол-во ОЗУ/свапа и статистика по нагрузке user/io/idle/etc. Т.е дефолт. В пиковой нагрузке. Также неплохо написать сколько ядер на серверах.

UDP подразумевает возможность потерять - а это чревато, в моём случае.

ну если поверх голой сети, то да. А если внутри впн-а, то тут можно экспериментально проверить, бывают ли потери в принципе. Какой именно VPN используется?

Самая правильная схема, на мой взгляд: пишется софтинка, которая слушает сокет и ждёт подключений. Каждый подключившийся клиент сразу сливает свои данные (можно предварительно сжатые и зашифрованные) и отрубается, без всяких приветствий и протоколов. Данные запоминаются в памяти. Когда отрубится последний 3000-ый клиент, данные инсертятся в базу

Да, крутили. Не помогло. Уповаем на центосопроблемы.
В общем уже выделил на завтра себе железку - сделаю тестовый сервак и погоняю всё как следует. Ибо 1000 для мускула - меня просто смущает даже.

scp как будто не поверх ssh работает

Я не хочу спорить, т.к. спор ни о чем. Одно дело пускать скриптики, другое - копировать файлы по 100кб.

Ну и плюс задержка из-за кучи запросов-ответов, которые по протоколу полагаются

В момент «задержек» ОС запоминает состояние процесса и переключается на другой. Почти любая операция по сети/сокетам это переключение контекста. Т.о 3000 процессов будут работать одновременно без особых задержек. Хватит теории, возьми да посмотри.

Поэтому надо стараться привести инфраструктуру к такому виду

Всё верно сказали, но мир не идеален, и некоторые вещи можно исправить только после сжигания всего до тла. Тут такое не прокатит, увы.

Я не хочу спорить, т.к. спор ни о чем. Одно дело пускать скриптики, другое - копировать файлы по 100кб.

какая разница? Установить ssh сеанс и залогиниться займет одинаковое время, независимо от того, файлик мы дальше будем копировать или буковки в консоли печатать

В момент «задержек» ОС запоминает состояние процесса и переключается на другой. Почти любая операция по сети/сокетам это переключение контекста. Т.о 3000 процессов будут работать одновременно без особых задержек. Хватит теории, возьми да посмотри.

не просто3000 процессов, а 3000 процессов, жрущих CPU на 100% :)

Тут такое не прокатит, увы.

Ростелеком какой-то ;)

но мир не идеален, и некоторые вещи можно исправить только после

Согласен. Но стараться не умножать проблемы можно начинать уже сейчас.

какая разница?

Ладно, соглашусь, но только с тем, что ssh прожорлив по cpu сильнее остальных вариантов, например, просто сериализации текстовых данных (soap, xml, json и т.п)

Итого приходим к варианту сброса данных на чистых сокетах. Вопроса два: хранение данных и нужна ли защищенность данных (получим ssl, что не лучше ssh по сути).

Легкие решения: zabbix, apache/nginx + fastcgi + soap/json/bson/xml, либо corba (т.е. без этапа сериализации данных).

ТС, чем zabbix не угодил?

Итого приходим к варианту сброса данных на чистых сокетах. Вопроса два: хранение данных и нужна ли защищенность данных (получим ssl, что не лучше ssh по сути).

SSL тоже не нужен, данные шифруем предварительно и отправляем одним куском. Например, используя gnupg или openssl

Только ТС пока не озвучил количество байт от одного компа, поместятся ли все 3000 отчётов одновременно в RAM сервера

При интенсивном поступлении событий из множества источников принято делать пакетный (butch) инсерт. Для этого события буферизируют, а затем несколько воркер-тредов (пул) - фиксируют записи пачками в БД.

Как правило, такой подход позволяет улучшить пропускную способность на порядок, а то и более.

Из готовых решений рекомендую Graylog2. http://server.dzone.com/articles/graylog2-optimization-high-log

Две копейки: если за NAT, то можно посмотреть в сторону всяких zabbix proxy. Ну это так. Малоли пригодно будет.

ТС, чем zabbix не угодил?

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

Только ТС пока не озвучил количество байт от одного компа, поместятся ли все 3000 отчётов одновременно в RAM сервера

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

При интенсивном поступлении событий из множества источников принято делать пакетный (butch) инсерт. Для этого события буферизируют, а затем несколько воркер-тредов (пул) - фиксируют записи пачками в БД.

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

Из готовых решений рекомендую Graylog2

Спасибо, сейчас посмотрим что за зверь.

Две копейки: если за NAT, то можно посмотреть в сторону всяких zabbix proxy. Ну это так. Малоли пригодно будет.

Да, решение, судя по уже не первому, очевидное. Но увы, пока я не вижу в нём удобства реализации для своего случая.
В любом случае большое спасибо за совет.

Совет - не нужно забывать старые хосты. После внедрения мониторинга в реальную практику обязательно появится потребность смотреть историю. Возникнут вопросы типа: когда хост «ИванПетрович» последний раз выходил на связь и какие параметры работы при этом имел.

Для отправки идеальным будет агент, во второй версии запилили много нового, к примеру https://www.zabbix.com/documentation/2.0/manual/discovery/auto_registration.

То есть сценарий такой:
1. Хост выходит на связь с заббиксом, пересылает свой идентификатор и данные мониторинга
2. Если идентификатор новый - создаётся новая запись о хосте в заббикс
3. Если идентификатор уже существует - данные будут сохранены в привязке к старой записи о хосте
4. Записи о хостах заббикс не удаляются, и по ним всегда можно посмотреть историю

P.S. Будет одна проблема - обеспечить уникальность имени, которым будет представляться агент. Поскольку это имя определяется на стороне агента. То есть как минимум предотвратить дублирование.
P.P.S. Нужно будет продумать обеспечение надёжной идентификации «своих» клиентов