ClickHouse Cloud для анализа логов ИИ-агентов: observability в 2026

Агент без логов - чёрный ящик, как и любая другая система. Когда вы получили странный ответ или зависание на ровном месте, без полных трейсов и наблюдаемости вы не поймёте почему так вышло. Сэмплированных логов мало - агенту нужен контекст каждого шага: какой промпт ушёл в модель, сколько токенов сожгли, какой инструмент дёрнули, что вернулось. И тут начинается главная боль 2026 года - ваш стек observability и анализа логов трещит по швам. 

ClickHouse Cloud в этой связке стал стандартом анализа логов и наблюдаемости ИИ-агентов, а старые системы (Elasticsearch, Loki, Prometheus, Postgres) не выдержали высокой кардинальности и дорогого retention. ClickHouse - колоночная база на C++, которая в 2026 окончательно вытеснила Elasticsearch из ниши хранения логов и стала фундаментом для observability ИИ-агентов и не только их. Кейсы LangChain, Canva, Sierra, Shopee, Trip.com - наглядный тому пример.

Зачем нужны логи ИИ-агентов и почему важна наблюдаемость

ИИ-агент - это не просто промпт в ChatGPT. Это цепочка вызовов: модель → инструмент → результат → следующий шаг → проверка. Один пользовательский запрос превращается в десятки и сотни внутренних операций. А без полных логов с отладкой будут проблемы.

[TGBLOCK]

Что хочется логировать от агента:

• Каждый шаг рассуждения. Что модель "подумала" перед действием.
• Промпт целиком. С системным промптом, контекстом, историей.
• Ответ модели целиком. Не сэмпл, не первые 1000 символов - всё.
• Вызовы инструментов. Какой инструмент, с какими аргументами, что вернул.
• Метрики токенов и денег. Prompt tokens, completion tokens, кешированные токены, цена.
• Латентность каждого шага. Где агент завис.
• Версии модели и промпта. Чтобы понять регрессии.
• Trace ID и Span ID. Чтобы связать всё в одну цепочку.

Получается примерно 10-50 КБ логов на один пользовательский запрос. Если у вас миллион запросов в день - это 10-50 ГБ ежедневных логов. И всё с очень высокой кардинальностью - миллионы уникальных Trace ID, миллионы инструментов, миллиарды токен-метрик - простыми системами такое не вытянуть. 

Почему старые системы не справляются с анализом логов ИИ-агентов

Стандартный observability-стек 2020-2024 это связка Prometheus + Loki + Grafana или Elasticsearch + Kibana. Они построены для другой эпохи - когда логов было в сто раз меньше, кардинальность ниже, а агентов вообще не существовало.

Что ломается на агентах:

Высокая кардинальность убивает индексы. В Prometheus каждая уникальная метка создаёт новую временную серию. Trace ID, Agent ID, Tool ID - всё это уникальные значения, миллионы серий, индексы раздуваются до невозможности.

Elasticsearch ест диск. Чтобы обеспечить поиск, Elasticsearch хранит инвертированные индексы для каждого поля. На больших объёмах логов это превращается в дорогое удовольствие - 70 ТБ на проекте может стоить $50-100К/мес.

Дорогой retention заставляет сэмплировать. Хранить 90 дней логов в Elasticsearch на 50 ТБ - слишком дорого. Поэтому компании выбрасывают 90% данных через сэмплирование. Но с агентами сэмплинг не работает - им нужен полный сырой контекст.

PostgreSQL захлёбывается на аналитике. Реляционная модель не для миллиардных событий. Beehiiv, Respan AI, LangChain - все они выросли из Postgres именно на агентских логах.

Команда LangChain в начале 2026 года официально перевела LangSmith с Postgres на ClickHouse. Причина - Postgres перестал тянуть аналитические запросы. Объём: 300 миллионов агентских прогонов в месяц. Это та цифра, при которой старые БД ломаются.

Что такое ClickHouse и почему он бьёт всех в логах

ClickHouse - колоночная база данных для аналитики (OLAP база данных). Открытый исходный код на C++ написан под Яндекс.Метрику, где нужно считать миллиарды строк за секунды. Доступен в двух форматах - self-hosted и управляемый ClickHouse Cloud. Почему именно ClickHouse выиграл нишу observability и анализа логов в 2026?

Колоночное хранилище + векторизация

В отличие от Postgres или MySQL (где строки хранятся целиком), ClickHouse хранит данные по столбцам. Когда вы делаете SELECT count(*) WHERE status = 500, движок читает только столбец status, а не всю строку. Плюс векторизация: одна инструкция CPU (SIMD) обрабатывает сразу пачку значений. На больших объёмах это разница в 10-100 раз.

Сортировка при вставке

ClickHouse сразу раскладывает данные по гранулам (8192 строки) в порядке сортировки. По заявлениям ClickHouse, подготовка данных к запросам у них в 22 раза дешевле, чем у Snowflake, который пишет как попало, а потом фоном кластеризует. 

Феноменальное сжатие

Реальные кейсы из практики: - Qonto (банк): 231 ТБ → 376 ГБ. Сжатие 99.8%. Экономия $70K/год только на S3. - Harvey AI (LegalTech с агентами): 5.4 ТБ логов в день → 4.5 ГБ. - ClickHouse сам: 20 ГБ nginx-логов → 109 МБ (в 178 раз). - Trio (бразильский финтех): сжатие данных на 88%.

Сжатие достигается за счёт колоночного формата + ZSTD/LZ4 + специальные кодеки под типы данных (Delta для timestamp, DoubleDelta для метрик).

Высокая кардинальность не пугает

Миллионы уникальных Trace ID, Span ID, Agent ID - ClickHouse переваривает без падения производительности. Это не Prometheus, где каждая уникальная метка плодит временную серию.

Три механизма прунинга

ClickHouse умеет отсекать ненужные данные ещё до чтения:

1. Primary Index - разреженный индекс по гранулам, сортировка.
2. Lightweight Projections (с версии 25.6) - копия данных в другом порядке сортировки, занимает мало места, ускоряет альтернативные паттерны запросов.
3. Skip Indexes (minmax, bloom) - пишут метаданные о каждой грануле.

Запрос автоматически использует оптимальный механизм, быстро отсекающий лишние блоки. На больших таблицах это даёт ускорение в 10-100 раз.

Data Lake-ready

ClickHouse научился читать Iceberg и Delta Lake прямо на месте без ETL-обвязки. Запрос к Parquet занимает 0.625 сек, тот же запрос после вставки в ClickHouse - 0.022 сек (в 30 раз быстрее). Это даёт возможность делать гибрид: горячее хранить в ClickHouse, а холодное - на S3 в Iceberg (не зря же он так называется).

300М агентских прогонов в месяц на ClickHouse

LangChain - один из главных фреймворков для построения ИИ-агентов. Их платформа LangSmith - это observability для агентов: трейсы, метрики, оценки качества, отладка.

До 2026 LangSmith был на PostgreSQL. Когда трафик дорос до сотен миллионов прогонов в месяц, Postgres перестал тянуть аналитические запросы:

• Тяжёлые JOIN на миллиардах строк.
• Агрегации по времени с группировкой по 5-7 измерениям.
• Дашборды отваливались, инженерам приходилось строить материализованные представления для каждого нового вида запросов.

Вот что получилось после перехода LangSmith на ClickHouse:

• 300 миллионов агентских прогонов в месяц обрабатываются без проблем.
• Latency аналитических запросов снизилась с десятков секунд до миллисекунд.
• Материализованные представления больше не нужны - ClickHouse считает на лету.
• Стоимость инфраструктуры упала кратно.

Это был один из самых показательных кейсов года, и он задал тренд: если вы строите observability для агентов, теперь ClickHouse - дефолтный выбор.

Три врага наблюдаемости и анализа логов

ClickHouse открыто объявил войну трём устоявшимся подходам, которые были стандартом 10 лет:

1. Сэмплированию

Старый подход: храним только 10% логов, остальное выбрасываем - экономим деньги. Когда агент сделал что-то странное и вам надо разобраться - нужный лог окажется в выброшенных 90%. Сэмплирование убивает отладку.

Новый подход с ClickHouse: храним всё сырое, без сэмплирования. За счёт сжатия x14-178 это дешевле чем хранить агрегаты в старых системах.

2. Агрегации (roll-ups)

Старый подход: сырые данные хранятся 7 дней, потом пересчитываются в агрегаты (среднее за час, день, неделю). Агрегаты хранятся долго. Но при этом теряется возможность нырнуть в конкретный трейс. Если что-то сломалось 30 дней назад - вы видите только усреднённую статистику. Это бесполезно для дебага.

Новый подход: храним сырое долго, агрегируем при чтении. ClickHouse достаточно быстр чтобы агрегировать миллиарды строк на лету.

3. Короткому retention

Старый подход: 7-14 дней хранения, дальше дорого. В то же время ML-команды хотят анализировать поведение моделей за месяцы. Регрессии моделей всплывают только на длинной дистанции.

Новый подход: 90-365 дней сырых данных в ClickHouse + Tiered Storage с уходом на S3. Стоимость сжатого хранения настолько низкая, что годовой retention становится нормой.

Agentic Data Stack: эталонная архитектура наблюдаемости для ИИ-агентов

Команда ClickHouse в 2026 предложила типовую архитектуру для агентских приложений - Agentic Data Stack. Что она включает:

• Интерфейс: LibreChat (open-source ChatGPT-подобный фронт) или своя оболочка.
• Данные: ClickHouse как единое хранилище для аналитики, логов, трейсов, метрик.
• Протокол связи: MCP-серверы (Model Context Protocol) - открытый стандарт от Anthropic для безопасного подключения моделей к данным и инструментам.
• Observability: Langfuse или ClickStack (от ClickHouse, на базе OpenTelemetry).

Что важно: всё в одном кластере. Единая БД для логов, метрик и бизнес-аналитики. Это упрощает архитектуру в разы.

Один разработчик собрал production-grade систему за пару дней: 
- Next.js на фронте. 
- ClickHouse для аналитики. 
- PostgreSQL для транзакций. 
- ClickPipes CDC для синхронизации Postgres → ClickHouse. 
- 18 специализированных агентов на LibreChat, каждый со своим системным промптом и доменом данных. 
- Langfuse для метрик промптов и токенов. 
- ClickStack на OpenTelemetry для инфраструктурных логов.

Главный инсайт автора - агентная разработка работает только когда платформа данных не сопротивляется. 

Кейс Canva: 6 миллионов событий в секунду

Canva (графический редактор для миллионов пользователей) держит observability на ClickHouse:

• 6 миллионов событий в секунду - 3 миллиона спанов + 3 миллиона логов.
• Сжатие в 14 раз. Реальное сжатие на их данных.
• Расходы на инфраструктуру упали на 70% после миграции.
• Поиск трейсов ускорился в 10 раз: с 30 секунд до 2.5 секунд.

Архитектурная фишка: они ушли от стандартных распределённых таблиц ClickHouse к прямой записи в локальные таблицы через кастомные коллекторы (буферизация по 200К записей). Это снимает нагрузку с координации вставок.

Материализованные представления используются как индекс для Trace ID - таблица переиндексируется в другом порядке сортировки, что позволяет искать конкретный трейс за миллисекунды.

Кейс Sierra: observability и аналитика в одном кластере

Sierra - стартап с оценкой больше миллиарда долларов. Что они сделали:

• Снесли раздельные стеки для мониторинга (Prometheus/Loki) и аналитики (Snowflake/BigQuery).
• Объединили всё в одном кластере ClickHouse.
• SRE-команда и продуктовые аналитики работают с одними данными.

Архитектура: Kafka → центральная таблица → Materialized Views → Alerts. Всё внутри ClickHouse.

ClickHouse достаточно быстрый для real-time дашбордов (миллисекунды на агрегации миллиардов строк) и достаточно дешёвый для долгого retention. Раньше эти роли выполняли разные системы. Теперь - одна.

Кейс Trip.com: 50 петабайт логов в ClickHouse

Trip.com - крупнейшая китайская тревел-платформа. Держат 50 петабайт логов в ClickHouse.

До миграции был Elasticsearch. После переезда: 
- Ускорение запросов в 4-30 раз в зависимости от паттерна. 
- Существенное сокращение расходов на инфраструктуру. 
- Возможность держать длинный retention без боли.

50 петабайт - в тысячу раз больше, чем "обычный большой проект". ClickHouse держит такую нагрузку.

Кейс Huntress: $70К → $5К в месяц после Elasticsearch

Huntress Labs защищают 4 миллиона эндпоинтов. Логи безопасности генерят непрерывным потоком. Вот что произошло после перехода с Elasticsearch на ClickHouse Cloud:

• Счёт упал с $70 000 до $5 000 в месяц.
• Объёмы те же.
• Поиск стал быстрее.

Это в 14 раз дешевле. Не на 30%, не в 2 раза - в 14. Такие разницы редко бывают, но в логах ClickHouse vs Elasticsearch они норма.

Анализ логов ИИ-агентов в ClickHouse Cloud: практика и мониторинг

Перейдём от кейсов к практике. Покажу как реально устроен анализ логов агентов ИИ в ClickHouse Cloud - какие запросы делают команды, что мониторят, как ловят аномалии.

Базовая схема таблицы для логов агентов ИИ:

CREATE TABLE agent_traces (
    timestamp DateTime64(3),
    trace_id String,
    span_id String,
    parent_id Nullable(String),
    agent_id LowCardinality(String),
    user_id String,
    step_type Enum('llm_call', 'tool_call', 'reasoning', 'memory_read'),
    model LowCardinality(String),
    prompt String CODEC(ZSTD),
    completion String CODEC(ZSTD),
    tokens_in UInt32,
    tokens_out UInt32,
    latency_ms UInt32,
    status LowCardinality(String),
    cost_usd Float32
)
ENGINE = MergeTree
ORDER BY (timestamp, agent_id, trace_id)
TTL timestamp + INTERVAL 90 DAY
SETTINGS index_granularity = 8192;

Что важно: LowCardinality для повторяющихся полей экономит место в десятки раз. CODEC(ZSTD) сжимает текстовые промпты и ответы в среднем в 5-10 раз. TTL на 90 дней даёт долгий retention без хайповых расходов на ClickHouse Cloud.

Типичные запросы для анализа логов агентов ИИ:

-- Сколько стоит каждый агент в день
SELECT
    agent_id,
    toDate(timestamp) AS day,
    sum(cost_usd) AS daily_cost,
    count() AS calls
FROM agent_traces
WHERE timestamp >= now() - INTERVAL 30 DAY
GROUP BY agent_id, day
ORDER BY day DESC, daily_cost DESC;

-- Самые медленные шаги по агентам
SELECT
    agent_id,
    step_type,
    quantile(0.95)(latency_ms) AS p95,
    quantile(0.99)(latency_ms) AS p99
FROM agent_traces
WHERE timestamp >= now() - INTERVAL 1 DAY
GROUP BY agent_id, step_type
HAVING p99 > 5000
ORDER BY p99 DESC;

-- Ловим всплески ошибок
SELECT
    toStartOfMinute(timestamp) AS minute,
    agent_id,
    countIf(status = 'error') AS errors,
    count() AS total,
    errors / total AS error_rate
FROM agent_traces
WHERE timestamp >= now() - INTERVAL 1 HOUR
GROUP BY minute, agent_id
HAVING error_rate > 0.05
ORDER BY minute DESC;

В ClickHouse Cloud такие запросы летят за миллисекунды даже на миллиардах строк. Это и есть та самая наблюдаемость, которой нет в классических Prometheus+Loki: вы видите не агрегаты, а сырые трейсы каждого вызова ИИ-агента.

ClickHouse vs Elasticsearch, Postgres, Loki, Snowflake

Краткая сравнительная таблица:

Главные выводы:

Elasticsearch - главная жертва. В 2026 ClickHouse буквально вытеснил его из ниши логов. Когда внедрили полнотекстовый поиск через инвертированные индексы, у Elasticsearch исчез последний повод оставаться.

Postgres - партнёр, не конкурент. Связка Postgres (OLTP, транзакции) + ClickHouse (аналитика, логи) через ClickPipes CDC - стандартный паттерн 2026.

Snowflake/BigQuery дорогие. В эпоху агентов с тысячами мелких запросов разница в стоимости подготовки данных становится критической.

ClickHouse Cloud или self-hosted: что выбрать для анализа логов

У ClickHouse Cloud и self-hosted версии тот же движок, но разная операционка. Для анализа логов ИИ-агентов это важно: Cloud даёт нулевую операционку, self-hosted - полный контроль над инфраструктурой.

ClickHouse Cloud - управляемый сервис

• Автоматическая репликация и бэкапы с PITR.
• Авто-скейлинг compute, разделение storage/compute (данные на S3).
• ClickPipes - управляемый CDC из Postgres/MySQL/MongoDB.
• BYOC (Bring Your Own Cloud) - софт управляется ClickHouse, крутится в вашем облаке.
• SharedMergeTree - облачно-нативный движок для параллельной работы compute-нод с одними данными.

Тарифы: Basic, Scale, Enterprise. Usage-based. Compute поминутный, блоками по 8 GiB RAM.

Self-hosted (бесплатно)

• Тот же движок, никакой лицензии.
• Все облачные фичи - руками: шардинг, репликация через ClickHouse Keeper, мониторинг, бэкапы, апгрейды.
• Скрытая стоимость: 10-20% времени одного инженера на стабильный кластер.
• Плюс затраты на железо, storage, трафик.

Когда выбирать ClickHouse Cloud vs self-hosted

Self-hosted подходит когда: 
- Объём данных больше 50 ТБ сжатого. 
- Стабильная предсказуемая нагрузка. 
- Сильная DevOps-команда внутри. 
- Жёсткие требования комплаенса.

Cloud подходит когда: 
- Объём меньше 50 ТБ. 
- Нагрузка переменная или растёт. 
- DevOps-ресурсов мало. 
- Нужно быстро в прод.

Показательно: Avride (автономный транспорт) с десятилетним опытом администрирования ClickHouse выбрали Cloud - не хотели тратить время на "прогрев" кластеров. Если уж они выбрали Cloud, обычной команде тем более стоит начать с него.

Архитектурные паттерны для логов агентов

Несколько проверенных паттернов из реальных кейсов.

Async Inserts по умолчанию

С версии 26.3 ClickHouse включил Async Inserts по умолчанию. Что это значит: вам больше не нужно городить буфер на стороне приложения. Можете слать мелкие вставки - ClickHouse сам собирает их в батчи.

Для логирования агентов это удобно: каждый шаг агента может писать одну строку в ClickHouse - со вставкой база разберётся сама.

Скользящее окно через Refreshable Materialized Views

Кейс Trio: вместо пересчёта всего исторического монолита - refreshable materialized views пересчитывают только последние 4 часа. Это спасает от дублей из Kafka и опоздавших событий (с использованием ReplacingMergeTree).

Для агентских логов это паттерн "горячие 4 часа всегда свежие, остальное - на лету".

Kafka → центральная таблица → Materialized Views → Alerts

Стандартный паттерн ETL для observability: 
- Kafka собирает поток логов от агентов. 
- Центральная таблица (RAW) принимает всё. 
- Materialized Views агрегируют для разных дашбордов. 
- Alerts срабатывают на условия в MV.

Sierra использует именно этот паттерн.

MCP-агент в ClickHouse

Свежий тренд - ClickHouse открыл MCP-сервер, через который агенты могут сами запрашивать данные. То есть LLM-агент может выполнять SQL-запросы к вашим логам, искать аномалии, генерировать алерты.

Это и есть Agentic Analytics в действии:

LLM генерирует SQL → проверяет схему → выполняет →
  → если ошибка - рефлексирует → пробует снова

ClickHouse дополнительно открывает API к Query Insights - агент сам видит, что база тормозит, анализирует план запроса и предлагает индекс.

SODA: наблюдаемость без вендор-лока

Большой тренд 2026 года - отказ от вендор-лока. Datadog, New Relic, Splunk запирают ваши данные у себя, и за выход придётся доплачивать.

Решение - OpenTelemetry как стандарт сбора + ClickHouse как место хранения + любой визуализатор сверху (Grafana, Superset, Metabase). Это и есть SODA - Send Observability Data Anywhere.

Для агентов это особенно важно: вы хотите иметь возможность кросс-коррелировать логи модели, инфраструктурные метрики, бизнес-события. В закрытых системах это невозможно. В связке OpenTelemetry + ClickHouse - норма.

С чего начать мониторинг ИИ-агентов в ClickHouse Cloud

Если вы решили попробовать - вот пошаговый план.

1. Начните с ClickHouse Cloud. Бесплатный trial, не надо настраивать инфру. Войдёте в продукт за час.
2. Создайте таблицу для трейсов агентов. Минимум полей: timestamp, trace_id, span_id, parent_id, agent_id, prompt, completion, tokens_in, tokens_out, latency_ms, status, metadata (JSON).
3. Используйте MergeTree с правильной сортировкой. ORDER BY (timestamp, trace_id) для большинства случаев.
4. Подключите OpenTelemetry. Стандартный коллектор + экспортер в ClickHouse через OTLP/HTTP.
5. Добавьте Langfuse поверх. Для красивых дашбордов трейсов агентов и анализа промптов.
6. Настройте retention. TTL на таблицу - 90 дней горячих, дальше в S3 через Tiered Storage.
7. Покройте критические метрики. Среднее время агента, p95/p99 latency, токены в секунду, стоимость на запрос.

Через месяц вы будете удивляться как раньше жили без полной картины.

FAQ

Зачем нужен ClickHouse для логов ИИ-агентов?

Логи ИИ-агентов имеют высокую кардинальность (миллионы Trace ID), большой объём (десятки ГБ в день) и требуют долгого retention для отладки регрессий моделей. Старые системы (Elasticsearch, Loki, Postgres) ломаются на этой нагрузке. ClickHouse выдерживает миллионы событий в секунду и сжимает данные в 14-178 раз.

Можно ли использовать ClickHouse бесплатно?

Да. ClickHouse - open-source проект с лицензией Apache 2.0. Self-hosted версия бесплатна. Платная только ClickHouse Cloud, где платите за compute и storage. Open-source движок идентичен по возможностям.

Чем ClickHouse лучше Elasticsearch для логов?

В 4-30 раз быстрее на агрегациях, в 5-15 раз дешевле в инфраструктуре, нормально работает с высокой кардинальностью, лучше сжатие. Кейс Huntress: счёт упал с $70К до $5К/мес после миграции. Кейс Trip.com: ускорение в 4-30 раз на 50 ПБ данных.

Что такое ClickStack?

ClickStack - референсная архитектура от ClickHouse для observability на базе OpenTelemetry: коллектор + ClickHouse как хранилище + Grafana/визуализатор. Стандартный путь для логов, метрик и трейсов, в том числе для ИИ-агентов.

Что выбрать: ClickHouse Cloud или self-hosted?

Cloud - если объём меньше 50 ТБ, нагрузка переменная, DevOps-ресурсов мало. Self-hosted - если больше 50 ТБ, нагрузка стабильная, есть сильная команда. Большинство команд начинают с Cloud и переезжают на self-hosted только при значительном росте.

Можно ли связать ClickHouse с Postgres?

Да, стандартный паттерн 2026. Postgres для OLTP (транзакции, авторизация), ClickHouse для аналитики и логов. Синхронизация через ClickPipes (управляемый CDC) или собственный пайплайн Kafka.

Подходит ли ClickHouse для real-time дашбордов?

Да, это его сильная сторона. Latency типичного запроса - миллисекунды на миллиардах строк. Кейс Mintlify: дашборды ускорились с десятков секунд до подсекунды после миграции с PostHog на ClickHouse Cloud.

Чем наблюдаемость отличается от мониторинга?

Мониторинг - это про известные метрики (CPU, память, RPS). Наблюдаемость глубже: вы можете задать любой вопрос о поведении системы и получить ответ. Для ИИ-агентов это критично - поведение модели часто непредсказуемо, и обычные алерты не помогают. Нужен полный сырой контекст в ClickHouse Cloud для глубокого анализа логов.

Что такое анализ логов ИИ-агентов и зачем он нужен?

Это разбор каждого шага агента: какой промпт ушёл в модель, какие инструменты вызвал, сколько токенов сжёг, где завис. Без анализа логов отладка ИИ-агента превращается в гадание. ClickHouse Cloud даёт нужный уровень детализации - сырые трейсы хранятся 90+ дней и аналитика летит за миллисекунды.

Подходит ли ClickHouse Cloud для логов небольшого проекта?

Да. ClickHouse Cloud тарифицируется по факту использования, минимальный compute стартует от пары долларов в день. Для проекта с миллионом событий в день это в разы дешевле Datadog/New Relic при той же или лучшей наблюдаемости.

Как итог

ИИ-агенты требуют другого подхода к observability. Сэмплирование, агрегация при записи, короткий retention - всё это паттерны прошлой эпохи, которые ломаются на агентских логах с высокой кардинальностью и большим объёмом.

ClickHouse в 2026 стал стандартом для observability ИИ-агентов: колоночное хранение, феноменальное сжатие, миллионы событий в секунду, кейсы LangChain (300М прогонов/мес), Canva (6М событий/сек), Sierra, Trip.com (50 ПБ). Стек называется Agentic Data Stack: ClickHouse как ядро + OpenTelemetry для сбора + MCP для интеграции с агентами + Langfuse для визуализации.

Главный совет: если строите серьёзную агентскую систему - начинайте observability на ClickHouse Cloud с первого дня. Когда вырастете, спасибо себе скажете. Логи - та инвестиция, которую недооценивают пока агент не сломается. А без полного контекста причину поломки установить очень сложно.