Подскажите, почему было недостаточно beats агентов на конечных серверах и вы добавили ещё один слой в виде Kafka? Агенты же тоже шлют данные по TCP и перешлют их, если не смогут достучатся до логстэша?
Добрый день! Спасибо за хорошее замечание.
Мы хотели, помимо пересылки, ещё и хранить данные некоторое время, в случае, если что-то пойдёт не так. Например, был кейс, когда нам нужно было удалить некоторые индексы из Elasticsearch, когда у нас сломалась ротация, чтобы стабилизировать работу кластера.
Мы сделали это не моргнув глазом, потому что знали, что данные мы сможем просто перечитать из топика Kafka, сбросив значение offset. Да, мы получили данные, которые было не очень удобно анализировать с точки зрения timestamp самого Elasticsearch, но тем не менее, это оставляло возможность использовать их для поисков исторических данных.
В данный момент наш сервис поставки логов переживает большой рефакторинг, возможно, что от текущей схемы мы перейдём к чему-то более удобному и простому. Может быть, мы расскажем об этом в будущих статьях
средний объем данных[1] в топиках – 555.1 ГБ
[1] значение за последние 90 дней
это что? Т.е. мы посчитали каждое мгновенное значение количества данных в каждом топике с неким разрешением в интервале 90 дней, а потом взяли и усреднили по всем измерениям и по всем топикам? Или это общий объем данных с ретеншеном 90 дней? Или общее количество «прокачанных» за 90 дней данных, среднее по топикам? Не совсем понимаю.
Это средние значения объема данных в каждом топике за промежуток времени (в данном случае за 90 дней), которые мы просуммировали
p.s. и еще вопрос — какой минимальный, средний и максимальный лаги по доставке логов от источника до эластика? Потому что есть гипотеза, что в определенных конфигурациях такой лаг может достигать 30 минут, что ставит полный крест на использовании эластика как средства оперативного мониторинга (но при этом это ок для расследования исторических инцидентов)
Спасибо за хорошую идею! Временные значения лагов мы не замеряем, пока не было необходимости в этих цифрах, но теперь, думаю, начнем. Пока же нам хватает данных по лагу в количестве сообщений.
В целом картина такая, что топик лаг возникает только в случае, когда проблема возникает на принимающей стороне, например, упал logstash. В остальном – топик лаг у нас либо нулевой, либо не превышает несколько тысяч сообщений, которые разгребаются быстро и задержка не становится критичной. Опять же, как только мы понимаем, что нагрузка растёт и очередь не успевает разгребаться, а только растёт, мы увеличиваем количество партиций и накидываем потоки на чтение. Особых жалоб на то, что данные поступают с большой задержкой мы не получаем.
В конце 2020 года была проблема с нестабильной работой кластера Elasticsearch, тогда системы, которые генерировали большое количество сообщений получили очень большой топик лаг и почти сутки разгребали очереди.
Это было неприятно, но подсветило нам проблемные места, которые мы успешно поправили.
Эти вопросы не относятся напрямую к теме статьи, поэтому не раскрывались. Автотесты встроены в пайплайн и в зависимости от тестового набора запускаются либо автоматически по принятию MR, либо вручную. У всей команды есть доступ к подробной отчетности в AllureEE, уровни детализации отчетов позволяют понять, что именно поломалось.
Хорошее замечание, пока у нас нет возможности маппить тесты с затрагиваемой функциональностью (есть маппинг по экранам, но нет по компонентам), но в перспективе мы планируем с этим вопросом разобраться.
Мы придерживаемся мнения, что unit-тесты – зона ответственности разработчиков. Snapshot-тесты полезны, хотя их поддержка не менее трудоемка, чем поддержка других тестов. Перевернуть мороженку в правильную пирамиду – как раз то, что нам нужно в перспективе, но для начала нужно подружить теорию с реальностью.
Конечно, мы запускаем тесты параллельно, количество потоков подбирается с учетом минимизации времени на запуск (увеличение количества потоков не всегда дает экономию на запуске).
Конечно, мы учитываем поддержку – тонуть под поддержкой автотестов не лучше, чем тонуть под ручным регрессом. В остальном вы спешите с выводами. Возможно, в одной из следующих статей мы рассмотрим именно ROI.
При принятии решения об автоматизации UI мы руководствовались спецификой продуктов и анализом дефектов по продукту. Пользы от автоматизации API никто не умаляет, однако гарантировать работоспособность продуктов API-тесты могут только в комплексе с unit-тестами на фронт. Практика автоматизации фронта со стороны разработки на наших продуктах в процессе внедрения. Поэтому с целью максимизации полезности автотестов было принято решение часть регресса и e2e автоматизировать на UI. По поводу ножа – у нас не настолько большая команда автоматизаторов, чтобы так легкомысленно пускать сотрудников в расход)
Расчетная окупаемость первых тестов – 40-45-й запуск, для нас это 2-3 месяца в зависимости от количества поставок. Но нужно учитывать, что в старт автоматизации вошла и трудоемкая часть – разработка фреймворка.
Все верно, исторические колебания есть. Но есть и гипотеза, что как раз усреднение оценок коллег позволяет немного убрать этот шум. Один пришел не в духе, зато другой — как раз в хорошем настроении. И так далее. Сюда же оценка от руководителя — предполагается, что он подходит ответственно, и убирает свой bias. То есть аргументы За имеются тоже. Опять же, с авторами оценок нужно работать, но это уже хорошо описано в процитированном тексте от коллег.
Тут ведь дело даже не в менеджерской лени, а в наличии инструмента, который может как-то помочь даже трудолюбивому менеджеру, который чего-то просто забыл или не учел.
В целом мы согласны, что любая работа с людьми — дело тонкое, инструменты ненадежны, и несколько раз в тексте на это указали, тут спорить действительно не о чем.
Действительно, сегодня у представителей ритейл свои требования, процессы и регламенты. Они были сформированы годами и менять их сложно, т. к. значимость изменений процессов мастер-данных не всегда очевидна в конкуренции с другими инновациями.
X5 делает этот шаг, понимая что во многом является первопроходцем.
В вопросе обеспечения соответствия кодов ТН ВЭД, ставок НДС и прочего важно соблюдать баланс. В противном случае есть риск просто перевести бюрократию в цифровое измерение и сделать требования невыполнимыми.
Использование портала дает поставщику дополнительные возможности. Поставщик может самостоятельно загрузить мастер данные своего товара как путем ручного заполнения формы, так и через загрузку Excel файла заданного формата. Услуги КСП провайдера являются дополнительной опцией, а не обязанностью. Каждый поставщик самостоятельно принимает решение, каким путем пойти.
В дальнейшем функционал портала будет развиваться. Но об этом позднее.
Это решение для внутреннего пользования.
Конечно, здесь речь не идет о поддержке абсолютно любого железа. Скорее о 4-5 вендорах, не более 10 моделей на каждого вендора.
Согласен, если говорить о поддержке гораздо более широкого перечня моделей и более широкого набора конечных образов систем, скорее всего, нужно будет смотреть в другую сторону.
Но данное решение хорошо вписывается в текущие потребности.
Добрый день! Спасибо за хорошее замечание.
Мы хотели, помимо пересылки, ещё и хранить данные некоторое время, в случае, если что-то пойдёт не так. Например, был кейс, когда нам нужно было удалить некоторые индексы из Elasticsearch, когда у нас сломалась ротация, чтобы стабилизировать работу кластера.
Мы сделали это не моргнув глазом, потому что знали, что данные мы сможем просто перечитать из топика Kafka, сбросив значение offset. Да, мы получили данные, которые было не очень удобно анализировать с точки зрения timestamp самого Elasticsearch, но тем не менее, это оставляло возможность использовать их для поисков исторических данных.
В данный момент наш сервис поставки логов переживает большой рефакторинг, возможно, что от текущей схемы мы перейдём к чему-то более удобному и простому. Может быть, мы расскажем об этом в будущих статьях
Это средние значения объема данных в каждом топике за промежуток времени (в данном случае за 90 дней), которые мы просуммировали
Спасибо за хорошую идею! Временные значения лагов мы не замеряем, пока не было необходимости в этих цифрах, но теперь, думаю, начнем. Пока же нам хватает данных по лагу в количестве сообщений.
В целом картина такая, что топик лаг возникает только в случае, когда проблема возникает на принимающей стороне, например, упал logstash. В остальном – топик лаг у нас либо нулевой, либо не превышает несколько тысяч сообщений, которые разгребаются быстро и задержка не становится критичной. Опять же, как только мы понимаем, что нагрузка растёт и очередь не успевает разгребаться, а только растёт, мы увеличиваем количество партиций и накидываем потоки на чтение. Особых жалоб на то, что данные поступают с большой задержкой мы не получаем.
В конце 2020 года была проблема с нестабильной работой кластера Elasticsearch, тогда системы, которые генерировали большое количество сообщений получили очень большой топик лаг и почти сутки разгребали очереди.
Это было неприятно, но подсветило нам проблемные места, которые мы успешно поправили.
Хорошее замечание, пока у нас нет возможности маппить тесты с затрагиваемой функциональностью (есть маппинг по экранам, но нет по компонентам), но в перспективе мы планируем с этим вопросом разобраться.
Мы придерживаемся мнения, что unit-тесты – зона ответственности разработчиков. Snapshot-тесты полезны, хотя их поддержка не менее трудоемка, чем поддержка других тестов. Перевернуть мороженку в правильную пирамиду – как раз то, что нам нужно в перспективе, но для начала нужно подружить теорию с реальностью.
Конечно, мы запускаем тесты параллельно, количество потоков подбирается с учетом минимизации времени на запуск (увеличение количества потоков не всегда дает экономию на запуске).
Тут ведь дело даже не в менеджерской лени, а в наличии инструмента, который может как-то помочь даже трудолюбивому менеджеру, который чего-то просто забыл или не учел.
В целом мы согласны, что любая работа с людьми — дело тонкое, инструменты ненадежны, и несколько раз в тексте на это указали, тут спорить действительно не о чем.
X5 делает этот шаг, понимая что во многом является первопроходцем.
В вопросе обеспечения соответствия кодов ТН ВЭД, ставок НДС и прочего важно соблюдать баланс. В противном случае есть риск просто перевести бюрократию в цифровое измерение и сделать требования невыполнимыми.
Использование портала дает поставщику дополнительные возможности. Поставщик может самостоятельно загрузить мастер данные своего товара как путем ручного заполнения формы, так и через загрузку Excel файла заданного формата. Услуги КСП провайдера являются дополнительной опцией, а не обязанностью. Каждый поставщик самостоятельно принимает решение, каким путем пойти.
В дальнейшем функционал портала будет развиваться. Но об этом позднее.
Конечно, здесь речь не идет о поддержке абсолютно любого железа. Скорее о 4-5 вендорах, не более 10 моделей на каждого вендора.
Согласен, если говорить о поддержке гораздо более широкого перечня моделей и более широкого набора конечных образов систем, скорее всего, нужно будет смотреть в другую сторону.
Но данное решение хорошо вписывается в текущие потребности.