Суммарный объем данных на дисках с учетом реплик: ~7.43 PiB.
У каждого кластера обязательно должен быть мастер, иначе это не кластер, а набор независимых нод (на самом деле нод, которые имеют роль мастера, должно быть минимум 3, для кворума, из которого активный мастер всегда 1). В связи с высокой нагрузкой на data-ноды, мы выносим роль мастера на отдельные (небольшие) ноды.
Система нормально себя чувствует, держит нагрузки.
Elastic Proxy Cluster — это не самописное, а просто отдельностоящий кластер Эластика, настроенны на Cross Cluster Search (средствами самого Эластика можно настроить такой кластер, чтобы он искал во всех кластерах с данными, при этом в самом proxy cluster данных нет, он только проксирует поиски и объединяет данные из результатов поисков).
Про мониторинг я не словом. SLA нет, мы (как команда) не представляем платный сервис клиентам. За год, пока я с этой командой uptime 100%, остановка критических сервисов команды - это остановка основного бизнеса компании
Ну раз SLA нет, и требования грепать за последние 15 мин., то наверно так еще норм. У нас были другие требования.
Интересно как выглядит grep с получением статистики в виде графика во времени.
Сколько инженеров суммарно в командах, которые так ищут по логам?
Все логи в кучу файликов складываете, или есть какая-то систематизация, разграничение доступа, или прям всем доступны все логи, и еще извне?
Как проверяете, что фичи выкатились на прод ожидаемо (например, разработчики включили фича-флаг или просто фичу выкатили новую сложную, и следят за подробностями работы приложения)?
Есть ли процесс проверки логов на наличие нежелательных данных (sensitive data, перс. данные и тд)?
не очень часто, может пару раз в день для одной группы, при этом Кафка часто партиции назначает на того же консьюмера и процесс занимает секунды для каждой группы отдельно
Один кластер Kafka в каждом ДЦ на всех пользователей. У каждого клиента есть как минимум одна из основных сущностей Sage — группа (group), бывает что у клиента есть несколько таких групп. Каждая группа логов пишется в отдельный топик.
Входной поток на Кафке: в пике 500 МБ (ДЦ1) + 400 МБ (ДЦ2) — сообщения могут приходить как в сжатом, так и в несжатом виде. При вычитке и обработке на переливалке после расжатия получается уже суммарно примерно те самые 3,5 ГБ/с в пике. В каждом кластере Kafka по 5 брокеров.
Обычно на топик создается 10 партиций, есть большие группы где поднимали до 20 партиций. Consumer group переливалки — один на кластер.
Семантика exactly-once не обеспечивается. Но для каждого записанного лога проставляется (кроме исходного времени внутри самого события) временная метка, когда сообщение было взято в обработку + id лога — можно понять, что событие повторно записано. Еще есть ряд проверок при записи события для минимизации ошибок на стороне клиента, например проверяется что событие не очень далеко из прошлого (на случай сбоя и попытки переотправки очень старых логов заново).
mq — имеется ввиду RabbitMQ? Не рассматривали, кажется что Кафка нас пока устраивает. Изначально когда выбирали Кафку, понравилось что есть очень много готовых клиентов для отправки, да и поддержка в библиотеках тоже есть во всех мейнстримовых языках. Схемы данных мы пока еще не вводили, но мысли такие есть (как минимум для больших клиентов, чтобы было меньше неожиданностей на стороне Elastic, и даже оптимизации можно будет сделать под схему).
Еще есть логи, на которых решаются задачи SOC — тут 14 дней часто не достаточно. Также на логах решаются аналитические задачи, которые также требуют хранить логи дольше.
В нашем случае логи льют сами пользователи, и группы под эти логи тоже создают сами пользователи, как показывает практика — редко кто из пользователей о таком задумывается. Но идея полезная, запишем в список на проработку, спасибо!
Five years ago Manticore began as a fork of an open source version of the once popular search engine Sphinx Search. We had two bags of grass, seventy-five pellets of mescaline, three C++ developers, a support engineer, a power user of Sphinx Search / backend team lead, an experienced manager, a mother of five helping us part-time, and a ton of bugs, crashes, and technical debts. So we got a shovel and other digging tools and started working to get it up to the search engine industry standards. Not that Sphinx was impossible to use, but many things were missing, and existing features weren’t quite stable or mature. And we had pushed it about as far as we could. So after 5 years and hundreds of new users, we’re ready to say that Manticore Search can be used as an alternative to Elasticsearch for both full-text search and (now) data analytics too.
Среди требований была поддержка полнотекстового поиска (Loki работает на основе лейблов), да и в 2019 году Loki только появился, а хотелось чего-то проверенного.
Prometheus — изначально метрики были в нем, но у него один из главных недостатков — он не умеет масштабироваться горизонтально, да и хранить в нем метрики долгосрочно (и доставать их поисковыми запросами) не так оптимально, как в VictoriaMetrics, которая к тому же менее требовательна к дисковой подсистеме.
GDRP и прочие регуляторные штуки — в логах не должно быть sensitive data и перс. данных, такие логи запрещается писать и они удаляются сразу, к отправителям логов быстро придут безопасники и отбезопасят.
Как сопровождавший такую систему с логами — соглашусь, что лучше не писать логи. Но без логов не решить многие проблемы в тех случаях, когда нужно большое cardinality, да и проблемы на проде надо как-то диагностировать. Мы стараемся не строить реалтайм-мониторинг на логах (вместо этого пишем метрики), но не во всех случаях это поможет.
У команд может быть несколько систем на сопровождении, и часто полезно смотреть логи из нескольких взаимосвязанных систем вместе.
В таких эпизодических случаях данные удаляются, как правило, прямо индексами. За счет того, что данные льются в индексы в разрезе группы/энва/системы, и нарезаются по времени в зависимости от потока, то удалить данные не сложно. В особых случаях можно и отдельные записи удалить.
Спасибо! Приятно слышать, что доклад и статья оказались полезны.
24 кластера с данными насчитал.
Суммарный объем данных на дисках с учетом реплик: ~7.43 PiB.
У каждого кластера обязательно должен быть мастер, иначе это не кластер, а набор независимых нод (на самом деле нод, которые имеют роль мастера, должно быть минимум 3, для кворума, из которого активный мастер всегда 1). В связи с высокой нагрузкой на data-ноды, мы выносим роль мастера на отдельные (небольшие) ноды.
Впрочем, это всё уже было описано в статье.
Система нормально себя чувствует, держит нагрузки.
Elastic Proxy Cluster — это не самописное, а просто отдельностоящий кластер Эластика, настроенны на Cross Cluster Search (средствами самого Эластика можно настроить такой кластер, чтобы он искал во всех кластерах с данными, при этом в самом proxy cluster данных нет, он только проксирует поиски и объединяет данные из результатов поисков).
На самом деле я бы почитал статью с подробностями и скриншотами
Ну раз SLA нет, и требования грепать за последние 15 мин., то наверно так еще норм. У нас были другие требования.
Интересно как выглядит grep с получением статистики в виде графика во времени.
Про то, что если ресурсы не считать и не привязывать к владельцам — рано или поздно ресурсы закончатся, даже спорить не буду, полностью согласен.
Интересны подробности:
В какой компании так делают, если не секрет?
Какой SLA у сервисов с таким мониторингом?
Сколько сервисов так логирует?
Сколько инженеров суммарно в командах, которые так ищут по логам?
Все логи в кучу файликов складываете, или есть какая-то систематизация, разграничение доступа, или прям всем доступны все логи, и еще извне?
Как проверяете, что фичи выкатились на прод ожидаемо (например, разработчики включили фича-флаг или просто фичу выкатили новую сложную, и следят за подробностями работы приложения)?
Есть ли процесс проверки логов на наличие нежелательных данных (sensitive data, перс. данные и тд)?
Нет ни одного алерта/дашборда по логам?
не очень часто, может пару раз в день для одной группы, при этом Кафка часто партиции назначает на того же консьюмера и процесс занимает секунды для каждой группы отдельно
Спасибо за замечания. Исправил англицизмы, но возможно не все. Проф. деформация дает о себе знать :(
Один кластер Kafka в каждом ДЦ на всех пользователей. У каждого клиента есть как минимум одна из основных сущностей Sage — группа (group), бывает что у клиента есть несколько таких групп. Каждая группа логов пишется в отдельный топик.
Входной поток на Кафке: в пике 500 МБ (ДЦ1) + 400 МБ (ДЦ2) — сообщения могут приходить как в сжатом, так и в несжатом виде. При вычитке и обработке на переливалке после расжатия получается уже суммарно примерно те самые 3,5 ГБ/с в пике.
В каждом кластере Kafka по 5 брокеров.
Обычно на топик создается 10 партиций, есть большие группы где поднимали до 20 партиций. Consumer group переливалки — один на кластер.
Семантика exactly-once не обеспечивается. Но для каждого записанного лога проставляется (кроме исходного времени внутри самого события) временная метка, когда сообщение было взято в обработку + id лога — можно понять, что событие повторно записано. Еще есть ряд проверок при записи события для минимизации ошибок на стороне клиента, например проверяется что событие не очень далеко из прошлого (на случай сбоя и попытки переотправки очень старых логов заново).
mq — имеется ввиду RabbitMQ? Не рассматривали, кажется что Кафка нас пока устраивает. Изначально когда выбирали Кафку, понравилось что есть очень много готовых клиентов для отправки, да и поддержка в библиотеках тоже есть во всех мейнстримовых языках. Схемы данных мы пока еще не вводили, но мысли такие есть (как минимум для больших клиентов, чтобы было меньше неожиданностей на стороне Elastic, и даже оптимизации можно будет сделать под схему).
Еще есть логи, на которых решаются задачи SOC — тут 14 дней часто не достаточно. Также на логах решаются аналитические задачи, которые также требуют хранить логи дольше.
В нашем случае логи льют сами пользователи, и группы под эти логи тоже создают сами пользователи, как показывает практика — редко кто из пользователей о таком задумывается. Но идея полезная, запишем в список на проработку, спасибо!
Храним логи по умолчанию 14 дней, для некоторых клиентов — дольше.
Почему так много логов — вопрос риторический, всем всегда хочется иметь как можно больше логов для разработки/тестирования/мониторинга.
APM — централизованно нет, но в компании есть трейсинг.
Метрики на основе логов — есть такая идея, сделать как сервис простую конвертилку, но еще не успели реализовать.
Какое бы решение вы выбрали в 2019 году с учетом требований из статьи?
Five years ago Manticore began as a fork of an open source version of the once popular search engine Sphinx Search. We had
two bags of grass, seventy-five pellets of mescaline, three C++ developers, a support engineer, a power user of Sphinx Search / backend team lead, an experienced manager, a mother of five helping us part-time, and a ton of bugs, crashes, and technical debts. So we got a shovel and other digging tools and started working to get it up to the search engine industry standards. Not that Sphinx was impossible to use, but many things were missing, and existing features weren’t quite stable or mature. And we had pushed it about as far as we could. So after 5 years and hundreds of new users, we’re ready to say that Manticore Search can be used as an alternative to Elasticsearch for both full-text search and (now) data analytics too.Звучит интересно, спасибо!
Среди требований была поддержка полнотекстового поиска (Loki работает на основе лейблов), да и в 2019 году Loki только появился, а хотелось чего-то проверенного.
Prometheus — изначально метрики были в нем, но у него один из главных недостатков — он не умеет масштабироваться горизонтально, да и хранить в нем метрики долгосрочно (и доставать их поисковыми запросами) не так оптимально, как в VictoriaMetrics, которая к тому же менее требовательна к дисковой подсистеме.
Я могу ошибаться, и это неактуальная инфа, но Clickhouse вроде не умеет в настоящий полнотекст: https://prohoster.info/blog/administrirovanie/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah#fulltext-search
GDRP и прочие регуляторные штуки — в логах не должно быть sensitive data и перс. данных, такие логи запрещается писать и они удаляются сразу, к отправителям логов быстро придут безопасники и отбезопасят.
Как сопровождавший такую систему с логами — соглашусь, что лучше не писать логи. Но без логов не решить многие проблемы в тех случаях, когда нужно большое cardinality, да и проблемы на проде надо как-то диагностировать. Мы стараемся не строить реалтайм-мониторинг на логах (вместо этого пишем метрики), но не во всех случаях это поможет.
У команд может быть несколько систем на сопровождении, и часто полезно смотреть логи из нескольких взаимосвязанных систем вместе.
В таких эпизодических случаях данные удаляются, как правило, прямо индексами. За счет того, что данные льются в индексы в разрезе группы/энва/системы, и нарезаются по времени в зависимости от потока, то удалить данные не сложно. В особых случаях можно и отдельные записи удалить.