Обсуждаем изменения в лицензионной политике для ключевых составляющих ELK-стека — Elasticsearch и Kibana. Что нужно знать об истории Elastic и лицензиях компании, оставляют ли они простор для кастомизации решений на основе стека, и как выглядят такие продукты. Disclaimer: материал не является юридической консультацией.

Фотография Kelly Sikkema / Unsplash license — *Фотография* *Kelly Sikkema / Unsplash license*

Как собирали стек

Составляющие ELK-стека — Elasticsearch, Logstash и Kibana — исторически развивались как самостоятельные решения. Прототип первого вышел в середине нулевых под названием Compass, а его единственным разработчиком был Шей Бэнон. Он спроектировал компактную систему для поиска рецептов, которой пользовалась его супруга, проходившая обучение в лондонском филиале одной из крупнейших кулинарных школ мира Le Cordon Bleu. В процессе развития Compass Бэнон столкнулся с проблемой масштабирования проекта, сложностями с обработкой больших объемов данных и задействовал библиотеку Lucene (ее разработал Дуг Каттинг в 1999 году).

К тому моменту, как Шей использовал ее, библиотека распространялась под открытой лицензией Apache. Lucene позволяла производить высокоскоростную индексацию данных на общедоступном оборудовании и предоставляла широкие возможности для поиска по сформированным индексам, в том числе с учетом метаданных. Функционал библиотеки лег в основу новой разработки Бэнона, которую он представил open source сообществу под названием Elasticsearch в начале 2010 года.

Решение, поддерживающее эффективный поиск и управляемое сегментирование поисковых индексов, получило широкую поддержку и привлекло интерес разработчиков. В течение нескольких месяцев с момента анонса Шей открыл одноименную компанию вместе с тремя контрибьютерами Elasticsearch. За год с небольшим коллектив пополнился разработчиками, которые отвечали за другие составляющие стека — Logstash и Kibana.

Джордан Сиссель привнес в проект экспертизу по извлечению, преобразованию и загрузке данных, реализованную в Logstash. Это — серверный конвейер дата-парсинга, позволяющий работать с разнообразными источниками данных: например, принимать программные логи и помещать результаты преобразования данных в хранилище. Третий компонент ELK под названием Kibana, отвечающий за визуализацию с помощью диаграмм и графиков, представил практически в одно время с коллегами Рашид Кан, органично дополнив стек интерфейсом для анализа содержимого индексов Elasticsearch.

Обновленная команда основала компанию Elastic в 2012 году. Долгое время она распространяла ELK по лицензии Apache License 2.0, разрешающей изменять код и свободно использовать стек, в том числе в коммерческих проектах. Однако в 2021 году политика организации изменилась. В Elastic активнее занялись коммерциализацией разработок — выработали единую стратегию развития продуктов и взяли за основу подписную модель с учетом потребляемых ресурсов.

Приоткрытая калитка

Новая политика компании — это реакция на избыточное — по мнению команды — использование составляющих стека as is в рамках облачных платформ. В Elastic посчитали, что cloud-вендоры вроде AWS по сути перепродавали решения компании как услугу, не участвуя в развитии ELK-экосистемы [ответ AWS].

Есть мнение, что AWS еще и фактически нарушили требования действовавшей тогда Apache License 2.0, не предоставлявшей разрешение на коммерческое использование торговой марки Elastic, и ввели в заблуждение пользователей облачной платформы относительно возможного сотрудничества с компанией.

Для Logstash лицензию оставили прежней. Это — Elastic License v1 (ELv1), которая по сути представляет собой Apache License 2.0. Для Elasticsearch, начиная с версии 7.11, и Kibana подход отличается. В Elastic ввели две лицензии на выбор: ELv2 и Server Side Public License (SSPL). Обе подразумевают ограничения.

Первая запрещает распространение конфигураций, содержащих «существенный» объем функциональных возможностей исходного продукта, в формате управляемых сервисов (managed service). Помимо этого — запрещает менять или скрывать информацию о лицензионном ключе Elastic, прятать обозначения копирайта и торговые марки компании.

При этом в FAQ на сайте Elastic используется формулировка «offering the product as a service», а текст ELv2 не уточняет понятие управляемых сервисов. Такой подход может говорить о том, что потенциально под ограничения соответствующего пункта может попасть как SaaS-продукт, предоставляющий пользователям существенные возможности стека на коммерческой основе, так и условная no-code платформа, предлагающая различные управляемые сервисы. Например, для автоматического развертывания инфраструктуры под задачи заказчика и работы исключительно с его данными.

Отличие SSPL от ELv2 заключается в том, что Server Side Public License дает свободу дистрибуции коммерческих решений на основе Elasticsearch и Kibana в рамках copyleft-подхода. И допускает это даже при использовании существенного объема функциональных возможностей исходника, но требует публикации полного исходного кода таких решений под open source лицензией.

По умолчанию новые версии Elasticsearch и Kibana будут выходить под Elastic License. Но компания не собирается отказываться от альтернативного варианта с SSPL, опираясь на опыт коллег из MongoDB, предложивших исходную редакцию лицензии в качестве развития General Public License. Однако подход разработчиков ELK-стека устраивает далеко не всех представителей рынка.

Реакция на изменения

Представители Open Source Initiative (OSI) — через некоторое время после анонса новой политики Elastic — опубликовали разъяснения о принадлежности Elasticsearch и Kibana к открытому программному обеспечению. В организации пришли к выводу о том, что действия компании не согласуются с принципами распространения open source решений, а SSPL не годится для таких задач. К оценкам OSI и критике Elastic присоединились AWS, долгое время использовавшие составляющие стека в проекте Open Distro. Облачный провайдер закрыл его в прошлом году и выпустил открытую альтернативу под названием OpenSearch на основе форка Elasticsearch версии 7.10.2, распространявшейся под Apache 2.0, помимо этого — заменил Kibana на OpenSearch Dashboards.

Есть мнение, что OpenSearch уже сейчас предлагает более широкие возможности — например, в контексте управления доступом — по сравнению с «бесплатным» Elasticsearch. Такие оценки и тренд на развитие альтернатив могут снизить эффект от усилий Elastic по «защите» от избыточного использования продуктов компании as is в коммерческих целях и ослабить настрой команды на активную коммерциализацию широкой части функциональных возможностей стека.

Представители Elastic ограничились короткими разъяснениями о том, что команда продолжит поддерживать собственные открытые проекты и ключевые open source решения, лежащие в основе стека, такие как Apache Lucene. Компания сообщила, что изменения в лицензионной политике не затронут разработчиков плагинов для Elasticsearch и Kibana, а использовать незначительную часть функциональных возможностей составляющих ELK-стека лицензия ELv2 все-таки позволяет: допустим, добавить поисковую строку и дешборды в SaaS-продукт или настроить Elasticsearch и Kibana для заказчика — например, если вы разворачиваете для него ad hoc решение не с помощью конфигураций и не в автоматизированном формате. Однако в процессе проектирования продукта и инфраструктуры для обработки данных стоит опираться на актуальное содержание лицензий, а не на FAQ вендоров программного обеспечения.

В целом ситуация с обновлением лицензионной политики Elastic не представляет собой исключительное событие для ИТ-рынка, но она подкрепляет тренд на коммерциализацию устоявшихся открытых решений и является еще одним примером перехода из категории «open source» в «source available». Для тех, кто проектирует коммерческие продукты и сервисы, использующие ключевые возможности ELK-стека, это новые правила игры. Кстати, одни из первых с ними согласились некоторые российские облачные провайдеры, договорившись с Elastic о партнерстве в рамках managed service. Не стали сразу же отказываться от ELK и те, кто использовал стек для инхаус-разработок в отвязанном от внешнего мира формате. Нашлись и примеры компаний, которые продолжили развивать самостоятельные продукты на основе составляющих стека.

Примеры с Kibana

Инструмент позволяет использовать стандартные графики и средства для представления данных «из коробки» — визуализировать контент индексов, фильтровать его на лету и делать запросы с помощью Kibana Query Language. Для классического варианта использования — анализа логов — в Elastic предусмотрели специальные дешборды. Например, для Kubernetes-кластеров можно отслеживать «здоровье» инфраструктуры. На Хабре есть базовые руководства по настройке Kibana для подобных задач.

Кастомизация и управление продуктами, построенными на основе Kibana, это — отдельная история. За пределы стандартных возможностей выходят многие организации, использующие в том числе специальные плагины, позволяющие менять лого на загрузке KIbana, форму авторизации, цветовую схему, шрифты и упрощать настройку дешбордов. В основном такие возможности используют для адаптации внутренних продуктов к корпоративному стилю. Но есть и примеры глубокой кастомизации для коммерческих Kibana-based решений. Один из наиболее заметных выходит под названием Skedler. Продукт представляет собой существенную доработку «коробки» — допустим, предлагает сэнки-диаграммы и более дружественный интерфейс для нетехнических пользователей. Также в Skedler внедрили плагин для формирования отчетов.

Экран с навигацией по пространству с дешбордами в Skedler — *Экран* *с навигацией по пространству с дешбордами в Skedler*

Меню выбора инструмента для визуализации данных в Skedler — *Меню* *выбора инструмента для визуализации данных в Skedler*

Вариант продукта с пред. настроенным функционалом предложили авторы системы для сетевого мониторинга SELKS. Интерфейс для идентификации угроз позволяет изучать уведомления и соответствующие метаданные, а дешборды — содержимое pcap-файлов.

Интерфейс для идентификации сетевых угроз — *Интерфейс* *для идентификации сетевых угроз*

Помимо кейса с разработкой Grafana на основе форка Kibana есть и другие примеры кастомизации инструмента. Так, в 2015 году IBM представили интерфейс для анализа логов сервиса контейнеризации на своей облачной платформе. Kibana используют и адаптируют в исследовательских организациях, используют для аналитических проектов.

Мы регулярно изучаем возможности открытых решений, специализированных инструментов и расширяем экспертизу команды, в том числе в области машинного обучения и обработки текстов на естественном языке. Наша система интеллектуального анализа больших данных iFORA позволяет не только сотрудникам института, но и многим компаниям воспользоваться преимуществами автоматизированной аналитики для анализа технологических трендов, выявления центров компетенций, оценки рынков и проектного управления.
Однако наши партнеры сегодня интересуются не только аналитикой, но и возможностями по разработке тематических ИТ-проектов — например, специализированных ML-моделей — для последующего внедрения на своей стороне в рамках собственной ИТ-инфраструктуры»

Константин Вишневский

директор Центра стратегической аналитики и больших данных ИСИЭЗ НИУ ВШЭ

К слову, проектировать и развивать продвинутые аналитические инструменты можно с помощью совместимого с Kibana языка для описания и конфигурирования шаблонов визуализаций под названием Vega. Например, его поддерживает Wikipedia, а продукты с дешбордами на Vega интересны сами по себе.

Проекты и визуализации на основе Vega — *Проекты и визуализации на основе* *Vega*

Что дальше

Экосистема, построенная ИТ-сообществом вокруг ELK-стека, уникальна, и перемены в политике лицензирования отдельных продуктов Elastic скорее всего не отразятся на активности энтузиастов. Однако переход в статус «source available» все-таки повлиял на управление продуктами с использованием открытых решений. Если у вас есть личный опыт в этой области, делитесь в комментариях и взгляните на опрос под материалом.

Неклассические лицензии на открытое ПО и управление продуктами: разбираем кейс стека ELK