в моих тестах мне удавалось жать CH еще сильнее

я тупо брал бд CH за прошлый месяц и хреначил bzip'ом :)

Тока вопрос - демон на чем? На гошке?

на плюсах, это часть FastNetMon Advanced

я думаю на го тоже будет ОК

главное собирать батч на несколько тысяч флоу и лишь как он накопится сбрасывать в CH

это про люубую почти базу справедливо

никто не любит 1 млн мелких записей

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

оно capnp юзает там, в общем сложнее будет интегрировать чем напейсать нетфлоу

на плюсах, это часть FastNetMon Advanced

Круть? Сам пишешь?

в основном да, иногда какие-то вещи, которые не осиливаю наемные программисты

А ты где работаешь если не секрет? Контракты какие то?

работаю я в Cloudflare, DNS инженер, а FNM - это мой личный проект, в свободное от работы время

работаю я в Cloudflare, DNS инженер, а FNM - это мой личный проект, в свободное от работы время

Спасибо!

Для событий эластиксеарч или кликхаус. Другие ответы еще есть?

По этому вопросу еще может кто то что то сказать?

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

PostgreSQL, как ни странно

но не он сам, на его базе есть несколько реализаций column based databases

они как плагины работают

но говорят там надо дьявола призавть, прежде чем их развенешь 5)

С постгрессом же есть проблемы кластеризации

у всех они есть :)

если нет петабайт метрик я бы тыпо поставил СХД теров на 100 с одной тачкой )

и не парился, чесслово

отсутствие кластеризации резко минимизирует боль в заду.

а потом тачка бы навернулась

По этому вопросу еще может кто то что то сказать?

Под твой конкретный кейс в любом случаи придется расчехлять IDE и писать. ES больше под offline-анализ, когда нужно много всякого разного искать, странного. Короче когда тебе lucene нужен.

Потому что по объемам ему плохеет быстрее чем кликхаусу, зато нечеткие схемы можно впихивать

да не нужно ему ничего, кроме большого хранилища

и грепа

большое хранилище - это жопа, если быть честным

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

как навернулась, так и бы и развернулась с нуля со склада :)

если нет такой же тачки на складе - это ссзб, увы.

если у вас есть СХД на 100Т - у вас есть и склад, и запас, я понимаю

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

ага, супермикра на 76 винтов :)

на кликхаус выше порог вхождения (меньше готового в опенсорсе)

но можно больше получить

ага, супермикра на 76 винтов :)

редкое говно

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

В него - кого?

работало норм, я более не работаю там где у меня это было

но вроде не говорили что упало :)

В него - кого?

В Эластик.

работало норм, я более не работаю там где у меня это было

а у меня - в ремонте проводит больше времени, чем работает

эластик имхо оверхедить будет

если твоя задача ложиться на сложить логи с не очень большой скоростью (порядка 100к строк в секунду макс) и дисков вагон и маленькая тележка - возьми для начала ES

эластик имхо оверхедить будет

КЭП?!

боюсь, что просто не повезло, мне с деллами 720ми не везло, они сыпались еженедельно по неведомой херне :)

как быстрый способ получить результат

если твоя задача ложиться на сложить логи с не очень большой скоростью (порядка 100к строк в секунду макс) и дисков вагон и маленькая тележка - возьми для начала ES

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

поанализируй что ты реально делаешь

Не нужно вобще там SSD и скорость. А вот возможность несколько инстансов подключить для балансировки - нужно

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

ну да, само собой. Просто простой способ начать )

Тогда следующий вопрос - для передачи события приложения какой протокол использовать? Есть готовые REST клиенты для того же ES?

@RShishkin у нас оно сделано может быть слегка через задницу, но приложение шлет данные в rsyslog, rsyslog обогощает дополнительной метаинформацией и шлет в кафку из которой это складывается в ES.

У меня мобильное приложение

@RShishkin у нас оно сделано может быть слегка через задницу, но приложение шлет данные в rsyslog, rsyslog обогощает дополнительной метаинформацией и шлет в кафку из которой это складывается в ES.

лучший вариант !

У меня мобильное приложение

делать post request в твой веб

который будет писать лог

вобще постики в файлик сохранять не такая сложная задача.

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

да можно на Го налабать сервис за полчаса

лучше только сразу сериализовать во что то типа протобафа \ авры

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

то есть кодировать бинарями

ERROR: S client not available

и протобаф поделить между твоим сервисом и мобильным приложением

Я знаю тока protobuf и msgpack

у вас тогда протокол появится и сможете версионировать изменения в событиях и всём таком иначе через пару лет бардак будет )

мы тут выкарабкивались год из такого

Но в отладке будет сложнее бинарный протокол?

Я знаю тока protobuf и msgpack

тут еще кстати вопрос в том как оно будет работать на плохой сети )

Но в отладке будет сложнее бинарный протокол?

tcpdump'ом уже не попыришь, а в остальном приложение ж

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

Сеть хорошая слава богу

но если ты людей ценишь то у тебя и так будет https

а там уже не мешает логировать на уровне веб-сервера столько, сколько надо

gRPC :)

capnp :)

msgp - имба, да

автор capnp со мной работает, могу потыкать

gRPC :)

Вот накидали зашибись! Я все эти слова знаю но опыта нет

gRPC дьявольская вещь, как ни странно по WAN вполне ок)

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

уууууу :)

обрисуй всю задачу, а?

а-то ты каждое требование оглашаешь и оно сужает все хотелки шибко

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

@RShishkin если бы я делал с нуля, то я бы выбрал примерно такой подход: 1. Слал от приложения только эвенты и ничего кроме эвентов. Впрочем эвент может содержать и похожие на time-series данные. 2. Слал бы их по https, например protobuf или msgpack внутри POST запросов. 3. В хттп сервере на первых порах складывал бы все в виде json в kafka -> elasticsearch или kafka -> clickhouse

и уже по данным из ES/CH строил бы графики по тем эвентам которые содержат полезную статистику

Ну клиент посылает метрики на сервер метрик и события на сервер событий. Как то так. Аутентификация наверно будет нужна не знаю.

возможно на этапе 2 делил бы эвенты и метрики. Вопрос дальше в количестве такого и во времени на разработку.

Кафка какую конкретно задачу решает? Или проблему?

Очередь?

Кафка какую конкретно задачу решает? Или проблему?

группировка и очередь

эластик - тормоз

и с этим надо как-то бороться

эластик - тормоз

но у него порог вхождения ниже. Если поток маленький на нем можно сделать proof of concept