Мониторим ИТ

Observability на стероидах Владимир Гордийчук, CTO Yandex Monium, в подкасте linkmeup рассказал о том, как появился Monium, как устроен внутри, что они для себя оптимизировали и почему Prometheus не справился. Понимаю, что слушать почти 2 часа запись это же сколько нужно свободного времени, поэтому я совместил прослушивание с силовой тренировкой и мне очень даже зашло. Ниже некоторые из ключевых тезисов подкаста (тут отдельная благодарность нейросказу, встроенному в Яндекс Браузер): ⚡️ Monium появился как система мониторинга для команды YDB (Yandex Database). Поэтому неудивительно, что в качестве бэкэнда хранения используется именно эта БД. Еще там есть собственная TSDB и даже ClickHouse. ⚡️ Предпосылкой к созданию система стала невозможность использования существующих решений. Яндексу нужно было собирать высококардинальные метрики. ⚡️ Внутри Яндекс в Мониум передается 3 миллиарда сэмплов в секунду и около 60 гигабайт логов в секунду. ⚡️ Мониум может использоваться независимо от Яндекс.Облака. ⚡️ Философия Мониума основана на принципе real-time мониторинга, т.е. данные попадают в систему через считанные секунды. ⚡️ Яндекс разработал свой бинарный протокол для обмена данными SPAC, что снизило накладные расходы на передачу данных. ⚡️ Протокол Protobuf требует много ресурсов для парсинга на больших объёмах данных. ⚡️ JSON неэффективен при передаче данных между системами, но удобен при взамодействии с ним человека. ⚡️ Monium имеет встроенный функционал агрегации алертов. ⚡️ В Monium есть встроенный функционал расчета SLO. ⚡️ В Monium есть встроенный функционал поиска аномалий. 📱 Telegram | 📲 MAX

Incident Relay Incident Relay закрывает базовый incident workflow: маршрутизация алертов, дежурства и ротации, ACK/Resolve, напоминания, эскалации, silences и maintenance windows. Из коробки есть интеграции с Zabbix, Grafana, Alertmanager, Datadog, Sentry и другими источниками, а уведомления можно отправлять в Telegram, Slack, Mattermost, Teams, email, webhook и даже голосовыми звонками. Плюс всё можно держать у себя — Docker, Kubernetes/Helm или обычный systemd/RPM. В общем, практичный вариант для команд, которым нужен on-call без SaaS и с полным контролем над маршрутизацией алертов. Я на это решение пока не смотрел, но выглядит интересно. Репыч на Гитхаб Статья на Хабре 📱 Telegram | 📲 MAX

Что за зверь такой Exponential Histogram Во вчерашнем посте про обновления в ClickStack я в том числе упомянул exponential histograms. Это интересная штука, которая может быть весьма полезна для автоматизации мониторинга. А вдруг вы про неё не знаете 🙃 Или знаете, но в качестве Prometheus Native Histogram. Exponential histogram — это тип гистограммы в OpenTelemetry, где границы бакетов задаются не вручную, а вычисляются по экспоненциальной шкале. Она нужна для метрик с большим динамическим диапазоном, например, latency, где значения могут быть и 1 мс, и 10 секунд. Главное преимущество такого подхода — не нужно заранее угадывать диапазоны значений. Границы диапазонов при режиме explicit histogram могут задаваться в коде приложения или на уровне OpenTelemetry SDK. Если специально не определить в настройках exponential histogram, то применится explicit histogram с интервалами по умолчанию. А вот примеры использования exponential histogram. Под капотом это работает так В exponential histogram бакеты строятся автоматически по экспоненте. OpenTelemetry определяет base (коэффициент роста границ соседних бакетов) через параметр scale (разрешение гистограммы): base = 2^(2^(-scale)) Чем выше scale, тем больше бакетов и тем выше точность. Например, при scale=3 между соседними степенями двойки будет 8 бакетов. Для примера посмотрите на приложенное изображение, а также на схему ниже: scale = 3 |--|--|--|--|--|--|--|--| scale = 2 |----|----|----|----| scale = 1 |--------|--------| При использовании exponential histogram возникает вопрос: какие buckets выбрать? Если сделать их слишком широкими — потеряется точность. Если слишком много — увеличится объём данных. Exponential histogram автоматически распределяет значения по шкале и позволяет одновременно хорошо описывать очень маленькие и очень большие значения. А еще гистограмму можно понижать в разрешении без пересчёта исходных измерений. У exponential histogram разные scale согласованы между собой: бакеты более высокой детализации можно объединить в более грубые. Это удобно для агрегации телеметрии в OTEL-коллекторе или бэкэнде. А вы используете у себя exponential histogram? 📱 Telegram | 📲 MAX

Whats new in ClickStack - June + July Не знаю, заметили вы или нет, но команда ClickStack настолько увлеклась допиливанием новых фичей, что забыла выпустить статью с пакетом обновлений июня. И вот теперь вышла публикация с обновлениями сразу за 2 месяца. ClickStack продолжает превращаться из ClickHouse для логов в полноценную observability-платформу. Они прокачали трейсы, добавили экспериментальную интеграцию с внешним Prometheus (вслед за OpenSearch и ElasticSearch), добавили поддержку экспоненциальных гистограмм, сделали алерты более умными, появился новый функционал дашбордостроения и расширили MCP Server. А еще команда ClickStack добавила ресивер для Datadog-агента, тем самым намекнув, что решение от Datadog можно не выкидывать сразу, а подключать к ClickStack и мигрировать постепенно. Кажется, это первая ласточка: следом они наверняка добавят ресивер для OneAgent от Dynatrace (и аналогов), предлагая более простые способы миграции на открытые платформы. Война за доминирование на observability-поляне становится всё интереснее. Читать статью в блоге ClickHouse 📱 Telegram | 📲 MAX

Почему 99% AI-агентов не доживают до продакшена? Вы тратите недели на разработку «умного» агента, а в итоге — счёт за сожжённые токены и грустный архив в GDrive. Знакомо? В новой статье экспертразбирает 5 главных причин: 🔹Недетерминированность 🔹Безграничная автономность 🔹Передача контекста — самая больная тема 2026 года. 🔹Тестирование — мокировать нейронку бесполезно, а семантические матчеры никто не настраивает. 🔹Мониторинг — как понять, что агент «ведёт себя разумно»? (Подсказка: KPI для людей тут работают лучше нейросетей). В статье —живые примеры, фрагменты кода (Ruby, семантическое сравнение), чёткий роадмап внедрения👇 ЗАБРАТЬ СТАТЬЮ В БОТЕ

PromQL Anomaly Detection Framework Фреймворк строит верхние и нижние границы для метрик, учитывает краткосрочную изменчивость и сезонность, а затем алертит, когда значение выходит за ожидаемый диапазон. Есть несколько стратегий детектирования: от адаптивной на основе среднего и стандартного отклонения до более устойчивой к выбросам через median/MAD. Поддерживаются типовые сценарии для request rate, latency, errors и resource-метрик, а сами anomaly bands можно накладывать поверх графиков в Grafana. Хороший вариант, когда хочется добавить динамический anomaly detection поверх обычного Prometheus, не таща отдельную систему анализа временных рядов. Репыч на Гитхаб 📱 Telegram | 📲 MAX

В Беларуси внедрили онлайн-полигон для расследования кибератак   Облачный провайдер beCloud уже несколько лет развивает собственный SOC с выстроенными процессами мониторинга и реагирования. Теперь команда будет регулярно тренироваться на сценариях сложных атак в Standoff Defend Pro компании Positive Technologies.   В программе — 12 сценариев APT-атак, основанных на тактиках и техниках реальных группировок, сценарии по мотивам кибербитв Standoff и более 100 практических кейсов: от отдельных этапов до полных цепочек атак.   Плюс менторство экспертов Positive Technologies и регулярные разборы результатов.   Для зрелой команды это уже не про то, как пользоваться средствами защиты. Важнее другое: как аналитики действуют, когда привычного сценария нет, насколько быстро проверяют гипотезы, связывают события между собой и обмениваются результатами.   Именно это beCloud будет отрабатывать на полигоне до конца года.

Как мониторить Java-приложения: метрики, алерты и правило 80/20 Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем, а бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения. В Календаре мы называем этот подход правилом 80/20. Всем привет! Меня зовут Настя, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. В этой статье я покажу, какие метрики стоит взять за основу, как выбирать полезные алерты и чем дополнять базовый набор для оставшихся 20%. В статье хороший разбор подхода 80/20: какие метрики реально ловят большую часть проблем, зачем следить за RED, лагами очередей, connection pool и JVM, когда нужны бизнес-метрики и SLO, и почему аномалии иногда полезнее очередного статического порога. Отдельно плюсую за onepager, drill-down и ранбуки. Потому что хороший мониторинг — это не «у нас есть график на всё», а «мы быстро поняли, что сломалось и что делать дальше». 📱 Telegram | 📲 MAX

Mastering Log Rotation in Linux with Logrotate Logrotate — тот самый компонент, про который обычно вспоминают в двух случаях: 👉 когда закончилось место на диске; 👉 когда после ротации внезапно выяснилось, что приложение продолжало писать не туда Статья разбирает, что происходит под капотом утилиты: когда использовать size, чем minsize отличается от maxsize, почему create обычно безопаснее и за что можно не любить copytruncate — у него есть небольшое окно, в котором часть логов действительно может потеряться. Читать в блоге Dash0 📱 Telegram | 📲 MAX

Знакомая конфигурация: Zabbix + Prometheus + Grafana + пачка скриптов, всё это держится на одном инженере, а при инциденте картина сшивается руками из трёх систем. Работает — пока этот инженер не ушёл в отпуск. Или просто не ушёл. Мы сделали Voltir — managed-платформу мониторинга для среднего бизнеса (50–500 сотрудников): ⚡️ Метрики, логи и трейсы в одной платформе — стек VictoriaMetrics cluster / VictoriaLogs / VictoriaTraces, честная изоляция тенантов ⚡️ Настройку, алертинг и сопровождение берём на себя — включая разбор ложных срабатываний. Вашей платформенной команды не требуется, потому что ею работаем мы ⚡️ Мониторинг 1С из коробки: APDEX, техжурнал, метрики кластера — реальный экспортёр в агенте, а не строчка в буклете ⚡️ Агент ставится за день: Linux, Windows, SNMP, докер-контейнеры Платформу строит инженер, а не отдел продаж — в канале показываем кухню изнутри: архитектуру, грабли прода, инциденты и что они поменяли в продукте. 👉 Канал: t.me/Voltir_tech · Сайт и демо: voltir.tech Реклама. Водинский Иван Юрьевич, ИНН 400331598671, erid: 2VtzqvjyPZD

Metric cardinality limits in OpenTelemetry: a practical guide Метрики OpenTelemetry разработаны таким образом, чтобы их было безопасно использовать в проде. Одним из элементов этой безопасности является ограничение кардинальности в SDK метрик. Это ограничение защищает от неограниченного роста объема памяти, когда метрика получает слишком много уникальных комбинаций атрибутов. Такая защита полезна, но у неё есть последствие, которого многие пользователи не ожидают: при переполнении потока метрик общее значение остаётся корректным, в то время как запросы, фильтрующие или группирующие данные по атрибутам, могут занижать его. Это может повлиять на панели мониторинга, цели уровня обслуживания (SLO) и оповещения, которые выглядели корректно до начала переполнения. В документации теперь есть раздел Ограничения кардинальности, который объясняет поведение SDK. Эта статья в блоге OpenTelemetry — оперативное дополнение к этой части документации. В ней объясняется, что означает ограничение на практике, почему это влияет на каждый атрибут измерения, в котором произошло переполнение, как выбрать разумное ограничение, как проверить, достигнуто ли оно уже, и как отслеживать его в проде. 📱 Telegram | 📲 MAX

VictoriaLogs Deployment: Single Node vs Cluster Mode — A Comprehensive Guide В статье разбираются оба варианта: single-node и cluster mode, с практическими примерами установки, настройкой Filebeat, подключением Grafana и базовым алертингом. Ключевая мысль простая: single-node хорошо подходит для небольших и средних нагрузок, а кластер имеет смысл разворачивать, когда появляются требования к горизонтальному масштабированию, высокой доступности и устойчивости при больших объёмах логов. Автор показывает архитектуру кластера VictoriaLogs: vlinsert принимает данные, vlstorage отвечает за хранение, а vlselect — за запросы. Также есть понятный сценарий миграции с одной ноды на кластер без полной перестройки ingestion-пайплайна. В статье разбираются оба варианта: single-node и cluster mode, с практическими примерами установки, настройкой Filebeat, подключением Grafana и базовым алертингом. Ключевая мысль простая: single-node хорошо подходит для небольших и средних нагрузок, где важны простота и экономия ресурсов. Кластер имеет смысл, когда появляются требования к горизонтальному масштабированию, высокой доступности и устойчивости при больших объёмах логов. Автор показывает саму архитектуру кластера VictoriaLogs: vlinsert принимает данные, vlstorage отвечает за хранение, а vlselect — за запросы. Плюс есть понятный сценарий миграции с одной ноды на кластер без полной перестройки ingestion-пайплайна. Читать статью на medium.com 📱 Telegram | 📲 MAX

Choosing Between ClickStack and Grafana for ClickHouse Observability Кажется, в observability снова выбор без выбора: Grafana или ClickStack? Статья разбирает вопрос выбора на примере ClickHouse. Если ClickHouse — центральное хранилище телеметрии, а инженеры чаще расследуют инциденты, чем смотрят на заранее созданные графики, авторы предлагают смотреть в сторону ClickStack: поиск, корреляция логов, метрик и трейсов, session replay и отдельный акцент на AI/SRE-агентов через MCP. Grafana остаётся сильнее там, где инфраструктура неоднородная: Prometheus, ClickHouse и ещё десяток источников, которые нужно собрать на одном дашборде, добавить алертинг и не заставлять команду менять привычные процессы. Так как статья опубликована в блоге Clickhouse, практичный вывод напрашивается сам собой: «А зачем выбирать?» Grafana можно оставить для дашбордов и мониторинга, а ClickStack использовать для глубоких расследований по данным ClickHouse. Причём данные и ingestion pipeline дублировать не придётся. Как вам такой подход? Ссылка на статью 📱 Telegram | 📲 MAX

Как VictoriaLogs хранит логи в колоночной структуре А вот добрые люди опубликовали перевод оригинальной статьи, о которой я публиковал пост пару дней назад. В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go. Читать на Хабре 📱 Telegram | 📲 MAX

Сообщество инженеров сопровождения Сбера продолжает агентизировать города. 📆13 августа собираем OPS, DevOps и SRE-инженеров Самары в необычном формате и только офлайн. ⛴Курсируем по Волге на двух теплоходах, где в формате барных стендапов и дискуссий обсудим, что умеют агенты в OPS, а что пока нет, как мы строим надёжность, как реагируем на инциденты, куда ведёт агентизация и что с этим делать. 13 августа, 18:30 Самара, Теплоходы "Вояж" и "Спутник" 👉Регистрация тут Количество очных мест ограничено

Building a Custom Metrics Exporter for Kubernetes Kubernetes поставляется со встроенной функцией отслеживания загрузки CPU и использования памяти, но большинство решений по масштабированию в реальных условиях зависят от сигналов, которые находятся за пределами этого узкого диапазона: сколько сообщений ожидает в очереди, сколько времени заняла последняя пакетная задача, сколько активных WebSocket-соединений поддерживает под. Когда встроенных метрик недостаточно, экспортер метрик восполняет этот пробел. В этой статье подробно описано, как создать такой контейнер с нуля, упаковать его в подобие контейнера и подключить к кластеру, чтобы Prometheus — и в конечном итоге HorizontalPodAutoscaler — могли его использовать. Статья в блоге Kubernetes 📱 Telegram | 📲 MAX

How VictoriaLogs Stores Your Logs in a Columnar Layout В этой статье в блоге VictoriaMetrics рассказывают про путь записи логов: от приёма и преобразования в единый внутренний формат до размещения в потоках, дневных партициях и неизменяемых частях на диске и объясняют, как VictoriaLogs группирует логи по полям потока, разбивает данные на блоки и хранит каждое поле в отдельной колонке. Также разбирается назначение основных файлов внутри партиций, работа bloom-фильтров, двухуровневых индексов и механизмов слияния небольших частей в более крупные. Главная идея архитектуры: сначала прочитать небольшой объём метаданных и исключить ненужные данные, а уже затем обращаться к конкретным блокам, колонкам и значениям. За счёт этого запросы не сканируют весь объём логов, а читают только необходимые данные. P.S. А мы, как пользователи, продолжаем ждать нативную поддержку хранения в S3. Интересно, когда же уже. Призываю мейнтейнеров VL в комментарии. Ссылка на статью 📱 Telegram | 📲 MAX

Мониторинг, который не переживёт собственного падения В статье разбирается, как при помощи самописного рещения правильно строить healthcheck, бороться с флаппингом и каскадными событиями, обнаруживать crashloop и сделать так, чтобы «тишина» мониторинга сама стала диагностическим сигналом. Статья на Хабре Репыч на Гитхаб 📱 Telegram | 📲 MAX

Все проверки зелёные, а данных нет: как мониторить gRPC server‑side стримы Стандартная (для многих) история. Отдаём какие‑то данные в реальном времени через server‑side web‑gRPC стримы. Цепочка: балансировщик, дальше Envoy с grpc‑web, дальше бэкенд. Все проверки зелёные: TCP поднят, хендшейк проходит, /healthz отвечает 200, в графане/slack'e тишина. А фронтенд у клиентов замёрз. И узнали мы об этом от клиентов, а не от мониторинга. В статье описание механизма работы демона, который по расписанию подгружает.proto на лету через proto‑loader, открывает server‑side RPC как обычный клиент, ждёт кадров (например 3) в бюджет времени и валидирует каждый кадр. Статья на Хабре Репыч на Гитхаб 📱 Telegram | 📲 MAX

Почему классический мониторинг перестал работать для ИИ-агентов? Observability для агентов устроена иначе, чем для обычных сервисов. В классическом мониторинге инфраструктура может быть полностью «зелёной»: latency в норме, ошибок нет. Но агент при этом может уверенно дать неверный ответ или уйти в бесконечный цикл вызовов. Для анализа таких кейсов нужно знать контекст, который был на каждом шаге работы агента: каким был промпт пользователя и системный промпт, ответ модели, запросы и ответы инструментов. Именно для этих задач мы и интегрировали Monium Traces в Yandex AI Studio. Что можно посмотреть в трейсах: • системный и пользовательский промпты; • ответы модели; • вызовы инструментов; • контекст каждого шага выполнения агента. По сути, это возможность «проиграть» работу агента шаг за шагом и понять, в какой момент он свернул не туда. Для сложных RAG-сценариев, агентных пайплайнов и интеграций с внешними инструментами такой уровень прозрачности становится необходимостью. Функциональность уже можно протестировать на своих агентах и посмотреть, как оно работает в реальных сценариях.