Проанализировав особенности использования в различных языковых экосистемах, мы отметили, что сообщество всё больше склоняется к OTLP, при этом экспортёры Zipkin получили ограниченное распространение — на некоторых языках, даже меньшее, чем уже устаревший экспортёр Jaeger. Учитывая минимальное участие пользователей в решении связанных вопросов и наличие альтернатив, мы считаем, что сейчас самое время прекратить поддержку экспортёров Zipkin в SDK OTel.

За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же.

Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.

Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.

В этом году инструменты observability с открытым исходным кодом вышли за рамки простого мониторинга. Теперь они конкурируют, а зачастую и превосходят коммерческие SaaS‑платформы по масштабируемости, гибкости и совместимости. Команды из разных отраслей внедряют стеки решений наблюдения с открытым исходным кодом, чтобы избежать привязки к одному поставщику, обеспечения сквозной прозрачности (логи, метрики, трассировки), экономии на лицензиях и много другого.

В этой статье мы рассмотрим 10 лучших инструментов наблюдения с открытым исходным кодом 2025 года, изучив их сильные стороны, недостатки и наилучшие варианты использования для современных DevOps‑ и SRE‑команд.

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

Сегодня хочу поделиться опытом того, как я отказался от стандартного пакета sssd-tools для мониторинга службы SSSD в пользу прямого общения с демоном через D-Bus и создал свой первый Ansible-модуль.

D-Bus (сокращенно от «Desktop Bus») — это система межпроцессного взаимодействия (IPC), которая позволяет приложениям на одном компьютере общаться друг с другом, обмениваясь сообщениями. Она действует как «шина сообщений», через которую один процесс может отправлять запросы, сигналы и данные другим процессам.

Рассказываю, как наша команда реализовала мониторинг состояния шины и аналитику запросов к ней через обратный прокси. Пришлось повозиться, ведь Zabbix из коробки не очень успешно с этим взаимодействует.

В сложных интеграционных системах мониторинг является неотъемлемым инструментом как для инженера, так и для бизнеса. Zabbix показал себя надёжной и гибкой системой, которая позволяет строить понятные дашборды. Но я, как тимлид команды поддержки, столкнулся с тем, что шину Red Hat JBoss Fuse так просто к Zabbix не подключить. Шина работает на JVM, а значит, нужен мониторинг по JMX.

Логи всегда играли ключевую роль в понимании поведения программного обеспечения. Они регистрируют события, ошибки и изменения состояния, раскрывая, что происходило внутри системы в определённый момент времени.

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

OpenTelemetry был создан именно для решения проблемы фрагментации такого рода. Благодаря определению общей модели данных логов, а также нейтральных к языку программирования API и SDK, OTel предоставляет стандартный способ представления, обработки и экспорта журналов.

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

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

Работая за компьютером по 10-12 часов в день, я постоянно ловил себя на том, что проверяю диспетчер задач. То процессор грузится, то память подыхает, то диск трещит по швам. Стандартные инструменты Windows работают, но постоянно переключаться между окнами — то еще удовольствие.

Попробовал разные программы — одни слишком навороченные, другие жрут память как не в себя, третьи выглядят так, будто их делали в 2005 году. В какой-то момент мне это надоело, и я подумал: "А почему бы не сделать свой монитор? Простой, удобный и легкий".

Aether Monitor+ — это как раз та утилита, которой мне не хватало. Она висит поверх всех окон маленьким виджетом и показывает самое важное: загрузку процессора, использование памяти, свободное место на диске и температуру. Всё это в реальном времени, без лишних деталей.