Comments 16
Под JVM Heap не более 50% общего объёма памяти и не более 30Гб во избежание набега garbage collector. Оставшаяся память будет использована как кэш операционной системы.
Я этого места ждал и, что неудивительно, дождался. Откровенно удивляет, что это можно увидеть в документации к версии 7.4, в то время как оно тянется ещё со времён эластика 2.5.
Мы переехали на Java11, используем 64-бит поинтеры и новый сборщик мусора, ограничиваем память JVM с помощью cgroup и хипе выдаём столько, сколько влезает оперативки с учётом ограничений, потому что запуск нескольких инстансов эластика на одной ноде (как написано в одном из документов с ответами на «а что делать, ведь сейчас сотни гигов оперативки не редкость») это добровольное поедание кактуса. «Been there, done that» как говорится.
Собираем и индексируем по 5+ ТБ данных в день, больше тысячи проиндексированных полей, до вышеописанного решения пришли опытным путём при переезде с 5-й на 6-ю версии. Написали себе свой сборщик бэкапов (на Go, выхлоп в json) потому что снэпшоты это всё тот же кактус.
Однажды, в далёкой, далёкой… параллельной реальности руки дойдут и время будет про всё это написать :)
Если это все еще есть в документации, то это значит что этот кейс работает для количества случаев приближенных к 100%.
Ваша же версия настройки эластика говорит о том что в вашем кейсе данная предосторожность не нужна.
Я сомневаюсь что такая большая компания как эластик забыла поправить документацию.
Мы тоже используем больше 32 GB heap, но тут четко нужно понимать для чего ты это делаешь и что поимеешь в каких случаях.
Ваша же версия настройки эластика говорит о том что в вашем кейсе данная предосторожность не нужна.
Я сомневаюсь что такая большая компания как эластик забыла поправить документацию.
Мы тоже используем больше 32 GB heap, но тут четко нужно понимать для чего ты это делаешь и что поимеешь в каких случаях.
ghostinushanka чем ищете в бэкапах, если не секрет? Скриптами? Или это вообще никогда не бывает надо? Нам тут как-то понадобилось пойти на полгода назад, посмотреть каких кастомеров потенциально могло зацепить одной редкой проблемой…
зависит от кол-ва искомых данных и точности задачи
если вопрос уровня «в день Д, час Ч в интервале между 10й и 20й минутой надо вот этот сквозной идентификатор», то просто парсится json, на то он и json
если что-то типа «такого-то числа, примерно, клиент делал Х на платформе, а ща говорит что этого не было, и он вообще делал У», то берётся набор бэкапов и проигрывается (replay) в эластик для дальнейшего разбора
храним мы 14 месяцев, при дневном обьёме не сложно посчитать сколько это и во что бы обошелся «отмороженный» индекс
если вопрос уровня «в день Д, час Ч в интервале между 10й и 20й минутой надо вот этот сквозной идентификатор», то просто парсится json, на то он и json
если что-то типа «такого-то числа, примерно, клиент делал Х на платформе, а ща говорит что этого не было, и он вообще делал У», то берётся набор бэкапов и проигрывается (replay) в эластик для дальнейшего разбора
храним мы 14 месяцев, при дневном обьёме не сложно посчитать сколько это и во что бы обошелся «отмороженный» индекс
Спасибо. При этом под «бэкапом» понимается зип, в котором лежит текстовый файл с экспортированными в json всеми документами за определенный период времени или что-то другое?
Вопрос не праздный, я поясню. Была сереьезная разборка, когда внешний компонент одной уважаемой компании, при определенных обстоятельствах, мог отдать респонс не на твой запрос, а на совсем другой запрос, сделанный параллельно. Мы конечно сами виноваты что недостаточно изолировали, но как говорится «кто без греха...». Такое случалось очень редко, но могло сильно навредить. После закрытия дыры, надо было посмотреть «кого за это время могло задеть». Для этого, надо было в логах за полгода 1) найти все «плохие сессии» по признаку повышенного количества в них определенных ошибок 2) для каждой такой сессии найти соседние сессии, которые происходили на этом же хосте в это же время. 3) для 1) и 2) вынуть идентификаторы клиентов из определнных эвентов в сессии. Мы сделали это скриптами по архиву текстовых логов.
Сейчас у девопсов появился Эластик, в него влезает 4 недели и делаются ежедневные снапшоты штатными средствами. Теперь вопрос: может ли Эластик + снапшоты эффективно решить проблему выше? Или нам все же нужно параллельно держать текстовый архив, чтобы иметь возможность искать там скриптами или, в простом случае, логпадом. Нам кажется, что это имеет смысл, ищем подтверждения.
Я правильно, что в Вашем случае, как раз у Вас организован похожий архив?
Вопрос не праздный, я поясню. Была сереьезная разборка, когда внешний компонент одной уважаемой компании, при определенных обстоятельствах, мог отдать респонс не на твой запрос, а на совсем другой запрос, сделанный параллельно. Мы конечно сами виноваты что недостаточно изолировали, но как говорится «кто без греха...». Такое случалось очень редко, но могло сильно навредить. После закрытия дыры, надо было посмотреть «кого за это время могло задеть». Для этого, надо было в логах за полгода 1) найти все «плохие сессии» по признаку повышенного количества в них определенных ошибок 2) для каждой такой сессии найти соседние сессии, которые происходили на этом же хосте в это же время. 3) для 1) и 2) вынуть идентификаторы клиентов из определнных эвентов в сессии. Мы сделали это скриптами по архиву текстовых логов.
Сейчас у девопсов появился Эластик, в него влезает 4 недели и делаются ежедневные снапшоты штатными средствами. Теперь вопрос: может ли Эластик + снапшоты эффективно решить проблему выше? Или нам все же нужно параллельно держать текстовый архив, чтобы иметь возможность искать там скриптами или, в простом случае, логпадом. Нам кажется, что это имеет смысл, ищем подтверждения.
Я правильно, что в Вашем случае, как раз у Вас организован похожий архив?
Мне кажется вы задаете несколько вопросов в одном.
Это не совсем релевантно к дискуссии.
Все это же с помощью эластика и Кибаны или без нее вы можете сделать в десятки а порой и в сотни раз быстрее при наличии определенного опыта и навыков.
Это же отдельный вопрос связанный скорее всего с бюджетированием и планированием. Ведь понятно что если вам надо посмотреть данные за полгода (26 недель), а в наличии места только на 4, то при ваших специфических ограничениях задача явно если и будет иметь решение то кривоватое.
Но если убрать это в сторону и рассматривать чисто технологически. То можно поднять эластик который либо будет держать бОльший объем данных постоянно. Либо поднимаем временный кластер в облаке заливаем в него данные за полгода, проводим анализ и убиваем кластер. Слава богу облака сегодня позволяют это делать быстро и недорого.
Была сереьезная разборка
Это не совсем релевантно к дискуссии.
Для этого, надо было в логах за полгода 1) найти все «плохие сессии» по признаку повышенного количества в них определенных ошибок 2) для каждой такой сессии найти соседние сессии, которые происходили на этом же хосте в это же время. 3) для 1) и 2) вынуть идентификаторы клиентов из определнных эвентов в сессии. Мы сделали это скриптами по архиву текстовых логов.
Все это же с помощью эластика и Кибаны или без нее вы можете сделать в десятки а порой и в сотни раз быстрее при наличии определенного опыта и навыков.
Сейчас у девопсов появился Эластик, в него влезает 4 недели и делаются ежедневные снапшоты штатными средствами.
Это же отдельный вопрос связанный скорее всего с бюджетированием и планированием. Ведь понятно что если вам надо посмотреть данные за полгода (26 недель), а в наличии места только на 4, то при ваших специфических ограничениях задача явно если и будет иметь решение то кривоватое.
Но если убрать это в сторону и рассматривать чисто технологически. То можно поднять эластик который либо будет держать бОльший объем данных постоянно. Либо поднимаем временный кластер в облаке заливаем в него данные за полгода, проводим анализ и убиваем кластер. Слава богу облака сегодня позволяют это делать быстро и недорого.
Спасибо за ответ.
Этот вариант не рассматривается по причинам высокой стоимости. 4 недели и так уже серьезная стоимость, тем более что их несколько, один на каждый регион.
Этот вариант интересный, спасибо. надо будет оценить размер и стоимость такого кластера в облаке. Я правильно понимаю, что Эластик сможет как-то автоматически смерджить данные из этих 26 снапшотов, без дупликатов?
То можно поднять эластик который либо будет держать бОльший объем данных постоянно.
Этот вариант не рассматривается по причинам высокой стоимости. 4 недели и так уже серьезная стоимость, тем более что их несколько, один на каждый регион.
Либо поднимаем временный кластер в облаке заливаем в него данные за полгода, проводим анализ и убиваем кластер. Слава богу облака сегодня позволяют это делать быстро и недорого.
Этот вариант интересный, спасибо. надо будет оценить размер и стоимость такого кластера в облаке. Я правильно понимаю, что Эластик сможет как-то автоматически смерджить данные из этих 26 снапшотов, без дупликатов?
под «бэкапом» понимается зип, в котором лежит текстовый файл с экспортированными в json всеми документами за определенный период времени или что-то другое
экспортированный в json индекс. Индексы автоматически обрабатывается через curator и rollover api. rollover по времени и достижению кол-ва документов (что первым происходит, наш трафик — волна). За счёт этого отдельные куски достаточно маленькие получаются. curator закладывает время «перемотки» для последующего упрощения поиска.
Архивируем, в два этапа — более свежие с меньшим сжатием, после трёх месяцев пережимаем ещё сильнее.
Для мелких запросов поиск по тексту быстрее чем проигрывание с восстановлением в эластик и переиндексацией.
Для больших же, с анализом, как я уже писал, и как вам советует dzsysop — заливайте в эластик. Однако стоимость кластера в облаке это в первую очередь стоимость передачи всего массива данных и для обьёмов о которых мы говорим, это, я уверен, будет стоить больше, чем сами вычислительные мощности.
Если нет своей инфраструктуры, берите в аренду managed сервера на короткий промежуток времени.
У того же hetzner, например, вы заплатите за модель с 10-ю дисками по 10ТБ каждый — 170 евро в месяц. Но у большенства моделей они берут ещё одну месячную плату за установку.
Альтернативно можно посмотреть в сторону провайдеров с почасовой оплатой (месяц выйдет понятно дороже, но в вашем случае может быть выгоднее), например packet
Если стоимость (при необходимом обьёме данных) приемлема для бизнеса — это вполне рабочий вариант.
ghostinushanka, спасибо за детальный ответ. Обьемы, конечно, смущают. У нас, конечно, не 5TB в день, но все же… Если взять Ваши цифры на секунду…
То есть я правильно Вас понял, что если бы Вам потребовалось провести сложное расследование на всех 14 месяцах, то специалисту по Эластику, при наличии бюджета и за разумный срок (скажем неделя) не составило бы проблемы поднять в облаке Эластик-кластер на 2 петабайта логов?..
То есть я правильно Вас понял, что если бы Вам потребовалось провести сложное расследование на всех 14 месяцах, то специалисту по Эластику, при наличии бюджета и за разумный срок (скажем неделя) не составило бы проблемы поднять в облаке Эластик-кластер на 2 петабайта логов?..
Можно еще использовать -XX:ObjectAlignmentInBytes для хипа больше 32Гб
Тоже используем elastic. Но пока не в таких больших объемах, в среднем по 30-40гб в сутки. Тема с горячими и холодными нодами- все про нее говорят, но как реализовать правильнее нигде не указано. Поэтому самым простым выходом из ситуации-это иметь кластер elasticsearch, который пишет боевые данные, например в течение месяца или двух- в зависимости от требований и наличия объема. А все остальные данные бэкапить используя snapshot на nfs диск. А потом в случае разбора каких то старых логов, восстановить на отдельный dev elasticsearch.
Еще не проверял, как можно сэкономить место на архивах snabpshot используя дедупликацию.
Еще не проверял, как можно сэкономить место на архивах snabpshot используя дедупликацию.
Может найдете что-то полезное для себя на этих слайдах
А index lifecycle management не пробовали?
Возможно, кому-то будет интересно. Вебинар по архитектуре Elastic Stack на русском языке. Рассказывает архитектор Elastic Татьяна Франк.
В дополнение — репозиторий с фреймворком для бенчмарка производительности Elatic
Sign up to leave a comment.
Сайзинг Elasticsearch