Представьте, вы добровольно передаёте партнёру свою долю в доверительное управление — на основе соглашения и дружеского рукопожатия. Вы верите людям, с которыми давно знакомы. А через пару лет вынуждены возвращать эти доли через суд. В офисе полиция, отсутствуют все важные документы и со счетов пропали деньги, в том числе на зарплату 150 человек… Нет, это не сюжет корпоративного триллера — это моя реальная история. Моему первому бизнесу уже 17 лет, и я прошел через арбитражные процессы, прокуратуру и доследственные проверки; сейчас, оглядываясь на трехлетнюю «корпоративную войну», хочу поделиться опытом, чтобы другие не попали в ту же ловушку.

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

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

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

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

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

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

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

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

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

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

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

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

Представим ситуацию: решили вы повысить производительность информационной системы. Команда девелоперов для этой цели развернула новые ноды, добавила элементы ИС, зарелизила изменения, система работает эффективнее, и, казалось бы, все счастливы. Да только от радости забыли поставить новые элементы на мониторинг. Так и будете вы спокойно пить кофе, любуясь зелеными огоньками на экране рядом с каждым компонентом системы, пока разъяренные пользователи не cымитируют DDoS атаку на внешний интерфейс вашего хелпдеска, когда один из новых элементов откажет.

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

Конечной задачей всей деятельности по созданию алгоритмов для обработки естественного языка (Natural Language Processing, NLP) является создание искусственного интеллекта (ИИ), который бы понимал человеческий язык, причем “понимал” в значении “осознавал смысл” (анализ текста) и “делал осмысленные высказывания” (синтез текста). Пока до этой цели ещё очень далеко, можно применять различные алгоритмические методы для извлечения какой-либо полезной информации из текстовых данных. А это уже очень полезно для ИТ мониторинга.
В этой статье мы расскажем о применении моделей ML для целей классификации поступающих данных.

В этом месяце мы набрали воздух в легкие и сделали это. Дали на сайте без регистрации, без ввода карточки ссылку на скачивание нашего продукта. Теперь у нас есть бесплатная версия и freemium модель распространения. Шаг был не из легких. Но я считаю его правильным и обоснованным. Постараюсь в этой статье себя вас в этом убедить и рассказать поподробнее про модель Freemium.

If you use Zabbix to monitor your infrastructure objects but have not previously thought about collecting and storing logs from these objects then this article is for you.

Если вы используете Zabbix для мониторинга ваших инфраструктурных объектов, но логи пока не покрыты мониторингом и не собираются в единое хранилище, то эта статья для вас. Расскажем о новом бесплатном анализе логов monq Collector.

I have already written about AIOps and machine learning methods in working with IT incidents, about hybrid umbrella monitoring and various approaches to service management. Now I would like to share a very specific algorithm, how one can quickly get information about functioning conditions of business applications using synthetic monitoring and how to build, on this basis, the health metric of business services at no special cost. The story is based on a real case of implementing the algorithm into the IT system of one of the airlines.

Currently there are many APM systems, such as Appdynamics, Dynatrace, and others, having a UX control module inside that uses synthetic checks. And if the task is to learn about failures quicker than customers, I will tell you why all these APM systems are not needed. Also, nowadays health metrics are a fashionable feature of APM and I will show how you can build them without APM. 

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

Сейчас есть много APM систем, таких как Appdynamics, Dynatrace, и других, где есть внутри модуль контроля UX через синтетические проверки. И если стоит задача быстрее пользователей узнать о сбое, я расскажу почему все эти APM не нужны. Также модной фишкой APM являются метрики здоровья, я покажу как можно их построить без дорогого APM.

Одной из задач систем ИТ-мониторинга является сбор, хранение и анализ различных метрик, характеризующих как состояние различных элементов ИТ-инфраструктуры (загруженность CPU, объем свободной оперативной памяти, объем свободного дискового пространства и т.п.), так и состояние различных бизнес-процессов. Для того чтобы применять обширный математический аппарат статистического анализа, эти данные часто удобнее представлять в виде упорядоченных временных рядов соответствующих переменных. Хорошим инструментом для обработки временных рядов в языке Python является комбинация трёх модулей: pandas, scipy и statsmodels (pandas.pydata.org, scipy.stats, statsmodels.org), которые предоставляют широкий набор классов и функций для построения временных рядов, для оценки множества различных статистических моделей, а также для проведения статистических тестов и исследования статистических данных. Из всего содержащегося в этих модулях математического паноптикума, конкретно в данной статье, будет описаны алгоритмы, в частности корреляционный анализ временных рядов метрик ИТ-инфраструктуры, которые мы применяем для root cause анализа в AIOps платформе monqlab.

ИТ-персонал круглосуточно смотрит на экраны и показатели работы своих ИТ-ресурсов — так проходит типичная рабочая смена в любом в ситуационном центре, SOC (Security Operational Center) или NOC (Network Operational Center). Ресурсы ваших талантливых инженеров можно использовать намного эффективнее, если внедрить интеллектуальную систему, которая будет выполнять такие задачи самостоятельно. Инженеров можно перераспределить на задачи, где человек и его интеллект нужнее — например, на задачи развития и контроля, — а рутину отдать роботам. Сделать это можно с помощью AIOps, с которым при этом связано много сомнений.

Три месяца назад я опубликовал историю про то, как не получилось из проекта сделать продукт, как он обратно превратился в проект и так и не вышел на рынок (прочитать об этом можно тут).

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

У нас небольшая продуктовая ИТ компания, чуть меньше 30 человек. Есть офисы в Дубне, Москве и в Таганроге, пару человек было разбросано по другим частям России. И мы до коронокризиса работали с 9 до 18, сидя на своих мягких креслах у 2-3 мониторов в офисе. Надеюсь, наша история перехода на удалёнку будет вам полезна.