Запуск синтетических мониторов по требованию для CI/CD

Пояснение

ActiveGate версии 1.233+

Помимо запуска синтетических мониторов по расписанию с заданными интервалами (в настройках Частота и локации), вы также можете запускать выполнение по требованию для мониторов браузера, а также HTTP мониторов. Вы даже можете запускать выполнение по требованию для автоматически созданных HTTP-мониторов для синхронизации учётных данных. В веб-интерфейсе Dynatrace выберите Выполнение по требованию в верхней части страницы сведений о мониторе.

Запуск выполнения по требованию

Вы также можете использовать мощный API Synthetic — Выполнение мониторов по требованию для запуска выполнения нескольких мониторов и получения результатов. Запросы на выполнение по требованию имеют приоритет над запланированными выполнениями и помещаются в начало очереди запросов.

Вы можете запускать выполнение по требованию из любой назначенной или не назначенной локации через веб-интерфейс или через API.

При создании и редактировании синтетического монитора вы также можете настроить его на выполнение исключительно по требованию — выберите частоту Только по требованию.

Частота «Только по требованию»

Выполнения по требованию с их мощными возможностями являются ценным инструментом в вашей стратегии CI/CD:

Мониторы можно запускать по требованию из любой локации — публичной или частной.
Результаты выполнения по требованию можно включать или исключать из общих результатов монитора.
Выполнения можно включать или исключать из обнаружения проблем.
Выполнения можно запускать через веб-интерфейс или API.

Такие выполнения позволяют проверить успешность нового развёртывания программного обеспечения и могут быть интегрированы с инструментами сборки, такими как Jenkins или Keptn.

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

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

Выполнение по требованию через интерфейс¶

Кнопка Выполнение по требованию на страницах сведений о синтетическом мониторе позволяет запускать выполнения для выбранного монитора из всех или выбранной локации. Здесь же отображается список всех выполнений по требованию для монитора за последние шесть часов, запущенных любым пользователем через веб-интерфейс или API.

Страница выполнения по требованию

Запуск выполнения¶

Любой пользователь с разрешением Просмотр среды на уровне среды или Management Zone может запустить выполнение через интерфейс.

Даже если вы отключите запланированное выполнение синтетического монитора в течение окон обслуживания, вы всё равно можете запускать мониторы по требованию.

Выберите Выполнение по требованию в верхней части страницы сведений о мониторе.
Вы будете перенаправлены на страницу Выполнение по требованию. Выберите Все назначенные локации или любую назначенную или не назначенную публичную или частную локацию.
Выберите Режим обработки — обратите внимание, что он применяется ко всем выполнениям при выборе всех локаций.
Стандартный (по умолчанию) — выполнения учитываются при обнаружении проблем, а также в статистике доступности и производительности. Для браузерных мониторов данные можно просматривать на странице Многомерный анализ. Для HTTP-мониторов результаты выполнения доступны при Анализе деталей выполнения.
Отключить обнаружение проблем — выполнения учитываются в статистике доступности и производительности, но не при обнаружении проблем. Для браузерных мониторов точки данных отображаются на странице Многомерный анализ; для HTTP-мониторов результаты выполнения доступны при Анализе деталей выполнения.
Только детали выполнения — выполнения не учитываются ни в статистике доступности и производительности, ни при обнаружении проблем. Для HTTP-мониторов результаты по-прежнему доступны при Анализе деталей выполнения; для браузерных мониторов точки данных отображаются на странице Многомерный анализ.

Обратите внимание, что для всех режимов обработки выполнения видны в списке выполнений по требованию в веб-интерфейсе и доступны через API выполнений по требованию. Сводная и подробная информация о выполнении доступна в течение шести часов через API. 4. Сбой при нарушении порога производительности — по умолчанию выполнения по требованию завершаются сбоем при нарушении порога производительности, поскольку их основная цель — проверка новых версий программного обеспечения в CI/CD-конвейере. Однако вы можете отключить этот параметр, чтобы выполнения по требованию вели себя как обычные запланированные (то есть нарушения порога производительности не приводили к сбою мониторов). 5. Только для HTTP-мониторов Сбой при отсутствующем или истекающем SSL-сертификате — сбой монитора, если один или несколько запросов обнаруживают истёкший, отсутствующий или истекающий SSL-сертификат.

Этот параметр работает только в том случае, если Проверка даты истечения SSL уже включена для HTTP-запроса в настройках монитора; он использует настройку на уровне запроса для проверки действительности SSL-сертификата в течение указанного количества дней.

Если в вашем мониторе несколько запросов с разными настройками действительности SSL-сертификата, параметр Сбой при отсутствующем или истекающем SSL-сертификате проверяет и учитывает каждую настройку. 6. Только для браузерных мониторов Делать снимок экрана при успешном выполнении — делать снимки экрана при успешном выполнении из публичных или частных локаций; по умолчанию этот параметр отключён. При включении снимки экрана при успехе делаются даже если монитор превысил порог производительности. Если вы запускаете выполнения из всех локаций, снимки экрана при успехе делаются из первой локации. Вы также можете включить создание снимков экрана при успехе для выполнений, запускаемых через API.

Обратите внимание, что снимки экрана автоматически делаются при сбое. 7. Выберите Запустить сейчас — появится диалоговое окно сводки со списком локаций выполнения; в списке выполнений появятся новые записи для запущенных выполнений. Стадия выполнения изначально имеет значение Triggered (Запущено).

Любые изменения сценария (конфигурации) монитора немедленно становятся доступны для выполнений по требованию в публичных или частных локациях.

Обратите внимание, что выполнения могут начаться не одновременно из разных локаций — из публичных локаций выполнение может начаться позже, чем из частных. Дополнительную информацию см. в разделе ограничение частоты запросов ниже.

Запущенное выполнение

Ограничение частоты запросов и лимиты¶

Между последовательными выполнениями монитора по требованию из одной и той же локации (независимо от способа запуска — через веб-интерфейс или API) для одного пользователя обязателен разрыв в 60 секунд.

Примеры ограничения частоты запросов

Во всех примерах предполагается выполнение из одной и той же локации.

Пользователь A запускает монитор через API в течение 60 секунд после запуска того же монитора через веб-интерфейс — запрос ограничен.
Пользователь B запускает монитор через API в течение 60 секунд после запуска того же монитора пользователем A через веб-интерфейс — без ограничений.
Пользователь B запускает монитор через веб-интерфейс в течение 60 секунд после запуска того же монитора пользователем A через веб-интерфейс — без ограничений.
Пользователь B запускает монитор через API в течение 60 секунд после запуска того же монитора пользователем A через API — без ограничений.
При запуске нескольких выполнений по требованию через API действует ограничение в 100 выполнений на пакет.
Также существует ограничение в 5000 выполнений по требованию в минуту для среды Dynatrace.
Вы можете определить до 64 пар ключ-значение метаданных на пакет, где ключи и значения могут иметь длину до 1024 символов каждый.
При указании повторных выполнений по требованию на локацию максимальное количество выполнений равно 10.

Ошибка запуска¶

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

Существует несколько дополнительных причин, по которым выполнения по требованию могут не быть успешно запущены через API: удаление монитора, некорректное указание идентификаторов монитора или локации, некорректное указание идентификаторов связанных служб или приложений, удаление локации, проблемы с публичной инфраструктурой Synthetic или проблемы с вашей средой мониторинга Dynatrace.

Если выполнение не может быть успешно запущено через веб-интерфейс, причины отображаются в Сводке статуса запуска после выбора Запустить сейчас. Стадия выполнения в списке выполнений имеет значение Not triggered (Не запущено). Сведения о выполнениях, не запущенных через API, возвращаются в параметрах ответа triggeringProblemsCount и triggeringProblemsDetails для POST-запроса.

Ошибка запуска

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

Список выполнений¶

В списке выполнений отображаются все выполнения по требованию (запущенные любым пользователем через веб-интерфейс или API) для данного монитора за последние шесть часов.

Список выполнений по требованию

Идентификатор выполнения — уникальный идентификатор, присвоенный каждому выполнению; при запуске выполнений из всех локаций выполнение в каждой локации имеет отдельный идентификатор.
Столбец Запущено показывает время начала выполнения в часовом поясе авторизованного пользователя.
Источник показывает, было ли выполнение запущено через веб-интерфейс (UI) или через API.
Столбец Пользователь показывает идентификатор пользователя Dynatrace, запустившего выполнение.
Столбец Локация показывает название публичной или частной локации, из которой был запущен монитор.
Стадия выполнения определяет различные этапы выполнения по требованию. Начальное значение — Triggered (Запущено) (или Not triggered — Не запущено). После завершения выполнения значение меняется на Executed (Выполнено). Основные результаты, такие как продолжительность и HTTP-код состояния, доступны на этой стадии. Индикатор загрузки продолжает отображаться на стадии Executed до тех пор, пока подробные результаты не станут доступны, а значение не изменится на Data retrieved (Данные получены). Если для одной локации запущено несколько последовательных выполнений, первое выполнение помечается как Triggered; остальные — как Waiting (Ожидание).
Столбец Результат показывает, было ли выполнение Success (Успешным) или Failure (Неуспешным) (с сопровождающей Причиной сбоя).
Вы можете Повторно запустить выполнение с точной заданной конфигурацией, например, с метаданными, определёнными через API. Помимо метаданных, повторяются и другие параметры выполнения: режим обработки, сбой при нарушении порога производительности, сбой из-за проблемы с SSL-сертификатом и создание снимка экрана при успехе.
Нажмите кнопку раскрытия в столбце Подробности, чтобы просмотреть продолжительность выполнения, метаданные пакета в виде пар ключ-значение (доступны только через API), а также ссылку на результаты.

Результаты¶

Когда Стадия выполнения в списке выполнений изменится на Data retrieved (Данные получены), вы можете перейти по ссылке детали выполнения для просмотра подробных результатов браузерного или HTTP-монитора.

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

Диаграмма рассеяния

Создание снимков экрана для браузерных мониторов при выполнении по требованию аналогично запланированным выполнениям. Однако вы можете включить создание снимков экрана при успехе через веб-интерфейс и через POST-запросы через API.

Для HTTP-мониторов вы будете перенаправлены на вкладку Выполнение по требованию страницы Анализ деталей выполнения. Также вы можете перейти на эту вкладку, выбрав Анализ деталей выполнения на странице сведений HTTP-монитора. Выберите выполнение по требованию Выполнение из выпадающего списка для просмотра его деталей.

Вкладка выполнений по требованию

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

API: Synthetic — Выполнение мониторов по требованию¶

Проверьте раздел об ограничении частоты запросов выше для получения информации о лимитах выполнения по требованию через веб-интерфейс и API.

Дополнительную информацию см. в документации по API v2 выполнения синтетических мониторов. Вы можете запустить пакетное выполнение, получить список выполнений по требованию, проверить основные и подробные результаты отдельного выполнения, а также проверить результаты пакетного выполнения.

Выполнения по требованию через API предлагают большую гибкость и масштабируемость, чем через веб-интерфейс. API Synthetic — Выполнение мониторов по требованию предлагает:

Возможность запуска нескольких мониторов по требованию (пакетное выполнение) путём указания идентификаторов мониторов и, опционально, идентификаторов локаций. Если локации не указаны, монитор запускается из всех назначенных локаций. Эта возможность доступна только через API.
Возможность запуска мониторов из любой локации. В POST-запросе для запуска выполнений по требованию каждый указанный монитор запускается из указанных локаций (или из всех назначенных локаций, если ни одна не указана).
ActiveGate версии 1.259+ Возможность указать количество выполнений для повторных запусков на локацию, что полезно для качественных шлюзов и нагрузочных тестов. Эта возможность доступна только через API. Параметр executionCount позволяет указать количество выполнений на локацию для каждого монитора; максимальное значение — 10; если значение не указано, монитор выполняется один раз на каждую локацию. Выполнения можно запускать последовательно (repeatMode имеет значение SEQUENTIAL) или параллельно (repeatMode имеет значение PARALLEL). Режим по умолчанию — последовательный.

В последовательном режиме каждое выполнение автоматически ссылается на следующее (если оно есть) с помощью параметра nextExecutionId. При запуске нескольких последовательных выполнений на одной локации первое выполнение находится на стадии Triggered, остальные помечаются как Waiting. Выполнения на каждой локации независимы друг от друга.

Если последовательное выполнение истекает по таймауту на одной локации, последующие выполнения на этой локации не запускаются.
Обратите внимание, что идентификаторы выполнений в nextExecutionId являются последовательными для публичных локаций и случайно генерируются для частных локаций.
Изменения сценария монитора или учётных данных после запуска пакета последовательных выполнений не влияют на оставшиеся выполнения. Таким образом, если другой пользователь изменяет сценарий, который вы выполняете последовательно, изменения сценария не отражаются в оставшихся выполнениях.
ActiveGate версии 1.259+ Возможность частичного переопределения сценария монитора и предоставления пользовательских значений параметров специально для выполнения по требованию, что упрощает перенастройку и тестирование синтетических мониторов. Эта возможность доступна только через API. Параметр customizedScript позволяет перечислить requests (для HTTP-мониторов) или events (для браузерных мониторов) с настройками для каждого запроса или события. Для HTTP-мониторов вы можете увидеть, какие параметры имели пользовательские значения, при Анализе деталей выполнения.

Следующие параметры можно настраивать для HTTP-мониторов

url
requestBody
validation
preProcessingScript
postProcessingScript
requestTimeout
authentication
configuration
- requestHeaders
- acceptAnyCertificate
- followRedirects

Следующие типы событий можно настраивать для браузерных мониторов

Navigate (Навигация)
Click (Клик)
JavaScript
Keystroke (Нажатие клавиши)
Tap (Касание)
Select option (Выбор опции)
Cookie

При желании можно указать sequenceId для порядка запроса или события в сценарии монитора. Например, используйте "sequenceId": "3", чтобы указать изменения для третьего события в браузерном мониторе. Если sequenceId не указан, изменения применяются к первому запросу или событию, которое ещё не было указано с помощью идентификатора последовательности в API-запросе. Примеры см. ниже.

Любые такие изменения сценария предназначены только для выполнения по требованию и после него не сохраняются.
Нельзя изменить или переупорядочить количество запросов или событий.
Нельзя изменить Имя запросов или событий (description в режиме сценария).
Нельзя изменить тип запроса (например, GET) или тип события (например, Navigate).
Нельзя добавить предварительный или последующий скрипт обработки к HTTP-монитору, у которого его нет.

Пример: HTTP-монитор с пользовательским URL для одного запроса

Поскольку идентификатор последовательности не указан, переопределение URL в этом примере применяется к первому HTTP-запросу.

{


"monitors": [


{


"monitorId": "HTTP_CHECK-C608F75BF82E5B22",


"customizedScript": {


"requests": [


{


"url": "https://www.yourdomain.com"


}


]


}


}


]


}

Пример: HTTP-монитор с переопределениями для двух запросов

Поскольку идентификатор последовательности не указан, переопределение URL и предварительный скрипт с методом api.fail() применяются к первому HTTP-запросу. Обратите внимание, что переопределить предварительный или последующий скрипт можно только для монитора, у которого уже определён такой скрипт. Для третьего запроса, где указан идентификатор последовательности, добавлено правило проверки.

{


"monitors": [


{


"monitorId": "HTTP_CHECK-6349B98E1CD87352",


"customizedScript": {


"requests": [


{


"url": "https://www.somepage.org",


"preProcessingScript": "if (response.getResponseBody().includes(\"error\")) {api.fail(\"HTTP failing monitor.\");}"


},


{


"sequenceId": "3",


"validation": {


"rules": [


{


"value": "=201",


"passIfFound": "true"


}


]


}


}


]


}


}


]


}

Пример: Браузерный монитор с пользовательским URL для события Navigate

Поскольку идентификатор последовательности не указан, переопределение URL в этом примере применяется к первому событию Navigate.

{


"takeScreenshotsOnSuccess": true,


"monitors": [


{


"monitorId": "SYNTHETIC_TEST-114F1C18CF07CD1D",


"customizedScript": {


"events": [


{


"type": "navigate",


"url": "www.yourdomain.com"


}


]


}


}


]


}

* Возможность запуска группы мониторов по требованию путём указания общих тегов и/или идентификаторов связанных служб или приложений. Обратите внимание, что для запуска монитора по требованию должны совпасть все указанные условия. Эта возможность доступна только через API.

Если в POST-запросе указаны три монитора по идентификатору и один тег, то будут выполнены все три монитора плюс все мониторы, соответствующие тегу. * Автоматическое присвоение идентификатора пакета для всех выполнений метода POST — как для одного монитора, так и для нескольких. Это позволяет получать результаты и по идентификатору пакета. * Возможность определять пользовательские пары ключ-значение, например, для идентификации версий приложений, в составе metadata пакета. Эта возможность доступна только через API. На пакет можно определить до 64 пар, где ключи и значения могут иметь длину до 1024 символов каждый. Метаданные в виде пар ключ-значение доступны в результатах отдельного и пакетного выполнения, получаемых через API, и отображаются в веб-интерфейсе. * Создание снимков экрана при успехе для браузерных мониторов из публичных или частных локаций путём установки "takeScreenshotsOnSuccess": true в POST-запросе (по умолчанию false). Снимки экрана при успехе делаются из первой указанной локации для каждого идентификатора монитора. Если локация не указана (например, при использовании тегов для определения списка мониторов), снимки делаются из любой из локаций, назначенных монитору.

Обратите внимание, что снимки экрана автоматически делаются при сбое. Но если монитор завершается с ошибкой из-за нарушения порога производительности, он всё равно считается доступным и снимки экрана не делаются; однако вы можете включить takeScreenshotsOnSuccess. * Возможность завершить выполнение HTTP-монитора по требованию с ошибкой, если SSL-сертификат отсутствует, истёк или истекает (параметр failOnSslWarning). * Возможность остановить запуск всех выполнений в пакете при возникновении проблемы с запуском любого выполнения (параметр stopOnProblem), например, если идентификатор монитора неверный/отсутствует или монитор удалён. Эта возможность доступна только через API. * Получение списка выполнений по требованию (запущенных через веб-интерфейс или API всеми пользователями в вашей среде) за последние шесть часов. Список содержит идентификаторы выполнений. Этот список можно фильтровать по:

Временным меткам выполнения и доставки данных
Идентификаторам пакетов
Идентификаторам мониторов
Идентификаторам локаций
Идентификаторам пользователей
Получение основных и более подробных результатов выполнения (для которого указывается идентификатор выполнения).

Основные результаты лучше всего подходят для целей CI/CD и включают количество выполненных запросов/событий, результат успеха/сбоя и некоторые ключевые метрики. Например, основные результаты для HTTP-мониторов сообщают общий размер запроса (для всех запросов вместе), время до первого байта, время TLS-рукопожатия, время установления TCP-соединения, время DNS-поиска и окончательный HTTP-код состояния.

Подробные результаты лучше подходят для устранения неполадок. Для HTTP-мониторов это полный набор результатов, отображаемых в веб-интерфейсе при выборе Анализ деталей выполнения. * Пакетное получение результатов при указании идентификатора пакета.

Результаты пакета включают информацию о запущенных выполнениях и выполнениях, завершившихся с результатом.

Обратите внимание, что executedCount — это количество выполнений, завершившихся успехом или сбоем. failedToExecuteCount — количество выполнений, которые были запущены, но для которых результаты недоступны по техническим причинам (например, проблема с ActiveGate или движком Synthetic, или результаты не удалось отправить в кластер Dynatrace). executedCount + failedToExecuteCount = triggeredCount. * Детализированные разрешения для запуска и получения данных о выполнениях по требованию.

Для запуска выполнений (POST) вам нужны права на создание мониторов (область токена ExternalSyntheticIntegration) или область токена syntheticExecutions.write, которая позволяет запускать выполнения, но не создавать новые мониторы.

Для получения данных (GET) вам нужна любая из областей токена ExternalSyntheticIntegration, ReadSyntheticData или syntheticExecutions.read.

Связанные темы¶

API v2 выполнения синтетических мониторов