Comments 39
А вот мне интересно, если же в лог залетит какой нибудь важный секрет, проскочив мимо валидации, то как его потом вычищать из базы, ведь удалять данные из логов, скорее всего, супер дорогая операция?
Ну или кто нибудь придет по gdpr, и попросит все свои данные из логов убрать, то как тогда жить?
В таких эпизодических случаях данные удаляются, как правило, прямо индексами. За счет того, что данные льются в индексы в разрезе группы/энва/системы, и нарезаются по времени в зависимости от потока, то удалить данные не сложно. В особых случаях можно и отдельные записи удалить.
GDRP и прочие регуляторные штуки — в логах не должно быть sensitive data и перс. данных, такие логи запрещается писать и они удаляются сразу, к отправителям логов быстро придут безопасники и отбезопасят.
Я загадал - почта? Не не угадал.
Хвастатьс тем, что развёл Авгиевы конюшни на рабочем месте - это для админа моветон. Надо прочитать кто тут СРЕ.
Самая лучшая оптимизация логов их не писать. Поймали ошибку - отправили в какой-нибудь sentry или аналог. Нужны метрики - пишите сразу метрики (prometeus, datadog, etc.) Нужен аудит? Это явно не elastic в котором можно потерять данные. Мне интересно, почему всегда круто решать проблему с неправильной сторны. Перепишем пол эластика, но не будем смотреть в сами логи и анализировать что из них нужно, а что нет.
Как сопровождавший такую систему с логами — соглашусь, что лучше не писать логи. Но без логов не решить многие проблемы в тех случаях, когда нужно большое cardinality, да и проблемы на проде надо как-то диагностировать. Мы стараемся не строить реалтайм-мониторинг на логах (вместо этого пишем метрики), но не во всех случаях это поможет.
У команд может быть несколько систем на сопровождении, и часто полезно смотреть логи из нескольких взаимосвязанных систем вместе.
У кого-то есть опыт перноса данных из эластика в кликхаус? По экономии места предполагаю, что будет в 10-100 раз эффект, а вот насколько изменится обозреваемость? Насколько сложнее будут запросы?
Я могу ошибаться, и это неактуальная инфа, но Clickhouse вроде не умеет в настоящий полнотекст: https://prohoster.info/blog/administrirovanie/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah#fulltext-search
зато manticoresearch умеет, да еще и с колоночным хранением
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+Prometheus не угодил?
Среди требований была поддержка полнотекстового поиска (Loki работает на основе лейблов), да и в 2019 году Loki только появился, а хотелось чего-то проверенного.
Prometheus — изначально метрики были в нем, но у него один из главных недостатков — он не умеет масштабироваться горизонтально, да и хранить в нем метрики долгосрочно (и доставать их поисковыми запросами) не так оптимально, как в VictoriaMetrics, которая к тому же менее требовательна к дисковой подсистеме.
Есть прекрасная картинка, как из буханки хлеба сделать троллейбус, но зачем? По заголовку сразу было понятно, что люди не понимают, что они делают и денег не считают. Так оно и оказалось. Запомните и повторяйте: "эластик всегда либо ещё не нужен, либо уже слишком дорог".
Какое бы решение вы выбрали в 2019 году с учетом требований из статьи?
Коротко: SSD на 7Gb/s и tail grep - решают все наши оперативные потребности в чтение логов. Поток таймсерий уже идет куда как более бедный, т.к. агрегируется еще в приложение.
Подробно: Если команды потребляют "несчитанные ресурсы", то они начинают их потреблять не считая. Зачем думать, сколько ты пожираешь трафика, проц. времени и памяти, когда это общие кластеры, откуда твою часть посчитать крайне сложно. Все колоссально меняется, когда команды сами платят за свою инфру. Вот тут каждый нанятый дурак виден - как прыщ на лбу. И 3 развернутых тестовых окружения со всеми интеграциями внезапно становятся неадекватно дорогими.
Сейчас 7 Гб/с ссд ничего не стоят, так что даже сотню Гб логов ворочить обычным grep - работает на ура, а если тело умеет в tmux, tail и grep - то он сам себе кибана.
Мы льем все в AWS на S3 и от туда достаем просто через Logs Insights. Это тоже самое, что HIVE или Presto.
Оперативно ворочить нужно логами минут 15-30 и то, если там трейс через несколько систем каких-то убогих. Правильные сервисы позволяют понять, что не так, просто по своим логам, правильные сервисы идемпотенты и умеют реплей.
В платежных системах логи нужно хранить дольше, но они могут уходить уже через день в более дешевые хранилища.
Можно сказать, переизобрели Loki
Нет, просто пишем на файловую систему (иногда кластерную) и грепаем с нее, по необходимости. 99% логов грепать не приходится вообще.
Мы переворачиваем несколько терабайт данных в день с семантикой exactly once и стоимостью меньше 10к на все в месяц в амазоне. До этого я работал в командах с гигабайтными потоками, которые только на логи пуляли больше.
Интересны подробности:
В какой компании так делают, если не секрет?
Какой SLA у сервисов с таким мониторингом?
Сколько сервисов так логирует?
Сколько инженеров суммарно в командах, которые так ищут по логам?
Все логи в кучу файликов складываете, или есть какая-то систематизация, разграничение доступа, или прям всем доступны все логи, и еще извне?
Как проверяете, что фичи выкатились на прод ожидаемо (например, разработчики включили фича-флаг или просто фичу выкатили новую сложную, и следят за подробностями работы приложения)?
Есть ли процесс проверки логов на наличие нежелательных данных (sensitive data, перс. данные и тд)?
Нет ни одного алерта/дашборда по логам?
Одна из топ 5 электронной коммерции, работающих в Европе.
Про мониторинг я не словом. SLA нет, мы (как команда) не представляем платный сервис клиентам. За год, пока я с этой командой uptime 100%, остановка критических сервисов команды - это остановка основного бизнеса компании, что просто не приемлемо и они все реактивные, идемпотентные и с реплеем. У нас нет тестового окружения, только тесты, канари или двухцветный деплой.
Метрики по логам из Cloud Watch и подобное используем для мониторинга наравне с графаной и ко.Наша команда отвечает за 18 микросервисов в EKS и лямдах. Но команд таких много - с несколько десятков, которые только я знаю. На уровне CTO и т.п. нет предписаний, как строить свои системы, отсюда и разнообразие.
Под сотню инженеров в компании так работают только из команд, которые я знаю. А так - миллионы, кто сидит на ванильном AWS и использует Cloud Watch.
Вся безопасность, поиск и отображение на стороне амазона с их инструментами. Это ui обертки поверх presto на hdfs. Если искать по функциям запросов, то часто выходишь на документацию presto.
Канари или двухцветный деплой. Сервисы редко мутируют или расширяются в функционале - принцип пайпов из ФП, где расширение функционала через композицию. Одного dependabot нам уже хватает с избытком ) он в 99% случаев единственный, кто изменяет старые сервисы. UI их просто агрегируют по смыслу.
Да, конечно. Там безопасники в своем кокпите имеют массу подобного. Они шныряют по нашим access и прочим логам, делают аудиты. Вроде как конфедеративный доступ это называется, который им обеспечивает доступ и управление всеми аккаунтами команд.
Несколько десятков в графане или сразу из Cloud Watch метрик на Opsgenie.
Централизованные сервисы, которые начинают превосходить типовые конфигурации систем, ставят нетривиальные задачи перед разработчиками и увеличивают свои бюджеты нелинейно. В таких случаях всегда нужно останавливаться и осматривать индустрию на предмет уже найденных решений. Отсутствие материальной заинтересованности в экономии ресурсов в купе с определенной формой изолированности решений (зачастую изоляция из-за огромного выбора возможностей, которые до конца никто не знает) приводят к экзотичным решениям. Это обыденность в нашей профессии.
Про мониторинг я не словом. SLA нет, мы (как команда) не представляем платный сервис клиентам. За год, пока я с этой командой uptime 100%, остановка критических сервисов команды - это остановка основного бизнеса компании
Ну раз SLA нет, и требования грепать за последние 15 мин., то наверно так еще норм. У нас были другие требования.
Интересно как выглядит grep с получением статистики в виде графика во времени.
На самом деле я бы почитал статью с подробностями и скриншотами
Про то, что если ресурсы не считать и не привязывать к владельцам — рано или поздно ресурсы закончатся, даже спорить не буду, полностью согласен.
Подскажите, какая главная причина большого количества логов? Сколько по времени вы храните логи? Используете ли APM? Строите ли метрики на основе логов?
Храним логи по умолчанию 14 дней, для некоторых клиентов — дольше.
Почему так много логов — вопрос риторический, всем всегда хочется иметь как можно больше логов для разработки/тестирования/мониторинга.
APM — централизованно нет, но в компании есть трейсинг.
Метрики на основе логов — есть такая идея, сделать как сервис простую конвертилку, но еще не успели реализовать.
Еще есть логи, на которых решаются задачи SOC — тут 14 дней часто не достаточно. Также на логах решаются аналитические задачи, которые также требуют хранить логи дольше.
А почему не используете routing? Это позволит ускорить типовые выборки, если у вас есть в рамках кластера условное разбиение на потоки данных (эти логи отвечают за фичу N, эти за M и т.д.), то роутинг подскажет es, что их нужно хранить в одном шарде, что ускорит запросы к ним.
Разрешите несколько вопросов.
тк Kafka часть решения начну с нее
На каждый ЦОД свой кластер. Один на всех потребителей или несколько? Как происходит группировка потребителей по кластерам?
Какой входной поток на кластер? Сколько брокеров?
Сколько партиций на топик? Какой консьюмер групп, как понимаю не один экземпляр приложения вычитывает.
Обеспечивается ли exactly one, если да, то как, если нет, то как происходит работа с дублями.
Рассматривали ли замену Kafka на mq, ведь там из коробки роуминг, фильтрация, проверка по схемам и т.д.
Один кластер Kafka в каждом ДЦ на всех пользователей. У каждого клиента есть как минимум одна из основных сущностей Sage — группа (group), бывает что у клиента есть несколько таких групп. Каждая группа логов пишется в отдельный топик.
Входной поток на Кафке: в пике 500 МБ (ДЦ1) + 400 МБ (ДЦ2) — сообщения могут приходить как в сжатом, так и в несжатом виде. При вычитке и обработке на переливалке после расжатия получается уже суммарно примерно те самые 3,5 ГБ/с в пике.
В каждом кластере Kafka по 5 брокеров.Обычно на топик создается 10 партиций, есть большие группы где поднимали до 20 партиций. Consumer group переливалки — один на кластер.
Семантика exactly-once не обеспечивается. Но для каждого записанного лога проставляется (кроме исходного времени внутри самого события) временная метка, когда сообщение было взято в обработку + id лога — можно понять, что событие повторно записано. Еще есть ряд проверок при записи события для минимизации ошибок на стороне клиента, например проверяется что событие не очень далеко из прошлого (на случай сбоя и попытки переотправки очень старых логов заново).
mq — имеется ввиду RabbitMQ? Не рассматривали, кажется что Кафка нас пока устраивает. Изначально когда выбирали Кафку, понравилось что есть очень много готовых клиентов для отправки, да и поддержка в библиотеках тоже есть во всех мейнстримовых языках. Схемы данных мы пока еще не вводили, но мысли такие есть (как минимум для больших клиентов, чтобы было меньше неожиданностей на стороне Elastic, и даже оптимизации можно будет сделать под схему).
Автор, мне интересна тема и нужна в работе, но перестал читать статью на середине из-за вашей не любви к русскому. Какие тула, ретраи?
„Употреблять иностранное слово, когда есть равносильное ему русское слово, — значит оскорблять и здравый смысл, и здравый вкус.“ — Виссарион Григорьевич Белинский
Как сейчас чувствует себя такая система? Я правильно понимаю что elastic proxy cluster это что-то написанное вами?
Система нормально себя чувствует, держит нагрузки.
Elastic Proxy Cluster — это не самописное, а просто отдельностоящий кластер Эластика, настроенны на Cross Cluster Search (средствами самого Эластика можно настроить такой кластер, чтобы он искал во всех кластерах с данными, при этом в самом proxy cluster данных нет, он только проксирует поиски и объединяет данные из результатов поисков).
О отлично! Спасибо за столь оперативный ответ. Подскажите а сколько у вас сейчас более мелких кластеров? Какой объем данных они переваривают? У каждого маленького кластера обязательно должен же быть свой мастер?
24 кластера с данными насчитал.
Суммарный объем данных на дисках с учетом реплик: ~7.43 PiB.
У каждого кластера обязательно должен быть мастер, иначе это не кластер, а набор независимых нод (на самом деле нод, которые имеют роль мастера, должно быть минимум 3, для кворума, из которого активный мастер всегда 1). В связи с высокой нагрузкой на data-ноды, мы выносим роль мастера на отдельные (небольшие) ноды.
Впрочем, это всё уже было описано в статье.
Спасибо за интересный материал и хороший доклад. Многие из проблем откликаются, и многие выводы перекликаются с собственными мыслями :)
7 петабайт логов в Elastic