Как прототип/идея весьма неплохо. N сессий тут решается простым KV хранилищем с ключом по ID клиента.
А для синхронизации последнего отправленного сообщения (проблема "отправленного" и не пришедшего сообщения) можно использовать алгоритм из биржевого FIX. Он прост как две копейки и, по моему, отлично ложится на предложенную архитектуру.
Не претендую на истинность, но я бы в свободное время поразмыслил над этим проектом
Работал и с тем и с другим на очень больших выборках.
ELK непросто ест больше ресурсов: он их сжирает в разы(!) больше.
На моих задача получалось соотношение: 1 инстанс splunk равен 3-4ем EL по производительности.
Субъективно splunk сильно проще и гибче настраивается.
Фатальным недостатком этого закрытого решения — космическая цена. Особенно для крупных компаний с большим объемом данных
Товарищи из Acronis!
Я уже год смотрю на True Image. Выглядит супер, репутация — отличная.
Давно готов купить, но останавливает лишь одно: почему нет версии под Linux? Серверную не предлагайте, пожалуйста.
Думаю немало разработчиков, а они прекрасно осведомлены о необходимости резервного копирования, используют Linux не только на серверах, но и как рабочие станции.
Во-первых, спасибо за s6.
Во-вторых, понятно, что задачу можно решить более одним способом.
В-третьих, все-же сравните затраты на запуск одной команды или на оркестрацию целого вороха утилит. Это как Docker: можно без него, напрямую с cgroups и bridge-utils, но с ним немного проще =)
Имелось ввиду, что мы хотим передать другим людям (например админам) для дальнейшей эксплуатации готовый набор параметров и настроек.
Грубый пример: перенос между стендами разработки и тестирования.
Вполне возможно. 500ГБ данных за 6-8 часов (логи). В дальнейшем планировалось нарастить до 1-2ТБ. Данные поступают ежедневно.
Мое мнение как инженера — очень качественный (скорость, удобство, возможности) продукт. Но бюджетом управляю не я)
Работал со Splunk. Система реально очень быстрая и удобная. «коробочный» ELK выдавал 1/10 скорости на том же оборудовании.
Только один минус: стоит как крыло самолета. Может даже дороже
Москва, 1 час на работу, 1.5 обратно. Пропуска и временной контроль. Хреновая столовая и отсутствие адекватных кафе рядом. Почти опен-спейс и шум.
Я разработчик (т.е. рабочее место — только компьютер по факту) и если есть хотя бы тень надежды, что когда-нибудь компания, в которой я работаю, перейдет на такой режим, я буду безумно счастлив (и огромное количество моих коллег думаю тоже)).
Вот эту боль я надеюсь решит Sococo или какие-нибудь еще альтернативы.
P.S.
Но для текущего места работы, это мечты укурившегося оптимиста
Очередь сообщений будет копится в зависимости от типа источника. Например: для БД, транзакция означает откат и в БД, seda — аналог BlockingQueue с заданием лимитов. В каждом случае по своему.
Если упрощено, то да, в большинстве случаев сообщение будет передано, когда абонент вернется в строй
Мое мнение зиждется на беглом прочтении документации о Apache Flume и нескольких лет разработки на Apache Camel)
Camel довольно таки универсальный инструмент для передачи, преобразования и маршрутизации сообщений откуда угодно, куда угодно и как угодно. С огромным набором готовых входов (Source в терминологии Flume), выходов (Sink в т. Flume) и преобразований. Важное отличие: надо кодировать (xml, DSL, java, scala, groovy) и одним конфигом как в Flume не обойтись.
У меня создалось впечатление, что Flume это Camel, из которого выкинули все по-максимуму и дописали пару функций)) Но это чисто ИМХО.
Меня, честно говоря, тоже сильно напрягает протокол HTTP/2. Да, я знаю, что за ним будущее. Но после поверхностной оценки RFC для него, мне стало не очень ясно, как впихнуть его поддержку во все популярные языки?
Скажем, для базового уровня поддержки HTTP/1.0 нужна лишь базовая поддержка TCP и работа со строками в минимальном варианте. Это позволяет реализовать его хоть в IoT. С другой стороны, множественные потоки, приоритеты и т.п. ввергают меня в пучину ужаса, при мысли о том, как все это впихнуть в 32КБ памяти. А тот-же gRPC в этой области избавил бы от множества проблем…
Поэтому, также прошу знающих людей разъяснить момент с альтернативным транспортом прикладного уровня.
Полностью согласен. Посему и написал just-for-fun) На работе все-таки используется IBM/Tibco, а для своих проектов RabbitMQ (в котором тоже есть грабли, но решаемые с меньшими трудозатратами).
Приятно видеть еще одного ZMQ'шника. С библиотекой я знаком более трех лет, но не профессионально. Может статью набросаете? А то в русскоязычном сегменте по ZMQ удручающе мало информации.
Если кому интересно, то я делал не сложный ui на этом фреймворке: https://github.com/reddec/monexec-ui
Это SPA UI для супервизора https://github.com/reddec/monexec
В целом удобно.
Как прототип/идея весьма неплохо. N сессий тут решается простым KV хранилищем с ключом по ID клиента.
А для синхронизации последнего отправленного сообщения (проблема "отправленного" и не пришедшего сообщения) можно использовать алгоритм из биржевого FIX. Он прост как две копейки и, по моему, отлично ложится на предложенную архитектуру.
Не претендую на истинность, но я бы в свободное время поразмыслил над этим проектом
Идея отличная.
Можете еще глянуть на эту статью https://habr.com/post/240053/ — там я описывал сходную идею на UDP multicast (не broadcast)
Работал и с тем и с другим на очень больших выборках.
ELK непросто ест больше ресурсов: он их сжирает в разы(!) больше.
На моих задача получалось соотношение: 1 инстанс splunk равен 3-4ем EL по производительности.
Субъективно splunk сильно проще и гибче настраивается.
Фатальным недостатком этого закрытого решения — космическая цена. Особенно для крупных компаний с большим объемом данных
Товарищи из Acronis!
Я уже год смотрю на True Image. Выглядит супер, репутация — отличная.
Давно готов купить, но останавливает лишь одно: почему нет версии под Linux? Серверную не предлагайте, пожалуйста.
Думаю немало разработчиков, а они прекрасно осведомлены о необходимости резервного копирования, используют Linux не только на серверах, но и как рабочие станции.
Во-первых, спасибо за s6.
Во-вторых, понятно, что задачу можно решить более одним способом.
В-третьих, все-же сравните затраты на запуск одной команды или на оркестрацию целого вороха утилит. Это как Docker: можно без него, напрямую с cgroups и bridge-utils, но с ним немного проще =)
Идея была именно такая (зашивать). Для мониторинга запущенных контейнеров "из-вне" лучше использовать Consul as-is.
Имелось ввиду, что мы хотим передать другим людям (например админам) для дальнейшей эксплуатации готовый набор параметров и настроек.
Грубый пример: перенос между стендами разработки и тестирования.
В образах для докера. Т.к. далеко не всем приложениям нужен питон для запуска, то большинство образов его в себя не включают. Например alpine.
Тут я вопроса не понял. Чутка деталей было бы отлично.
Предполагаю, что речь шла про какой-то web UI, но зачем в мелкие контейнеры тянуть еще N утилит общего назначения?
Мое мнение как инженера — очень качественный (скорость, удобство, возможности) продукт. Но бюджетом управляю не я)
Только один минус: стоит как крыло самолета. Может даже дороже
Я разработчик (т.е. рабочее место — только компьютер по факту) и если есть хотя бы тень надежды, что когда-нибудь компания, в которой я работаю, перейдет на такой режим, я буду безумно счастлив (и огромное количество моих коллег думаю тоже)).
Вот эту боль я надеюсь решит Sococo или какие-нибудь еще альтернативы.
P.S.
Но для текущего места работы, это мечты укурившегося оптимиста
Если упрощено, то да, в большинстве случаев сообщение будет передано, когда абонент вернется в строй
Camel довольно таки универсальный инструмент для передачи, преобразования и маршрутизации сообщений откуда угодно, куда угодно и как угодно. С огромным набором готовых входов (Source в терминологии Flume), выходов (Sink в т. Flume) и преобразований. Важное отличие: надо кодировать (xml, DSL, java, scala, groovy) и одним конфигом как в Flume не обойтись.
У меня создалось впечатление, что Flume это Camel, из которого выкинули все по-максимуму и дописали пару функций)) Но это чисто ИМХО.
По делу:
Скажем, для базового уровня поддержки HTTP/1.0 нужна лишь базовая поддержка TCP и работа со строками в минимальном варианте. Это позволяет реализовать его хоть в IoT. С другой стороны, множественные потоки, приоритеты и т.п. ввергают меня в пучину ужаса, при мысли о том, как все это впихнуть в 32КБ памяти. А тот-же gRPC в этой области избавил бы от множества проблем…
Поэтому, также прошу знающих людей разъяснить момент с альтернативным транспортом прикладного уровня.
Приятно видеть еще одного ZMQ'шника. С библиотекой я знаком более трех лет, но не профессионально. Может статью набросаете? А то в русскоязычном сегменте по ZMQ удручающе мало информации.