12 дашбордов для дежурных, которые успокаивают всех

В этой статье приведены примеры 12 дашбордов для Grafana, которые хорошо помогают быстро диагностировать проблему. Опыт и еще раз опыт.

@monitorim_it

Автоматизированные процессы реагирования на инциденты с помощью n8n и Prometheus

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

@monitorim_it

Приглашаю вас на новый Продвинутый курс по OpenSearch (продолжение курса База)

❗️ Специальные условия для физических лиц при оплате до конца текущего года.

📅 Когда: 18-20 марта 2026 года

👨‍💻 Для кого: для тех, кто уже имеет опыт работы с OpenSearch и хочет углубить знания, а также улучшить кругозор в продукте.

🎁 Зачем идти на курс: формат интенсива предполагает быстрое погружение в продукт и закрепление теоретических знаний выполнением практических заданий. Сразу после курса вы сможете применить полученные знания в вашем продукционном окружении.

📖 Что ждет на курсе:

🔎 День 1

🚀 Безопасность в OpenSearch. Работа с ролевой моделью. Ограничения для пользователей: настройка безопасности на уровне документов и полей документов. Аудит-лог. Интеграция с LDAP.

🚀 Распределенная архитектура OpenSearch. Кросс-кластерная репликация. Кросс-кластерный поиск. Отказоустойчивая архитектура OpenSearch. Кворум мастер-нод. Split-brain.

🚀 Продвинутые технологии репликации данных: подокументная и сегментная репликации. Разделение шардов по назначениям: индексация и поиск. Контроль рабочей нагрузки.

🚀 Доступность и восстановление. Продвинутая настройка политики ISM. Создание снапшотов и восстановление из них. Работа с searchable snapshots в хранилище S3.

🔎 День 2

🚀 Эффективная работа с данными. Оптимизация хранения данных. Типы полей. Продвинутый маппинг полей. Настройки индексов для оптимального хранения.

🚀 Загрузка данных. Работа с Vector, Logstash, DataPrepper, OpenTelemetry Collector, Ingest Pipeline. Настраиваем эффективные пайплайны и портируем пайлайны из одного ETL-инструмента в другой.

🚀 Работа с PPL, DQL и DSL. Эффективный поиск по данным.
Мониторинг кластера. Сбор ключевых метрик. Prometheus, Zabbix, Performance Analyzer.

🔎 День 3

🚀 Работа в OpenSearch Dashboards. Ролевая модель. Мультитенантность. Продвинутые визуализации. Создание PNG и PDF-отчетов.

🚀 Работа с Observability. Создание визуализаций для данных наблюдаемости (логи, трейсы, метрики). Работа с Notebooks.

🚀 Оповещения. Настройка уведомлений из OpenSearch и OpenSearch Dashboards.

Подробнее о курсе на специальной странице. Там же можно оставить заявку на обучение и узнать другие подробности. Вопросы по курсу вы можете задать по почте hello@gals.software или в телеграм @galssoftware.

Реклама. ООО «Галс Софтвэр», ИНН 5047195298, erid 2VtzquYcAp6

pixie

Pixie — это инструмент мониторинга с открытым исходным кодом для приложений Kubernetes. Pixie позволяет просматривать общее состояния кластера (карты сервисов, ресурсы кластера, трафик приложений), а также, для более детального анализа, состояние пода, графики, отдельные запросы приложений.

Три ключевых возможности инструмента:

🚀 Автоматическая телеметрия: Pixie использует eBPF для автоматического сбора телеметрических данных, таких как полные запросы, метрики ресурсов и сети, профили приложений и многое другое. Полный список источников данных можно посмотреть здесь .

🚀 Внутрикластерные вычисления: Pixie собирает, хранит и запрашивает все телеметрические данные локально в кластере. Pixie использует менее 5% ресурсов CPU кластера, а в большинстве случаев — менее 2%.

🚀 Возможность использования скриптов: PxL, гибкий язык запросов на языке Python, разработанный Pixie, может использоваться во всех компонентах пользовательского интерфейса Pixie, интерфейса командной строки и клиентских API.

Репыч на Гитхаб

2025 vs 2026 в наблюдаемости

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

В этом году выходило много постов про разные платформы, подходы к мониторингу, но больше всего было про OpenTelemetry, который становится все популярнее. 2025 окончательно закрепил OTel как де-факто стандарт телеметрии:

📈 OTel Metrics → заменяют Prometheus-экспортеры в новых проектах
📜 OTel Logs → активно внедряются вместо собственных форматов
🕸 OTel Traces → стали базовой точкой входа для APM

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

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

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

Логи — приятное дополнение к метрикам и трейсам, которые ответят на вопрос «почему болит». В логировании важны стандарты (что записывать, а что нет), борьба с лог-спамом, внедрение семплирования, log-budgeting. На эти процессы нужно обратить особое внимание. Где-то прочитал хорошую фразу: логи — не хранилище совести, а инструмент анализа.

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

2026:

Уже в этом году был тренд на единое хранилище, в 2026 году он будет усиливаться. Системы вроде ClickHouse и другие колоночные СУБД имеют большое преимущество.

Вместо «сначала собрали всё — потом поняли, что дорого» → «сначала решили, что нам нужно — потом собрали». Систем все больше, данных больше и счета за хранение и обработку тоже постоянно растут. Поэтому становится критически важным оптимизация на этапе обработки (семплинг, нормализация на уровне коллекторов) и на этапе хранения (выбор оптимального бэкэнда хранения).

В новом 2026 году мы будем больше говорить об оптимизации логирования, выборе бэкэнда хранения и снижении стоимости хранения и обработки данных. Остаемся на связи!

@monitorim_it

🎉 Дорогие подписчики ! 🎉

Поздравляю вас с новым 2026 годом!

📈 Пусть метрики растут только те, которые должны расти — количество пользователей и выручка!

📜 Логи пусть будут информативными, а не загадками в стиле «something went wrong but we don't know what».

🕸 Пусть трейсы ведут к конкретной причине, вместо путешествия по микросервисам, где каждый отвечает: Проблема не на нашей стороне».

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

И пусть мониторинг будет не источником боли, а системой раннего предупреждения, которая действительно предупреждает, а не устраивает квест на внимательность в 3 часа ночи.

Спасибо, что Мониторите ИТ вместе со мной ❤️ До встречи в новом году!

Инцидент-менеджмент с нуля: практический гайд для растущих команд

3 часа ночи. Звонок от незнакомого номера. ”Пользователи не могут залогиниться, п****ц”.

Вы лихорадочно листаете Slack. Непонятно, где проблема и кого будить. Подняли тестеров — они тоже гадают. Бэкенд? Инфра?

Идёте во флудилку в телеге, ищете похожий ник тимлида. Не отвечает. Кто замещает - никто не знает. Начинается массовый обзвон. Через 40 минут находится человек. Смотрит код. “Не моё. Это к Сане — он, кажется, редирект криво поменял в гугл клауд консоли”. Ещё 20 минут — поиск Сани, доступы только у него.

Утром все разбитые. CTO вопрошает. И становится ясно: баг простой. Проблема не в коде. Проблема в бардаке.

Знакомо? Я тоже через это прошел. И после такой ночи решил: хватит. Нужна система.

Эта статья для тех, кто сталкивается с проблемами при организации дежурных команд, приоритизации инцидентов и системными проблемами с эскалациями.

Автор в статье также упоминает собственную разработку — duty_bot. Это бот для управления дежурствами через телеграм.

@monitorim_it

OTel Injector

В дни новогодних праздников хотелось бы рассказать об одном малоизвестном решении — OTel Injector. Если вам нужно быстро что-то заинструментировать.

Этот инструмент был анонсирован где-то полгода назад, когда стало известно, что широко известный в узких кругах Splunk пожертвовал свои наработки в OpenTelemetry (как и Grafana некогда задонатила свою Beyla). Пишут, что решение имеет стабильность, пригодную для работы в прод-средах.

Инструмент был разработан для традиционных окружений (не микросервисных) или легаси-приложений, устанавливается на виртуалку в виде предкомпилированного пакета и использует механизм LD_PRELOAD. Это означает, что инструментироваться будет любое приложение, основанное на Java, Node.js или .NET сразу после его запуска. Но можно также заинструментировать что-то определенное из systemd. На схеме, приложенной к этому посту есть схема его работы.

После установки в вашем распоряжении будет библиотека /usr/lib/opentelemetry/libotelinject.so, которая будет использоваться при запуске вашего приложения. Предварительно нужно определить переменные в конфигурационных файлах, чтобы указать эндпоинт OTEL-коллектора, протокол передачи данных, имя сервиса и другой контекст. Далее будет использоваться один из агентов автоинструментации Java, Node.js, .NET.

Репыч на Гитхаб

Статья на medium с подробностями работы

@monitorim_it

Снизить кардинальность метрик

3 часа ночи, у вас красный дашборд, неделю назад вы дропнули user_id в угоду оптимизации хранения данных, но запросы все равно отрабатывают жутко медленно. Идентификаторы типа container_id, customer_tenant_id, request_trace_id, user_id, feature_flag_version или commit_sha — не просто метрики. Это важные параметры, необходимые для отладки сложных систем.

Несколько очевидных стратегий:

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

Один из способов выполнения агрегаций — это использование stream aggregation в vmagent от VictoriaMetrics. В этом видео кофаундер VM Роман Хавроненко рассказывает как это работает.

P.S. Это не единственный способ агрегации. Похожий функционал есть и в других инструментах, например, OTEL Collector.

Наблюдаемость .NET-сервисов с помощью OpenTelemetry (traces/metrics/logs). Практический пример

Практический пример:

Поднимаем стенд в docker-compose (gateway + api + postgres + otel-collector + SigNoz/ClickHouse).

Делаем 3 запроса: быстрый / медленный / с исключением.

Смотрим в SigNoz трейсы (включая DB span), метрики и логи с привязкой к trace_id.

Разбираем, как это конфигурируется в .NET (Resource, OTLP export, логирование).

В этой статье показано как с нуля подключить OpenTelemetry в ASP.NET Core проект и получить полноценную наблюдаемость: распределённые трейсы, метрики и логи.

@monitorim_it

VictoriaLogs в Kubernetes: от установки до практического применения

Гигантская статья на Хабре по устройству VictoriaLogs с воркшопом по установке и настройке. Прочитайте, если рассматриваете этот инструмент в качестве бэкэнда для хранения логов.

@monitorim_it