​Пеориодическая таблица инструментов DevOps. Отсюда.

Написал колонку про AIOps штуки для мониторинга.

AIOps — это смесь технологий больших данных (bigdata), машинного обучения (machine learning) и визуализации (visualization) двух перечисленных выше вещей. Платформа AIOps принимает на вход как исторические данные так и данные в режиме реального времени, складывает их в хранилище и выполняет таинства искусственного интеллекта.

​Был вчера на бизнес-завтраке PRTG. Знаете такую систему мониторинга?

С прошлого года (когда также удалось побывать на их мероприятии) в системе появились бейзлайны и какой - никакой предикшен.

Стоит рассматривать эту систему, если у вас некому поддерживать Zabbix и/или хочется что-то серьёзнее. Этим инсайтом со мной кулуарно поделились другие участники бизнес-завтрака, которые потенциальные заказчики. И не поспоришь. Другой заказчик добавил, что их фирма подросла, и по мнению руководства использовать Nagios не солидно, давайте-ка уже купим что-то за небольшие деньги. Напомню, что безлимитная версия PRTG стоит $14 500.

Что такое 4Т-мониторинг? Читайте в новом посте на Медиуме.

​Этот файл содержит развесистое дерево систем мониторинга. Здесь собраны известные вендоры, которые специализируются на той или иной области мониторинга (приложения, сети, инфраструктура и т.д.). Каждый год этот отчёт выкладывает у себя на сайте BigPanda. Их решение — event consolidator с искусственным интеллектом (или AIOps).

​Издательство Wiley, которое выпускает серию «Для чайников» часто под этим же брендом публикует совместные издания с разными компаниями. В этой подборке три книги по теме мониторинга.

Alert Correlation for Dummies (совместно с BigPanda)

AIOps for Dummies (совместно с FixStream)

Network Monitoring for Dummies (совместно с Solarwinds)

​Видели бесплатную штуку для предиктивной аналитики в Grafana? Работает пока только с некоторыми источниками (Influxdb, Graphite, Prometheus, PostgreSQL / TimescaleDB, ElasticSearch).

​29 августа Gartner выпустил новый квадрант по ITSM системам. В лидерах BMC и ServiceNow. Читайте свежий отчёт, а ещё вы можете сравнить с таким же за 2017 год и попробовать найти 10 отличий.

​Кстати, с версии 4.2 Zabbix из коробки начал поддерживать TimescaleDB — расширение PostgreSQL. Почитайте описание работы на Хабре, но перед миграцией учитывайте грабли, на которые наступили коллеги. На картинке показана разница производительности TSDB и PG. Обратите внимание, что когда таблица истории незаполнена, скорость записи в TSDB сравнима со скоростью записи в PG, но, когда количество записей увеличивается, TSDB начинает вырываться в лидеры.

Используете TSDB в своём Zabbix? 👍 — да, 👎— нет, 👀 — не пользуюсь Zabbix.

В продолжение прошлой темы с TimescaleDB в Zabbix. Выступление инженера Zabbix SIA Андрея Гущина на Highload Conf. На Хабре вышла статья с текстовым описанием выступления.

👍 — обязательно посмотрю, 👎 — мне неинтересно, 👀 — уже видел.

Одна большая разница: доступность бизнес-сервиса в 99,9% в год это 525,6 минут, а в неделю — 10,08 минут. При заключении SLA, лучше учесть этот момент. Или не учесть, если в соглашении не указан период этой доступности и вам его потом же и соблюдать.

👍 — полезно
👎 — так себе совет
👀 — от меня до SLA как до Марса

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

👍 — удобно, чо
👎 — я и сам могу посчитать
👀 — где я, а где доступность?

​В Grafana 6.4 добавилась новая возможность — отображение логов. Об этом сообщается в блоге Grafana.

👍 — вот теперь заживём!
👎 — логи меня не интересуют, люблю смотреть на метрики
👀 — я смотрю логи в других местах

​Обнаружил интересную систему мониторинга ServicePilot. Французская. Признаться, из Франции до этого момента ничего не встречалось. Пишут, что умеют в фулстэк мониторинг. Может договорюсь с ними на вебинар, потом расскажу что да как.

👍 — расскажи потом. Интересно узнать что за система такая
👎 — не интересно
👀 — от меня до мониторинга несколько миллионов световых лет

​Компания Zabbix через свой блог на Хабре намекает, что зарелизила версию 4.4.

Что нового?

⚡️ Zabbix-агент теперь переписан на Go
⚡️ Официальная поддержка TimescaleDB
⚡️ Появилаьсь база знаний по элементам данных и триггерам
⚡️ Добавились новые возможности визуализации (ещё не Grafana, но приближаются)
⚡️ и много чего ещё (это ссылка на release notes))

👍 Zabbix — это стильно, модно, молодёжно
👎 Я свою коммерческую ласточку (платную систему мониторинга) ни на какой opensource не променяю

​Эту ссылку мне прислал Medium среди еженедельной подборки постов, которые могли бы мне понравится. Здесь рассказывают про подход к мониторингу ключевых метрик nginx при помощи Nginx_vts_exporter, Prometheus и Grafana. Энджой.

👍 — Полезно
👎 — Так себе
👀 — Не нужно мне nginx мониторить

​В ноябре Gartner выпустил новый отчёт AIOps-решений на 2019-2020 годы. Там появились новые вендоры, остались некоторые старые и написано про общие тренды. Я прочитал отчёт и выделил основные моменты. По ссылке статья на Медиуме. Вэлкам.

AIOps — это подход к мониторингу с использованием алгоритмов искусственного интеллекта.

👍 — AIOps — это стильно, модно, молодёжно. Когда-нибудь он у меня тоже будет.
👎 — мне бы пинговалки нормально настроить, какой там AIOps?
👀 — машин лёрнинг и артифишиал интеллидженс для меня пшик.

​Из серии «Мичурину и не снилось». Оказывается учёным удалось скрестить Elasticsearch и Cassandra и получилось как думаете что? Elassandra.

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

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

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

Чтобы не разрушать эффективно работающие и толково настроенные мониторинги есть выход — зонтичная система.

Но сбор событий в одном месте когда-нибудь приведёт к тому, что событий станет слишком много и дежурные на них не будут обращать должного внимания. Ручные выборки критичных и не очень событий может превратиться в непрерывный процесс. Но почему бы не поручить эту работу, которая будет сама выбирать критичные и не очень события? Да ещё и говорить, что вот это событие в будущем приведёт вот к этим двум и так далее.

Это была небольшая вводная про необходимость заиметь в хозяйстве одну из AIOps систем, которые постепенно захватывают мир. Я посмотрел вебинар и вкратце поделюсь впечатлениями. В целом, всё выглядит позитивно.

​Посмотрите как можно контролировать инфраструктуру kubernetes с точки зрения сетевого взаимодействия при помощи анализа flow-трафика. Растислав (да, именно через «а») говорит, что дропы пакетов между подами, бутылочные горлышки, распределение трафика в кластере и подозрительную активность по-другому выявить не получится.

Flow-трафик извлекается при помощи CNI-плагина Contiv-VPP.

В качестве дополнительного инструмента диагностики — почему бы и нет?

​Статья от начала декабря на Хабре о том, как ИТ-Град создавал объединенную систему мониторинга как услугу для облачных сервисов МТС, собственного IaaS и инфраструктуры 1cloud. Это типа всё объединилось.

Пишут:

В результате трансформации основными требованиями стали:

- система мониторинга должна работать не только на ИТ-ГРАД, но и стать внутренним сервисом для «Объединенного облачного провайдера» и услугой для заказчиков.

- требовалось решение, которое будет собирать статистику со всей IT-инфраструктуры.

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

В цитате выше смотреть нужно на 3 пункт. CMDB — полезная штука для сервисных провайдеров (и всех остальных). События/инциденты обогащаются данными оттуда и сразу видно какой заказчик, где оборудование, когда инсталлировано и т.д. Но в статье нет ничего про связи между КЕ (конфигурационными единицами). А наличие связей — очень большое преимущество. Если они есть, в инциденте можно сразу же показать соседние устройства.

Если к системе мониторинга прикрутить автоматизацию, то, до генерации события/инцидента эти соседние устройства можно пропинговать (или собрать любую другую статистику) и приложить к инциденту/событию. Получится некая первичная диагностика. Конечно, можно прикрутить и какие-то другие проверки. Вы удивитесь насколько быстрее будут решаться инциденты. Надеюсь, те ребята уже идут по этому пути.

Следующий момент. Обратите внимание на прилепленную к этому посту схему. Данные мониторинга собираются 4 различными системами — это 4 источника событий. В статье не сказано как в такой ситуации ведётся работа с шумовыми событиями. Но эту работу вести надо, иначе заказчики через некоторое время перестанут доверять такой системе мониторинга.

А теперь гипотетическая часть. Как там на самом деле я не знаю, но потеоретизирую. SCOM здесь, скорее всего, используется для серверов на Windows, а Zabbix для Unix. vCenter это, возможно, на самом деле система мониторинга vRealize. СХД может быть какими-то вендорскими схдешными решениями мониторинга. Очевидно, что часть Unix и Windows машин виртуализировано, следовательно, события по серверам приходят сразу из трёх систем мониторинга: SCOM, Zabbix, vRealize (vCenter). По СХД события приходят их двух источников: СХД и vRealize (vCenter). Вывод: шумовые события есть, их не может не быть.

Снижение количества шумовых событий отдельная и трудоёмкая задача. Здесь многое зависит от используемого стека систем мониторинга и сервис-деска. Можно почитать об этом коротку статью на Медиуме. Думаю, с этим тоже ведётся определённая работа.