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

13,84 млрд рублей потерялись. Моя гипотеза: заметную часть этой суммы мы тратим на повторное создание одинаковых платформенных функций. Размер этой части ещё нужно измерить, но он точно существенен. И эта часть вместо мультиплицирования технологического задела в тиражируемых решениях российских вендоров остается технологиями для одного клиента.

10 июля мы выпустили Monq 9.2.0. Если описать релиз одной фразой: пороги получили собственное рабочее пространство, научились учитывать расписание, автоматически находить свою КЕ в CMDB и хранить прогноз собственного состояния. Для работы на больших объёмах хранение порогов перенесено из PostgreSQL в ClickHouse, а связанный конвейер сервисов переработан.

Перед вами обзор обновления отечественной observability платформы зонтичного мониторинга от вендора. Тут не будет обещаний «предсказать любую аварию» и общих слов про AIOps. Разберём точную механику, новые фичи, работу дежурной смены, нюансы обновления и честную границу между тем, что уже работает в 9.2, и адаптивными порогами, которые появятся в 9.3.

В целом статья будет о том, как превратить миллионы состояний в понятную работу дежурной смены, автоматизировать типовые реакции и реже отвлекать владельцев сервисов.

Главная мысль этой статьи простая: не надо встраивать ИИ в каждую корпоративную систему как отдельный самостоятельный AI-контур. Пользователь должен видеть ИИ там, где работает: в CRM, СЭД, ITSM, мониторинге, портале или корпоративном чате. Но модели, GPU, gateway, лимиты, аудит, политики доступа, RAG, журналы и ответственность должны жить в отдельном корпоративном слое.

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

Это статья про архитектурную ошибку, которую мы почти совершили в Monq, про зоопарк корпоративных копилотов, теневой ИИ, GPU-инфраструктуру, AI Gateway, безопасность, аудит и новый слой между людьми и информационными системами.

Казалось бы, сейчас мы наблюдаем всё, но факт в том, что не управляем ИТ-ландшафтом в целом. Упор на автономию команд и разрозненные инструменты приводит к «разрывам» в управлении: нет единой картины при инцидентах, SLA считаются в табличках, корреляция событий происходит «в головах людей», интеграции держатся на 1–2 специалистах, а построение CMDB и моделей ИТ ландшафта часто игнорируется. В этой статье мы постараемся переосмыслить роль зонтичного мониторинга, и докажем, что это не еще один мониторинг, а важный архитектурный слой.

Ещё пару лет назад на одной из офлайн-встреч мы решили: как только появится возможность, проведём корпоратив в горах. Хотели подниматься на вершины, встречать рассветы в палатках и ловить падающие звёзды где-то над Кавказом. Возможность всё не наступала — проекты, релизы, клиенты, ставка… — но мечта жила. И вот в начале сентября Олег и Никита, наши руководители клиентского сервиса и продаж, просто взяли билеты на Камчатку, собрались в поход и ушли на неделю по Толбачинскому массиву. Без лишних слов, без анонсов. А потом — прислали фото: флаг Monq 9 на фоне вулкана, облака под ногами и подпись «Мы готовы». Подняв этот флаг они даже опередили команду разработки 😀

Мы долго ждали этого релиза и наконец-то мы готовы представить Monq 9.0, новую версию all-in-one платформы наблюдаемости (observability), ИТ-мониторинга и low-code/no-code автоматизации с AIOps функционалом на борту. Monq эволюционировал из событийного «зонтичного» мониторинга, который собирает данные из других систем, в “observability-зонтик”, который с большой производительностью умеет собирать любые данные сам. В этой статье расскажем, что нового появилось в версии 9.0, как устроена платформа и главное – зачем всё это нужно DevOps-инженерам, архитекторам и тимлидам. Поехали!

Как получить от мониторинга уверенность, что ИТ-инфраструктура работает как надо? В этойстатье разберемся, как устроена работа с метриками в Monq: от их сбора и автоматической привязки к контекстным элементам до создания кастомных метрик и контроля качества покрытия. Поговорим о том, как быть уверенным, что система действительно «зеленая» — а не делает вид,что у вас все в порядке. А в конце статьи вас ждет видео с конкретным примером работы с метриками от А до Я.

Кто бы мог подумать, что внедрение корпоративного ИТ-мониторинга может быть таким… скажем так, «интересным»? Вы начинаете с благих намерений, а заканчиваете в окружении мигающих экранов и тысячи алертов. Большинство проектов могли бы проходить гораздо быстрее, если бы не хаотичный подход. Особенно «весело» дела обстоят с legacy-системами, где документация — это древний свиток, а знания разбросаны, как пазл, потерявший половину деталей. Мы собрали 9 правил, которые помогут избежать хаоса и внедрить мониторинг без боли.

О том, «Что делать?» (без «Кто виноват?») — читайте в нашей статье.

Это обзорная статья: высоконагруженные системы обеспечивают работу онлайн-сервисов, облачных платформ, финансовых операций, стриминговых сервисов и других цифровых решений. Их отказоустойчивость и производительность напрямую влияют на удовлетворенность пользователей и соответствие условиям 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 и как с ее помощью можно оптимизировать обработку данных высоконагруженных систем. В центре внимания – «работяги» – обработчики автоматизации. На конкретных примерах показываем, какие опции использовать, чтобы нагрузка между ними распределялась равномерно.