Мониторинг сайта с помощью Azure Logic Apps

Быстрые ссылки

• Требования
• Создание Logic App
• Сохранение и тестирование
• Дополнения: чеклисты, тесты, альтернативы

Введение

Azure Logic Apps — это облачный сервис для визуального создания и автоматизации рабочих процессов. Его удобство в том, что вы почти без кода связываете события, HTTP-запросы и действия третьих сервисов. В этой статье мы реализуем мониторинг сайта: периодический HTTP-запрос к вашему домену каждые 15 минут и отправку письма через Gmail при получении кода состояния, указывающего на ошибку (4xx или 5xx).

Краткое определение: Logic App — это последовательность шагов (триггер → действия), описанная в JSON и выполняемая облачной платформой.

Требования

• Аккаунт Azure с правами на создание ресурсов.
• Логин в Gmail для отправки писем (или другой почтовый сервис, если вы предпочитаете альтернативы).
• URL сайта, который вы хотите мониторить.

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

Создание Logic App

Следуйте этим шагам для создания приложения Logic App и базового workflow:

1. Войдите в портал Azure и нажмите «Создать» (New) в левом меню.
2. Перейдите в раздел «Web + Mobile», выберите «Logic App».
3. В форме создания укажите имя приложения. Имя станет частью поддомена доступа к Logic App и может содержать только буквы, цифры и дефисы.
4. Выберите группу ресурсов, подписку и регион (Location).
5. Нажмите «Create».
6. После создания откройте ссылку на приложение — вы попадёте в Logic App Designer.

7. В списке шаблонов найдите и выберите «Blank Logic App».
8. Вам предложат выбрать триггер и сервис. Нажмите «See More Options» и в списке сервисов найдите «HTTP».

9. Выберите триггер «HTTP trigger» (первый пункт).

Настройка HTTP-пробы

1. Для поля Method укажите GET.
2. В поле URL введите корневой адрес вашего сайта, например: http://www.yourdomain.com или https://www.yourdomain.com.
3. Установите частоту (Frequency) в Minutes, интервал (Interval) = 15 — это создаст GET-запрос каждые 15 минут.

Теперь добавим условие, которое будет срабатывать при ошибочных статусах.

Добавление условия по статус-коду

1. Нажмите New Step → Add a Condition.
2. В первом поле выберите параметр Status Code из раздела Insert Parameters From Previous Steps (значение возвращаемого статуса HTTP).
3. В выпадающем меню условий выберите GreaterThan Or Equal To.
4. Введите 400 в третье поле.

Это условие интерпретирует любой ответ с кодом 400 или выше как ошибку (4xx и 5xx).

Если условие принимает значение “Yes” (истина), мы добавим действие отправки письма. Для ветки “If No” оставьте шаги пустыми.

Конфигурация отправки письма через Gmail

1. В ветке “If Yes” нажмите Add An Action и в списке найдите “Gmail - Send Email”.
2. Авторизуйте подключение к вашему аккаунту Gmail (OAuth). Подтвердите разрешения.

3. Заполните поля действия:
   • To: адрес получателя (например, dev-team@company.com или ваш e‑mail).
   • Attachments Content: вставьте параметр Body из предыдущего шага (Insert Parameters From Previous Steps).
   • Attachments Content-Type: в текстовом поле укажите enter text/html (или text/plain, если предпочитаете).
   • Attachments Name: response.html (имя вложения).
   • Body: текст письма. Внутрь вставьте код статуса из Insert Parameters From Previous Steps и короткое описание.
   • Subject: включите код статуса и краткий заголовок, например “Site check: {{StatusCode}} for www.yourdomain.com”.

Сохраните действие.

Сохранение и тестирование

1. Нажмите Save в верхней части дизайнера.
2. После сохранения вы вернётесь на Overview приложения, где будут появляться логи выполнения.
3. Проверьте первые выполнения через 15–30 минут или запустите тест вручную.

Ручное тестирование

Чтобы принудительно запустить workflow для проверки:

1. Вернитесь в Logic App Designer.
2. Откройте панель условия и временно измените операцию на Is Less Than (или другой критерий), чтобы имитировать срабатывание при успешном статусе (1xx/2xx/3xx).
3. Сохраните и нажмите Run. Когда тест пройдёт, откатите изменения на исходное условие (>= 400) и снова сохраните.

Если всё настроено верно, вы получите письмо с вложением response.html, содержащим тело ответа и код статуса.

Когда это не подходит

• Высокая частота опроса. Для крупных систем частые опросы могут увеличить расходы и нагрузку. Logic Apps тарифицируются по количеству выполнений.
• Нужна сложная логика анализа ответа (например, распознавание изменения DOM). Для глубокого анализа лучше использовать специализированные инструменты мониторинга.
• Требуются SLA и долгосрочные графики — рассмотрите интеграцию с Prometheus/Grafana или Azure Monitor.

Альтернативные подходы

• Azure Monitor / Application Insights: для детального мониторинга и метрик.
• Использовать внешний сервис uptime (Pingdom, UptimeRobot) для независимого мониторинга с нескольких локаций.
• Развернуть self-hosted скрипты на сервере (cron + curl) и отправлять алерты в чат/почту.

Мини-методология для внедрения мониторинга

1. Определите цели: доступность, время отклика, корректность контента.
2. Выберите интервал опроса, уровень оповещений и канал(ы) уведомлений.
3. Настройте Logic App с условием и действием — тестируйте на «мягких» триггерах.
4. Включите логирование и интеграцию с системой инцидентов.
5. Проводите ретроспективы по ложным срабатываниям и настраивайте фильтры.

Чек-лист ролей

• Владелец проекта:
  • Утвердить частоту опроса и каналы уведомлений.
  • Проверить бюджет на Logic Apps.
• DevOps-инженер:
  • Создать Logic App и настроить авторизацию Gmail.
  • Настроить безопасные секреты и доступы.
  • Интегрировать логи в центральную систему наблюдения.
• Разработчик приложения:
  • Предоставить URL и критерии успешности.
  • Описать ожидаемое поведение API/страницы.

Критерии приёмки

1. Рабочий Logic App создаёт GET-запрос к указанному URL каждые 15 минут.
2. При получении кода >= 400 отправляется письмо на указанный адрес.
3. Письмо содержит код статуса и тело ответа в виде вложения response.html.
4. Workflow занимает не больше 2 минут от триггера до завершения (в большинстве случаев).

Сценарии тестирования и приёмки

• Тест A: Симулировать 500 ответ. Ожидается письмо с кодом 500 и вложением.
• Тест B: Симулировать 200 ответ. Никаких писем не приходит.
• Тест C: Убедиться, что при потере авторизации Gmail отрабатывается корректная ошибка и администратор уведомляется другим каналом.

Безопасность и конфиденциальность

• Никогда не храните учётные данные в открытом виде. Используйте Azure Key Vault или встроенные секреты Logic Apps.
• Ограничьте доступ к Logic App по ролям и Azure RBAC.
• Для передачи чувствительных данных используйте шифрование и HTTPS.
• Если в теле ответа содержится конфиденциальная информация, продумайте фильтрацию перед отправкой по e‑mail.

Стоимость и оценка воздействия

Logic Apps тарифицируется за выполнение. В исходном примере указывалась стоимость для первых 250 000 выполнений — проверьте актуальные тарифы на сайте Azure, они могут меняться. Для частоты каждые 15 минут (≈4 выполнения в час → ≈96 в сутки → ≈2880 в месяц) это будет недорогой вариант для небольшой нагрузки. Оцените влияние на бюджет и убедитесь, что вы не превышаете разрешённый объём бесплатных или обусловленных тарифами выполнений.

Важно: уточняйте текущие цены в вашей подписке и регионе.

Когда мониторинг даёт ложные срабатывания (и как с ними бороться)

Причины ложных срабатываний:

• Короткие периоды недоступности при обновлениях сервера.
• Балансировщик возвращает разные коды в зависимости от региона.
• Сеть между Azure и проверяемым хостом нестабильна.

Митигирование:

• Увеличьте число последовательных неудач прежде чем оповещать (например, считать ошибкой только N подряд >1).
• Добавьте проверку по содержимому ответа (например, ожидать специфичный фрагмент HTML).
• Выполняйте повторные запросы с интервалом в несколько секунд.

Пример расширения: считать ошибкой только при N подряд неудач

1. Добавьте в Logic App состояние (Storage/Blob/Table или Azure Table Storage) для счётчика.
2. При ошибке увеличивайте счётчик; при успешном ответе обнуляйте.
3. Отправляйте письмо только если счётчик >= N.

Это уменьшит шум от кратковременных сбоев.

Диаграмма принятия решения

flowchart TD
  A[Начать проверку каждые 15 мин] --> B{Код ответа >= 400?}
  B -- Да --> C[Увеличить счётчик ошибок]
  B -- Нет --> D[Обнулить счётчик]
  C --> E{Счётчик >= N?}
  E -- Да --> F[Отправить уведомление через Gmail]
  E -- Нет --> G[Логировать ошибку]
  D --> G
  F --> G
  G --> H[Завершить]

Дополнительные варианты интеграции

• Вместо Gmail: отправка в Microsoft Teams, Slack, PagerDuty, или веб-хук в систему инцидентов.
• Сохранять каждый ответ в хранилище для исторического анализа.
• Генерировать метрики и экспортировать их в Azure Monitor / Log Analytics.

Заключение

Azure Logic Apps позволяет быстро развернуть базовый мониторинг сайта без написания серверного кода. Это удобно для мелких проектов и быстрых оповещений. Для крупномасштабных и гарантирующих SLA решений используйте специализированные сервисы мониторинга и интегрируйте Logic Apps как один из каналов оповещения.

Важно: проверяйте актуальные цены и используйте безопасное хранение секретов.

Короткая сводка:

• Настройка базового HTTP GET каждые 15 минут.
• Условие по статус-коду >= 400 — отправка Gmail с вложением.
• Рекомендации: считать ошибкой только N подряд попыток, хранить секреты в Key Vault, интегрировать с системой инцидентов.