OpsKnight

Центр управления инцидентами с открытым исходным кодом. Весь жизненный цикл инцидента, графики дежурств и страницы состояния — на одной мощной платформе.

OpsKnight — это альтернатива с открытым исходным кодом PagerDuty и OpsGenie, разработанная для команд, которые хотят получить полный контроль над своей системой управления инцидентами без затрат на SaaS-сервисы.

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

Страница проекта

📱 Telegram | 📲 MAX

Opsgenie ушёл, JSM не пришёл: как я собрал собственный incident management с AI

Я посмотрел альтернативы. Ближе всего по общей идее оказался OpsKnight: проект позиционирует себя как open-source self-hosted платформу для incident response, on-call, routing и status pages. На бумаге соседство было почти семейным. Но мой набор требований включал автоматическое создание задач именно в нашей Jira, Slack и eXpress, прозрачную передачу L2 в L3, русский и английский интерфейс, простое развёртывание и предсказуемое поведение в небольшом внутреннем контуре. В моём тестировании OpsKnight с этим набором не совпал и не дал нужной уверенности. Это не универсальный вердикт проекту, а описание моего опыта и моей планки риска.

Описание на Хабр

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

📱 Telegram | 📲 MAX

От firing до postmortem: рабочее место дежурного поверх Grafana и Mattermost

Алертинг у нас построен на правилах Grafana. Сами правила описаны в Terraform, хранятся в Git и применяются через CI/CD-пайплайн. Такой подход даёт review, историю изменений и воспроизводимую конфигурацию вместо ручного редактирования правил в интерфейсе.

Дальше Grafana Alertmanager маршрутизирует уведомления по labels в несколько каналов внутреннего Mattermost. За этими каналами следит дежурная смена. В Grafana также есть отдельная доска, которая выводит активные алерты списком. Она помогла видеть общую картину, но не решила вопрос, что происходит с каждым алертом после доставки.

Во время всплеска нужное сообщение иногда теряется среди десятков похожих. Некоторые алерты горят неделю, а обновления по ним появляются раз в несколько дней и каждый раз начинаются почти с нуля, как будто сигнал пришёл только что. Дежурные меняются и не всегда помнят, разбирали ли этот алерт раньше, занимается ли им другой инженер и кто сейчас ведёт исправление — инфраструктура или команда разработки. Получается своеобразная карусель: алерт продолжает гореть, люди меняются, а контекст приходится восстанавливать заново.

В статье описан подход, при котором вокруг Grafana построен операционный слой: единая карточка алерта, назначение владельца, история повторных срабатываний, автогруппировка связанных алертов, метрики MTTA/MTTR и автоматическая подготовка postmortem с использованием LLM. При этом AI не принимает решений, а только помогает анализировать уже собранные данные — вся логика жизненного цикла алерта остается детерминированной.

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

Читать на Хабре.

📱 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

Мониторинг, который не переживёт собственного падения

В статье разбирается, как при помощи самописного рещения правильно строить healthcheck, бороться с флаппингом и каскадными событиями, обнаруживать crashloop и сделать так, чтобы «тишина» мониторинга сама стала диагностическим сигналом.

Статья на Хабре

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

📱 Telegram | 📲 MAX

How VictoriaLogs Stores Your Logs in a Columnar Layout

В этой статье в блоге VictoriaMetrics рассказывают про путь записи логов: от приёма и преобразования в единый внутренний формат до размещения в потоках, дневных партициях и неизменяемых частях на диске и объясняют, как VictoriaLogs группирует логи по полям потока, разбивает данные на блоки и хранит каждое поле в отдельной колонке. Также разбирается назначение основных файлов внутри партиций, работа bloom-фильтров, двухуровневых индексов и механизмов слияния небольших частей в более крупные.

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

P.S. А мы, как пользователи, продолжаем ждать нативную поддержку хранения в S3. Интересно, когда же уже. Призываю мейнтейнеров VL в комментарии.

Ссылка на статью

📱 Telegram | 📲 MAX

Building a Custom Metrics Exporter for Kubernetes

Kubernetes поставляется со встроенной функцией отслеживания загрузки CPU и использования памяти, но большинство решений по масштабированию в реальных условиях зависят от сигналов, которые находятся за пределами этого узкого диапазона: сколько сообщений ожидает в очереди, сколько времени заняла последняя пакетная задача, сколько активных WebSocket-соединений поддерживает под. Когда встроенных метрик недостаточно, экспортер метрик восполняет этот пробел.

В этой статье подробно описано, как создать такой контейнер с нуля, упаковать его в подобие контейнера и подключить к кластеру, чтобы Prometheus — и в конечном итоге HorizontalPodAutoscaler — могли его использовать.

Статья в блоге Kubernetes

📱 Telegram | 📲 MAX

Как VictoriaLogs хранит логи в колоночной структуре

А вот добрые люди опубликовали перевод оригинальной статьи, о которой я публиковал пост пару дней назад.

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

Читать на Хабре

📱 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 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

Metric cardinality limits in OpenTelemetry: a practical guide

Метрики OpenTelemetry разработаны таким образом, чтобы их было безопасно использовать в проде. Одним из элементов этой безопасности является ограничение кардинальности в SDK метрик. Это ограничение защищает от неограниченного роста объема памяти, когда метрика получает слишком много уникальных комбинаций атрибутов.

Такая защита полезна, но у неё есть последствие, которого многие пользователи не ожидают: при переполнении потока метрик общее значение остаётся корректным, в то время как запросы, фильтрующие или группирующие данные по атрибутам, могут занижать его. Это может повлиять на панели мониторинга, цели уровня обслуживания (SLO) и оповещения, которые выглядели корректно до начала переполнения.

В документации теперь есть раздел Ограничения кардинальности, который объясняет поведение SDK.

Эта статья в блоге OpenTelemetry — оперативное дополнение к этой части документации. В ней объясняется, что означает ограничение на практике, почему это влияет на каждый атрибут измерения, в котором произошло переполнение, как выбрать разумное ограничение, как проверить, достигнуто ли оно уже, и как отслеживать его в проде.

📱 Telegram | 📲 MAX

Mastering Log Rotation in Linux with Logrotate

Logrotate — тот самый компонент, про который обычно вспоминают в двух случаях:

👉 когда закончилось место на диске;

👉 когда после ротации внезапно выяснилось, что приложение продолжало писать не туда

Статья разбирает, что происходит под капотом утилиты: когда использовать size, чем minsize отличается от maxsize, почему create обычно безопаснее и за что можно не любить copytruncate — у него есть небольшое окно, в котором часть логов действительно может потеряться.

Читать в блоге Dash0

📱 Telegram | 📲 MAX

Как мониторить Java-приложения: метрики, алерты и правило 80/20

Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем, а бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения. В Календаре мы называем этот подход правилом 80/20.
Всем привет! Меня зовут Настя, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. В этой статье я покажу, какие метрики стоит взять за основу, как выбирать полезные алерты и чем дополнять базовый набор для оставшихся 20%.

В статье хороший разбор подхода 80/20: какие метрики реально ловят большую часть проблем, зачем следить за RED, лагами очередей, connection pool и JVM, когда нужны бизнес-метрики и SLO, и почему аномалии иногда полезнее очередного статического порога.

Отдельно плюсую за onepager, drill-down и ранбуки. Потому что хороший мониторинг — это не «у нас есть график на всё», а «мы быстро поняли, что сломалось и что делать дальше».

📱 Telegram | 📲 MAX

PromQL Anomaly Detection Framework

Фреймворк строит верхние и нижние границы для метрик, учитывает краткосрочную изменчивость и сезонность, а затем алертит, когда значение выходит за ожидаемый диапазон. Есть несколько стратегий детектирования: от адаптивной на основе среднего и стандартного отклонения до более устойчивой к выбросам через median/MAD.

Поддерживаются типовые сценарии для request rate, latency, errors и resource-метрик, а сами anomaly bands можно накладывать поверх графиков в Grafana.

Хороший вариант, когда хочется добавить динамический anomaly detection поверх обычного Prometheus, не таща отдельную систему анализа временных рядов.

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

📱 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

Что за зверь такой 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

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

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