# Телеметрія вебсайту > Чому трасувальник завантажується для кожного розгортання сайту проєкту на Netlify і жодного іншого, чому поширення контексту залишається без Zone, і як виявляється збій експорту, коли збирач відстає від експортера --- Site [llms.txt](/uk/llms.txt) --- Примітки щодо дизайну для функції [телеметрії вебсайту](/site/features/#website-telemetry). ## Шлюз розгортання {#deployment-gate} Завантажуйте трасувальник для [кожного розгортання сайту проєкту на Netlify](/site/features/#website-telemetry) і жодного іншого розгортання. Частковий шаблон `body-end` розпізнає цей сайт за змінною збірки `SITE_NAME`, яку встановлює Netlify. - Попередні перегляди мають трасуватися. Обмеження за ідентичністю сайту, а не за середовищем Hugo, ставить виробництво, deploy preview і розгортання гілок в однакові умови, тож зміна в трасуванні видно в її deploy preview. - Форки не мають трасуватися. Форк, розгорнутий на власному сайті Netlify, має власний `SITE_NAME`, тож він успадковує шлюз, але не трасування. - Це простий шлюз розгортання. Значення Netlify не можна змінити, але будь-хто, хто контролює власну збірку, може встановити будь-яку змінну. Відхилення сфабрикованої телеметрії є завданням збирача, а не сайту. - Незаданий `SITE_NAME` закриває шлюз без сигналу; перейменування сайту Netlify дало б той самий результат, доки шаблон не наздожене. Локальна збірка долучається, встановивши змінну ([Build та serve](/site/build/npm-scripts/#build-and-serve)). ## Менеджер контексту {#context-manager} Використовуйте `StackContextManager` з `@opentelemetry/sdk-trace`, пакунка, який [посібник з міграції на 3.x][3.x migration guide] JS SDK називає заміною `sdk-trace-web`, а не `ZoneContextManager`. - `zone.js` перехоплює поширені асинхронні API у браузері (`Promise`, таймери, обробники подій) і додає близько 13 КБ після gzip-стиснення до кожної сторінки. Його поширення контексту через зворотні виклики справжнє, але воно не може перетнути нативні `async`/`await`, а статичному сайту з одним-двома викликами `fetch` на сторінку це не потрібно. Контекст не поширюється автоматично через `await` чи в незвʼязаний зворотний виклик: відрізок, розпочатий там, є власним коренем, якщо код явно не передає батьківський контекст, як це робить інструментування `fetch` для свого preflight-відрізка. Для телеметрії цього сайту це прийнятно. ## Збирач {#collector} Збирач, що стоїть за експортом, має іншого власника й інший цикл випуску, ніж сайт, тож його версія OTLP не привʼязана до версії експортера сайту, і оновлення експортера може надсилати поля, які збирач ще не приймає. Збій експорту не впливає на сторінку. SDK не повідомляє про нього (діагностичний логер не налаштовано), тож єдиною ознакою є власний запис браузера про відхилений запит на панелі мережі DevTools (консолі Chromium також його логують, але Firefox ні); відрізки, які друкує консольний експортер, нічого не кажуть про те, чи прийняв їх збирач. [3.x migration guide]: https://github.com/open-telemetry/opentelemetry-js/blob/main/doc/3.x/migration-guide.md#opentelemetrysdk-trace-web-package-removed