Comments 11
Спасибо большое за статью - прочёл одном дыхании.
Подскажите, правильно ли я понял, что в итоге ушли от kafkabeat на Baikalbeat, подскажите в чем их разница реализации. Ведь оба были внутренние реализации? Что не дало покрутить kafkabeat ?
Есть ли у вас в планах раскрытие побольше деталей по тюнингу elastic search, ситуации с высокой утилизацией дисковых операции и перевод на sas в hot, а также реализации hot/warm. Заранее благодарен.
1) Baikalbeat (https://github.com/elabpro/baikalbeat/) не совсем корректное название, так как он не beat, а узко специализированная утилита, созданная с определенными допущениями. Kafkabeat - полноценный beat. Экономить приходилось на всем - от конкатенации строк до выкидывания JSON парсинга. За счет этого и получили нужные скорости с меньшим потреблением ресурсов
2) SAS ноды у нас легко были переведены в HOT - там ничего не тюнилось специально под это. Изначально при создании нод делался уже максимальнный тюнинг: RAID0 для создания быстрых объемных разделов, оптимизация файловой системы (xfs - журнализация), ограничение каждой ноды объемом в 32Gb RAM, тюнинг jvm и остального всего, до чего можно добраться на своем сервере.
Почему решили использовать shared SAN NetApp? Это же единая точка отказа, хоть и имеет резервирование на уровне контроллеров. И оно особо не масштабируется горизонтально в дальнейшем. Почему не использовать локальное диски разных видов (warm,hot) в каждом сервере?
Не рассматривали вариант с поместить ElasticSearch в k8s кластер на этом же железе?
1) у меня был хороший Netapp с хорошей гарантией, и нужный объем в несколько петабайт мне могли обеспечить. Но мне и не надо было много петабайт для дальнейшего роста, там уже лучше было тратить деньги на адаптацию инструментов и переход на Clickhouse подобные решения.
2) По ES на k8s - 2-3 раза обдумывали это решение и не нашли ему применения. Мало того, что сам k8s съедает часть ресурсов, так и его использование усложняет процесс troubleshooting-а. Его лучше использовать там, где требуется запускать множество разнородных процессов с динамическим распределением серверных ресурсов. В таких местах там как раз мы использовали кубер.
3) Локальные диски мы использовали, но для наших объемов стоимость локального хранения выходила дороже, чем Netapp. В силу еще разных ценовых политик.
А если эти объемы считать в облаках, то там и ценники уходят в облака :)
В списке приложений для вставки данных из Kafka в Elasticsearch почему то отсутствует Rsyslog, почему решили его не тестировать? Это готовое решение и по скорости скорее всего было бы на 1-м месте.
Насколько я помню его вспомнили при анализе и его производительность была на уровне Kafkabeat. Основная проблема в обработке данных была в том, что надо было вытащить имя индекса, а для этого нужен был JSON парсинг, который съедал много ресурсов при любом вариант реализации. Возьмем к примеру их публикацию ( https://www.rsyslog.com/performance-tuning-elasticsearch/ ) - там они радуются 30K/s. Для 3M/s мне бы потребовалось 100 инстансев с их конфигурацией. Это достаточно ресурсоемко и затратно. Я обходился гораздо меньшим количеством своих байкалбитов
А почему не рассматривались какие-то другие инструменты для хранения, кроме ElasticSearch? Тот же CH или хотя бы Influx или иные инструменты?
Кажется, что использование полнотекстового движка для мониторинга по метрикам - не самое лучшее решение.
А где я говорил что в ES хранятся метрики? Для метрик у там использовались специализированные хранилища на базе graphite / prometheus. Graphite перевели на backend на базе Clickhouse, а тугой prometheus на VictoriaMetrics.
ES нужен именно для полнотекстового поиска по разным исходным данным.
Спасибо за статью. Читал с большим интересом. Не могу не заметить один недостаток в этой архитектуре. На практика это будет его поддержка будет очень трудоемкой, иногда невозможной. При очень больших данных и очень большой нагузке плюс огромном кластере из 20+ машин контролирование (eng. monitoring) всего хозайства становиться почти нерешаемой задачей. Придеться нанимать новых людей чтобы следили за уведомлениями (eng. alerts), но и это не поможет. Если бы это решение работала на практике на больших данных, то его не приподносили бы как учебный в этой статье https://www.cloudskillsboost.google/focuses/12964?parent=catalog. Заранее отвечу, решение проблемы уведомлений (eng. alerts) это либо использование решений с Hadoop от Cloudera либо переход в облоко.
Кластер ElasticSearch на 1Ptb+