Self-hosted Langfuse: когда телеметрия видит 7% агентов, а ClickHouse пишет о себе

Редакция 1 октября 2026 г.

Полчаса на один ход, пост не ушёл, в Langfuse трейс выглядит штатным: Anderson в Discord поймал именно такой сбой, потом сверил session DB с UI и увидел 91 traced из 1387 model calls за 14 дней (около 7%). У соло с парком ролей (coder, security, writer и остальные) это не «настройка на потом», а дыра в vibe-workflow: coder дал 522 вызова без трейса, default (chat) нёс почти весь видимый хвост. В кейсе тот же аудит вскрыл и вторую проблему: 6,03 GiB диска ClickHouse при 2,2 MiB данных трейсов Langfuse.

Цена ошибки: пост не ушёл, трейс выглядел правдоподобно

Anderson дал агенту команду post с id комментария, шаг одобрения черновика ответа на Dev.to. Пост не опубликовался. Ход занял примерно 25 минут: в Langfuse трейс «Hermes turn» около 1526 секунд, инструменты суммарно ~4,6 с, модель ~1517 с. Три вызова web_search / web_extract и три LLM-вызова на локальной qwen3.5-64k. На выходе детальное резюме статьи, которой не было.

Сессия стартовала до появления skill для постинга; список skills читается один раз при старте, в этой сессии инструмента для поста не было. На «post» без tool агент ушёл в веб и написал правдоподобный текст. Первичный фикс: новая сессия. Сразу после инцидента Anderson пошёл сверять, сколько вызовов вообще попадает в Langfuse.

Почему Langfuse видел только 7% вызовов AI-агентов

За четыре недели в Langfuse оказалось 618 событий и 79 трейсов, порядка трёх трейсов в день. За последние 14 дней по session DB агента: 188 сессий, 1387 model calls, 10 agent profiles. Трассировка была включена на одном профиле, default (chat) с 91 вызовом, что даёт примерно 7% трафика. Остальные роли несут основной объём: coder 522 вызова, sec 390, itadmin 172, writer 120, все без traced.

Плагин трассировки включается per profile, ключи Langfuse лежат в secret scope профиля, чтобы трейсы одной роли не уезжали с ключами другой. На старте ключи и плагин стояли только на default; специализированные профили работали без трассировки, без ошибки и без предупреждения: плагин fail-open (нет ключей, хуки молча не работают). Второй зазор: one-shot jobs в «safe mode» пропускают плагины; reply drafter так и жил, пока Anderson не добавил отдельную отправку трейсов через Langfuse SDK.

Anderson для каждого из десяти профилей скопировал ключи в env файл профиля, включил плагин и задал в Langfuse environment = имя профиля: без тега роли трейсы бесполезны для отчётов. После рестарта gateway probe одним словом на двух профилях; трейсы пришли с тегами legal и writer. Estate: около десяти ролей (chief of staff, coder, security, IT admin, writer, scout, reviewer, legal, analyst и ещё несколько), inference смесь локальных моделей на GPU 6 GB и дешёвых облачных с fallback chain.

ClickHouse: 6 GiB «про себя» при 2,2 MiB трейсов агентов

Langfuse v3+ хранит трейсы в ClickHouse; Postgres отвечает за users/projects; Redis за очередь; MinIO за blobs. ClickHouse убрать нельзя: это хранилище трейсов. На момент замера 6,03 GiB диска у ClickHouse против 2,2 MiB фактических данных трейсов Langfuse. Anderson оценивает порядок ~2700× больше байт «про ClickHouse», чем про агентов. Узел на 5400 rpm HDD; после ребута около 15 минут IO-нагрузки; контейнер Langfuse он останавливал, чтобы разгрузить диск.

Основной объём в системных log-таблицах, не в самих трейсах:

System table	Size
`system.trace_log`	3,38 GiB (174,6 million rows)
`system.text_log`	1,19 GiB
`system.part_log`	492 MiB
`system.asynchronous_metric_log`	485 MiB
`system.metric_log`	461 MiB

Фикс через override в /etc/clickhouse-server/config.d/ (read-only mount в compose): удалены 12 system log tables из конфига; query_log оставлен с TTL 7 дней; уровень server logger → warning. После recreate контейнера Langfuse web отвечает 200; trace_log перестал расти за 30 секунд; данные трейсов на месте. Удаление таблиц из конфига не чистит уже записанное: ~5,9 GiB старых log tables Anderson drop’нул отдельно. Использование диска контейнером Langfuse: с 15 GB до 7,7 GB, трейсы сохранены.

Зачем вообще трейсы при десяти профилях и локальных моделях

Anderson использует Langfuse как «сборщик фактов» про агентов при правиле estate: scripts gather facts, models never do. Модели суммируют только то, что измерили скрипты. Трейсы отвечают на конкретные вопросы: какая роль жрёт вызовы (coder 522 из 1387 за 14 дней); куда уходит время медленного хода (модель vs tool); сработал ли fallback облака; local vs cloud по латентности. В таблице по default profile local qwen3.5-64k даёт p50 125,2 s против cloud flash p50 4,3–6,7 s; terminal вызывался 135 раз с median 0,6 s, самый медленный tool search_files 120,6 s.

Еженедельный скрипт сравнивает session records агентов и Langfuse: по понедельникам turns, calls, tokens, cost, errors, доля traced, latency p50/p95, split model/tools, топ-5 медленных ходов, ошибки tools, контроль размера ClickHouse. Три проверки для self-hosted Langfuse:

Трассировка реально включена везде, где кажется (per service/profile/worker): сверить счётчик вызовов приложения с числом трейсов Langfuse.
Размер system log tables ClickHouse (system.parts by table); при доминировании trace_log / asynchronous_metric_log нужен config.d override.
Probe trace с каждого агента (одно слово, один turn) и проверка тега environment.

22 сентября сменился адрес tracing server, конфиги 12 specialist agents обновили. 23 сентября сервер вернулся на старый адрес: обновили только main config, специалисты сутки без трассировки, снова без ошибок в логах. 24 сентября нашли и исправили. Deploy gate на ratio traced/total Anderson не ставит, намеренно еженедельный spot check.

Observability агентов и observability инфраструктуры это разные задачи. Fail-open плагины и safe mode без трейсов дают «зелёные» логи при чёрной дыре в Langfuse; ClickHouse без настройки system logs может съесть диск быстрее, чем вы накопите осмысленные трейсы. Сверка 1387 вызовов с 91 traced отсекает следующий «post» на 25 минут галлюцинации без следа в UI.

Источники

Christian Anderson, «Self-hosted Langfuse: tracing 7% of my AI agents, and ClickHouse logging itself»: dev.to (публикация 2026-10-01, доступ к тексту 2026-10-01 UTC).