Привет, Хабр! Хотим рассказать о том, как и зачем Х5 Group внедряет зонтичный мониторинг Monq, почему сущность и состояние «магазина» для бизнеса важнее виртуальных объектов, ну и как вообще стало возможным не только собрать под один зонтик >1.1 млн объектов и данные всего ИТ-окружения, но и силами ЛАНИТ-Интеграции автоматизировать построение модели здоровья и ресурсно-сервисной модели с помощью low-code автоматизации. 

«Ну вот и дожили до системы мониторинга систем мониторинга», «А потом ещё обязательно нужно настроить мониторинг системы мониторинга, объединяющую мониторинги» – иронизируют пользователи в одном Telegram-канале о системном администрировании.

Шутки в сторону – в этой статье ищем ответы на вопросы, зачем нужен зонтичный ИТ-мониторинг и как в нём действительно всё работает. 

Невозможно зайти в мобильное приложение, записаться к врачу, оплатить покупку в интернет-магазине, не работают кассы, подрядчик нарушает SLA по доступности сервисов, а инженеры поддержки приступают к поиску проблем после жалоб пользователей и проверяют вручную десятки, а иногда и сотни информационных систем – типичный процесс эксплуатации в быстро развивающихся и сильно зависящих от стабильной работы IT крупных компаниях. Инженерам сложно выполнять KPI по доступности и проактивно работать со сбоями, а бизнес несет финансовые и репутационные потери. 

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

Рассказываем, как работать с синтетическим мониторингом в платформе зонтичного мониторинга Monq (кстати, функционал доступен в бесплатной версии платформы).

Надоело, что одни пороги метрик настроены в Prometheus, другие в Zabbix, третьи еще в каком‑то Zabbix? А когда трясет инфру и vCenter, то с vROps летят оповещения, причем те же самые о виртуалках, что поставлены на мониторинг в первом и втором Zabbix?!

Тут можно менять названия уровней вашего ИТ‑окружения, можно менять названия систем мониторинга. Дубли, штормы, алярмы и алармы. Проблема будет знакома всем, кто работает с большими инфраструктурами. А еще не забываем о проблеме «сложить все в одну банку»: все метрики с разных прометеев, например; ну и, конечно же, совсем было бы здорово в одной системе увидеть все метрики и логи и настроить по ним корреляции и автоматизацию.

А так можно было? Конечно!

В последние годы среди организаций, живущих философией DevOps и SRE, стал популярен подход “всего как кода”. Особенно часто он встречается при управлении инфраструктурой. Направление IaC (infrastructure as a code), где ручная настройка заменяется использованием скриптов, появившись в ответ на растущую виртуализацию данных, превратилось в IT-стандарт и неотъемлемую часть DevOps. Представление инфраструктуры в виде кода обеспечивает её гибкость и масштабируемость, автоматизирует ручные задачи, минимизирует риск человеческого фактора и позволяет эффективнее использовать существующие ресурсы. Но рука об руку с инфраструктурой идёт и её мониторинг, а потому резонным является вопрос о том, как на нём отразилась описанная выше концепция. 

В этой статье я расскажу про такой подход как Monitoring as a Code и покажу его реализацию на примере нашей платформы для мониторинга и автоматизации Monq 7.0.

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