Это обзорная статья: высоконагруженные системы обеспечивают работу онлайн-сервисов, облачных платформ, финансовых операций, стриминговых сервисов и других цифровых решений. Их отказоустойчивость и производительность напрямую влияют на удовлетворенность пользователей и соответствие условиям SLA (Service Level Agreement). Мониторинг помогает следить за поведением систем, а также и предотвращать сбои.

Сегодня обсудим разницу между мониторингом и наблюдаемостью (observability), а также их значение для современных распределенных ИТ-систем. Если ваша инфраструктура поддерживает сложные сервисы или работает в условиях постоянно растущей нагрузки, вы, вероятно, уже задумывались о необходимости видеть полную картину происходящего в реальном времени. Мы расскажем, почему в 2025 году мониторинг и наблюдаемость стали двумя сторонами одной медали, и как эти подходы помогают предотвращать сбои, анализировать проблемы и повышать надежность систем.

В этом посте затронем тему про Chaos Engineering и роль мониторинга в обеспечении отказоустойчивости сложных ИТ-систем. Возможно, вы уже слышали про термин хаос-инжиниринг, и если ваша ИТ-инфраструктура обслуживает критически важные сервисы с большим числом пользователей, то самое время добавить ей надежности, внедрив этот самый Chaos Engineering вместе с системой зонтичного мониторинга. 

Эффективное реагирование на инциденты — это ключевая задача команды ITOps (IT Operations), которая помогает поддерживать стабильность и безопасность ИТ-инфраструктуры предприятия. Весь процесс состоит из нескольких этапов, каждый из которых играет важную роль в минимизации ущерба, восстановлении работы и предотвращении будущих сбоев. В этой статье разберем сущность каждого этапа, чтобы показать как обеспечить систематизированное и оперативное реагирование на инциденты в ИТ-среде.

Привет, Хабр!

Простая истина: когда какой-то элемент инфраструктуры или бизнес-сервис простаивает из-за сбоя, то компания несёт потери. Чем понятнее текущее состояние ИТ, тем быстрее можно реагировать на возникающие проблемы и не допускать простоев. Для этого, конечно, нужен мониторинг. 

Рассказываем, какой концептуальный подход к мониторингу мы применяем в команде НЛМК ИТ и как идёт один из наших проектов по внедрению зонтичного мониторинга и автоматизации на базе российской платформы Monq. Читать всем, кто хочет агрегировать данные из различных инструментов мониторинга в одном месте и автоматизировать управление этими данными. 

Сегодня расскажем про то, как модуль управления инцидентами и модуль CMDB работают в паре для общей цели — сокращения времени на устранение аварий в несколько раз. Традиционно — все примеры из статьи можно реализовать в бесплатной комьюнити версии Monq.

Управление инцидентами - это порой ночной кошмар любого ИТ-директора. Поднимите руку те, у кого не было ночных сообщений, что упал критический сервис! Почему так мало рук? Да потому что этот самый процесс в большинстве компаний устроен криво. Каждый раз его придумывают заново, проходя путь от ручного режима, далее общей почты или телеграмм группы до самописной системы управления инцидентами. И чем позже мы приходим в компанию выправлять процесс, тем больше сопротивления и непонимания “А что так можно было?”.

Помню, как 8 лет назад я руководил сервисной службой в компании, которая предоставляла услуги поддержки важной внутренней системы крупного клиента. Однажды ночью, примерно в три часа, мой телефон разрывается от звонка. На экране — заказчик. Не успеваю сказать "алло", как слышу: "Вы там спите что ли? У нас АСУ ПОБСУ лежит! Вы в курсе почему? (Я молчу) Мы больше не будем с вами работать!" — и бросает трубку.

Сегодня я расскажу, как с помощью системы Monq и ее инструмента low-code автоматизации можно эффективно настраивать мониторинг и управление инцидентами на примере интеграции с Zabbix. Будет описание ключевых элементов, включая создание и обработку сигналов, управление состоянием конфигурационных единиц и автоматизации процессов. А еще — полезные ссылки на бесплатную комьюнити версию и ранний доступ к облачной версии. Надеюсь, этот пост будет полезен специалистам, которые хотят оптимизировать мониторинг сложной ИТ-инфраструктуры, заодно улучшив управление инцидентами.

По мере развития генеративного ИИ, вендоры в сфере  ИТ-мониторинга работают над созданием инструментария AI CoPilot. Название тула пошло от представления, что управление ИТ-инфраструктурой подобно пилотированию самолетов. В случае инцидента пилоты пользуются «Руководством по летной эксплуатации» (РЛЭ) и «Аварийной картой» для быстрого решения проблемы, стремясь сохранить контроль над ситуацией. AI Copilot (второй пилот, 2/П в терминах авиации) помогает сотруднику ITOps (в роли КВС) быстро проанализировать данные мониторинга, найти в базе данных описание похожего инцидента, предложить путь решения проблемы и затем автоматически запротоколировать событие в журнале инцидентов (Postmortem).

Современные практики devops и sre не обходятся без грамотного управления событиями, алертами, графиками дежурств, и т.д. Имея за плечами более 15 лет поддержки сложных систем и сервисов, решили поделиться прописными истинами в форме данной статьи. Весь этот процесс теперь можно построить с помощью бесплатного сервиса Monq OnCall, так что приглашаем на ранний доступ, ссылка внутри.

Hola. Хабр! В этой статье хотелось рассказать, как корпоративный ИТ-мониторинг Monq отслеживает работоспособность ИТ-систем предприятия, облачных сервисов и коннекторов с внешними поставщиками, такими как системы оплаты, логистики, бронирования товаров или билетов, а также в других сферах. Real-time мониторинг инфраструктуры и работоспособности ИТ-инфраструктуры бизнеса критически важен для функционирования электронной торговли, ритейла, промышленности, банкинга и страхования, медклиник и госучреждений. 

Дать что-то бесплатно и тем самым подсадить на свой продукт всегда было одной из наилучших стратегий продвижения. Быть может также рассуждал Билл Гейтс, который возможно целенаправленно поставлял “пиратские” копии своих продуктов в Россию. В 1996 году знаменитая Горбушка попала в Книгу рекордов Гиннесса за достижение в области «Самое быстрое пиратство». Билл Гейтс объявил о старте продаж пакета «Офис 97» по цене 495 долларов за копию. Уже через 4 часа «Офис 97» продавался на Горбушке по цене чуть менее 5 у. е. за ту же самую копию. Спустя 25 лет мы не меньше хотим “бесплатное”. В корпоративном IT рынка бесплатного софта нет, но есть всем известный Open Source. Насколько это выгодно самим разработчикам разберемся в этой статье.

Привет,  Хабр! 

В этом статье рассказываем, как устроена low и no-code автоматизация в Monq и как с ее помощью можно оптимизировать обработку данных высоконагруженных систем. В центре внимания – «работяги» – обработчики автоматизации. На конкретных примерах показываем, какие опции использовать, чтобы нагрузка между ними распределялась равномерно.

Привет, Хабр! Это снова я, Николай, сооснователь компании Монк Диджитал Лаб, российского разработчика системы мониторинга Монк. Но о мониторинге сегодня в статье практически ничего не будет. Эту статью я пишу про самый популярный вопрос на любом нашем ивенте «А вы не замечали, ваше лого очень похоже на…» Так и хочется каждый раз включить сарказм и ответить что‑то типа: «ой, вы первый кто заметил!» Было решено, в нашем блоге просто обязана появиться статья на тему логотипа. Мы с вами посмотрим примеры российских лого, обсудим тренды, и я вам расскажу несколько курьезов и забавных историй. Так что поехали читать!

Привет, Хабр! 

Последние несколько лет мы активно строили зонтичный мониторинг и здорово в этом преуспели. Теперь у нас новая задача – построить лучший комплексный мониторинг на рынке РФ. С версией 8.0 Monq становится all-in-one мониторингом, который покроет максимум мониторинговых задач в крупных компаниях. Это самый крупный релиз за последнее время. Рассказываем, какими теперь возможностями обладает платформа.

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

Привет, Хабр! Хотим рассказать о том, как и зачем Х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.