Проанализировав особенности использования в различных языковых экосистемах, мы отметили, что сообщество всё больше склоняется к 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.