Всем привет! Меня зовут Юрий, я руковожу группой прикладной разработки в департаменте мультивендорных решений и экспертизы YADRO. Мы занимаемся развитием собственного сервисного инструмента «Гегелло», который позволяет работать с диагностическими данными различного оборудования и визуализировать проблемы в системах.
Какую задачу решает платформа, почему это не просто «Grafana у нас дома» и что в основе архитектуры «Гегелло» — читайте в статье.
Предпосылки появления «Гегелло»
Мой коллега Артём Смирнов уже рассказывал про наш департамент — это особое сервисное подразделение третьей линии технической поддержки YADRO. Мы отвечаем за обслуживание сложных инфраструктур, зачастую состоящих из оборудования и ПО разных вендоров. Обычно вендоры не распространяют инструменты для анализа состояния своих систем и продвигают собственное сервисное обслуживание. У некоторых производителей даже есть ряд ограничений, чтобы оборудование обслуживалось только в специализированных сервисных центрах штатными инженерами.
Сложные инциденты часто связаны с неисправностями оборудования и/или ПО разных вендоров. В результате они затрагивают и наши продукты, работающие в той же инфраструктуре. Поэтому нам была нужна система, которая позволила бы следить за состоянием довольно сложного набора оборудования за счет сбора, обработки логов и различных визуализаций. Наша задача состояла в создании репрезентативной и удобной визуализации обслуживаемого оборудования для сервисных инженеров.
Как и любая подобная внутренняя некоммерческая система, «Гегелло» развивалась постепенно с ростом пользовательских сценариев и с учетом доступных ресурсов. Поскольку в разработке учитывались особенности оборудования и пожелания сервисных инженеров, степень требуемой визуализации для каждого оборудования разная. Для каких-то систем это просто вывод работы диагностического скрипта, а для других это несколько вкладок с разбиением на подсистемы, визуализацией топологии соединений, автоматической проверкой десятков внутренних параметров и компонентов для быстрого поиска событий.
Такая широкая функциональность обусловлена разными требованиями. Одним инженерам достаточно распаковать архив с логами, чтобы проверить состояние оборудования с помощью скриптов для командной строки, а другим нужна 3D-визуализации оборудования с подсветкой проблем.
Что удалось сделать?
Вот как может выглядеть один из 3D-рендеров в системе. На демо одна из пяти полок в СХД работает неисправно:
Кликаем на неисправную систему и попадаем на следующую визуализацию:
Вентилятор 1 вышел из строя. Сервисному инженеру проще локализовать проблему — он быстрее реагирует на неисправности.
Мы решили сделать 3D-визуализацию, чтобы ускорить определение источника неисправности и снизить вероятность ошибок инженера при диагностике. Вот что им помогает:
Общий вид: характеристики оборудования некоторых производителей распределены по разным файлам — анализ данных довольно сложный и занимает много времени.
Наглядность: визуализация помогает понять, где в стойке находится блок относительно основного, где и как нужно будет провести ремонт.
Удаленный доступ: инженер удаленной поддержки, который анализирует сервисную информацию на экране, и выездной инженер, который находится перед оборудованием, быстрее понимают друг друга.
Всех, кто хотел бы протестировать «Гегелло» — поработать с визуализацией и поучаствовать в решении сложных амбициозных задач — мы зовем к себе в команду. Сейчас открыты вакансии:
Теперь расскажу, как мы реализовали систему, какой стек технологий выбрали и почему.
С чего все начиналось и как система обрела текущий вид
«Гегелло» — это внутренняя платформа для сбора, обработки и анализа логов с различного оборудования. Она автоматически принимает диагностические данные из разных источников, распознает их формат, извлекает нужную информацию, приводит ее к единому виду и предоставляет инженерам инструменты для анализа. Платформа появилась как ответ на рост количества систем, с которыми приходилось работать службе технической поддержки, и постепенно превратилась из вспомогательного инструмента в единую среду диагностики.
История началась с двух собственных парсеров логов — для наших продуктов и внешних систем. Чтобы не дублировать работу с файлами, мы вынесли загрузку, хранение и распаковку логов в отдельный сервис uploader. Он принимал архивы, сохранял их, передавал нужному парсеру и возвращал ссылку на результаты обработки. Для uploader был разработан отдельный графический интерфейс и настроена распределенная файловая система, обеспечивающая всем парсерам доступ к загруженным данным.
Число обработчиков логов с внешнего оборудования постепенно росло. Для каждого нового типа данных появлялись отдельные обработчики и сервисы визуализации. В какой-то момент их стало шесть. Хотя все они использовали общий uploader, сами сервисы были реализованы на разных языках программирования и фреймворках. Это усложняет развитие функциональности и исправление ошибок. Поскольку принципы обработки логов во всех случаях были схожими, мы решили объединить их в единую платформу.
Название выбрали в соответствии с традицией компании. Многие наши продукты названы в честь архитекторов-конструктивистов: серверы — в честь Георгия Вегмана, системы хранения данных — в честь Владимира Татлина. Новая платформа получила имя Александра Гегелло — советского архитектора, одного из ведущих мастеров ленинградского конструктивизма.
Сегодня «Гегелло» анализирует данные с систем хранения, серверов, коммутаторов различных производителей, операционных систем и инструментов нагрузочного тестирования. Логи могут поступать автоматически из внутреннего хранилища файлов, загруженных заказчиками в рамках сервисных обращений, или инженеры могут загружать их напрямую в «Гегелло».
После загрузки платформа автоматически распаковывает архивы, определяет тип данных, выбирает подходящий обработчик, извлекает необходимую информацию и преобразует ее во внутренний формат. Затем показатели сравниваются с референсными значениями для соответствующего оборудования. Если параметры выходят за допустимые пределы, система автоматически выделяет их как потенциальные аномалии.
Сейчас мы разрабатываем возможность настраивать такие пороги вручную, чтобы инженеры могли адаптировать проверки под особенности конкретной инфраструктуры и уменьшить количество ложных срабатываний.
Визуализация сетевых топологий
Одна из важных фичей «Гегелло» — визуализация сложных сетевых топологий. Система поддерживает топологию Infiniband, технологию связи с минимальными задержками, которая используется для создания высокопроизводительных кластеров, а также SAN, ориентированную на высокоскоростную передачу данных от серверов к СХД. Обе технологии подразумевают создание больших сетей из десятков тысяч устройств, из-за этого отображение всех элементов таких сетей становится сложной задачей.
Мы группируем элементы сети по типам и другим параметрам, чтобы представить анализируемые элементы сети иерархически — так инженеру проще разобрать конкретную ситуацию.
Рассмотрим пример для сети типа SAN, которая состоит из четырех физических коммутаторов, каждый из них имеет 768 портов. Это значит, что к этой сети может быть подключено около 3000 устройств. Визуализация позволила нам виртуально рассортировать коммутаторы по фабрикам, а внутри каждой распределить порты по слотам. Для рассмотрения определенной части топологии достаточно открыть нужный слот — не надо тратить время на анализ всей топологии.
Конкретно на этом примере конечные устройства — сервера и СХД — скрыты, но пользователь может добавить их отображение в топологию отдельно.
Стек и подход к разработке
Изначально созданием uploader и новых парсеров занимались инженеры технической поддержки. Так как разработка не была их основным профилем, они выбрали языки программирования с меньшим порогом входа — Python и JavaScript.
Когда мы решили объединить наработки в одной системе, наняли несколько стажеров-разработчиков для создания универсального веб-приложения на React и переноса существующих парсеров на Go. React мы выбрали, так как это самый распространенный фреймворк для веб-разработки, а Go — из-за быстродействия и меньшего веса собираемых пакетов, что было важно из-за активного роста платформы.
Был выстроен новый CI/CD, который тестирует, проверяет безопасность, собирает и доставляет код в одно из трех окружений:
На тестовом окружении нет чувствительных или важных данных, и разработчики могут опробовать любые свои наработки.
На стейдж-окружении код тестируется на копии продуктовых данных.
В продуктовом окружении все сервисы доступны инженерам.
Мы продолжаем добавлять новые сервисы в платформу «Гегелло»:
Можем взять уже существующий сервис, написанный кем-то из инженеров YADRO. Он приводится к стандартам безопасности и нашей кодовой базы, а потом запускается в нашем контуре.
Можем подготовить собственный сервис, на который есть спрос. Разработчики пишут его, изучая документацию по теме и плотно взаимодействуя с инженерами из области. Например, когда Infiniband стал пользоваться спросом на рынке, мы предложили экспертизу для построения и диагностики сетей такого типа.
Как сервисные инженеры используют систему
Работая над инцидентом, большинство заказчиков хотят контролировать отправку данных со своего оборудования. Поэтому в технической поддержке YADRO используется общий процесс по работе с инцидентами:
сервисный инженер проводит предварительный анализ обращения,
запрашивает у клиента необходимую для дальнейшего анализа информацию,
отправляет заказчику инструкции по сбору файлов и их загрузке на сервисный портал.
После загрузки «Гегелло» подтягивает эти файлы, обрабатывает и отправляет ссылку на результаты в систему ведения заявок. Инженер по ссылке может быстро найти результаты обработки, формируя по ним ответ и решение.
В зависимости от типа оборудования можно уточнить текущую аппаратную конфигурацию, события, взаимосвязи с другим оборудованием, историю загрузок логов. На вкладках отображается статус проверок, таким образом можно быстро перейти к разделу, где были обнаружены отклонения.
Сейчас «Гегелло» визуализирует данные, собранные с отдельных устройств, и позволяет ретроспективно изучать информацию о них. В дальнейшем мы хотим добавить отображение связей между компонентами инфраструктуры, чтобы инженер мог прямо в интерфейсе переходить от операционной системы к серверу, коммутатору или СХД и анализировать их взаимосвязи.
Журналы и диагностические данные из разных систем предварительно приводятся к единому формату и сохраняются в общей базе данных. Во время обработки также добавляются дополнительные теги, которые позволяют фильтровать данные и облегчают поиск. В основе анализа лежит загруженный пользователем файл — чаще всего архив с диагностическими данными. Если его формат распознается как известный, система извлекает идентификатор устройства, например серийный номер сервера, на котором работает операционная система. Для виртуальных машин задача несколько сложнее, однако в большинстве случаев также удается получить уникальные идентификаторы.
Используя идентификатор системы, мы формируем историю всех загруженных данных по этому устройству. Это позволяет отслеживать его состояние во времени. Так можно сформировать ссылку, содержащую тип системы, ее идентификатор и временную метку, и сразу открыть нужный результат обработки. В дальнейшем этот же механизм станет основой для навигации между связанными объектами инфраструктуры.
По мере роста инфраструктур инженерам приходится анализировать все больше разрозненных данных: журналы, метрики, результаты тестов, сведения о конфигурации оборудования. Наша задача — собрать эту информацию в одном месте, связать ее и сделать анализ сервисных инцидентов быстрее и удобнее. Именно в этом направлении «Гегелло» продолжает развиваться.
А как подобные задачи решаются у вас? Используете готовые инструменты, разрабатываете собственные или комбинируете оба подхода? Будет интересно обсудить ваш опыт в комментариях.