Elk linux что это

Обновлено: 04.07.2024

Разворачивая очередную систему, столкнулись с необходимостью обрабатывать большое количество разнообразных логов. В качестве инструмента выбрали ELK. В данной статье пойдёт речь о нашем опыте настройки этого стека.

Не ставим цели описать все его возможности, но хотим сконцентрироваться именно на решении практических задач. Вызвано это тем, что при наличии достаточно большого количества документации и уже готовых образов, подводных камней достаточно много, по крайней мере у нас они обнаружились.

Мы разворачивали стек через docker-compose. Более того, у нас был хорошо написанный docker-compose.yml, который позволил нам практически без проблем поднять стек. И нам казалось, что победа уже близка, сейчас немного докрутим под свои нужды и всё.

К сожалению, попытка донастроить систему на получение и обработку логов от нашего приложения, с ходу не увенчалась успехом. Поэтому, мы решили, что стоит изучить каждый компонент отдельно, а потом уже вернуться к их связям.

Итак, начали с logstash.

Для развёртывания используем docker-compose, описанные здесь эксперименты проводились на MacOS и Ubuntu 18.0.4.

Образ logstash, который был прописан у нас в исходном docker-compose.yml, это docker.elastic.co/logstash/logstash:6.3.2

Его мы будем использовать для экспериментов.

Для запуска logstash мы написали отдельный docker-compose.yml. Можно конечно было из командной строки образ запускать, но мы ведь конкретную задачу решали, где у нас всё из docker-compose запускается.

Кратко про конфигурационные файлы

Как следует из описания, logstash можно запускать как для одного канала, в этом случае, ему нужно передать файл *.conf или для нескольких каналов, в этом случае ему надо передать файл pipelines.yml, который, в свою очередь, будет ссылаться на файлы .conf для каждого канала.
Мы пошли по второму пути. Он нам показался более универсальным и масштабируемым. Поэтому, мы создали pipelines.yml, и сделали директорию pipelines, в которую будем класть файлы .conf для каждого канала.

Внутри контейнера есть ещё один конфигурационный файл — logstash.yml. Мы его не трогаем, используем как есть.

Итак, структура наших каталогов:

Для получения входных данных пока считаем, что это tcp по порту 5046, а для вывода будем использовать stdout.

Вот такая простая конфигурация для первого запуска. Поскольку ведь начальная задача — запустить.

Итак, у нас есть вот такой docker-compose.yml

Что мы здесь видим?

Networks и volumes были взяты из исходного docker-compose.yml (тот где целиком стек запускается) и думаю, что сильно здесь на общую картинку не влияют.
Мы создаём один сервис (services) logstash, из образа docker.elastic.co/logstash/logstash:6.3.2 и присваиваем ему имя logstash_one_channel.
Мы пробрасываем внутрь контейнера порт 5046, на такой же внутренний порт.
Мы отображаем наш файл настройки каналов ./config/pipelines.yml на файл /usr/share/logstash/config/pipelines.yml внутри контейнера, откуда его подхватит logstash и делаем его read-only, просто на всякий случай.
Мы отображаем директорию ./config/pipelines, где у нас лежат файлы с настройками каналов, в директорию /usr/share/logstash/config/pipelines и тоже делаем её read-only.

Здесь описан один канал с идентификатором HABR и путь к его конфигурационному файлу.

И наконец файл «./config/pipelines/habr_pipeline.conf"

Не будем пока вдаваться в его описание, пробуем запустить:

Контейнер запустился. Можем проверить его работу:

И видим в консоли контейнера ответ:

Но при этом, видим также:

И наш лог всё время ползёт вверх.

Работать можно, но не удобно.

Решением является отключить эту проверку через переменную окружения XPACK_MONITORING_ENABLED.

Внесём изменение в docker-compose.yml и снова запускаем:

Вот теперь, всё нормально. Контейнер готов к экспериментам.

Можем снова набрать в соседней консоли:

Итак, мы запустились. Теперь собственно можно уделить время настройке непосредственно logstash. Не будем пока трогать файл pipelines.yml, посмотрим, что можно получить, работая с одним каналом.

Надо сказать, что общий принцип работы с файлом конфигурации канала хорошо описан в официальном руководстве, вот здесь
Если хочется почитать по-русски, то мы пользовались вот этой статьёй(но синтаксис запросов там старый, надо это учитывать).

Пойдем последовательно от секции Input. Работу по tcp мы уже видели. Что ещё здесь может быть интересного?

Включаем, начинаем раз в минуту получать

Получение данных из файла

Ещё решили посмотреть режим file. Если нормально с файлом работает, то возможно, и агента никакого не потребуется, ну хотя бы для локального использования.

По описанию, режим работы должен быть аналогичный tail -f, т.е. читает новые строки или, как опция, читает весь файл.

Итак, что мы хотим получить:

Мы хотим получать строки, которые дописываются в один лог файл.
Мы хотим получать данные, которые записываются в несколько лог файлов, при этом, иметь возможность разделить что откуда получено.
Мы хотим проверить, что при перезапуске logstash он не получит эти данные повторно.
Мы хотим проверить, что если logstash отключить, а данные в файлы продолжают писаться, то, когда мы его запустим, то мы эти данные получим.

И изменим секцию input в habr_pipeline.conf

Для создания и записывания лог файлов будем пользоваться командой:

При этом, мы видим, что у нас автоматически добавилось поле path. Значит в дальнейшем, мы сможем по нему фильтровать записи.

А теперь в другой файл:

Отлично! Файл подхватился, path указался верно, всё хорошо.

Остановим logstash и запусти заново. Подождём. Тишина. Т.е. Повторно мы эти записи не получаем.

А теперь самый смелый эксперимент.

Кладём logstash и выполняем:

Снова запускаем logstash и видим:

Ура! Всё подхватилось.

Но, надо предупредить о следующем. Если контейнер с logstash удаляется (docker stop logstash_one_channel && docker rm logstash_one_channel), то ничего не подхватится. Внутри контейнера была сохранена позиция файла, до которой он был считан. Если запускать «с нуля», то он будет принимать только новые строки.

Считывание уже существующих файлов

Допустим мы первый раз запускаем logstash, но у нас уже есть логи и мы хотели бы их обработать.
Если мы запустим logstash с той секцией input, которую использовали выше, то мы ничего не получим. Только новые строки будут обрабатываться logstash.

Для того, чтобы подтянулись строки из существующих файлов, следует добавить в input секцию дополнительную строчку:

Причём, есть нюанс, это действует только на новые файлы, которые logstash ещё не видел. Для тех же файлов, что уже попадали в поле зрения logstash, он уже запомнил их размер и теперь будет брать только новые записи в них.

Остановимся на этом на изучении секции input. Там ещё множество вариантов, но нам, для дальнейших экспериментов пока хватит.

Маршрутизация и преобразование данных

Для этого, от секции input переходим к filter и output.

Для того, чтобы разбирать текстовые строки и получать из них набор полей, в секции filter есть специальный плагин — grok.

Не ставя себе целью дать здесь его детальное описание (за этим отсылаю к официальной документации), приведу свой простой пример.

Для этого, надо определиться с форматом входных строк. У меня они такие:

1 INFO message1
2 ERROR message2

Т.е. Идентификатор на первом месте, затем INFO/ERROR, затем какое-то слово без пробелов.
Не сложно, но для понимания принципа работы хватит.

Итак, в секции filter, в плагине grok мы должны определить паттерн для разбора наших строк.

Выглядеть он будет так:

По сути, это регулярное выражение. Используются уже готовые паттерны, такие как INT, LOGLEVEL, WORD. Их описание, а также другие паттерны, можно посмотреть вот здесь

Теперь, проходя через этот фильтр, наша строка превратится в hash из трёх полей: message_id, message_type, message_text.

Именно они будут выводиться в секции output.

Описание работы с полями и операторами, можно посмотреть вот в этой секции официального мануала.

Эта статья является первой в серии статей по стеку Elasticsearch, Logstash, Kibana (ELK). Цикл статей ориентирован на тех, кто только начинает знакомится со стеком ELK, и содержит минимально необходимый набор знаний, чтобы успешно запустить свой первый кластер ELK.

В рамках данного цикла будут рассмотрены такие темы, как:

установка и настройка компонентов ELK,

безопасность кластера, репликация данных и шардирование,

конфигурирование Logstash и Beat для сборки и отправки данных в Elasticsearch,

визуализация в Kibana

запуск стека в Docker.

В данной статье будет рассмотрена процедура установки Elasticsearch и конфигурирование кластера.

План действий:

Скачиваем и устанавливаем Elasticsearch.

Запускаем и проверяем работоспособность кластера.

Делаем важные настройки.

Скачиваем и устанавливаем Elasticsearch

Существует множество вариантов установки Elasticsearch, под любые нужды и желания. С перечнем можно ознакомится на официальном сайте. Не смотря на то, что на своем стенде я использовал установку из Deb пакетов, считаю правильным так же описать установку из RPM пакетов и архива tar.gz для Linux системы.

Установка из Deb пакетов

Импортируем Elasticsearch PGP ключ:

Перед установкой пакета необходимо добавить репозиторий Elastic:

Устанавливаем Elasticsearch из пакета:

Настраиваем Elasticsearch для автоматического запуска при запуске системы:

Установка из RPM пакетов

Импортируем Elasticsearch PGP ключ:

В директории /etc/yum.repos.d/ создаем файл репозитория Elasticsearch elasticsearch.repo :

Устанавливаем Elasticsearch c помощью пакетного менеджера в зависимости от операционной системы, yum или dnf для CentOS , Red Hat , Fedora или zypper для OpenSUSE :

Установка из архива tar.gz

Скачиваем архив с Elasticsearch

Извлекаем данные из архива и переходим в каталог с Elasticsearch:

Текущий каталог считается, как $ES_HOME .

Конфигурационные файлы лежать в каталоге $ES_HOME/config/ .

На этом шаге установка из архива считается завершенной.

Для запуска Elasticsearch можно создать отдельного пользователя, предоставив все необходимые права к каталогу с Elasticsearch и указывая данного пользователя при настройке файловых дескрипторов.

Настраиваем кластер

На текущем этапе у нас есть три хоста с установленным Elasticsearch. Следующим и самым важным этапом является настройка каждого узла для объединения их в единый кластер.

Для настройки Elasticsearch используется YAML файл, который лежит по следующему пути /etc/elasticsearch/elasticsearch.yml при установке из Deb или RPM пакетов или $ES_HOME/config/elasticsearch.yml - при установке из архива.

Ниже будут приведены пример конфигурации для узла es-node01. Аналогичные настройки необходимо сделать на каждом узле, указав соответствующие имя и адрес.

Указываем имя узла и определяем роли. Укажем для узла роли master и data :

master Данная роль дает возможность узлу быть избранным, как управляющий узел кластера

data узел с данной ролью содержит данные и выполняет операции с этими данными
Со списком всех ролей узла можно ознакомится тут.

Настраиваем адрес и порт, на которых узел будет принимать запросы:

Если указать 0.0.0.0 или просто 0 , то Elasticsearch будет принимать запросы на всех интерфейсах.

Определяем имя кластера и начальный список узлов в голосовании по выбору master узла:

cluster.initial_master_nodes

При начальной загрузке кластера определяются узлы, участвующие в голосовании по выбору мастера, поэтому в новом кластере мы должны указать перечень этих узлов. Если данный параметр оставить пустым (по умолчанию), то узел будет ожидать подключения к уже созданному кластеру.
Данный параметр следует удалить после создания кластера и не использовать при добавлении новых узлов в существующий кластер.

Указываем список master узлов кластера:

До версии 7.0 в конфигурации Elasticsearch также использовался параметр discovery.zen.minimum_master_nodes , который можно увидеть и сейчас в некоторых конфигурациях. Этот параметр был необходим, чтобы защитится от Split Brain, и определял минимальное количество master узлов для голосования. Начиная с версии 7.0 данный параметр игнорируется, так как кластер автоматически защищает себя. Более подробно о том, как это работает, можно прочитать в данной статье.

Определяем, где будем хранить данные и логи

На выходе мы должны получить следующий конфигурационный файл:

При необходимости настраиваем межсетевой экран на хосте:

9300-9400 - порты (по умолчанию) для коммуникации между узлами кластера. Elasticsearch будет использовать первый свободный из данного диапазона (для настройки данного порта в Elasticsearch можно использовать параметр transport.port ).

Запускаем и проверяем

Запускаем на каждом узле службу elasticsearch :

Для установки из архива используем:

или если мы хотим запустить Elasticsearch как демон, то:

Для выключения службы используйте Ctrl-C для первого варианта запуска (из архива) или pkill -F pid для второго варианта.

После запуска первого узла в логах можно увидеть, что узел ожидает подключение других узлов, чтобы определить, кто возьмет роль master :

После включения остальных узлов в логах появится запись о том, что кластер собрался:

Проверяем состояние кластера, обратившись к любому его узлу:

Узнаем, какой узел взял на себя роль master . В нашем примере это узел es-node02 :

Делаем важные настройки

Для нормальной работы кластера необходимо произвести еще некоторые настройки.

Heap size

Так как Elasticsearch написан на Java, то для работы необходимо настроить размер «кучи» ( heap size ). В каталоге установки Elasticsearch имеется файл jvm.options , в котором уже указаны размеры, по умолчанию - это 1 Гб. Однако, для настройки рекомендуется указать новые параметры в файле каталога jvm.options.d , который находится там же.

Пример выше использует минимальный Xms и максимальный Xmx размер heap size , равный 16 Гб. Для настройки данных параметров следует использовать следующие рекомендации:

установите значения Xmx и Xms не более 50% от имеющейся физической памяти узла. Оставшуюся память Elasticsearch будет использовать для других целей. Чем больше heap size , тем меньше памяти используется под системные кеш;

устанавите значение не более того значения, которое использует JVM для сжатия указателей, он же compressed object pointers . Данное значение составляет около 32 Гб. Стоит также отметить, что рекомендуется ограничивать heap size еще одним параметром JVM , а именно zero-based compressed oops (обычно размер около 26 Гб). Узнать подробнее об этих параметрах можно тут.

Отключаем подкачку

Подкачка негативно сказывается на производительности и стабильности работы Elasticsearch, ведь система может выгрузить страницы JVM на диск. Есть несколько вариантов работы с подкачкой:

Полное отключение подкачки. Перезапуск Elasticseach при этом не требуется.

Ограничение подкачки через значение vm.swappiness=1 для sysctl .

Использование mlockall для блокировки адресного пространства в оперативной памяти.

Чтобы включить mlockall в конфигурации Elasticseach elasticsearch.yml указываем для параметра bootstrap.memory_lock значение true .

Перезапускаем Elasticsearch и проверяем настройки через запрос к любому узлу:

Если перезапуск Elasticsearch завершился ошибкой вида:

или проверка показывает, что данная настройка не применилась, необходимо сделать следующее в зависимости от способа установки:

Установка из архива

Установите ulimit -l unlimited перед запуском Elasticsearch или значению memlock устанвоите unlimited в файле /etc/security/limits.conf .

Установка из пакета RPM или Deb

Установите значение параметра MAX_LOCKED_MEMORY как unlimited в /etc/sysconfig/elasticsearch для rpm или /etc/default/elasticsearch для dep .

Если вы используете systemd для запуска Elasticsearch, то лимиты должны быть указаны через настройку параметра LimitMEMLOCK . Для этого выполните команду:

и укажите следующее значение:

Настройка файловых дескрипторов

Elasticsearch работает с большим количеством файловых дескрипторов, и их нехватка может катастрофически сказаться на его работе. Согласно официальной документации необходимо указать значение файловых дескрипторов не ниже 65 536.

Если Elasticsearch установлен из RPM или Deb пакетов, то настройка не требуется.

Для установки из архива необходимо в файле /etc/security/limits.conf установить параметр nofile для пользователя, который осуществляет запуск Elasticsearch. В примере ниже таким пользователем является elasticsearch :

Проверить установленные значения можно следующим образом:

Настройка виртуальной памяти

Elasticsearch по умолчанию использует каталог mmapfs для хранения индексов, и ограничение операционной системы по умолчанию для счетчиков mmap может привести к нехватки памяти. Для настройки запустите из-под root следующую команду:

Чтобы настройка сохранилась после перезапуска системы, необходимо указать параметр vm.max_map_count в файле /etc/sysctl.conf .

Если Elasticsearch установлен из RPM или Deb пакетов, то настройка не требуется.

Настройка потоков

Необходимо убедиться, что количество потоков, которые Elasticsearch может создавать, было не менее 4096.

Это можно сделать, установив ulimit -u 4096 или установив значение nproc равным 4096 в файле /etc/security/limits.conf .

Если Elasticsearch работает под управлением systemd , то настройка не требуется.

DNS кеширование

Временный каталог для JNA

Elasticsearch использует Java Native Access (JNA) для запуска кода, необходимого в его работе, и извлекает этот код в свой временный каталог директории /tmp . Следовательно, если каталог смонтирован с опцией noexec , то данный код невозможно будет выполнить.

В данном случае необходимо или перемонтировать каталог /tmp без опции noexec , или изменить настройку JVM , указав другой путь через опцию -Djna.tmpdir=<new_path> .

На этом шаге дополнительные настройки Elasticsearch окончены.

Заключение

Дойдя до этого места, вы должны иметь работоспособный кластер Elasticsearch.

В следующей статье будут описаны процедуры установки и настройки Kibana и Logstash. А в качестве проверки работоспособности кластера соберём данные из файла и посмотрим на них с помощью Kibana.

Еще материалы по теме

ACID-транзакции в Apache Hive: настройка, принципы работы и ограничения

Один на всех: реализация единого API для унифицированной аналитики больших…

PXF, Greenplum и оптимизация SQL-запросов к разным источникам данных

Новое на сайте

Отзывы на Google

Курсы от инженеров и для инженеров. Всё чётко, по делу. Тренеры глубоко знают продукты, о которых читают лекции. read more

Принимал участие в обучении по курсу "KAFKA: Администрирование кластера Kafka". В целом понравилось, но хотелось бы более качественной организации работы с лабгайдами. Когда лектор выполняет лабораторную работу, не совсем удобно выполнять её параллельно - где-то отстаешь, где-то убегаешь вперед. Может будет лучше разделить на более мелкие модули. read more

Прошел Курс Администрирование кластера Hadoop. Подача материала хорошая, размеренная. Преподаватель отвечает на все вопросы, и пытается как можно прозрачней приподнести материал. read more

Обучался на программе HADM. Подача материала доступная. Порадовало соотношение теории и практики 50/50. Отзывчивый преподаватель. Однозначно рекомендую. read more

Заканчиваю прохождения курса "ADH: Администрирование кластера Arenadata Hadoop". Хочу сказать, что выстроен грамотный план обучения, где отслеживается отличное соотношение практики и теории. Преподаватель, Комисаренко Николай, обладает отличным чувством юмора, что позволило не скучать на серьезных темах, и обладает отличным навыком объяснять сложные вещи простыми словами. На курс приходил с большим числом вопросов, на все из которых получил грамотные ответы, после чего все разложилось по полочкам. read more

В декабре 2020 прошел курс "Администрирование кластера Kafka". Курс проводился удаленно. В части организации обучения придраться не к чему. Необходимую информацию прислали заранее, лабораторный стенд и портал обучения работали стабильно. Немного разочаровали лабораторные работы. На месте BigDataSchool я бы их переделал. В документах с лабами нужно сделать нормальное форматирование и нумерацию пунктов. Все пункты, необходимые для выполнения, нужно сделать в виде текста. В лабах много работ по созданию «обвязки» kafka (создание самоподписных сертификатов, развертывание MIT и т.п), которые можно сделать заранее. Это позволит студентам уделять больше времени изучению самой kafka. BigDataSchool идет навстречу и позволяет пользоваться лабораторным стендом гораздо дольше установленных часов обучения. Это очень к стати, если в течении дня Вы вынуждены отвлекаться от обучения. В целом, курс дает хорошую базу по kafka. Преподаватель хорошо подает материал, делает акценты в нужных местах, подробно отвечает на вопросы. read more

С 30 ноября по 4 декабря прошел курс "Администрирование кластера Hadoop". Учитывая, что я обладал довольно поверхностной информацией в данной теме (я CIO) - ушел с курсов просветленным. Многое стало понятным, в процессе обучения наложил знания на существующую инфраструктуру компании, в которой работаю. Рекомендую коллегам руководителям в ИТ - прокачаться на данном курсе, вы поймете куда двигаться в ближайшие 2-3 года. Админам, работающим или стремящимся в BigData- обязательно! Рекомендация - настойчиво, для тех кто "думает, что знает": перед курсом уделите время работе с командной строкой Linux! Total recall - обязательное условие. Много практической работы, и если есть затык в Linux - будете безнадежно отставать при выполнении лабораторных работ. read more

В октябре прошел курс Анализ данных с Apache Spark, это был второй раз, когда я обучался в этом месте. В целом, все хорошо, думаю что не последний. Не могу не подчеркнуть профессионализм преподавателя Королева Михаила, отвечал на поставленные вопросы, делился своим опытом. В общем, рекомендую! read more

Прошел тут курс "NIFI: Кластер Apache NiFi", вёл Комисаренко Николай. Живое и понятное обучение. Преподаватель отвечал на все вопросы от самых глупых, до самых умных и это было приятно. Так же порадовало, что преподаватель не идёт по заранее проложенным рельсам, а проходит весь путь вместе с вами, стараясь привнести, что-то новое. read more

Спасибо за обучение!

Очень крутое место, много практики, понятное объяснение заданной темы. Еще вернусь :) read more

Обучался на курсе HADM администрирование кластера Arenadata Hadoop. Интересный курс, хорошая подача. read more

Обучался на курсе по администрированию Apache Kafka. Хорошая подача материала, интересные практические задачи. Возникающие вопросы доходчиво и ясно объясняют. Остался очень доволен. read more

Был на курсе "Администрирование кластера Hadoop". Отличная подача материала. Очень много практики и технических подробностей. Подробный обзор стека технологий, платформы и инструментов. Рекомендую! read more

Учился на курсе Администрирование Hadoop. Курс вёл Николай Комиссаренко. Отлично подготовленная, продуманная, системная программа курса. Практические занятия организованы так, что у студентов есть возможность познакомиться с реальными особенностями изучаемого продукта. Отключил голову и прощёлкал лабы по книжке - здесь не работает. Преподаватель легко и развёрнуто отвечает на возникающие вопросы не только по теме предмета, но и по смежным. read more

Прошёл курс по администрированию Apache Kafka. Очень понравилась как подача материала, так и структура курса. Только вот времени маловато оказалось. не всё успел доделать, но это уже не к курсу претензии :). Практики было довольно много, и это хорошо read more

Прошёл курс "Hadoop для инженеров данных" у Николая Комиссаренко. Информация очень актуальна и полезна, заставляет задуматься о текущих методах работы с большими данными в нашей компании и, возможно, что-то поменять. Занятия с большим количеством практики, поэтому материал хорошо усваивается. Отдельное спасибо Николаю за то, что некоторые вещи объяснял простым языком, понятным даже для "чайников" в области Hadoop. read more

I did not find any disadvantages in the course. Pluses: + A lot of practice (50% of the time). + The teacher can explain difficult topics easy way. + Announced topics were considered. Besides additional materials were studied. read more

Посетил курс администрирование Hadoop. На курсе устанавливали кластер с нуля на виртуалках в облаке Amazon. Настраивали Kerberos, тестировали выполнение задач на кластере, управление ресурсами кластера. Т.к. кластер развернут в облаке, после завершения занятий можно самостоятельно работать с кластером из дома. Лекции вел Николай Комиссаренко, после обучения предоставил все материалы. На занятиях отвечал на дополнительные вопросы, рассмотрели как решить пару живых задач от студентов. Хороший курс для начала изучения BigData. Update Дополнительно прошел обучения по Airflow и NiFi. Курсы двух дневные упор на занятиях делался на использовании продуктов, администрированию уделялось меньше времени. Т.к. курсы короткие, то перед занятиями желательно почитать обзорные статьи по продуктам, чтобы не терять время на базовое погружение и задавать более предметные вопросы. Перед началом занятий желательно связаться с школой и запросить что больше интересуется на обучении. Может быть предложить свои кейсы, чтобы на лабораторных отработать не только общий функционал. read more

Был на основах хадупа, все материалы описаны доступным языком. В частности хочу отметить преподавателя Николая Комисаренко, как очень квалифицированного преподавателя и специалиста. read more

Отличные курсы по "Администрированию Hadoop" и отличная организация проведения занятий, все по делу и понятно. Очень понравилось, знания получены основательные. Материал подаётся основательно. Постараюсь ещё попасть на другие курсы. read more

Курс по Isilon у Николая Комиссаренко мне тоже понравился. Грамотный и отзывчивый. Возникали вопросы по курсу он отвечал на все вопросы. Спасибо. Успехов ему read more

Эффективный практический курс. Прошел курс Администрирование Hadoop в октябре 2018. Хорошо наполненный материал, оптимальная длительность курса и все делалось своими руками. Местами было непросто, но преодолимо. Оправдал все ожидания, после курса появилось целостное понимание создания и работы кластера. Николай, большое спасибо read more

Прошёл курс по администрированию Hadoop Cloudera. Отличная "живая" подача материала на "простом" языке. Как плюс работа с кластером построена на платформе AWS. На курсах не скучно, рекомендую! read more

Я узнал много нового посетив курс уважаемого Николая Комиссаренко по айзелону. Очень грамотный специалист обучение было очень полезным и грамотным. Спасибо вам большое read more

Related Entries

Новое на сайте

Отзывы на Google

Спасибо за обучение!

Очень крутое место, много практики, понятное объяснение заданной темы. Еще вернусь :) read more

Обучался на курсе HADM администрирование кластера Arenadata Hadoop. Интересный курс, хорошая подача. read more

Читайте также: