Поздравления всем! Я работаю системным инженером в компании «Онланта» .
В одном из наших проектов я занимался внедрением и сопровождением Elastic Stack. Мы перешли от сбора журналов практически вручную к централизованному автоматизированному процессу.
Вот уже два года мы практически не меняем архитектуру решения и планируем использовать удобный инструмент в других проектах.
В этом посте я делюсь с вами историей его внедрения, а также некоторыми его сильными и слабыми сторонами.
Источник
В начале 2016 года у наших администраторов и разработчиков логи были, что называется, «под рукой», то есть для работы с ними инженер, подключавшийся по SSH к хосту, на котором находился интересующий его сервис, раскопал универсальный набор Tail/grep/sed/awk и надеялся, что необходимые данные можно будет найти на этом хосте.
Источник
Еще у нас был отдельный сервер, куда все каталоги с логами со всех серверов монтировались через NFS, и который иногда долго думал, что все на нем делают с логами.
Ну а tmux с несколькими панелями, идущими хвостом по каким-то активно обновляющимся логам, выглядел для сторонних наблюдателей на большом мониторе очень эффектно и создавал захватывающую атмосферу сопричастности к тайнам производства.
Все это даже работало, но только до тех пор, пока не нужно было быстро обработать большой объем данных, а требовалось это чаще всего в моменты, когда в продукте уже что-то пошло не так.
Иногда на расследование инцидентов уходило совсем неприличное количество времени.
Значительная часть ушла на ручную агрегацию логов, прогон различных скриптов на Bash и Python, ожидание загрузки логов куда-нибудь для анализа и т.д. Словом, все это было очень медленно, вызывало уныние и явно намекало, что пора заняться централизованным хранением логов.
Честно говоря, сложного процесса отбора кандидатов на роль технологического стека, который бы нам это обеспечил, не было: связка ELK уже была популярна на тот момент, имела хорошую документацию и было большое количество статей по Интернет на всех компонентах.
Решение было немедленным: надо было попробовать.
Источник
Самая первая установка стека была сделана после просмотра вебинара «Logstash: 0-60 из 60» на трех виртуальных машинах, на каждой из которых мы запускали экземпляр Elasticsearch, Logstash и Kibana.
Далее мы столкнулись с некоторыми проблемами при доставке логов с конечных хостов на серверы Logstash. Дело в том, что на тот момент Filebeat (стандартное стековое решение для доставки логов из текстовых файлов) гораздо хуже работал с большими и быстро обновляемыми файлами, регулярно терял оперативную память и в нашем случае вообще не справлялся со своей задачей.
К этому добавлялась необходимость найти способ доставки журналов сервера приложений с машин под управлением IBM AIX: основная часть наших приложений тогда работала на WebSphere Application Server, который работал именно под этой ОС.
Filebeat написан на Go; более-менее работоспособного компилятора Go для AIX в 2016 году не было, а использовать Logstash в качестве агента доставки очень не хотелось.
Мы протестировали несколько агентов для доставки логов: Filebeat, logstash-forwarder-java, лог-курьер , питон-бобер и NXLog. От агентов мы ожидали высокой производительности, низкого потребления системных ресурсов, простой интеграции с Logstash и возможности выполнять базовые манипуляции с данными агента (например, сборку многострочных событий).
Отдельно стоит сказать про сборку многострочных событий.
Эффективно это можно сделать только на стороне агента, читающего конкретный файл.
Несмотря на то, что в Logstash когда-то был многострочный фильтр, а теперь есть многострочный кодек, все наши попытки совместить балансировку событий на нескольких серверах Logstash с многострочной обработкой на них не увенчались успехом.
Такая конфигурация делает эффективную балансировку событий практически невозможной, поэтому для нас едва ли не самым важным фактором при выборе агентов была поддержка многопотокости.
Победители распределились следующим образом: log-courier для машин с Linux, NXLog для машин с AIX. С такой конфигурацией мы прожили почти год без проблем: логи доставлялись, агенты не падали (ну почти), все были довольны.
В октябре 2016 года была выпущена пятая версия компонентов Elastic Stack, включая Beats 5.0. В этой версии была проделана большая работа над всеми агентами Beats, и мы смогли заменить log-courier (у которого к тому времени были свои проблемы) на Filebeat, которым мы пользуемся до сих пор.
Когда мы перешли на версию 5.0, мы начали собирать не только логи, но и некоторые метрики: Packetbeat стал кое-где использоваться как альтернатива записи логов HTTP-запросов в файлы, а Metricbeat собирал системные метрики и метрики некоторых сервисов.
К этому времени работа наших инженеров с логами значительно упростилась: теперь не нужно было знать, на какой сервер зайти, чтобы просмотреть интересующий вас лог, обмен найденной информацией упростился до простой отправки ссылка на Кибану в чатах или почте, а отчеты, которые раньше строились за несколько часов, теперь стали создаваться за несколько секунд. Нельзя сказать, что это был просто вопрос комфорта: мы заметили изменения в качестве нашей работы, в количестве и качестве решаемых задач, в скорости реагирования на проблемы на наших стендах.
В какой-то момент мы начали использовать утилиту ElastAlert от Yelp для рассылки оповещений инженерам.
И тогда мы подумали: а почему бы не интегрировать его с нашим Zabbix, чтобы все оповещения имели стандартный формат и отправлялись централизованно? Решение было найдено довольно быстро: ElastAlert позволяет выполнять любые команды вместо отправки реальных оповещений, чем мы и воспользовались.
Теперь наши правила ElastAlert при срабатывании выполняют bash-скрипт из нескольких строк, которому в качестве аргументов передаются необходимые данные из события, вызвавшего срабатывание правила, а из скрипта, в свою очередь, вызывается zabbix_sender, который отправляет данные в Zabbix для нужного узла.
Поскольку вся информация о том, кто и где сгенерировал событие, всегда доступна в Elasticsearch, сложностей с интеграцией не возникло.
Например, ранее у нас был механизм автоматического обнаружения серверов приложений WAS, и события, которые они генерируют, всегда записывают имя сервера, кластера, ячейки и т. д. Это позволило нам использовать параметр query_key в правилах ElastAlert, чтобы условия правила обрабатывались отдельно для каждого сервера.
Скрипт с zabbix_sender затем получает точные «координаты» сервера и данные отправляются в Zabbix для соответствующего узла.
Еще одно решение, которое нам очень нравится и которое стало возможным благодаря централизованному сбору логов — скрипт автоматического создания задач в JIRA: раз в день он вычищает из логов все ошибки и, если задач для них еще нет, создает их.
При этом из разных индексов по уникальному идентификатору запроса в задачу подтягивается вся информация, которая может оказаться полезной в ходе расследования.
В результате получается некая стандартная заготовка с необходимым минимумом информации, которую инженеры затем при необходимости могут дополнить.
Разумеется, перед нами встал вопрос мониторинга самого стека.
Частично это реализовано с помощью Zabbix, частично с помощью того же ElastAlert, а основные метрики производительности для Elasticsearch, Logstash и Kibana мы получаем с помощью стандартного встроенного в стек мониторинга (компонент Monitoring в X-Pack).
Также на самих серверах со стековыми сервисами мы установили сетевые данные от Файерхола.
Это может быть полезно, когда вам нужно увидеть, что происходит с конкретной нодой прямо сейчас, в реальном времени и с высоким разрешением.
Когда-то модуль мониторинга Elasticsearch был слегка сломан, мы его нашли, исправили, добавили всяких полезных метрик и сделали пул-реквест. Таким образом, теперь netdata может отслеживать последние версии Elasticsearch, включая базовые метрики JVM, показатели производительности индексирования и поиска, статистику журнала транзакций, сегменты индекса и т. д. Нам нравится Netdata, и мы рады, что смогли внести в нее небольшой вклад.
Сегодня, почти три года спустя, наш Elastic Stack выглядит примерно так: 
Инженеры работают со стеком тремя основными способами:
- просмотр и анализ логов и метрик в Kibana;
- дашборды в Grafana и Kibana;
- прямые запросы к Elasticsearch с использованием SQL или встроенного DSL запросов.
На каждом горячем узле Elasticsearch работает экземпляр Kibana. Так было с самого начала, и до сих пор у нас не было необходимости переносить Kibana на отдельные машины.
А вот решение о переносе Logstash на отдельные машины оказалось, пожалуй, одним из самых правильных и эффективных при работе стека: высокая конкуренция за процессорное время между JVM Elasticsearch и Logstash приводила к не очень приятным спецэффектам во время скачков нагрузки.
Больше всего пострадали сборщики мусора.
Источник
В кластере мы храним данные за последние 30 дней: сейчас это около 12 миллиардов событий.
Ежедневно «горячие» ноды записывают на диск 400-500ГБ новых данных с максимальной степенью сжатия (включая данные из шардов-реплик).
Наш кластер Elasticsearch имеет горячую/теплую архитектуру, но мы перешли на нее сравнительно недавно, поэтому «теплые» узлы по-прежнему хранят меньше данных, чем «горячие» узлы.
Наша типичная загруженность в рабочее время:
- индексация – в среднем 13 000 rps с пиками до 30 000 (без учета индексации в шарды-реплики);
- поиск – 5200 об/с.
Около 50% оперативной памяти на хостах с узлами Elasticsearch всегда доступно для страничного кэша и потребностей JVM вне кучи.
За время, прошедшее с момента запуска первого кластера, нам удалось выявить для себя некоторые положительные и отрицательные стороны Elastic Stack как средства агрегации журналов и поисково-аналитической платформы.
Что нам особенно нравится в стеке:
- Единая экосистема продуктов, хорошо интегрированная друг с другом, содержащая практически все необходимое.
Биты когда-то были не очень хорошими, но сейчас к ним претензий нет.
- Logstash, при всей своей чудовищности, является очень гибким и мощным препроцессором и позволяет многое сделать с необработанными данными (а если он не позволяет что-то сделать, всегда можно написать сниппет на Ruby).
- Elasticsearch с плагинами (а в последнее время и из коробки) поддерживает SQL как язык запросов, что упрощает его интеграцию с другим программным обеспечением и людьми, которым SQL как язык запросов ближе.
- Качественная документация, позволяющая быстро вовлекать новых сотрудников в работу над проектом.
«Поэтому эксплуатация стека не становится делом одного человека, обладающего каким-то специфическим опытом и «тайными знаниями».
- Не нужно заранее много знать о структуре получаемых данных, чтобы начать их собирать: можно начать агрегировать события такими, какие они есть, а затем, как поймете, какую полезную информацию из них можно извлечь, изменить подход к их обработку без потери «обратной совместимости».
Для этого в стеке есть множество удобных инструментов: псевдонимы полей в индексах, скриптовые поля и т.д.
Источник Что нам не нравится:
- Компоненты X-Pack распространяются только по модели подписки и никак иначе: если Gold, например, поддерживает только отчеты RBAC или PDF, то за все, что есть у Gold, придется платить.
Особенно это расстраивает, когда, например, из Platinum вам нужен только Graph, а вдобавок вам предлагают приобрести Machine Learning и кучу другого функционала, который вам может быть и не особо нужен.
Наши попытки около года назад связаться с отделом продаж Elastic по поводу лицензирования тех или иных компонентов X-Pack ни к чему не привели, но, возможно, с тех пор что-то изменилось.
- Довольно частые релизы, в которых каким-то образом (каждый раз новым) ломают обратную совместимость.
Необходимо очень внимательно читать список изменений и заранее готовиться к обновлениям.
Каждый раз вам нужно выбирать: остаться на старой версии, которая работает стабильно, или попытаться обновиться для получения новых функций и прироста производительности.
отказаться от них сейчас.
В нашей компании также открыт ряд вакансий.
- Руководитель экспертной группы
- Руководитель группы экспертов (Windows)
- Инженер по сетевой информационной безопасности
- Менеджер по предпродажной подготовке (облачные сервисы)
-
Ноутбуки Создают Связь На Подиуме
19 Oct, 24 -
Карты Google Не Работают
19 Oct, 24 -
Новая Функция Notion И 3 Приложения
19 Oct, 24 -
Чистка Разъема Vga На Видеокарте
19 Oct, 24 -
10 Лучших Инструментов Тестирования Api
19 Oct, 24
