Comments 15
Какое количество данных безболезненно тянет ES?
Так однозначно сложно ответить. Всё зависит от количества Data-нод и производительности этих нод.
Чем больше потоков, тем быстрее.
На тестовом стенде с 2мя Data-нодами тянет 17M (~2Gb) логов в день. Каждая нода по 2 ядра и 2Гб. 2 недели логов тянет хорошо, но начинает напрягаться HDD. Но с учётом того, что ресурсы общие с ещё кучей VM, то весьма хороший результат.
В прочем сложно судить: загружаемые данные более или менее одинаковы.
Чем больше потоков, тем быстрее.
На тестовом стенде с 2мя Data-нодами тянет 17M (~2Gb) логов в день. Каждая нода по 2 ядра и 2Гб. 2 недели логов тянет хорошо, но начинает напрягаться HDD. Но с учётом того, что ресурсы общие с ещё кучей VM, то весьма хороший результат.
В прочем сложно судить: загружаемые данные более или менее одинаковы.
Спасио, я понял. Не как шпилька, но для меня это смешные объемы :) По нашим наблюдениям, при большом количестве читающих клиентов к ES(у нас порядка 100 дашбордов, для разных бизес и ИТ отделов), мы начинаем валится где-то на 8-10 Gb в день. Потому сейчас пересобираем свою елку на другие базовые рельсы, так как поток сырых логов у нас все растет и растет.
Если не секрет, в сторону чего нового смотрите?
Есть ли какая-либо cache-прослойка между дашбордами или клиентом? Мне кажется это изрядно бы разгрузило нагрузку на бд.
Есть ли распараллеливание шардами нагрузки между несколькими хостами?
Это я всё больше для себя узнаю :)
Есть ли какая-либо cache-прослойка между дашбордами или клиентом? Мне кажется это изрядно бы разгрузило нагрузку на бд.
Есть ли распараллеливание шардами нагрузки между несколькими хостами?
Это я всё больше для себя узнаю :)
О кеше между клиентами и ES пока не думали. Да и наверно не видим особо смысла. Поясню: новые данные обычно достаточно легко читаются, проблема в старых данных или больших выборках(кстати то же касается и метрик, но об этом ниже). Мы скорее хотим придти к схеме, когда на долговременные данные можно заказать отчет, которые спокойно выполнится в фоне, а kibana, использовать, в основном, для горячих данных.
В целом, мы сейчас идем к уборки логов в hadoop, и над ним уже ставить ES. Поясню почему такое решение: сейчас наш поток логов хранится 2 недели от момента появления, но по 152 ФЗ нам надо его хранить 180 дней. В перспективе на эти данные можно будет посадить аналитика и пусть он майнингом занимается, а такое уже требует бесконечного хранения. От сюда и решения. Еще плюс hadoop в том, что данные внутри его hdfs можно хранить в сжатом виде, что дает экономию места(кстати метрик то же касается).
Еще момент, что мы имеем соизмеримый с объемом логов, объем метрик(сейчас около 20Гб в день, предполагается увеличение на 25-40%), и столкнулись с проблемами хранения и репликации этого дела (Господи, упаси нас от carbon). Сейчас приходим к тому, что хорошим вариантом является opentsdb, так как оно живет на базе hbase.
Резюмируя: мы весь мониторинг (и аналитику) переводим в одной место, и даем к нему несколько интерфейсов взаимодействия, в зависимости от целей. И на едином наборе данных делаем метрики, алерты, логи и аналитику.
В целом, мы сейчас идем к уборки логов в hadoop, и над ним уже ставить ES. Поясню почему такое решение: сейчас наш поток логов хранится 2 недели от момента появления, но по 152 ФЗ нам надо его хранить 180 дней. В перспективе на эти данные можно будет посадить аналитика и пусть он майнингом занимается, а такое уже требует бесконечного хранения. От сюда и решения. Еще плюс hadoop в том, что данные внутри его hdfs можно хранить в сжатом виде, что дает экономию места(кстати метрик то же касается).
Еще момент, что мы имеем соизмеримый с объемом логов, объем метрик(сейчас около 20Гб в день, предполагается увеличение на 25-40%), и столкнулись с проблемами хранения и репликации этого дела (Господи, упаси нас от carbon). Сейчас приходим к тому, что хорошим вариантом является opentsdb, так как оно живет на базе hbase.
Резюмируя: мы весь мониторинг (и аналитику) переводим в одной место, и даем к нему несколько интерфейсов взаимодействия, в зависимости от целей. И на едином наборе данных делаем метрики, алерты, логи и аналитику.
Т.е. если я правильно Вас понял, то у Вас будут храниться данные сразу в двух местах: неделя-две в ES и + hadoop для текущих и остальных, так? Решение интересное. Запомню на будущее.
Еще до конца всю схему не проработали. Но предполагаем, что ES будет индексировать все, что хранит в себе hadoop. Как мы распределим и настроим индексы, еще не решили.
Хранить ли весь набор данных за какой-то срок в ES, мы будем решать уже по факту быстродействия рабочего кластера, на тестовом у нас маленький набор данных и слабое железо.
Хранить ли весь набор данных за какой-то срок в ES, мы будем решать уже по факту быстродействия рабочего кластера, на тестовом у нас маленький набор данных и слабое железо.
А расскажите про вашу конфигурацию: сколько нод (дата, мастер, балансер) и каких: сколько памяти, процессоров и я так понял у вас 8-10 Гб логов в день?
Мы еще в глубоком пилоте, и пока работаем на простых «консервных банках». Мы идем поступательно, от задачи хранить, к задаче отдавать быстро.
Я потом может напишу статью сюда об этом.
Предварительные расчеты такие: 4 дата-ноды (2 камня, 64 Гб, диск по максимуму), два сервака с мастером и на нем же ES. К чему придем когда будем готовы переходить на продакшен — увы, но вопрос открытый.
Я потом может напишу статью сюда об этом.
Предварительные расчеты такие: 4 дата-ноды (2 камня, 64 Гб, диск по максимуму), два сервака с мастером и на нем же ES. К чему придем когда будем готовы переходить на продакшен — увы, но вопрос открытый.
UFO just landed and posted this here
Sign up to leave a comment.
ELK+R как хранилище логов 2. Установка и настройка