Как отслеживать состояние инфраструктуры
После того как вы подготовите среду добавления тегов на стороне сервера к работе в реальных условиях, вам нужно будет активно отслеживать ее состояние.
Проверять работу системы нужно регулярно, но особенно важно делать это в следующих случаях:
- при первоначальном развертывании среды и в последующие несколько дней или недель, чтобы убедиться, что у вас достаточно вычислительных ресурсов для обработки входящего трафика;
- перед ожидаемым увеличением объема трафика, например при запуске сезонных кампаний или накануне выпуска нового продукта.
В Google Cloud Platform есть три полезных инструмента для мониторинга: отчеты Cloud Run, Cloud Logging и отчеты о платежах.
Отчеты Cloud Run
Если вы развернули среду добавления тегов на стороне сервера в Google Cloud Run, то в разделе Cloud Run консоли Google Cloud Platform вам доступны весьма полезные отчеты.
При выборе сервиса Cloud Run откроется страница статистики с отчетом об общем состоянии сервера тегов.
- Выберите промежуток времени, по которому будет показана статистика.
- На карточке Request count (Количество запросов) можно посмотреть, сколько запросов получает сервис. Каждые 60 секунд осуществляется выборка и категоризация значений по различным кодам HTTP-ответов (например, 2XX, 4XX, 5XX).
- На карточке Container instance count (Количество экземпляров контейнера) можно посмотреть, сколько экземпляров было развернуто в указанное время. Если этот показатель окажется меньше установленного вами минимального значения, в выбранном регионе Google Cloud могут возникнуть проблемы с доступностью ресурсов.
- На карточке Container CPU utilization (Использование ЦП контейнера) можно посмотреть, насколько сильно сервис загружает ЦП. У вас будет возможность наблюдать, как Cloud Run создает дополнительные экземпляры, когда существующие используют более 0,6 (60 %) ЦП. Если вы видите, что загрузка ЦП постоянно близка к целевому пороговому значению или превышает его, это означает, что минимального количества экземпляров недостаточно.
Если данные этих диаграмм или отчетов вызывают у вас беспокойство, рекомендуем развернуть новую версию в пользовательском интерфейсе Cloud Run. Это может решить проблему, даже если вы оставите настройки без изменений. Обратите внимание, что среда добавления тегов на стороне сервера будет развернута повторно.
Иногда в регионе Google Cloud, в котором работает ваш сервис (по умолчанию это us-central1), могут возникнуть проблемы с доступностью ресурсов. Чтобы это проверить, рекомендуем использовать Cloud Logging (см. далее), а также панель мониторинга Google Cloud Service Health (Состояние сервисов Google Cloud).
Cloud Logging
Cloud Run автоматически сохраняет много полезной информации о состоянии вашей среды в сервисе Google Cloud, который называется Cloud Logging.
Вы можете изучить журналы своего сервера тегов на странице Logs Explorer (Просмотр журналов).
- Выберите диапазон дат, по которому будет показана статистика.
- Введите запрос, чтобы отфильтровать записи в журналах (варианты запросов приведены ниже).
- Включите параметр Histogram (Гистограмма), чтобы быстро оценить серьезность, присвоенную записям в журналах (примеры: "Информация", "Предупреждение", "Ошибка").
- Нажмите на любую запись в списке, чтобы посмотреть дополнительные сведения.
Ниже приведены варианты запросов, которые помогут вам отслеживать состояние сервера тегов.
Фильтрация по системным ошибкам
По запросу severity = "ERROR"
возвращаются записи, которые классифицируются как ошибки в работе сервера. Этот запрос позволяет отследить сбои в работе сервера тегов и неполадки с экземплярами. Например, запись в журнале со статусом ERROR
может иметь такое описание: ZONE_RESOURCE_POOL_EXHAUSTED
. Эта ошибка означает, что Google Cloud Platform не удалось предоставить вам нужные экземпляры.
Фильтрация по HTTP-запросам с ошибкой
По запросу httpRequest.status >= 400
в журналах показываются HTTP-запросы, в ответ на которые серверный контейнер Менеджера тегов вернул ошибку HTTP (со статусом 400 или выше).
Ошибки 400 обычно означают, что запрос был отправлен в конечную точку среды добавления тегов на стороне сервера, но ни один клиент не смог его принять. Это могут быть запросы от ботов и поисковых роботов, которые можно проигнорировать. Если же к ошибке 400 приводят ваши потоки данных, вам нужно проверить конфигурацию клиентов в серверном контейнере.
Ошибки 5XX указывают на проблему с самим сервисом Google Cloud. Они могут свидетельствовать о непройденных проверках состояния или проблемах с балансировщиком нагрузки. Кроме того, ошибки 5XX часто возникают в том случае, если вашей среде не хватает ресурсов.
Фильтрация по журналам со стандартными выходными данными
Запрос logName: "stdout"
возвращает журнал со стандартными выходными данными вашего сервиса. Этот журнал может быть полезен, если ваши серверные ресурсы (клиенты, теги и переменные) используют для регистрации данных изолированный API logToConsole.
Фильтрация по входящим HTTP-запросам
Запрос logName: "logs/requests"
возвращает журналы с данными самих входящих HTTP-запросов. Вы увидите их только в том случае, если не отключили ведение журнала запросов, когда выполняли сценарий командной строки, и не применили другие фильтры журналов.
Чтобы посмотреть подробные сведения о запросе, нажмите на нужную строку в списке, но учтите, что тело HTTP-запроса не отображается в журналах. Вы увидите только URL запроса и дополнительные метаданные. Если запрос отправляется с помощью метода POST
, например, когда содержимое закодировано в теле запроса, это содержимое нельзя посмотреть в журналах.
Поздравляем с завершением курса!
Помогите нам его улучшить, пройдя опрос.
Что дальше?
Если вам нужно настроить дополнительные теги, ознакомьтесь с материалами по добавлению тегов на стороне сервера:
- Как настроить теги Google Floodlight
- Как настроить конверсии Google Рекламы
- Как настроить ремаркетинг в Google Рекламе
Нужна помощь?
Если вам нужна помощь в настройке тегов отслеживания, вы можете обратиться к нашим сертифицированным партнерам или задать вопрос участникам сообщества.