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

Команда VK Cloud рассказывает, почему выбрала ClickHouse для Cloud Tracing: чем не подошли Cassandra и Elasticsearch, как устроила поиск трейсов и зачем понадобились собственный приёмник и авторизующий прокси. Отдельно — о компромиссах при отказе от Kafka и о том, что изменила нативная поддержка ClickHouse в Jaeger v2.

Полезный разбор для тех, кто выбирает хранилище телеметрии и хочет заранее оценить не только производительность, но и объём собственной разработки.

Обвязка (harness) оборачивает модель. Риг (rig) оборачивает ваши обвязки. Определите команду агентов в YAML и запустите её одной командой. Claude Code и Codex в одном риге, управляемые как единая система.

OpenRig превращает ИИ-агентов для написания кода из набора терминальных сессий в постоянную, организованную команду. Общайтесь с ведущим агентом о желаемом результате; он может координировать специалистов между командами и приносить вам результаты и решения, требующие вашего внимания. Начните с репозитория и одного полезного изменения, затем сохраняйте работу и контекст команды по тем же адресам.

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

Чувствительные данные теперь можно удалять сразу из нужных трейсов с помощью запроса TraceQL — перечислять каждый trace ID вручную больше не требуется. Метрики TraceQL научились учитывать сэмплирование, а ускоренный путь чтения позволяет выполнять некоторые запросы почти вдвое быстрее.

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

Возможности:
— информативный и эффектный вывод: отображает больше информации, чем nvidia-smi, с помощью цветной графики в виде рамок.
— режим мониторинга: может работать как монитор ресурсов, а не выводить результаты только один раз
— интерактивный: реагирует на ввод данных пользователем (с клавиатуры и/или мыши) в режиме монитора.
— портативный: работает как на Linux, так и на Windows
— интегрируемость: легко интегрируется с другими приложениями, превосходит функции мониторинга. (по сравнению с nvidia-htop и nvtop)

Применение на стороне сервера важно, так как объекты Kubernetes представляют собой общее состояние: оно переносит право владения полями на API-сервер, что позволяет инструментам в стиле apply выявлять конфликты, а не скрывать их в виде тихих перезаписей.

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

Команда Google Cloud представила k8s-aibom — инструмент с открытым исходным кодом, который помогает автоматически собирать AIBOM.
Что инструмент дает:
- инвентаризацию AI-компонентов в кластере;
- понимание, какие модели и ML-фреймворки используются;
- повышение прозрачности AI-нагрузок;
- помощь в анализе рисков, уязвимостей и соответствия требованиям безопасности;
- более удобный контроль AI-софта в production-средах.

Со временем окружение быстро усложняется, а ручной учет компонентов становится практически невозможным. По сути, k8s-aibom — это попытка сделать для AI-компонентов то же, что SBOM (только в формате OWASP CycloneDX 1.6 Machine Learning Bill of Materials (ML-BOM)) делает для обычного программного обеспечения: дать структурированное представление о составе системы, чтобы защитить цепочку поставки (supply chain), борьба с shadow AI.