Как включить сбор метрик

Зачем нужен сбор метрик

Внедрение любых новых процессов должно быть прозрачно, особенно если эти процессы предполагают денежные затраты. Есть ли эффект, что привело к успеху или провалу, что работает и не работает?

Базово мы хотим знать хотя бы частоту использования (adoption) и паттерны использования (какие модели, какие режимы и тулзы, длина сессий).

Это поможет нам понимать, есть ли базовые проблемы внедрения:

• Сложность настройки
• Неудовлетворительное качество
• Отсутствие командных процессов и опыта

Возникновение этих проблем мы можем понять по метрикам использования инструмента - если инструментом не пользуются, возможно есть проблемы с освоением или недостаточным качеством. Если инструмент используется чересчур, возможно могут возникнуть проблемы с безопасностью, с AI-slop или неправильным использованием инструмента. Все события мы будем отрабатывать в ручном режиме и искать лучшие паттерны использования.

Подходы к сбору метрик

Встроенные метрики вендора

Если у вас Team-план, то, возможно, вендор предоставляет нужные метрики в админке. В случае с Claude Code нам не повезло и пришлось отказаться от этого варианта. В админскую панель на данный момент выгружается единственная метрика — использовался ли в этот день инструмент или нет пользователем (давно обещают когда-то завести нормальную статистику в Team-план).

Плюсы:

• быстро
• без разработки

Минусы:

• скудный набор метрик, на который не повлиять

Всё что смог показать Anthropic из коробки.

Нативный OpenTelemetry-экспорт

У Claude Code есть встроенный OpenTelemetry-экспорт — метрики и события засылаются в любой OTLP-коллектор (например, Prometheus). Включить можно централизованно через энв-переменные в managed-настройках организации.

"env": {
  "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
  "OTEL_METRICS_EXPORTER": "otlp",
  "OTEL_LOGS_EXPORTER": "otlp",
  "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
  "OTEL_EXPORTER_OTLP_ENDPOINT": "http://your-collector:4317"
}

Из коробки доступны разные метрики — например, claude_code.session.count, claude_code.token.usage, claude_code.cost.usage, claude_code.lines_of_code.count и события по использованию инструментов.

По умолчанию содержимое сессий не выгружается. Переменные OTEL_LOG_USER_PROMPTS, OTEL_LOG_TOOL_DETAILS, OTEL_LOG_TOOL_CONTENT, OTEL_LOG_RAW_API_BODIES включают выгрузку разного содержимого.

Плюсы:

• встроено, централизованное включение через managed-настройки, без скрипта на каждой машине
• стандартный формат — подключается к существующему стеку

Минусы:

• нужен поднятый и настроенный OTLP-коллектор, к которому есть доступ с клиентских машин

Прокси

Идея простая — все запросы к ИИ от пользователей идут через прокси-сервис, который сохраняет все запросы для дальнейшей аналитики. Также через прокси можно управлять безопасностью, например ловить сообщения к ИИ с секретами и запрещать их. Мы сейчас как раз пилим такой сервис, но пока он не внедрён.

Плюсы:

• полный контроль над использованием ИИ
• единая точка данных

Минусы:

• сложно в разработке и поддержке

Единый MCP

На компанию создаётся один MCP gateway. Внутри он имеет доступ до всех остальных MCP серверов. Пользователь должен подключить у себя только один MCP gateway сервер. Это упрощает настройку и администрирование.

MCP gateway может собирать логи по использованию различных инструментов внутри себя, а также гибко настраиваются права доступа.

Плюсы:

• Гибкий контроль прав доступа
• Простое внедрение для пользователя

Минусы:

• собираем информацию только по использованию различных MCP
• сложно в разработке и поддержке

Свой кастомный сборщик

Для старта мы пошли по своему пути и сделали свой анализатор логов. Архитектурно он представляет собой скрипт на машине пользователя, который раз в день парсит логи Claude Code и отправляет на хранение в БД.

Этот сборщик сделал Claude Code, так сказать доделал начатое за Anthropic.

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

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

Важно: Сборщик метрик — это инструмент улучшения процессов и принятия решений на уровне компании, а не контроля разработчиков.

Что собирает скрипт

Скрипт читает локальные JSONL-логи Claude Code из ~/.claude/projects, агрегирует данные по дням и отправляет в API суточную статистику:

• количество AI-запросов
• входные, выходные и общие токены
• число web search запросов
• количество промптов
• суммарную и медианную длину промптов
• количество сессий
• количество прерываний агента
• dev_id и hostname машины

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