но ессно она ничего читать не умеет - ты В нее пишешь, либо ИЗ нее читаешь

Ты в нее *пушишь*

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

ага

А как минус - Кафка геморройная весьма

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

кафка прям лапочка :) если ее сравнивать со всякими там эластиками или кролями и прочим

ну кролик тоже хороший, но сильно другой

кажется это оффтоп

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

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

ну тот же project frankenstein тоже на кафке был основан

он же project vulkan

ныне почивший

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

а, на проме

https://github.com/digitalocean/vulcan

угу

эммм.... не то окно?

да ну, зачем мне это

пардоньте

жалко ничего НДА не рассказал :(

скучно

ну да только фоток с субботников тут не хватало :)

жалко ничего НДА не рассказал :(

я не такой

ныне почивший

Откуда такие сведения? А их текущий мониторинг не через вулкан работает?

не знаю как их нынешний. но репозиторий архивирован и в рид-онли

написано же огромными буквами

Warning: This project is currently not maintained, and there is no plan to do so ATM.

думаю они за два года всё переделать успели

> This repository has been archived by the owner. It is now read-only.

они его собрали ради теста и перед каким то промкомом, а вот что там дальше было я как то нить потерял

два года назад это было, на промкон 2016

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

угу

но держать инфлюкс в проде это такое

ну там на выбор, но чтение/запись, из официального выбор не особо велик

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

это некоторое общее правило, хотелок с исключениями полно

Центральной системе проще работать в режиме пулла т.к. нет вероятности того что в одну секунду ничего не прилетит а в другую прилетит 10М метрик и их надо прожевать и никого из агентов не обидеть. Агенты в этом случае тоже более простые по логике - вот я что то собрал а взяли это с меня или нет - мне пофигу. По этому пути пошел пром (там скорее всего были и другие причины, но понедельник и я мало кофе выпил) Но у этой схемы есть заложенная в нее особенность - если что то протупило в центральной системе то мы теряем метрики сразу по целому контуру.

Хуевая особенность, имхо ?

ну можно поставить 2 прома... или 3 и таким макаром снижать вероятность такой ситуации, но как то красота решения начинает падать

вот если в стек впихнуть MQ которая по производительности » остальных компонент - мы получаем плюсы и той и той архитектуры, но как "-" наш стек становится сложнее

У нас вот было соображение (пока не реализованное) что mq в идеале должна работать как stack, потому что если агент затупил (или не было связи), собрал много данных и прислал большую пачку, а другие агенты продолжали и продолжают нормально все присылать, то пачку хорошо бы обрабатывать только в те моменты когда текущие, "свежие" данные уже обработаны

kafka так умеет

такой QoS как бы.

kafka так умеет

Расскажи?

что именно?

Как именно это на кафке ты подразумеваешь делать?

хм, кажется я неправильно прочитал

разные топики? или консьюмеры "перескакивают" на конец, а потом дочитывают непрочитанное? или как?

Логика такая должна быть на стороне консьюмера. Кафка такую магию с временем не умеет.

У нас в первом приближении что-то такое есть, но не достаточно системно.

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

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

ну вот "перескочить" на последние записи - я еще понимаю как сделать. А как сделать дочитку непрочитанного ппотом — это какой-то геммор.

У нас просто вот недавно прям был реальный случай когда у клиента "проснулся" агент, который два месяца ничего не присылал (выяснилось, что они его сами по сети отрубили от всего). Но агент все это время собирал данные исправно и тут начал за все это время их присылать. И хоть у агента есть лимит сколько он старых данных хранит, там все два месяца влезли, т.к. пожалось хорошо.

не, ну проблема понятна

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

а не проще было горизонтально размасштабировать консьюмеры?

или что-то мешало так сделать?

типа "много данных - много консьюмеров-воркеров в консьюмер-группе"

"мало данных - мало воркеров"

Там думаю паника была из за данных, которые сломали текущую картину

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

Сильнее чем по партициям консьюмеров не заскейлишь все равно

Там думаю паника была из за данных, которые сломали текущую картину

Не мог бы пояснить?

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

сколько там данных-то за два месяца пришло?

Не мог бы пояснить?

Ну у вас время старья разве не совпало с текущими метриками?

нет, агент записывает время когда он что снял.

сколько там данных-то за два месяца пришло?

ща посмотрим

И в чем необходимость старых метрик?

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

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

пиздеть не мешки ворочать!

пиздеть не мешки ворочать!

это я про себя если что

Зачем нужны старые не актуальные данные?

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

почему потеряло?

но так то это можно сделать 2 топиками - в один льется сырятина во вторую группа демонов перекладывает то что прилетело в 1 по условию, я это стейтлесс парсерами на ГО реализовывал, возможно кафка стрим можно прикрутить

ну вот нафига данные с сервера если на нем небыло сети 2 месяца? :)

Зачем нужны старые не актуальные данные?

а кто решает какие данные актуальные а какие нет?

во во!

ну вот нафига данные с сервера если на нем небыло сети 2 месяца? :)

на нем не было сети до мониторинга, это не значит что он ничего не делал

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

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

ну вот у меня по кафке в подсетке с хостами лежит (чтобы вообще роутинга небыло), и с них данные кушаются в центральную кафку

в общем случае конечно низя

вопрос стоимости всегда надо поднимать

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

мне близка ваша боль хоть и не в такой степени :)

Там почти гиг был выделен агенту для старых данных, ну вот он столько и прислал примерно вроде

ну вот много кафок - одно из решений либо распиливание одного топика на два

У нас совсем недавно была похожая ситуация, один из контейнеров зарезали фаерволом, потом разбанили ему порт до графита, и он отправил всё что накопил, 68 млн метрик. Разъжевали вообще без каких либо проблем, на память остался 30секундный пик на графиках приема метрик в КХ

Ну гиг вроде не безумно большой объём

2М в секунду - норм