Комментарии 13
Добрый !
Спасибо за статью!
Единственное, что я хотел бы уточнить:
средний объем данных[1] в топиках – 555.1 ГБ
[1] значение за последние 90 дней
это что? Т.е. мы посчитали каждое мгновенное значение количества данных в каждом топике с неким разрешением в интервале 90 дней, а потом взяли и усреднили по всем измерениям и по всем топикам? Или это общий объем данных с ретеншеном 90 дней? Или общее количество "прокачанных" за 90 дней данных, среднее по топикам? Не совсем понимаю.
p.s. и еще вопрос — какой минимальный, средний и максимальный лаги по доставке логов от источника до эластика? Потому что есть гипотеза, что в определенных конфигурациях такой лаг может достигать 30 минут, что ставит полный крест на использовании эластика как средства оперативного мониторинга (но при этом это ок для расследования исторических инцидентов)
средний объем данных[1] в топиках – 555.1 ГБ
[1] значение за последние 90 дней
это что? Т.е. мы посчитали каждое мгновенное значение количества данных в каждом топике с неким разрешением в интервале 90 дней, а потом взяли и усреднили по всем измерениям и по всем топикам? Или это общий объем данных с ретеншеном 90 дней? Или общее количество «прокачанных» за 90 дней данных, среднее по топикам? Не совсем понимаю.
Это средние значения объема данных в каждом топике за промежуток времени (в данном случае за 90 дней), которые мы просуммировали
p.s. и еще вопрос — какой минимальный, средний и максимальный лаги по доставке логов от источника до эластика? Потому что есть гипотеза, что в определенных конфигурациях такой лаг может достигать 30 минут, что ставит полный крест на использовании эластика как средства оперативного мониторинга (но при этом это ок для расследования исторических инцидентов)
Спасибо за хорошую идею! Временные значения лагов мы не замеряем, пока не было необходимости в этих цифрах, но теперь, думаю, начнем. Пока же нам хватает данных по лагу в количестве сообщений.
В целом картина такая, что топик лаг возникает только в случае, когда проблема возникает на принимающей стороне, например, упал logstash. В остальном – топик лаг у нас либо нулевой, либо не превышает несколько тысяч сообщений, которые разгребаются быстро и задержка не становится критичной. Опять же, как только мы понимаем, что нагрузка растёт и очередь не успевает разгребаться, а только растёт, мы увеличиваем количество партиций и накидываем потоки на чтение. Особых жалоб на то, что данные поступают с большой задержкой мы не получаем.
В конце 2020 года была проблема с нестабильной работой кластера Elasticsearch, тогда системы, которые генерировали большое количество сообщений получили очень большой топик лаг и почти сутки разгребали очереди.
Это было неприятно, но подсветило нам проблемные места, которые мы успешно поправили.
Спасибо за интересную статью! Тема очень интересная, изучаю смежные области.
Подскажите, почему было недостаточно beats агентов на конечных серверах и вы добавили ещё один слой в виде Kafka? Агенты же тоже шлют данные по TCP и перешлют их, если не смогут достучатся до логстэша?
Подскажите, почему было недостаточно beats агентов на конечных серверах и вы добавили ещё один слой в виде Kafka? Агенты же тоже шлют данные по TCP и перешлют их, если не смогут достучатся до логстэша?
Добрый день! Спасибо за хорошее замечание.
Мы хотели, помимо пересылки, ещё и хранить данные некоторое время, в случае, если что-то пойдёт не так. Например, был кейс, когда нам нужно было удалить некоторые индексы из Elasticsearch, когда у нас сломалась ротация, чтобы стабилизировать работу кластера.
Мы сделали это не моргнув глазом, потому что знали, что данные мы сможем просто перечитать из топика Kafka, сбросив значение offset. Да, мы получили данные, которые было не очень удобно анализировать с точки зрения timestamp самого Elasticsearch, но тем не менее, это оставляло возможность использовать их для поисков исторических данных.
В данный момент наш сервис поставки логов переживает большой рефакторинг, возможно, что от текущей схемы мы перейдём к чему-то более удобному и простому. Может быть, мы расскажем об этом в будущих статьях
Добрый день. Я правильно понял, что вы рекомендуете выставлять replication factor равным количеству нод минус 1? Чтобы переживать выпадание одной тачки? Т.е. сейчас у вас в кластере 5 машин и rf=4?
Что касается рекомендации про количество нод — 1 – это относится к min insync replicas. Это значение мы используем для трёхнодовых кластеров, которые мы предоставляем командам.
Как можно видеть в статье, мы используем значение kafka_cfg_min_insync_replicas: "{{ kafka_cfg_min_insync_replicas | default([kafka_cfg_default_replication_factor|int — 1, 1] | max) }}".
Это значит, что количество минимально синхронизированных реплик будет равно replication factor — 1 (в нашем случае, как раз количество нод — 1), но не менее 1.
Этот параметр отвечает за то, сколько минимально нам нужно нод для того, чтобы обрабатывать запросы, которые для которых установлено значение acks=all.
странное дело. Я смотрел рекомендации от IBM Hyperledger и они то точно знают толк в Кафке!
https://hyperledger-fabric.readthedocs.io/en/release-2.2/kafka.html
Вот. Очень четко написано что и к чему.
K — это количество брокеров (общее)
N — это количество реплик
и указывается строгое неравенство N < K, что меня сбило с толку.
Далее там еще идут конфигурации с аргументацией, но общая суть, что min insync M: 1 < M < N (т.е. наибольшее для ин-синк реплик — K - 2)
Как упомянуто в статье, если команда понимает, что для их нужд лучше подходят другие значения, то мы готовы настроить их иначе, в том числе и значение min ISR.
Для справедливости стоит отметить, что IBM Hyperledger также рекомендуют использовать минимум 4 брокера Kafka, именно из этого расчёта они исходят:
Let K and Z be the number of nodes in the Kafka cluster and the ZooKeeper ensemble respectively:
1. At a minimum, K should be set to 4.
Ну это общие требования по записью в кластер с консенсусом по записи. То есть у вас должно не меньше половины+1 брокеров подтвердить доставку, тогда вы будете уверены, что при отвале части брокеров (1 при кластере из 3, 2 при кластере из 5 и т.п.) у вас сообщения не пропадуют.
При этом если требовать подтверждения ото всех брокеров, то увеличится время отправки, но зато меньше возни, если лидер отвалится. Мы тоже не паримся и пишем во все.
Супер, спасибо за статью!
Очень интересная тема с авторизациями консумеров и продьюсеров. Я правильно понимаю схему, что сначала нужно сходить в KSM и спосить "могу ли я (серт/кред) писать/читать такой-то топик), и уже потом писать в кафку? Или это непосредственно кафка делает?
Вопрос под таким углом: могу ли я явно запретить кому-то писать в кафку, если он знает адреса брокеров через KSM? Или если я хочу именно явного запрета (то есть чтобы несанкционированный трафик вообще не мог в топик попасть), то придется проксировать?
Хотим реализовать что-то подобное, но при этом давать сервисам, которым не очень доверяем, возможность писать в кафку, если у них есть валидная авторизация, но при этом чтобы возможности вообще не было, если авторизация невалидна (роли там нет etc.).
могу ли я (серт/кред) писать/читать такой-то топик), и уже потом писать в кафку? Или это непосредственно кафка делает?
Ответ: Kafka забирает данные из KSM и применяет на себе. Консьюмеры и продьюсеры ходят непосредственно в Kafka.
могу ли я явно запретить кому-то писать в кафку, если он знает адреса брокеров через KSM?
Ответ: Для этого как раз используется KSM. Вы включаете авторизацию, например SSL, создаете пользователя и генерируете для него JKS сертификаты, с помощью которых он может авторизоваться в Kafka. Если пользователь не добавлен в ACL или у него нет валидных сертификатов, то он не сможет получить доступ.
Насколько надежным оказался Logstash, часто падает? у нас в проекте в основном используется flink, но мы данные сохраняем в hdfs.
По поводу надёжности у нас к Logstash особо нет претензий. Поскольку у каждой команды, которая подключается к системе свой Logstash (и часто не один), то, конечно, падения иногда случаются, но на моей памяти за последнее время падали 2 или 3 экземпляра из почти трёх десятков. Основная проблема Logstash, которая нас смущает — ресурсы, которые он требует для нормальной работы.
Одна Kafka хорошо, а несколько — лучше