Мониторим ИТ

Весь стек мониторинга внутри одноплатника. Telegraf, InfluxDB и Grafana на процессоре RK3568

Частый кейс в промышленной инженерии — предположим, понадобилось снимать телеметрию с управляемых iPDU в стойке. Стандартный маршрут включает виртуалку под Zabbix, рядом SQL-база, сверху веб-интерфейс, дальше по вкусу облако и оплата за хранение данных. В этом кейсе другой стек — Telegraf, InfluxDB и Grafana — целиком внутри промышленного одноплатника, который сидит в той же стойке, что и опрашиваемое оборудование, потребляет несколько ватт и настраивается из браузера с рабочего места.

Читать дальше на Хабре

📱 Telegram | 📲 MAX

trippy

Утилита объединяет функциональность traceroute и ping и предназначена для помощи в анализе сетевых проблем, работает на Linux, BSD, macOS и Windows, её можно установить из большинства менеджеров пакетов, предварительно скомпилированных бинарных файлов или исходного кода.

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

📱 Telegram | 📲 MAX

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

Если вы планировали присмотреться к этим решениям, то вот три страницы документации с Key Concepts, где понятно рассказывают как устроена каждая система. Хорошая стартовая точка, как по мне.

VictoriaMetrics

VictoriaLogs

VictoriaTraces

📱 Telegram | 📲 MAX

Кроссплатформенный мониторинг аппаратных ресурсов на C++ и Python: библиотека hardware_monitor_cpp

Гуглил я как‑то опенсорс C++ библиотеку для мониторинга, температуры и нагрузки компонентов ПК. И не нагуглил. Вот такие вот дела. Есть HWiNFO, платно и закрыто. Есть OpenHardwareMonitor — написан C# и библиотека мертва. Есть форк предыдущей библиотеки — LibreHardwareMonitor — живее всех живых, но C#, да ещё и по дефолту требует 10.NET.

Библиотека HardwareMonitorCpp написана на C++. Потому что я плюсовик и я могу! Консольное приложение в ходе разработки раздулось с 7 мб оперативы до 30 мб на винде. Да и только потому, что я решил больше снапшотов системы хранить в истории отображения.

Из плюшек библиотеки: можно запросить по всему оборудованию только нагрузку или только температуру.

Подробности в статье на Хабре

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

📱 Telegram | 📲 MAX

beszel

Легковесная платформа для мониторинга серверов, которая умеет собирать стату Docker, хранить исторические данные и имеет функции отправки оповещений.

Поддерживается автоматическое резервное копирование, многопользовательский режим, аутентификацию OAuth и доступ к API.

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

📱 Telegram | 📲 MAX

How to scale Alloy as a central telemetry gateway: capacity planning, load testing, and production lessons

Grafana Alloy вполне себе можно рассматривать полноценный центральный шлюз телеметрии для метрик, логов и трейсов. Если используете или планируете использовать Grafana Stack рассмотрите использование Alloy.

В этой статье в блоге Grafana разбирают кейс: около 17 млн метрик, до 1 ТБ логов в сутки, терабайты трейсов, десятки подов Alloy и отдельная стратегия автоскейлинга. А еще рассказали где всё начинало ломаться во время нагрузочных тестов.

Из полезного: не ставить лимит на CPU, держать высокий MinReplica, использовать GOMEMLIMIT как защиту от OOM, отдельно мониторить сам telemetry gateway и тестировать нагрузку выше ожидаемого пика.

Еще в статье немного коснулись тему автомасштабирования кластера k8s не только по CPU и памяти, но и по заполнению очередей экспортера через KEDA — то есть реагировать на обратное давление ещё до того, как поды начнут себя чувствовать так себе.

Напишите в комментах кто как реализовал автоскейлинг кластеров k8s на основе данных наблюдаемости.

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

📱 Telegram | 📲 MAX

neko-master

Инструмент для анализа и визуализации трафика в локальных сетях. Собирает данные в реальном времени через WebSocket с задержкой в ​​миллисекунды.

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

📱 Telegram | 📲 MAX

logchef

Logchef — это легковесная платформа для анализа и мониторинга логов из ClickHouse, VictoriaLogs или обоих сервисов одновременно. Logchef предоставляет единое окружение для исследования, создания дашбордов, сохранения запросов, оповещений и контроля доступа — без перемещения или изменения структуры данных.

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

Публичное онлайн-демо

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

📱 Telegram | 📲 MAX

Вышла Grafana 13.2

Одна из самых интересных новинок — Saved Queries. Теперь запросы PromQL или SQL можно сохранять в общей библиотеке, искать, переиспользовать в Explore и дашбордах и управлять ими через Terraform.

Также появился View panel sidebar, который позволяет выявлять перегруженные временными рядами дашборды, менять представления и делать fanout даже без прав на редактирование дашборда.

А ещё Grafana продолжает двигаться в сторону Observability as Code: Git Sync теперь поддерживает GitHub Enterprise, вебхуки для GitLab и Bitbucket, а Saved Queries можно хранить и разворачивать как код.

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

📱 Telegram | 📲 MAX

How to visualize workflows and business processes in Grafana: Introducing the Graphviz panel

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

Виджет Graphviz позволяет описывать карты сервисов, payment flow, CI/CD-пайплайны, сетевые карты и ранбуки через DOT-синтаксис — без ручного перетаскивания десятков блоков.

А главное, цвета узлов, подписи и связи можно привязать к живым метрикам и запросам. Схема может строиться прямо из данных: в помощь Service registry, Terraform state или Kubernetes-топология.

Старый вопрос «а можно в Grafana сделать нормальную карту сервисов?» наконец получает ответ.

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

Плагин Graphviz

📱 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

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

PromQL Anomaly Detection Framework

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

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

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

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

📱 Telegram | 📲 MAX

Как мониторить 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

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