Экспорт телеметрии выводит наружу метрики и журналы работы команды в коллектор, который вы держите у себя. Механизм серверный: данные отправляет сторона сервиса, а не машины разработчиков, поэтому ни установка агентов на рабочие места, ни правка настроек у каждого человека не требуются. Порог входа выглядит так: адрес HTTPS, принимающий OTLP/HTTP в двоичном protobuf по путям /v1/metrics и /v1/logs, аутентификация по bearer-токену или ключу API и доступность этого адреса из публичной сети. Возможность относится к корпоративному уровню и находится в стадии беты.
Наивное представление обычно звучит так: указать адрес, включить переключатель, дальше данные потекут сами, как из любого другого источника внутри периметра. Ожидание разумное, потому что именно так ведёт себя большинство внутренних конвейеров наблюдаемости: коллектор стоит рядом, сеть своя, формат переживает почти всё, а если что-то не пришло, это видно по пустому графику через минуту после включения.
Ломается ожидание в нескольких местах сразу. Базовый адрес указывают без путей: /v1/metrics и /v1/logs дописываются автоматически, и адрес, указанный вместе с ними, приведёт не туда, куда вы думаете. Формат один - двоичный protobuf; конвейер, настроенный на приём JSON, молча не примет ничего. Отправка идёт с фиксированного набора исходящих адресов, и коллектор за списком доступа надо открыть заранее, иначе первый же поток упрётся в межсетевой экран. Наконец, встроенная проверка соединения подтверждает адрес и учётные данные, но не подтверждает, что ваш конвейер разберёт записи и что вы найдёте их потом у себя в хранилище.
Порядок работ поэтому фиксированный: создать назначение с базовым адресом и заголовками аутентификации, проверить соединение, включить экспорт - поток начинается примерно через минуту. Заголовки хранятся в зашифрованном виде. Смена учётных данных делается правкой назначения, изменение расходится примерно за полминуты; отключение или удаление назначения роняет данные, находящиеся в полёте. Отсюда правило ротации: ключ меняют редактированием, а не парой удалить и создать заново, иначе окно между двумя действиями станет дырой в ряду.
Состав выгрузки определён заранее и разложен на семейства сигналов, каждое из которых выключается отдельно: расход моделей, вызовы инструментов, события навыков, обработчиков и плагинов, жизненный цикл облачных агентов. Такое деление важнее, чем кажется: оно задаёт единицу торга с юристами и службой безопасности, потому что отключают не отдельные поля, а целое семейство. Ниже такая карта: слева имена записей, посередине их содержимое, справа семейство, которым запись включается и выключается.
Метрики приходят монотонными суммами с дельта-темпоральностью: токены по типам, где типов четыре - вход, выход, чтение кеша и создание кеша; вызовы встроенных инструментов и инструментов MCP; оценка стоимости в долларах. Слово оценка тут несущее: это не счёт. При собственном ключе провайдера оценка отражает только тариф сервиса за токены и ничего не знает о том, что выставит провайдер. Журналы несут сводки вызовов модели, события ошибок без исходного текста сообщений, уточнения расчёта, срабатывания навыков, завершение обработчиков, установку плагинов и жизненный цикл облачных агентов: подготовку окружения, артефакты, открытие пул-реквестов и отказы авторизации MCP. Содержимое подсказок, код и трассировки не уходят вовсе.
| Запись | Что несёт | Семейство |
|---|---|---|
| cursor.token.usage | Токены по типам: вход, выход, чтение кеша, создание кеша | model_usage |
| cursor.cost.usage | Оценка расхода в долларах по возможности, не счёт | model_usage |
| cursor.api.request, cursor.api.error, cursor.api.correction | Сводка вызова модели, ошибка без исходного текста, уточнение расчёта | model_usage |
| cursor.tool.calls | Вызовы встроенных инструментов и инструментов MCP | tool_calls |
| cursor.skill.activated, cursor.hook.execution_complete, cursor.plugin.installed | Срабатывание навыка, завершение обработчика, установка плагина | skills_hooks_plugins |
| cursor.cloud_agent.setup, .artifact, .pull_request, .mcp_auth_error | Подготовка окружения, артефакты, пул-реквесты, отказ авторизации MCP | cloud_agents |
Сшивание записей устроено намеренно неудобно, и причина в кардинальности. Метрики не несут идентификаторов связи: если бы каждая точка ряда носила номер разговора, число рядов росло бы вместе с числом сессий и хранилище задохнулось бы на ровном месте. Поэтому связь ищут в журналах. Ключ сессии - cursor.conversation.id, он же идентификатор чата или облачного агента. Ключ уровня запроса для сверки - cursor.usage_event.id. Идентификатор отдельного вызова - cursor.request.id, необязательный. И cursor.event.id, который годится только для устранения дублей и ни для чего больше. Ресурсные атрибуты несут имя службы, идентификатор команды, необязательный идентификатор пользователя и поверхность, с которой пришла запись.
Гарантии доставки у двух сигналов разные, и это цена, которую платят молча. Журналы доставляются не менее одного раза, с окном повторов около недели: дубли неизбежны, снимают их по ключу события, и конвейер, не умеющий их снимать, будет считать вдвое. Метрики доставляются не более одного раза и без повторов: после сбоя в ряду останется провал, и восполнить его нечем. Данных за время до создания назначения не будет вовсе - историю не подгружают. И ещё одна деталь ломает наивную обработку: уточнения расчёта приходят позже запросов, которые они правят, поэтому порядок восстанавливают по времени записи, а не по времени прихода.
Политика изменений формата объявлена прямо: поверхность дополняемая, неизвестные атрибуты, события и значения перечислений следует принимать молча, а переименования и удаления получают явное предупреждение. Версия области телеметрии - 0.1.0, стадия - бета, и до общего доступа формат может измениться. Практический вывод один: разбор строят терпимым, без жёсткой схемы, падающей на незнакомом поле. Проверяют результат не переключателем и не тестом соединения, а сквозным проходом: сделать реальную работу, найти запись в своём хранилище по ключу сессии, сверить число событий с ожидаемым и убедиться, что повторная доставка не задваивает счёт.
Типичные провалы предсказуемы. Указать адрес вместе с путями и получить не тот приёмник. Настроить приём JSON и ждать данных, которых не будет. Забыть открыть коллектор фиксированным исходящим адресам. Считать успешный тест соединения доказательством, что записи разбираются. Ротировать ключ через удаление назначения и потерять то, что было в полёте. Принимать оценку стоимости за счёт, особенно при собственном ключе провайдера. Строить отчёты на метриках в расчёте на разбор по разговорам, для которого нужны журналы. И жёстко фиксировать схему разбора на формате, который объявлен дополняемым и находится в бете.