GK
Откуда вообще такие выводы?
К получателю.
У тебя схема вида "приложение->сайдкар отправителя -> транспорт -> сайдкар получателя -> хранилище логов.
Тут от надежности транспорта (кафка или http) общая надежность практически не зависит.
Size: a a a
2021 July 05
PD
НИ
Из твоих слов, но выводы могут быть ошибочными. Я ведь задаю вопросы, например:
> Куда будут доставляться логи если кафка недоступна?
> Куда будут доставляться логи если кафка недоступна?
PD
При этом всегда есть буферизация на стороне сайдкара отправителя, обычно и у сайдкара получателя.
И репликации (там разные варианты есть, зависит обычно от хранилища логов)
И репликации (там разные варианты есть, зависит обычно от хранилища логов)
GK
Утверждение ровно одно, если получатель логов МЕНЕЕ надёжен, чем Кафка, то цепочка доставки логов с Кафкой будет в сумме более надёжной.
GK
И уверждение второе: Эластик менее надёжен, чем Кафка.
PD
Не. Вся цепочка имеет надежность самого слабого звена. И тут это эластик, а не http между флюентами.
Поэтому вместо кафки можно взять http и не париться.
Поэтому вместо кафки можно взять http и не париться.
НИ
из этого не следует что все должно идти через 1 кластер кафки. Нет?
GK
А это тут при чём?
НИ
Это неправда.
Недоступность эластика компенсируется кафкой - она же хранит сообщения пока хватает диска.
Недоступность эластика компенсируется кафкой - она же хранит сообщения пока хватает диска.
GK
Это неправда, как выше заметил Николай.
PD
Мы про какую ненадежность? Про потерю накопленных данных? Тут эластик так же надежен, как и кафка.
Про локальные простои? Тут флюента достаточно для буферизации на время недоступности
Про локальные простои? Тут флюента достаточно для буферизации на время недоступности
PD
Увы, но правда, если рассматривать не надежность хранения (она одинаковая), а время простоя.
GK
Речь про доступность, да.
AC
редис был для буфера, пайплайнов отправки было несколько
приложение - редис - логстеш - эластик
рсислог(локальный) - рсислог для буфера - логстэш - эластик
Сейчас fluentbit отовсюду (монолит, soa, openshift) пишет в кафку, оттуда логи забирают разные fluentd (есть отдельный для ИБ, отдельный для аналитиков и тд) и отправляют по разным местам.
приложение - редис - логстеш - эластик
рсислог(локальный) - рсислог для буфера - логстэш - эластик
Сейчас fluentbit отовсюду (монолит, soa, openshift) пишет в кафку, оттуда логи забирают разные fluentd (есть отдельный для ИБ, отдельный для аналитиков и тд) и отправляют по разным местам.
НИ
Если я тебя верно понял - все приложения твоей компании поставляют логи через 1 кластер кафки.
Отсюда мой вопрос - Что будет если кафка упадет?
Отсюда мой вопрос - Что будет если кафка упадет?
GK
И случае недоступности бэкенда (куда логи должны попасть) мы сравниваем надёжность локального буфера и реплицированного буфера (Кафку).
PD
А зачем кафка (сейчас), а не простой http?
Понятно, что текущий вариант через флюент - много лучше.
Понятно, что текущий вариант через флюент - много лучше.
GM
хттп было модно 15 лет назад
PD
Не, у тебя перед попаданием в кафку - все равно все летит через локальный буфер. Там нет сравнения (