OVH в значительной степени полагается на метрики для эффективного мониторинга всего своего стека. Независимо от того, являются ли они низкоуровневыми или ориентированными на бизнес , они позволяют командам получить представление о том, как наши службы работают на повседневной основе. Необходимость хранить миллионы точек данных в секунду привела к необходимости создать специальную команду для создания продукта, способного справиться с этой нагрузкой: Metrics Data Platform .  Опираясь на Apache Hbase , Apache Kafka и Warp 10 , нам удалось создать полностью распределенную платформу, которая обрабатывает все наши показатели… и ваши!

После создания платформы для работы со всеми этими метриками нашей следующей задачей было создать одну из самых необходимых функций для метрик: оповещение.

Встречайте OMNI, наш уровень оповещения

OMNI наше кодовое название  полностью распределенной ,  как-код ,  предупреждая  систему , которую мы разработали на вершине Метрики. Он разделен на компоненты:

• Часть управления , которая берет определения ваших предупреждений, определенных в репозитории Git, и представляет их как непрерывные запросы,
• Исполнитель запросов, распределяющий ваши запросы по расписанию.

Исполнитель запроса помещает результаты запроса в Kafka, готовые к обработке! Теперь нам нужно выполнить все задачи, которые выполняет система оповещения:

• Обработка дедупликации и группировки предупреждений, чтобы избежать усталости от предупреждений. 
• Обработка шагов эскалации , подтверждения  или откладывания .
• Уведомить конечного пользователя по разным каналам : SMS, почта, Push-уведомления и т. Д.

Чтобы справиться с этим, мы посмотрели на проекты с открытым исходным кодом, такие как Prometheus AlertManager,  LinkedIn Iris, и обнаружили скрытую правду:

Обработка предупреждений как потоков данных,
передача от оператора к другому.

Мы приняли это и решили использовать Apache Flink для создания Beacon . В следующем разделе мы собираемся описать архитектуру Beacon, а также то, как мы ее построили и эксплуатировали.
Если вам нужна дополнительная информация об Apache Flink, мы предлагаем прочитать вводную статью на официальном сайте: Что такое Apache Flink?

Архитектура маяка

По сути, Beacon читает события от Кафки . Все представлено в виде сообщения , от предупреждений до правил агрегирования, отложенных заказов и так далее. Трубопровод разделен на две ветви:

• Тот, который выполняет агрегирование и запускает уведомления на основе правил клиента.
• Тот, который обрабатывает шаги эскалации .

Тогда все объединяется , чтобы произвести  на  уведомление , что собирается быть вперед к нужному человеку. Уведомляющее сообщение помещается в Kafka, которое будет использоваться другим компонентом, называемым beacon-notifier.


Если вы новичок в потоковой архитектуре, я рекомендую прочитать модель программирования потока данных из официальной документации Flink.



Все объединяется в поток данных, разделяется (с ключом в Flink API) пользователями. Вот пример:

final DataStream<Tuple4<PlanIdentifier, Alert, Plan, Operation>> alertStream =

  // Partitioning Stream per AlertIdentifier
  cleanedAlertsStream.keyBy(0)
  // Applying a Map Operation which is setting since when an alert is triggered
  .map(new SetSinceOnSelector())
  .name("setting-since-on-selector").uid("setting-since-on-selector")

  // Partitioning again Stream per AlertIdentifier
  .keyBy(0)
  // Applying another Map Operation which is setting State and Trend
  .map(new SetStateAndTrend())
  .name("setting-state").uid("setting-state");

• SetSinceOnSelector , который устанавливается с момента срабатывания предупреждения
• SetStateAndTrend , который устанавливает состояние  (ПРОДОЛЖЕНИЕ, ВОССТАНОВЛЕНИЕ или ОК) и тренд (есть ли у нас более или менее метрики в ошибках).

Каждый из этого класса содержит менее 120 строк кода, потому что Flink справляется со всеми трудностями . Большая часть конвейера состоит только из классических преобразований, таких как Map, FlatMap, Reduce , включая их версии Rich и Keyed . У нас есть несколько функций процессов , которые очень удобны для разработки, например, таймера эскалации.

Интеграционные тесты

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

Запрашиваемое состояние

Убийственная особенность Apache Flink — это возможность запрашивать внутреннее состояниеоператора . Даже если это бета-функция, она позволяет нам узнать текущее состояние различных частей работы:

• на каких этапах эскалации мы находимся
• это он прилег или извед -ed
• Какое оповещение продолжается
• и так далее.

Благодаря этому мы легко разработали API для состояния запроса, который поддерживает наше представление предупреждений в Metrics Studio, наше кодовое имя для веб-интерфейса платформы данных метрик.

Развертывание Apache Flink

Мы развернули последнюю версию Flink ( 1.7.1 на момент написания) непосредственно на голых металлических серверах с выделенным кластером Zookeeper с использованием Ansible. Работа с Flink стала для нас действительно приятным сюрпризом, с понятной документацией и настройкой , а также впечатляющей устойчивостью . Мы можем перезагрузить весь кластер Flink, и задание перезапускается в его последнем сохраненном состоянии , как будто ничего не произошло.

Мы используем RockDB в качестве государственного сервера, поддерживаемого хранилищем OpenStack Swift,  предоставляемым OVH Public Cloud.

Для мониторинга мы полагаемся на Prometheus Exporter с Beamium, чтобы получить возможность наблюдать за состоянием здоровья рабочих.

Одним словом, мы любим Apache Flink!

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




Таким образом, мы настоятельно рекомендуем всем разработчикам взглянуть на Apache Flink. Я рекомендую вам пройти обучение Apache Flink , написанное Data Artisans. Более того, сообщество приложило немало усилий, чтобы легко развернуть Apache Flink в Kubernetes, поэтому вы можете легко попробовать Flink с помощью нашего управляемого Kubernetes!

Что дальше?

На следующей неделе мы вернемся к Kubernetes, поскольку мы расскажем, как мы работаем с ETCD в нашей службе OVH Managed Kubernetes .