Надоело, что одни пороги метрик настроены в 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 мониторов в офисе. Надеюсь, наша история перехода на удалёнку будет вам полезна.

В публикациях на Хабре я уже писал о своем опыте построения партнерских отношений со своей командой (здесь рассказывается о том, как составить партнерское соглашение при старте нового бизнеса, чтобы бизнес не развалился). А сейчас я бы хотел рассказать о том, как строить партнерские отношения с клиентами, так как без них разваливаться будет нечему. Я надеюсь эта статья будет полезна стартапам, начинающим продажи своего продукта крупному бизнесу.

Я сейчас как раз возглавляю такой стартап MONQ Digital lab, где мы с командой разрабатываем продукт по автоматизации процессов поддержки и эксплуатации корпоративного ИТ. Выход на рынок очень не простая задача и мы начали с небольшой домашней работы, прошли по экспертам рынка, нашим партнерам и провели сегментацию рынка. Основным вопросом было понять “чьи боли мы лучше всего можем излечить?”

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

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

Если вообще не соблюдать правила гигиены, быть токсичным, не последовательным, корыстным, обманывать других, то до первых денег вообще не добраться. Представим, что все хорошо, вы все молодцы и не за горами время, когда пойдет первая серьезная прибыль. Тут рушатся воздушные замки, которые были так скрупулезно выстроены каждым членом команды. Первый думал, что он главный и он заберет 80% прибыли, так как именно он продал машину и на его деньги жила первое время вся команда. Второй думал, что два основателя получат по 50%, так как он программист и создал то самое приложение, на котором все сейчас зарабатывают. Третий и четвертый думали, что они получат долю в бизнесе, как только пойдут деньги, ведь они работали почти круглосуточно и получали значительно меньше, чем могли бы в том же банке.

В итоге бизнес под угрозой развала. А ведь всего бы этого можно было бы избежать, правильно договорившись на берегу. Как?