openobserve

А сколько жмет от груди ваша Observability-платформа? OpenObserve делает это в 140 раз лучше, чем ElasticSearch. А еще они пишут, что ваш CFO позже признается вам в любви❤️

OpenObserve простой (запускается из одного бинарника) и уже имеет UI на борту. Данные хранятся в формате parquet (это бинарный, неизменяемый, колоночно-ориентированный формат хранения данных).

Система выглядит интересно и заслуживает внимания. Пока что не совсем понятно на сколько она production-ready, но customer stories на сайте у них есть.

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

Описание архитектуры решения

❓ Если кто-то разворачивал, напишите в комментариях о ваших впечатлениях.

UPD: в комментарии пришел реальный пользователь. Интересный опыт.

Веб-мониторинг МФУ и уровня тонера через SNMP на Python + Flask

Когда одного Zabbix мало.

В этой статье я расскажу, как с помощью Python, Flask и SNMP создать простой веб-мониторинг для МФУ в корпоративной сети. Решение позволяет видеть статус, уровень тонера, тип картриджа и серийный номер принтера прямо в браузере.

Для реализации на МФУ должен быть включен SNMP v1/v2c. Порт 161/UDP должен быть открыт.

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

@monitorim_it

Минимальный набор практик для микросервиса

Если вы Go-разработчик и к вам пришли и сказали "мне нужны твои метрики, трейсы и логи", прочитайте эту статью. Здесь собраны рекомендации, например, о том, что нужно разделять логи на технический поток и поток аудита. А еще:

Почему я так упираюсь в связку “трейсы + логи”? Потому что это реально магия. Ты открываешь проблемный трейс, видишь trace_id, и дальше хочешь в один клик найти все логи по этому запросу. Чтобы это работало, логгер должен вытаскивать trace_id и span_id из контекста.

И еще:

Идея простая: у каждого запроса есть trace_id, и по нему ты видишь весь путь запроса через сервисы, очереди, базы и внешние интеграции. Внутри trace есть span — атомарные операции. Хорошая новость в том, что большая часть спанов создаётся автоматически, если ты используешь нормальные инструменты (HTTP middleware, SQL драйверы с OTel-инструментацией, клиенты Kafka/Redis и т.д.). Плохая новость в том, что бизнес-логика “между ними” сама себя не оттрассирует, и иногда надо уметь добавить span руками.

И еще:

Я люблю метрики, которые привязаны к смыслу. Если это сервис постов, то тебе важно понимать, сколько постов создают, как часто добавляют картинки или видео, как меняется поведение пользователей. Это не «хочу поиграться в аналитика», это реально помогает принимать решения и продукту, и инженерам.

Плюс есть технические метрики, которые не про сервис в целом, а про конкретную бизнес-механику: сколько сообщений улетело в DLQ, сколько промахов у кэша, как часто включается fallback. Такие числа позволяют развивать сервис на цифрах, а не на ощущениях.

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

@monitorim_it

Поддержка Zabbix Connector в VictoriaMetrics

Невероятно, но факт — в VM появилась поддержка стриминга данных из Zabbix. Принимаются только данные типов numeric (unsigned) и numeric (float). Метки и группы можно передавать в виде лейблов.

В практическом плане это означает, что вы теперь можете не отягощать БД Zabbix запросами, например, из Grafana, а строить визуализации напрямую из VM со всеми вытекающими преимуществами. Нет, мы не спорим, что раньше можно было перекладывать данные через Kafka, но напрямую же проще это делать.

См. как это работает в документации

@zabbix_ru

Using Event Patterns in ClickStack to accelerate observability analysis

Анализ логов в больших масштабах — одна из самых сложных задач в области мониторинга. Современные системы генерируют огромные объемы неструктурированных данных — они часто повторяются, содержат много шума и не имеют контекста, необходимого инженерам для принятия решений. В результате получается океан строк логов, где сигнал скрыт в шуме, а поиск смысла становится медленным и дорогостоящим процессом.

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

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

Это статья из блога ClickHouse. В ней упоминается интересное выражение "логи от недисциплинированных команд". Я такое выражение вижу впервые, но согласен, что такая ситуация имеет место быть. Некоторое время назад у меня даже был соответствующий опыт улучшайзинга логов. Такие логи обычно содержат много избыточной информации, что приводит к сложностям при дальнейшем анализе. Да и хранилище обычно не резиновое.

🔎 Как все работает под капотом (если лень читать статью)

Возможность автоматической кластеризации событий реализована при помощи Drain3, производительной библиотеки с открытым исходным кодом для анализа шаблонов логов. Drain3 — это алгоритм онлайн-кластеризации логов, который извлекает шаблоны из потоков сообщений логов. Он использует дерево разбора фиксированной глубины для управления формированием групп логов, избегая глубоких и несбалансированных структур, которые могут замедлять работу других алгоритмов или потреблять много памяти. Такой подход делает его быстрым для интерактивной работы даже с большими наборами данных логов. Drain3 применяется во время выполнения запроса, а не во время вставки.

Drain3 написан на Python, поэтому для его непосредственного выполнения в браузере используется Pyodide. Pyodide — это среда выполнения Python, скомпилированная в WebAssembly, которая работает исключительно на стороне клиента, без необходимости обработки на бэкэнде.

Кстати, этот Drain3 можно вызывать напрямую в качестве определяемой пользователем функции (UDF) в ClickHouse, что позволяет прямо там анализировать большие наборы данных. Шаблоны событий можно использовать для идентификации общих структур в конкретных источниках логов, например, принадлежащих одному сервису или компоненту. Затем эти обученные шаблоны можно скомпилировать в правила извлечения на основе регулярных выражений, что позволит ClickHouse автоматически захватывать структурированные поля во время приема данных.

@monitorim_it

Вышел OpenSearch 3.4

Не успели мы опомниться от 3.3 как уже выходит новая версия.

🚀 Новый пользовательский интерфейс для агентного поиска.

🚀 Множество новых инструментов для повышения релевантности результатов поиска.

🚀 Расширенный набор  команд языка конвейерной обработки (PPL) для аналитических задач и задач мониторинга.

🚀 Значительное повышение производительности для задач агрегирования.

Подробности в блоге OpenSearch

@elasticsearch_ru

Миграция базы данных Grafana: от внутреннего хранилища к PostgreSQL

Если вдруг ваша Grafana перестала справляться, прочитайте эту статью. Нет так давно этот туториал очень помог.

@monitorim_it

Один сервис — четыре стека: практический бенчмарк с SLO по p99 и Docker/JMeter

В этой статье представлено сравнение четырёх реализаций одного и того же сервиса поверх PostgreSQL:

Spring MVC + JDBC

Spring WebFlux + R2DBC

Ktor + JDBC

Go + pgx

Все сервисы крутятся в Docker с одинаковыми ресурсными лимитами и прогоняются через один и тот же JMeter-план. Для каждого стека определяется максимальный RPS при соблюдении SLO по p99-латентности.

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

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