Как отслеживать состояние инфраструктуры

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

Проверять работу системы нужно регулярно, но особенно важно делать это в следующих случаях:

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

В Google Cloud Platform есть три полезных инструмента для мониторинга: отчеты App Engine, Cloud Logging и отчеты о платежах.

Отчеты App Engine

Если вы развернули среду добавления тегов на стороне сервера в Google App Engine, то в разделе App Engine консоли Google Cloud Platform вам доступны весьма полезные отчеты.

В подразделе Instances (Экземпляры) вы можете выбрать в раскрывающемся списке Chart Settings (Настройки диаграммы) пункт Instances (Экземпляры), чтобы получить удобный отчет об общем состоянии ваших экземпляров:

Скриншот отчета App Engine в Google Cloud Platform
  1. Выберите промежуток времени, по которому будет показана статистика.
  2. На карточке Instances (Экземпляры) можно посмотреть, сколько экземпляров было развернуто в указанное время. Если количество экземпляров окажется ниже настроенного вами минимального значения, в выбранном регионе Google Cloud могут возникнуть проблемы с доступностью ресурсов.
  3. Карточка Autoscaling (Автомасштабирование) показывает, сколько экземпляров создается в зависимости от общей загрузки ЦП. Вы можете увидеть, как App Engine создает дополнительные экземпляры, когда уже имеющиеся используют более 0,6 (60 %) мощности своего ЦП. Если у вас три экземпляра, общая загрузка ЦП должна быть ниже 1,8. Если вы видите, что она постоянно близка к целевому пороговому значению или превышает его, это означает, что минимального количества экземпляров недостаточно.
  4. В списке Instances (Экземпляры) перечислены экземпляры, которые используются в данный момент. Убедитесь, что все они имеют статус Healthy (Без сбоев).

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

Иногда в регионе Google Cloud, в котором работает ваше приложение (по умолчанию это us-central1), могут возникнуть проблемы с доступностью ресурсов. Чтобы это проверить, рекомендуем использовать Cloud Logging (см. далее), а также панель мониторинга Google Cloud Service Health (Состояние сервисов Google Cloud).

Cloud Logging

App Engine автоматически сохраняет много полезной информации о состоянии вашей среды в сервисе Google Cloud, который называется Cloud Logging.

Вы можете изучить журналы своего сервера тегов на странице Logs Explorer (Просмотр журналов).

Скриншот панели мониторинга для изучения журналов.
  1. Выберите диапазон дат, по которому будет показана статистика.
  2. Введите запрос, чтобы отфильтровать записи в журналах (варианты запросов приведены ниже).
  3. Включите параметр Histogram (Гистограмма), чтобы быстро оценить серьезность, присвоенную записям в журналах (примеры: "Информация", "Предупреждение", "Ошибка").
  4. Нажмите на любую запись в списке, чтобы посмотреть дополнительные сведения.

Ниже приведены варианты запросов, которые помогут вам отслеживать состояние сервера тегов.

Фильтрация по системным ошибкам

По запросу 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, например, когда содержимое закодировано в теле запроса, это содержимое нельзя посмотреть в журналах.

Поздравляем с завершением курса!

Помогите нам его улучшить, пройдя опрос.

Что дальше?

Если вам нужно настроить дополнительные теги, ознакомьтесь с материалами по добавлению тегов на стороне сервера:

Нужна помощь?

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