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

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

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

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

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

Отчеты Cloud Run

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

При выборе сервиса Cloud Run откроется страница статистики с отчетом об общем состоянии сервера тегов.

Скриншот отчета Cloud Run в Google Cloud Platform
  1. Выберите промежуток времени, по которому будет показана статистика.
  2. На карточке Request count (Количество запросов) можно посмотреть, сколько запросов получает сервис. Каждые 60 секунд осуществляется выборка и категоризация значений по различным кодам HTTP-ответов (например, 2XX, 4XX, 5XX).
  3. На карточке Container instance count (Количество экземпляров контейнера) можно посмотреть, сколько экземпляров было развернуто в указанное время. Если этот показатель окажется меньше установленного вами минимального значения, в выбранном регионе Google Cloud могут возникнуть проблемы с доступностью ресурсов.
  4. На карточке 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 (Просмотр журналов).

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

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

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

Что дальше?

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

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

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