Несколько раз в год MongoDB Engineering (кстати, вы проверяли MongoDB 4.0?) Организует трехдневную сессию мира и программирования во всех глобальных офисах. Мы называем это Skunkworks. В течение этих трех дней инженеры сами решают, чем они хотят заниматься. Подготовка к Skunkworks начинается несколькими месяцами раньше, и люди начинают добавлять идеи проекта и делиться ими. Другие участники могут выбрать присоединиться к чужой идее или выбросить свою и искать людей (#BuildTogether) или пойти в одиночку. Последний Skunkworks (завершившийся сегодня) проходил с 16 по 18 июля.

Уже довольно давно меня интересует работа над проектами Go lang. В этом году я планировал использовать свои первые два дня для решения задач Gophercises и Exercism для пересмотра экосистемы Go, а последний день - на изучение некоторых небольших репозиториев корпоративных инструментов MongoDB, чтобы познакомиться с их внутренним устройством. инструменты. Я также обсуждал другие интересные проекты с другими членами команды, но в глубине души я действительно хотел сосредоточиться на стеке технологий в этом году, чем на чем-либо еще.

Однако в день Skunkworks мы с моим коллегой Nishant обсудили несколько идей, и, наконец, я был убежден, что принял его идею. Мы решили создать небольшое приложение PoC (названное MongoDB Vaidya: врач на санскрите; они могут диагностировать болезнь по частоте пульса), которое могло бы помочь клиентам MongoDB Atlas получить базовый анализ своих файлов журналов (mongod, mongos, audit журналы и т. д.) на их электронную почту каждый день или по запросу. Идея заключалась не только в обучении, но и в развлечениях.

Присоединяйтесь к нам в путешествии по созданию этого простого приложения с экосистемой MongoDB.

Идея заключалась в том, чтобы получить файлы журнала кластера с помощью MongoDB Atlas API, выполнить анализ этих файлов журнала с помощью существующих инструментов (таких как mtools) и отправить файлы вывода по электронной почте заказчику. Мы решили использовать Go lang для реализации бэкэнда этого приложения и кода MongoDB Stitch для других грязных задач.

Сначала мы решили создать REST API для серверного приложения, которое позволило бы клиенту Stitch отправлять запрос на анализ. Однако позже мы отказались от этой идеи из-за некоторых сложностей.

Наконец, мы согласовали архитектуру, в которой:

  1. клиентский интерфейс ждет нажатия кнопки,
  2. запускает функцию MongoDB Stitch
  3. и вводит все детали запроса в коллекцию в облачной службе базы данных (размещенной на MongoDB Atlas).
  4. Затем серверное приложение будет отвечать за опрос сервера базы данных (mgo еще не реализует Потоки изменений, а драйвер MongoDB Go все еще находится в альфа-версиях) каждые 30 секунд для получения нового набора запросов. . Приложение загружает журналы и выполняет анализ.
  5. (A.) После завершения анализа серверное приложение загружает выходные файлы в S3 и (B.) отмечает запрос как «выполненный» в той же облачной базе данных.
  6. Приложение Stitch продолжает прослушивать это событие изменения,
  7. захватывает выходные файлы и
  8. отправляет клиенту электронное письмо.

Бэкэнд-код

Используемые внешние библиотеки (без них было бы невозможно завершить этот PoC):

Код доступен в репозитории github здесь. (Обратите внимание, что это очень грубый код PoC, и его не следует оценивать на предмет правильности или качества)

Код стежка MongoDB

  1. Пользователь нажимает кнопку и вызывает функцию в Stitch SDK
  2. Функция вставляет данные в Атлас MongoDB.
  3. Серверное приложение опрашивает эти данные, и
  4. загружает обработанный вывод файла в S3 и добавляет информацию о файле в базу данных
  5. Стич продолжает прислушиваться к этому событию, и
  6. запускает функцию, которая работает со стеком AWS для захвата вывода и упаковки в электронное письмо
  7. Отчет по электронной почте отправляется пользователю

Код MongoDB Stitch, используемый в этом проекте, можно найти здесь.

Этот небольшой проект стал отличным обучающим упражнением, и мы хотели бы улучшить его в будущем и посмотреть, может ли он стать потенциальной новой функцией. К концу этого проекта мы поняли, что в экосистеме MongoDB есть что использовать и исследовать, и мы действительно прошли долгий путь по ряду предложений. например: MongoDB Compass помогал на протяжении всего этого проекта для быстрых операций CRUD на этапе тестирования, которые в противном случае потребовали бы дополнительных усилий. Мы также благодарны за поддержку со стороны других членов нашей команды, которые выполняли нашу повседневную работу, пока мы сосредоточились на этом.

Было еще несколько интересных и продвинутых проектов от других наших коллег, и мы с нетерпением ждем подробностей об их опыте.

Надеюсь, вам понравилось это читать.

Ваше здоровье!