​Обнаружил интересную систему мониторинга 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). Вывод: шумовые события есть, их не может не быть.

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

Дмитрий Комаров из Яндекс-денег рассказывает как они у себя делали MaaC — мониторинг как код. К приложению в виде зависимости добавляется дополнительный артефакт, который генерит новые дашборды в Grafana и порождает соответствующий сбор метрик через StatsD и Heka. Говорит, что Heka это хорошо из-за бестродействия в силу приёма метрик от приложений по протоколу UDP.

Ещё одна важная часть его выступления — это алертинг. Алертинг в Grafana оказался недостаточно гибким и они использовали Moira, которая позволила гибко создавать триггеры и использует собственное хранилище на базе Redis.

Ниже ссылки на соответствующие репозитории на Github:

→ moira-trigger-plugin
→ moira-kotlin-dsl
→ grafana-dashboard-dsl
→ moira-kotlin-client
→ grafana-dashboard-plugin

Статья на Хабре про партиционирование MySQL под нужды Zabbix. Проблема партиционирования, конечно, решается использованием TimescaleDB, но, если по каким-то причинам её использование невозможно, статья будет полезна.

​Хоум Кредит унд Финанс банк пишет как они прикрутили к своему мониторингу на Zabbix и ELK машинное обучение. Вот теперь дежурные могут расслабиться 🙂

​Если не знаешь о чём написать — напиши как настроить Заббикс. Х5 пишет как они сделали мониторинг складских помещений. Интересно почитать, если вы видите Заббикс в первый раз. Ну хотя бы узнали как выглядит их склад.

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

Если используете для мониторинга TICK, то вот полезные хинты для обработки метрик в Kapacitor.

​Популярная, говорят, штука этот service mesh. В комментариях к статье резонно подмечают:

Единственный плюс который я вижу — если в компании действительно есть микросервисы на разных языках программирования. Если всё пишется на одном — лучше общую либу.

Резонно, чо уж там.

Что такое service mesh?

Несмотря на весь хайп, структурно service mesh устроена довольно просто. Это всего лишь куча userspace-прокси, расположенных «рядом» с сервисами (потом мы немного поговорим о том, что такое «рядом»), плюс набор управляющих процессов. Прокси в совокупности получили название data plane, а управляющие процессы именуются control plane. Data plane перехватывает вызовы между сервисами и делает с ними «всякое-разное»; control plane, соответственно, координирует поведение прокси и обеспечивает доступ для вас, т.е. оператора, к API, позволяя манипулировать сетью и измерять её как единое целое.

​Машинное обучение — горячая тема. В мониторинге предсказания аутаджей особенно важно. Читайте в этой статье о поиске аномалий в данных мониторинга. Кстати, используемый стек у них во многом аналогичен используемому в Яндекс-деньгах (см. видео Дмитрия Комарова на несколько постов выше).

​ЦИАН рассказывает как у них устроен сбор и анализ логов. На Elastic Stack.

Ого, нас уже тысяча человек! 🔥 Раз нас уже так немало, давайте проведём небольшой опрос. Конечно, про мониторинг. Проголосуйте за ваше мнение. А ещё можно оставить развёрнутый комментарий.

Вендоры, которые выпускают коммерческие продукты, обычно пишут у себя нечто такое:

Put simply, there is a lot of work involved with implementing open-source distributed tracing. Even if you’re capable of doing that work, you should ask yourself if all of that time and effort might be better spent developing business functionality.

Что переводится как:

Проще говоря, если вы используете open-source, нужно выполнить много работы, связанной с трассировкой распределённого приложения. Даже если вы можете выполнять эту работу, не стоит ли спросить у себя: «а не лучше ли потратить это время на разработку бизнес-функций?»

Вам слово.

💩 удавлюсь, но не буду платить проклятым капиталистам и пусть часть команды занимается поддержкой мониторинга на prometheus/zabbix/…
😏 начинаю поглядывать в сторону платных решений, не хочу утилизировать время команды непрофильным занятием
💰 заплатил деньги и доволен платным решением, пусть мои ребята занимаются разработкой
💣 заплатил деньги, но лучше бы я этого не делал и остался на бесплатном решении

​Ребзики, это комбо! Видео, текстовое описание и ссылка на Github. 3в1. Речь о elastiflow — расширении Elastic Stack для мониторинга и анализа flow-трафика. Это набор дашбордов для Kibana, обвес Logstash для разбора Netflow и советы как это всё использовать. Расширение распознаёт трафик flow различных версий и от различных вендоров. Все подробности в репозитории Github.

Разбор специализированных вендорских полей в flow-трафике — это большая проблема при работе с коммерческими решениями мониторинга (вроде Solarwinds или PRTG). Доработка парсера своими силами там обычно невозможна и остаётся дожидаться когда сам вендор решения для мониторинга наконец-то расширит воспринимаемые коллектором поля. Но к тому времени во flow-трафике появится что-то новое. Вот такой круговорот полей в природе. В Logstash же можно самостоятельно настраивать коллектор на необходимый набор полей.

→ выступление Rob Cowart — содателя расширения
→ описание решения в блоге Koiossian
→ репозиторий на Github

Канал про мониторинг начал приносить дивиденды основателю. Слёрм выдал мне курс по Prometheus, чтобы я его прошел онлайн и дал фидбек. Как пройду, напишу, толково или так себе.

Они же позвали на интенсив по DevOps. Заявлены инструменты DevOps: командная работа с Git, CI/CD, IaC, тестирование, логирование, мониторинг, ChatOps. Предстоит посмотреть на эти инструменты с трёх сторон (своеобразный трипл-вижн): заказчика, разработчика и администратора. На интенсиве будет про реальные кейсы, эффективное взаимодействие между сторонами внутри процесса и вот это всё. Это не конференция, где диалог ограничен 1-2 вопросами, на интенсиве можно полноценно пообщаться со спикерами и прояснить многое. Больше всего интересует мониторинг, но для меня очень даже полезно будет увидеть весь процесс, чтобы понять что и зачем делается.

Интенсив будет с 30 января по 1 февраля. Возможно очное (в Москве) и удалённое участие. Рега по ссылке.

​Весточка для линукс-администраторов. Но и безопасников тоже заинтересует. Ещё один подход к сбору системных логов с линукс-серверов — rsyslog + logstash + elasticsearch + kibana. Некто Антуан Солничкин просто и пошагово пишет какие команды и зачем выполнять, чтобы конструкция взлетела. Мануал подойдёт, если нужно быстро запустить мониторинг.

P.S. Посмотрите другие статьи этого автора на Медиуме, пишет он преимущественно про мониторинг причём разными средствами и подробно.

​Трейсинг распределённых приложений в Jaeger (Егерь). Статья для тех, кто ещё не начал использовать Istio.