Да нифига непонятно. Я даже прочитав текст не понял, о чём речь. Впрочем, не важно. Важно то. что на первом я более-менее могу проследить каждую линию, а на втором красная в правой части вообще перестаёт быть видна. Это очень не наглядно.
Понятия не имею, что такое репликас, но я из этой картинки совершенно не могу понять: 80 - это слишком мало или слишком много?
раз красным, значит — значит важно обратить внимание, в данном случае прийдет алерт.
Кстати, 16 из 18 это 89%, а не 80. Так что данная картинка не столько отвечает на вопросы, сколько задаёт новые.
Поправил скриншот и подпись, действительно было неправильно.
Зато текст и заголовков и легенд непонятный.
Average CPU Usage — что тут непонятно?
И ещё я бы не стал смешивать разные единицы измерений.
Но тут же две отдельные панели, они просто оказались рядом, специального смысла тут нет.
Да нифига непонятно. Я даже прочитав текст не понял, о чём речь. Впрочем, не важно. Важно то. что на первом я более-менее могу проследить каждую линию, а на втором красная в правой части вообще перестаёт быть видна. Это очень не наглядно.
Вы же понимаете, что такое стекирование?
Вообще не видно. Если бы не это примечание, то я бы сроду не догадался, что каждая строка - это отдельная метрика.
В скриншот не вошли названия метрик (подписи справа) — попросили убрать для соблюдения NDA.
П.С. Я понимаю, примеры могли быть сделаны для демонстрации только одного аспекта, но странно выглядит статья, где автор что-то рекомендует, а потом в следующей же картинке игнорирует все свои рекомендации.
А вот напихать всех метрик для разной ЦА на один дашборд — не самая лучшая идея. Дашборд постепенно станет очень тяжелым, и как показывает практика — такое соседство рано или поздно станет неудобно всем (для удовлетворения нескольких ЦА одних переменных-выпадашек сколько будет!). В такие моменты лучше распилить дашборд на несколько.
Суммарный объем данных на дисках с учетом реплик: ~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 дней часто не достаточно. Также на логах решаются аналитические задачи, которые также требуют хранить логи дольше.
В нашем случае логи льют сами пользователи, и группы под эти логи тоже создают сами пользователи, как показывает практика — редко кто из пользователей о таком задумывается. Но идея полезная, запишем в список на проработку, спасибо!
Поменял график с легендой на более подходящий для примера.
На самом деле, действительно местами может быть что-то неочевидно по скриншотам. Да и объяснять особенности визуализации по скриншотам — сложно.
Появилась идея сделать какой-нить дашборд для примера, с живыми панелями с метриками. Как-нибудь попробую сделать что-то такое.
Спасибо за ваши замечания!
Вот так наглядно?
раз красным, значит — значит важно обратить внимание, в данном случае прийдет алерт.
Поправил скриншот и подпись, действительно было неправильно.
Average CPU Usage — что тут непонятно?
Но тут же две отдельные панели, они просто оказались рядом, специального смысла тут нет.
Вы же понимаете, что такое стекирование?
В скриншот не вошли названия метрик (подписи справа) — попросили убрать для соблюдения NDA.
Где именно я это делаю?
Про row добавлю, действительно важная штука.
А вот напихать всех метрик для разной ЦА на один дашборд — не самая лучшая идея. Дашборд постепенно станет очень тяжелым, и как показывает практика — такое соседство рано или поздно станет неудобно всем (для удовлетворения нескольких ЦА одних переменных-выпадашек сколько будет!). В такие моменты лучше распилить дашборд на несколько.
а как правильно, "приборная доска"?
Хорошая статья! В начале есть опечатка "DHCPDISOCVER", нужно заменить на "DHCPDISCOVER".
Спасибо! Приятно слышать, что доклад и статья оказались полезны.
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 — централизованно нет, но в компании есть трейсинг.
Метрики на основе логов — есть такая идея, сделать как сервис простую конвертилку, но еще не успели реализовать.