Dasha — дашборд PostgreSQL

Когда Графиня уже занята, остается Даша. Написана на Go. Дополнительно в качестве источника данных можно подключать Prometheus или VictoriaMetrics.

Dasha анализирует состояние кластеров PostgreSQL, выявляет проблемы и даёт рекомендации по оптимизации.

Статья с описанием на Хабре

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

UPD: в комментах рассказали про еще один похожий инструмент — Powa.

📱 Telegram | 📲 MAX

Observability в одном Go-бинарнике: как я собрал self-hosted без Kafka и Redis

Мне нужна была observability для собственных сервисов, и хотелось держать её у себя: логи ошибок — часто самые чувствительные данные в системе, и отдавать их наружу не хотелось. Официальный self-hosted-вариант знакомого стека — серьёзная инсталляция: приёмник, брокер, воркеры, кэш, отдельное аналитическое хранилище — в референсном docker-compose набегает под два десятка контейнеров. Для одного человека и нескольких проектов это несоразмерно: такое надо не только поднять, но и обновлять, чинить и держать в памяти.

Тогда я задал себе вопрос: сколько из этого действительно необходимо, если цель — self-hosted-инстанс на небольшой и средний объём? Ответ оказался неожиданным — почти ничего. Так появилась Gotcha: один Go-бинарник поверх двух баз, который принимает ошибки, трейсы, метрики, профили и аптайм.

Статья с подробностями на Хабре.

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

Сайт проекта

📱 Telegram | 📲 MAX

One-command OpenTelemetry setup on Linux hosts

Множество приложений на Java, .NET, Node.js и Python, работающие на Linux-хостах, до сих пор не имели автоматизации. Для их мониторинга приходилось вручную загружать агенты и самостоятельно настраивать переменные окружения. На конференции OTel Unplugged EU в Брюсселе в феврале этого года постоянно звучал один и тот же вопрос: понятные инструкции по упаковке, установке и использованию. Вы просили:

{apt|yum} install opentelemetry

И теперь вы действительно можете это сделать!

Этот пакет устанавливает OpenTelemetry Injector вместе с SDK OpenTelemetry и пакетами автоматической инструментации для Java, .NET, Node.js и Python. Injector подключается к запуску процессов на хосте и активирует соответствующую автоматическую инструментацию для приложений без изменений в коде приложения или скриптах деплоя.

Подробнее в блоге OpenTelemetry

📱 Telegram | 📲 MAX

Gartner Magic Quadrant for Observability Platforms 2026

Вот так выглядит расклад сил в этом году. Каких-то больших сюрпризов нет — всё достаточно ожидаемо.

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

Один из ключевых трендов, который отмечает Gartner, — контроль стоимости observability. Всё больше компаний обращают внимание на поддержку Bring Your Own Cloud/Storage (BYOC/BYOS), инструменты управления затратами, оптимизацию объёмов хранимой телеметрии и прозрачность расходов.

История из практики

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

Стоит ли на этом фоне задумываться о миграции? Думаю, что да, но не обязательно делать это сразу. Хорошим первым шагом может стать переход с проприетарных агентов на OpenTelemetry. Это позволит отправлять телеметрию сразу в несколько бэкендов, например ClickStack, VictoriaMetrics (VM/VL/VT) или Grafana Stack. Такой подход даст возможность постепенно переносить часть данных в альтернативную платформу, сравнить результаты в реальной эксплуатации и уже потом принять взвешенное решение — нужна миграция полностью или текущая система по-прежнему оправдывает свои затраты.

📱 Telegram | 📲 MAX

Migrate Datadog telemetry with the OpenTelemetry Collector

Если вы используете коммерческую APM (Dynatrace, Datadog, Appdynamics, Ключ Астром и пр.), она, скорее всего, совместима с OTel. А раз совместима, то и лить данные можно при помощи инструментов OTel. А раз вы уже используете инструменты OTel, то почему б не присмотреться к OTel-совместимой платформе ClickStack?

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

Пример переезда с Datadog на ClickStack в блоге ClickHouse

📱 Telegram | 📲 MAX

endpoint-monitoring-operator

Легковесный, расширяемый оператор Kubernetes, который проверяет любой эндпоинт — HTTP/JSON, TCP, DNS, ICMP, Trino, OpenSearch и другие — и направляет оповещения в Slack или по электронной почте.

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

📱 Telegram | 📲 MAX

Особенности SRE в мобильном банкинге: подходы, вызовы и специфика

Однажды мы отключили проблемные функции на Android с помощью конфигурационной заглушки. Через 15 минут система зафиксировала резкий рост крашей — но уже на iOS. Оказалось, что решение, безопасное для одной платформы, сломало приложение на другой.

Этот случай еще раз подтвердил, что mobile SRE не классический SRE и в нем нельзя полагаться на привычные практики. Нет ни отката, ни новых логов задним числом, ни полного контроля над средой.

В статье — как в Т-Банке адаптируют SRE‑подходы под мобильный банкинг, где фронт работает на миллионах устройств, которые не контролируются.

📱 Telegram | 📲 MAX

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