И да. Если логи по факту нужно отдавать в сеть то срание на диск ни к чему

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

а логи надо сохранять

а логи надо сохранять

Буферблоат блеать

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

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

Смотри, у нас схема например такая что если выходит кластер в Европе из строя то кластер в Америке просто накапливает у себя. Америка работает только с HA Америки

Смотри, у нас схема например такая что если выходит кластер в Европе из строя то кластер в Америке просто накапливает у себя. Америка работает только с HA Америки

да, норм. это проблемы раббита. но до этого приложение должно плюнуть евентом в раббит.

Это 10 строк кода )

да, норм. это проблемы раббита. но до этого приложение должно плюнуть евентом в раббит.

Вот для таких хуевин я и предлагаю протокол сислога

Это 10 строк кода )

а сколько строк кода обработка невозможности плюнуть в раббит? :)

обработка буферизации сообщений, которые не плюнулись в раббит?

Ну ладно, еще fail safe драйвер с раундробином для выбора ноды. Еще +100

Прога срет в юникссокет в сислогный демон который уже например срет в рабит или куда там надо

У нас кстати fail safe драйвер тоже запилен

Вернее 10 прог все срут в сислог. По СТАНДАРТНОМУ протоколу

Такого чтобы прилег весь кластер в одном из регионов... Ну если весь регион недоступен то у тебя проблемы гораздо больше чем отсутствие логов

Без выебонов. Хочешь буфферизовать логи ? Делай это в своем хитровыебанном сислоге

Без выебонов. Хочешь буфферизовать логи ? Делай это в своем хитровыебанном сислоге

между приложением и сислогом тоже нужна буферизация.

между приложением и сислогом тоже нужна буферизация.

Если энтот сислог написать правильно то можно забить

Если энтот сислог написать правильно то можно забить

нельзя

Рантайм прио в тхреаде и млокалл

Короче на самом деле дискуссия ни о чем пока не определятся критерии дюрабилити для логов

Короче на самом деле дискуссия ни о чем пока не определятся критерии дюрабилити для логов

да

нельзя

Обоснуй

Обоснуй

если UDP - то мы теряем евенты. если TCP - то мы вынуждены уметь обрабатывать ситуацию, когда мы пишем бёрст логов, а с той стороны не успевают вычитывать. буфера ОС нам будет мало.

если UDP - то мы теряем евенты. если TCP - то мы вынуждены уметь обрабатывать ситуацию, когда мы пишем бёрст логов, а с той стороны не успевают вычитывать. буфера ОС нам будет мало.

Рантайм прио же у сислога

Рантайм прио же у сислога

охуеть и он теперь что, начал работать быстро?

охуеть и он теперь что, начал работать быстро?

Блять ну сделай мультитхреадным

Явно в цпу не упрется жи. А в писалку. Тоесть в сеть или диск

Явно в цпу не упрется жи. А в писалку. Тоесть в сеть или диск

ты удивишься

ты удивишься

Подробнее

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

он просто не станет читать сокет, потому что в этот момент он, сука, рестартнулся и порвал коннект.

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

Организуй в нем буфер на 5 гигов

если UDP - то мы теряем евенты. если TCP - то мы вынуждены уметь обрабатывать ситуацию, когда мы пишем бёрст логов, а с той стороны не успевают вычитывать. буфера ОС нам будет мало.

есть два протокола. на одном пакеты точены, на другом датаграммы дрочены

в нем - да. но это его буфер.

он просто не станет читать сокет, потому что в этот момент он, сука, рестартнулся и порвал коннект.

Это аварийная ситуация

Это аварийная ситуация

поднимем ручки и заплачем.

А вдруг кернел паник ?

А вдруг бед сектор ? Оом ?

одно из хороших правил при программировании - с той стороны сокета вам вообще никто ничего не должен :)

Метеорит ?

одно из хороших правил при программировании - с той стороны сокета вам вообще никто ничего не должен :)

Это верно

Но кагбе при писании на диск тебе тоже не очень то и много должны

Но кагбе при писании на диск тебе тоже не очень то и много должны

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

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

Сислог на этом же контупере. Юникссокет жи

А диск имеет свойство внезапно притормаживать

А диск имеет свойство внезапно притормаживать

реже фсинкай и не дрочи свой сеф.

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

В итоге пиздец сложнейший код пологированию

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

а то. впрочем, писать логи в отдельном треде - это вообще гудпрактис

В каждом приложении

правда мы щас дойдем до буферизации сообщений между тредами и на запись

:)

как хорошо что я девопс и не занимаюсь ничем этим, а просто жму кнопочку "build & deploy & make zbs" :)

На таких объемах можно других китайцев прогнуть. aic например

Дело в том что логи не нужны

Они нужны только когда что-то сломалось, что решается трейсингом.

Они нужны только когда что-то сломалось, что решается трейсингом.

Чувак, искренне желаю тебе удачи

q

да, да. кафка тоже теряет сообщения.

зависит от настроек. вообще не должна, если правильно кластер приготовить

ERROR: S client not available

Надо гарантию — кластер рэбита и так далее

вот реббит точно гарантирует только потерю данных на не-мастере при split brain

и вообще никакой консистентности не обещает

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

приложение должно уметь отправлять в stdout

А кто тебе будет гарантировать такое в таких условиях?

А кто тебе будет гарантировать такое в таких условиях?

любой честный кластер, типа zookeeper

русько-склавенский врач гарантирует

да, да. кафка тоже теряет сообщения.

С дефолтными настройками - точно теряет )

И где в zookeeper очереди или стримы?

Я просто не очень понял почему ты сейчас zookeeper привел в пример )

Я просто не очень понял почему ты сейчас zookeeper привел в пример )

заведи в zookeeper очередь — будет очередь. я делал, работала надёжно и быстро.

А топики? А фанауты? А раутинг из коробки?

Какой смысл сравнивать несравнимое, я об этом.

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

Уже бегу тратить время на то, что можно взять и использовать

Куча middleware демонов которые перегребают из одной очереди/топика в другой — вот еще мне этого не хватало. Особенно в наших масштабах

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

Я вот думаю что если взять 5 самых умных девопсов, и закрыть их вместе в офисе на пару месяцев...

... то придя туда через 2 месяца, нет, вы не найдете идеально работающую инфраструктуру. Вы найдете 5 мертвых девопсов, перегрызших друг другу глотки. А на серверах установленные rabbitmq zookeeper elasticsearch docker lxc kubernetes collectd statsd kibana terraform ansible prometheus concourseci postgres kafka mongodb cassandra jenkins bamboo. И все это не работает.

А стены исписаны разными требованиями друг к другу, к бизнесу и от бизнеса.

Ты имеешь ввиду, что она будет выглядеть как типичный берлинский клуб? http://varlamov.me/img/ger_berlin/28.jpg ?

Какая разница чья задача есть throughput в итоге такой что все пиздой накрывается?

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

так он не падает. она просто проебывает маленькую порцию сообщений. молча.

занятно. там в протоколе есть ack от сервера, если его запросить, с ним тоже терялось??

Да ладно, сколько процентов логов читается?)

ротация необязательна даже, во многих кейсах можно тупо транкейтить файлы (если объемы единичных write'ов невелики)

как truncate без потерь сделать? там же гонка между последним чтением, записью от приложения и truncate

как truncate без потерь сделать? там же гонка между последним чтением, записью от приложения и truncate

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

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

есть FALLOC_FL_COLLAPSE_RANGE, но я не думаю, что где-нибудь это используется :) к тому же оно на практике реализовано через обязательный fsync внутрях

Кто есть дока по убунте 16.04 - там в инсталяшке можно thin lvm thinpool and mirror сразу сделать, или надо в консоль и... и RAID1 не понимает GRUB...

Кто есть дока по убунте 16.04 - там в инсталяшке можно thin lvm thinpool and mirror сразу сделать, или надо в консоль и... и RAID1 не понимает GRUB...

В консоль

А с рейдом чего делать? Я хочу, а... а вот этот простой mirror я даже по доке е понял зачем существует