10 дашбордов Grafana, которые позволяют выявлять инциденты на ранней стадии

Давайте будем реалистами: тысяча графиков не спасет вас в 2 часа ночи. Спасут вас десять правильных графиков, основанных на фундаментальных принципах и настроенные на сигнал, а не на шум. Ниже приведены дашборды, которые я снова и снова видел превращающими «загадочные падения» в «незначительные сбои». Каждый из них объясняет, как он работает, и содержит фрагмент кода, который вы можете адаптировать под себя.

В статье собраны 10 примеров того, что вы можете отобразить в Grafana для быстрой локализации проблемы.

@monitorim_it

Introducing Observable Load Testing = Locust + OpenTelemetry!

Проблема: Традиционное нагрузочное тестирование включает в себя обширную ручную корреляцию данных с бэкэндом и часто заходит в тупик из-за «слепых зон» в коде приложения и распределенных системах.

Решение: Благодаря автоматической инструментации скриптов Locust с помощью OpenTelemetry, нагрузочные тесты теперь будут генерировать сигналы OpenTelemetry. Эта телеметрия нагрузочных тестов передается в платформу мониторинга на основе OTel в режиме реального времени, позволяя визуализировать каждый запрос нагрузочного тестирования и отслеживать всю его транзакцию. Теперь у вас есть полная сквозная видимость — ваши запросы нагрузочного тестирования коррелированы с вашим приложением, инструментированным OTel.

Статья с описанием подхода (на портале medium.com)

Locust — это инструмент с открытым исходным кодом для тестирования производительности и нагрузки HTTP и других протоколов. Его удобный для разработчиков подход позволяет определять тесты в обычном коде Python.

Тесты Locust можно запускать из командной строки или с помощью веб-интерфейса. Пропускную способность, время отклика и ошибки можно просматривать в режиме реального времени и/или экспортировать для последующего анализа.

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

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

Finding “Dead” Metrics and Silent Alerts in Your Monitoring

На этой записи Роман Хавроненко, сооснователь VictoriaMetrica, рассказывает как выявлять и устранять «фантомные» метрики и «скрытые» оповещения с помощью экосистемы VictoriaMetrics. Это если вы еще не знаете, что такое Cardinality Explorer.

r9y.dev

По ссылке выше вы найдете ответ как прокачать практику SRE в вашей организации и пройти путь от 90.0% к 99.999%. Каждый топик на этой карте сопровожден ссылкой с описанием практики, преимуществами её внедрения и ссылками на релевантные материалы.

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

@monitorim_it

Why OpenTelemetry instrumentation needs both eBPF and SDKs

В одном из прошлых постов на канале вы могли прочитать:

Результатом коллаборации Grafana Labs, Splunk, Coralogix, Odigos и многих других членов сообщества стало решение OpenTelemetry eBPF Instrumentation (OBI). Этот продукт основан на Grafana Beyla, которая была пожертвована Grafana Labs в начале этого года. Разработка инструментария eBPF значительно ускорилась после того, как проект перешёл под управление OpenTelemetry. Было добавлено множество новых протоколов, качество повысилось, особенно при масштабном деплое, а тестирование выполняется в 10 раз быстрее.

На днях в блоге Grafana вышла статья про коллаборацию SDK и eBPF в рамках инструментирования при помощи OpenTelemetry — гибридный подход, при котором вы одновременно инструментируете бэкэнд-сервисы с помощью eBPF и SDK. Инструментарий eBPF анализирует приложения извне, на сетевом уровне, а инструментарий SDK анализирует внутреннее поведение.

SDK не предоставляют метрики графа сервисов по умолчанию. В качестве обходного пути можно генерировать метрики графа сервисов из трассировок, предоставляемых распределенной трассировкой. Метрики графа сервисов могут быть сгенерированы либо OpenTelemetry Collector с помощью коннектора графа сервисов , либо на стороне бэкэнда хранилища .

Генерация метрик графа сервисов из трассировок может привести к дополнительным накладным расходам как для отслеживаемых бэкэнд-сервисов, так и для конвейера генерации метрик. При использовании OBI генерация метрик графа сервисов из данных трассировки не требуется, т.к. этот инструмент предоставляет метрики графа сервисов «из коробки». Это позволит в итоге не собирать метрики из трейсов.

@monitorim_it

10 вопросов о наблюдаемости Kubernetes, которые задают на каждом собеседовании в DevOps

Некоторые ответы на некоторые вопросы, если вы планируете собеседоваться на позиции SRE или Observability-инженера.

@monitorim_it

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.