​Статья от начала декабря на Хабре о том, как ИТ-Град создавал объединенную систему мониторинга как услугу для облачных сервисов МТС, собственного 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.

​Про систему мониторинга, которая строит графы из элементов приложения, а потом при помощи искусственного интеллекта ищет корневую причину проблемы уже писал в канале. То был Fixstream, кстати. Основа для работы алгоритма — netflow-трафик от сетевых устройств. Кроме netflow, конечно, ещё используются данные из CMDB и события из других систем мониторинга.

Сегодня расскажу про кое-что попроще. На просторах гитхаба обнаружил репозиторий с клёвой штукой, которая называется skydive. Чем она хороша? Помимо бесплатности еще много чем.

Skydive в режиме реального времени достаёт данные по netflow из базы данных Elasticsearch. Есть коннекторы к OpenStack, Docker, OpenContrail и Kubernetes.

Я уже давно считаю, что анализ netflow — недооценённая технология мониторинга и её стоило бы использовать активнее. А тем более это делать для распределённых приложений.

Вы только посмотрите какие интерактивные графы ↑

​Поднимите руки кто знает Instana. Это observability-система для контроля распределённых (=микросервисных) приложений. Очень крутая и динамично развивающаяся, как говорится. Самое охрененское — это их визуализации. Больше так никто не делает. Причём все технологии контролируются одним единственным агентом, который после установки на сервер сам распознает что там и как работает. Распространение агентов заточено под использование CI/CD. По деньгам они получаются дешевле Appdynamics или New Relic, если посчитать стоимость за агента.

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

Если хотите пилот на вашей инфре или просто узнать больше — пишите в личку.

👍 — слышал про Instana и считаю интересным решением

👎 — я свой Jaeger, OpenTracing или <свой вариант> не променяю на платное решение

👀 — у меня монолитное приложение, работает на физическом сервере в кладовке и мне не до ваших распределённых глупостей

​Посмотрите на эту картинку. Да, это из известной сказки, в которой лживый мальчик кричал «Волки! Волки!» в то время, когда волки доедали каких-то других козлят. А когда волки пришли за его козлятами — никто не прибежал с вилами на помощь.

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

1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.

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

3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».

4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.

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

6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.

7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).

Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.

​Мониторинг – это очень важная штука, которую нужно иметь. Это все понимают. Но в то же самое время мониторинг не относится к бизнес-продукту и на напрямую не влияет на прибыль компании, поэтому на мониторинг всегда уделяют время по остаточному принципу. Если у нас есть время, то мы занимаемся мониторингом, если времени нет, то ОК, поставим в бэклог и когда-нибудь вернемся к этим задачам.

Согласны? Голосуйте в конце поста: 👍 — согласен, 👎 — не согласен. В комментах можно написать развёрнутый ответ.

По этой ссылке вы найдёте расшифровку доклада и сам доклад Алексея Лесовского — PostgreSQL DBA в компании Data Egret. Он рассказывает об информативных точках мониторинга БД PostgreSQL.

В конце статьи вы найдёте ссылки на репозитории проектов на гитхабе для мониторинга PostgreSQL.

​Подвезли стафф для линукс-администраторов. Ещё одна интересная статья от уже известного вам Антуана Солничкина, на которую стоит обратить внимание. Пишет про мониторинг MySQL при помощи специализированного экспортера для Prometheus и создании бизнес-дашборда в Grafana. Там есть список ключевых метрик и парав видосов с объяснениями.

И ещё вдогонку к предыдущему посту. Статья о мониторинге DIsk I/O на Linux-системах при помощи Prometheus c небольшим рассказом о том, как устроена файловая система в Linux.