Как отслеживать состояние инфраструктуры
После того как вы подготовите среду добавления тегов на стороне сервера к работе в реальных условиях, вам нужно будет активно отслеживать ее состояние.
Проверять работу системы нужно регулярно, но особенно важно делать это в следующих случаях:
- при первоначальном развертывании среды и в последующие несколько дней или недель, чтобы убедиться, что у вас достаточно вычислительных ресурсов для обработки входящего трафика;
- перед ожидаемым увеличением объема трафика, например при запуске сезонных кампаний или накануне выпуска нового продукта.
В Google Cloud Platform есть три полезных инструмента для мониторинга: отчеты App Engine, Cloud Logging и отчеты о платежах.
Отчеты App Engine
Если вы развернули среду добавления тегов на стороне сервера в Google App Engine, то в разделе App Engine консоли Google Cloud Platform вам доступны весьма полезные отчеты.
В подразделе Instances (Экземпляры) вы можете выбрать в раскрывающемся списке Chart Settings (Настройки диаграммы) пункт Instances (Экземпляры), чтобы получить удобный отчет об общем состоянии ваших экземпляров:

- Выберите промежуток времени, по которому будет показана статистика.
- На карточке Instances (Экземпляры) можно посмотреть, сколько экземпляров было развернуто в указанное время. Если количество экземпляров окажется ниже настроенного вами минимального значения, в выбранном регионе Google Cloud могут возникнуть проблемы с доступностью ресурсов.
- Карточка Autoscaling (Автомасштабирование) показывает, сколько экземпляров создается в зависимости от общей загрузки ЦП. Вы можете увидеть, как App Engine создает дополнительные экземпляры, когда уже имеющиеся используют более 0,6 (60 %) мощности своего ЦП. Если у вас три экземпляра, общая загрузка ЦП должна быть ниже 1,8. Если вы видите, что она постоянно близка к целевому пороговому значению или превышает его, это означает, что минимального количества экземпляров недостаточно.
- В списке Instances (Экземпляры) перечислены экземпляры, которые используются в данный момент. Убедитесь, что все они имеют статус Healthy (Без сбоев).
Если данные этих диаграмм или отчетов вызывают у вас беспокойство, рекомендуем повторно выполнить сценарий командной строки. В результате среда добавления тегов на стороне сервера будет развернута повторно. Это может решить проблему, даже если вы оставите настройки без изменений.
Иногда в регионе Google Cloud, в котором работает ваше приложение (по умолчанию это us-central1), могут возникнуть проблемы с доступностью ресурсов. Чтобы это проверить, рекомендуем использовать Cloud Logging (см. далее), а также панель мониторинга Google Cloud Service Health (Состояние сервисов Google Cloud).
Cloud Logging
App Engine автоматически сохраняет много полезной информации о состоянии вашей среды в сервисе 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 Рекламе
Нужна помощь?
Если вам нужна помощь в настройке тегов отслеживания, вы можете обратиться к нашим сертифицированным партнерам или задать вопрос участникам сообщества.