Простая улучшенная сигнализация работоспособности для среды Beanstalk с расширениями .ebextensions
Разработка программного обеспечения обычно связана с кодированием, когда разработчики пытаются определить это с первого взгляда. Однако это процесс, который идет от разработки до поддержки самого программного обеспечения. Конечно, кодирование оживляет программное обеспечение, но его поддержка - вот что действительно выделяет его из общей массы.
Под обслуживанием мы имеем в виду, чтобы он работал должным образом со своими функциями, а также оставался живым. Для этого необходимы знания выбранного языка программирования и инфраструктуры, поскольку запуск его на «моей машине» отличается от запуска на сервере / облаке (я знаю, что это трудно читать, но, к сожалению, это правда).
Есть много вещей, которые мы можем сделать, чтобы помочь поддерживать приложение, и одна из них - проверка его работоспособности. Проверка работоспособности - это периодический запрос, отправляемый приложению для проверки его статуса, в котором в ответе определяется, является ли приложение работоспособным или нездоровым. Облачные сервисы, такие как AWS, Azure и Google Cloud, используют проверки работоспособности в качестве стандартной меры состояния приложения. На этом мы можем начать говорить о нашей улучшенной тревоге работоспособности на AWS.
Усиленная тревога здоровья?
«Расширенная отчетность о работоспособности - это функция, которую вы можете включить в своей среде, чтобы позволить AWS Elastic Beanstalk собирать дополнительную информацию о ресурсах в вашей среде».
Эта функция помогает выявлять проблемы, которые могут вызвать недоступность вашего приложения, например, экземпляр EC2 с перегрузкой памяти или ЦП. Для его использования требуется версия 2 или более новая версия платформы Elastic Beanstalk (в показанном примере в нашей среде используется Amazon Linux 2).
Статус, предоставляемый этой расширенной отчетностью о работоспособности, может быть опубликован как настраиваемая метрика, которая будет использоваться CloudWatch, службой мониторинга и наблюдения, которая предоставляет данные и аналитические данные для мониторинга приложений. С его помощью мы можем создать сигнал метрики CloudWatch, который «выполняет одно или несколько действий на основе значения метрики или выражения относительно порогового значения в течение ряда периодов времени».
Что ж, это хорошо, но как я могу создать его для своей среды?
Во-первых, платформа вашей среды должна быть версии 2 или новее. Во-вторых, проверьте, включены ли в вашей среде расширенные отчеты о работоспособности, перейдя в свою среду и выбрав «Конфигурация» ›« Мониторинг »› «Отчеты о работоспособности» и отметив «Улучшено».
Потом…
Просто скопируйте / вставьте следующий файл «.config» в папку «.ebextensions» и разверните его в исходном пакете.
Что такое файл:
Политика масштабирования AWSEBAutoScalingScaleDownPolicy представляет собой одну из двух политик по умолчанию, созданных автоматически во время создания среды. В нашем примере в нашей среде одновременно используется только один экземпляр, а «желаемая емкость» и «минимальная емкость», настроенная для нашей группы Auto Scaling, равна 1 (значение по умолчанию для каждую среду Elastic Beanstalk после ее создания). Это означает, что когда мы предпринимаем действие по уменьшению масштаба, мы удаляем неисправный экземпляр и добавляем еще один, чтобы поддерживать среду в рабочем состоянии, и все это управляется его группой автоматического масштабирования.
Название метрики аварийного сигнала для этого улучшенного состояния здоровья - «EnvironmentHealth», и оно доступно только для платформ 2.0 или новее, требование ранее выделено, без дополнительных затрат! Статус среды может соответствовать следующим значениям:
- OK = 0
- Информация = 1
- Неизвестно = 5
- Нет данных = 10
- Предупреждение = 15
- Деградировано = 20
- Тяжелая = 25
Из этого списка последние 3 статуса - это те, которые показывают, что наша рабочая среда каким-то образом затронута. Мы можем увидеть их причины, нажав кнопку «Причины», чтобы просмотреть подробную информацию. Из-за этого мы выбрали для нашего «ComparisonOperator» значение «GreaterThanThreshold» и значение «10», поскольку оно охватывает именно эти 3 состояния.
Наш будильник выглядит так: он срабатывает после того, как «Период» остается в «180» секунд (должно быть кратно 60) с «Средним» «EnvironmentHealth», значение «Больше чем» порог «10», при котором будет выполнено «AlarmAction» из уменьшения на один экземпляр.
Просмотр будильника
Перейдя в сервис CloudWatch, мы просматриваем созданные тревоги внутри меню «Alarms». Сразу после создания аларма он переходит в состояние «Недостаточно данных», затем в состояние «В тревоге» и, наконец, в состояние «ОК».
Нажав на название будильника, мы переходим на экран предварительного просмотра, где видим график с синей линией и красной линией. Ожидаемое поведение состоит в том, что наше приложение работает без проблем, представляя сигнал тревоги в состоянии «ОК», что означает, что синяя линия остается под красной линией (наше пороговое значение).
Когда сигнализация переходит в состояние «В тревоге», это означает, что синяя линия находится над красной. Если он остается выше в течение более 3 минут (180 секунд), выполняется действие по уменьшению масштаба, выполняется развертывание нового экземпляра, после чего аварийный сигнал снова переходит в состояние «ОК».
Вот и все! Вроде бы простая функция, но в конечном итоге оказывается очень и очень полезной.
Заключение
Аварийный сигнал с метрикой - это мощный инструмент, который помогает нам автоматически отслеживать нашу среду Elastic Beanstalk, избавляя нас от постоянного беспокойства в голове, которое заставляет нас думать: «Пойдем, проверим, все ли в порядке с нашим приложением?»
Сервисы AWS публикуют целый мир показателей, которые можно использовать для создания комбинации сигналов тревоги, которая наилучшим образом соответствует потребностям каждого проекта. Это действительно дает нам, разработчикам, возможность тратить больше времени на создание новых и лучших решений в нашей повседневной работе.
использованная литература
Больше контента на plainenglish.io
