Синтетические мониторы в Smartscape

Синтетические мониторы в Smartscape

Синтетические мониторы, их шаги и локации, из которых они запускаются, моделируются как ноды первого класса в Smartscape. Они используют тот же граф топологии, семантику и язык запросов, что и остальное окружение — хосты, сервисы, фронтенды и рабочие нагрузки Kubernetes. На этой странице описана модель — её типы нодов, их атрибуты и связи между ними, а также показано, как запрашивать синтетические мониторы, шаги и локации с помощью DQL (astromkey Query Language).

Синтетические сущности моделируются как ноды Smartscape, а их отношения — как связи. На этой странице под неуточнённой сущностью или dt.entity.* подразумевается классическая модель.

Типы нодов

Синтетический мониторинг моделируется следующими типами нодов Smartscape:

Сущность Smartscape	Тип ноды	Идентификатор модели Smartscape	Классическая модель сущности
Браузерный монитор	BROWSER_MONITOR	dt.smartscape.browser_monitor	dt.entity.synthetic_test
Шаг браузерного монитора	BROWSER_MONITOR_STEP	dt.smartscape.browser_monitor_step	dt.entity.synthetic_test_step
HTTP-монитор	HTTP_MONITOR	dt.smartscape.http_monitor	dt.entity.http_check
Шаг HTTP-монитора	HTTP_MONITOR_STEP	dt.smartscape.http_monitor_step	dt.entity.http_check_step
Монитор сетевой доступности	NETWORK_AVAILABILITY_MONITOR	dt.smartscape.network_availability_monitor	dt.entity.multiprotocol_monitor
Синтетическая локация	SYNTHETIC_LOCATION	dt.smartscape.synthetic_location	dt.entity.synthetic_location

Типы нодов, их атрибуты и отношения определены в группе моделей Smartscape — Synthetic в Семантическом словаре.

Атрибуты

Как ноды Smartscape, синтетические мониторы, шаги и локации могут запрашиваться для дашбордов, соглашений об уровне обслуживания (SLO) и навигации по топологии. Каждый тип ноды отвечает на разные вопросы:

Тип ноды	Примеры вопросов	Ключевые атрибуты
HTTP_MONITOR, BROWSER_MONITOR, NETWORK_AVAILABILITY_MONITOR	Какие мониторы существуют, кто их владелец, как часто они запускаются, когда они в последний раз завершились успешно или с ошибкой, включены ли они?	created_by, creation_timestamp, last_successful_execution_timestamp, last_failed_execution_timestamp, frequency, enabled
HTTP_MONITOR_STEP, BROWSER_MONITOR_STEP	Из каких отдельных запросов или действий состоит монитор и в каком порядке?	step.sequence_number, step.url, http.request.method, dt.synthetic.step.type
SYNTHETIC_LOCATION	Где выполняются мониторы — в каком облаке, регионе и городе, и что может делать каждая локация?	cloud.provider, location_type, deployment_type, capabilities, geo.*

Каждая нода также содержит общие базовые атрибуты: id, id_classic, name, deleted и tags.

deleted — это флаг мягкого удаления. Удалённый монитор, локация или учётные данные не удаляются из Smartscape немедленно — их нода остаётся доступной для запросов в течение периода хранения с deleted == true, так что недавно удалённые элементы всё ещё отображаются. Добавьте | filter deleted == false, чтобы исключить их.

Теги существуют в двух формах. Поле tags содержит обычные теги, агрегированные по всем контекстам; для запроса одного контекста используйте tags:<контекст>. Основные теги (primary tags) — это выбранный набор, который Ключ-АСТРОМ прикрепляет ко всем телеметрическим данным при приёме (например, метки Kubernetes или облачные теги) — они доступны у мониторов и шагов с префиксом primary_tags.* и являются самым быстрым способом фильтрации или группировки. Правила на основе тегов из классической модели в этой модели отсутствуют.

Географические атрибуты и атрибуты выполнения: синтетические локации содержат полные географические атрибуты (geo.continent.name, geo.country.name, geo.region.name, geo.city.name, geo.location.latitude, geo.location.longitude), поэтому вы можете группировать и фильтровать мониторы по месту выполнения и отображать их на карте. Мониторы предоставляют время последнего успешного и последнего неудачного выполнения как отдельные атрибуты (last_successful_execution_timestamp, last_failed_execution_timestamp), что позволяет находить мониторы как по результату, так и по давности выполнения.

Полный авторитетный список атрибутов, типов и примеров для каждого типа ноды см. в группе моделей Smartscape — Synthetic в Семантическом словаре.

Отношения

Синтетические сущности Smartscape связаны следующими отношениями:

Источник	Отношение	Цель	Тип	Описание
HTTP_MONITOR	runs_on	SYNTHETIC_LOCATION	static	Локации, из которых выполняется монитор
HTTP_MONITOR	contains	HTTP_MONITOR_STEP	static	Отдельные HTTP-запросы, составляющие монитор
HTTP_MONITOR	uses	CREDENTIAL_VAULT_ENTRY	static	Записи хранилища учётных данных, которые монитор читает
HTTP_MONITOR	updates	CREDENTIAL_VAULT_ENTRY	static	Записи хранилища учётных данных, которые монитор записывает обратно
HTTP_MONITOR	monitors	SERVICE	dynamic	Бэкенд-сервис, который монитор проверяет
HTTP_MONITOR	is_assigned_to	FRONTEND	dynamic	Фронтенд-приложение, с которым связан монитор
HTTP_MONITOR_STEP	belongs_to	HTTP_MONITOR	static	Родительский монитор шага
BROWSER_MONITOR	runs_on	SYNTHETIC_LOCATION	static	Локации, из которых выполняется монитор
BROWSER_MONITOR	contains	BROWSER_MONITOR_STEP	static	Шаги в скрипте браузерного теста
BROWSER_MONITOR	uses	CREDENTIAL_VAULT_ENTRY	static	Записи хранилища учётных данных, которые монитор читает
BROWSER_MONITOR	monitors / is_assigned_to	FRONTEND	dynamic	Фронтенд-приложение, которое монитор тестирует
BROWSER_MONITOR_STEP	belongs_to	BROWSER_MONITOR	static	Родительский монитор шага
NETWORK_AVAILABILITY_MONITOR	runs_on	SYNTHETIC_LOCATION	static	Локации, из которых выполняется монитор
NETWORK_AVAILABILITY_MONITOR	monitors	HOST	dynamic	Хост, который монитор проверяет (ping или соединение)

Статические и динамические связи

Столбец «Тип» в таблице выше отражает, как создаётся каждая связь. Связи бывают двух видов:

• Статические определяются конфигурацией монитора и стабильны во времени — например, какие шаги содержит монитор, из каких локаций он запускается и какие записи хранилища учётных данных он использует.
• Динамические выводятся из данных выполнения и могут появляться и исчезать по мере наблюдения трафика — например, бэкенд-сервис, который HTTP-монитор проверяет (monitors), или RUM-фронтенд, с которым связан браузерный монитор (is_assigned_to). Монитор без недавних выполнений может временно не иметь динамических связей.

Связи contains (монитор → шаг) и belongs_to (шаг → монитор) описывают одну и ту же связь с обоих концов, поэтому вы можете перейти от монитора к его шагам или от шага обратно к монитору.

Отношения монитор-фронтенд

Эти связи позволяют увидеть, с каким RUM-приложением связан монитор — чтобы можно было сопоставить результаты монитора с фронтендом, который фактически используют пользователи. Монитор может быть связан с фронтендом двумя способами, и различие важно:

• is_assigned_to: фронтенд, который вы явно назначили монитору, связывая результаты монитора с этим приложением.
• monitors: цель, которую монитор проверяет во время выполнения: для браузерных мониторов — RUM-фронтенд, для HTTP-мониторов — бэкенд-сервис, для мониторов сетевой доступности — хост.

Обе связи являются динамическими, даже назначенная: связь материализуется на основе выполнения монитора, а не из сохранённой конфигурации. Поэтому связь появляется только после того, как монитор запустился и его целевая сущность была определена; она может меняться или исчезать по мере наблюдения выполнений. Монитор, который не запускался недавно, или чей назначенный фронтенд или обнаруженная цель больше не разрешаются, может не иметь ни одной связи.

Хранилище учётных данных: чтение и запись

Две связи для учётных данных различают, как монитор взаимодействует с записью хранилища учётных данных:

• uses: монитор читает учётные данные (в предварительном/постскрипте, в URL или в любом другом месте, где используется секрет).
• updates: монитор записывает учётные данные обратно в хранилище (например, скрипт, который вызывает API save-credential для их ротации).

Это различие позволяет понять, «этот монитор потребляет эти учётные данные» или «этот монитор обслуживает эти учётные данные» — полезно при планировании ротации учётных данных. Браузерные мониторы читают учётные данные, но никогда не записывают их обратно, поэтому BROWSER_MONITOR имеет связи uses, но не updates — это сделано намеренно, а не является пропуском.

Запросы с помощью DQL

Используйте команду smartscapeNodes для запроса синтетических нод. Все запросы выполняются к таблице smartscape.nodes.

Вывести все мониторы заданного типа

smartscapeNodes HTTP_MONITOR
| fields id, name, enabled, frequency,
    creation_timestamp, last_successful_execution_timestamp
| sort name asc

Замените HTTP_MONITOR на BROWSER_MONITOR или NETWORK_AVAILABILITY_MONITOR для других типов мониторов.

Показать читаемые имена и атрибуты вместо сырых идентификаторов

При навигации по связям или работе со ссылочными идентификаторами часто есть SmartscapeId ноды, но нужно получить его имя или атрибут. Функции getNodeName() и getNodeField() являются аналогами классических entityName() / entityAttr() и разрешают значение непосредственно по идентификатору — без соединения или дополнительного запроса.

smartscapeEdges is_assigned_to
| filter source_type == "HTTP_MONITOR"
| fields monitorName = getNodeName(source_id),
    frontendName = getNodeName(target_id),
    monitorEnabled = getNodeField(source_id, "enabled")

getNodeName(id) возвращает имя ноды; getNodeField(id, "<атрибут>") возвращает любой атрибут (например, "enabled", "cloud.provider", "geo.country.name"). Классическая функция entityName() недоступна для нод Smartscape.

Найти мониторы, которые не выполнялись успешно в последнее время

Мониторы, у которых last_successful_execution_timestamp старше 24 часов, могут указывать на постоянный сбой или неправильно настроенное расписание.

smartscapeNodes HTTP_MONITOR
| filter enabled == true
| filter isNull(last_successful_execution_timestamp)
    OR last_successful_execution_timestamp < now() - 24h
| fields id, name, last_successful_execution_timestamp, last_failed_execution_timestamp
| sort last_successful_execution_timestamp asc

last_successful_execution_timestamp отражает успешные выполнения, зафиксированные в модели Smartscape, поэтому монитор без зафиксированных успехов показывает null — в том числе если он только когда-либо завершался ошибкой. Для полной исторической картины используйте метрики доступности; если ваш диапазон может охватывать период до данных Smartscape, см. раздел «Запрос доступности во время перехода от классической модели к Smartscape».

Найти все отключённые мониторы

smartscapeNodes HTTP_MONITOR
| filter enabled == false
| fields id, name, last_modification_timestamp, last_modified_by
| sort last_modification_timestamp desc

Сравнить частоту выполнения по всем типам мониторов

Синтетические ноды запрашиваются командой smartscapeNodes — нет объекта данных fetch smartscape.nodes. Один вызов smartscapeNodes принимает несколько типов нод (через запятую) и предоставляет поле type, поэтому можно перечислить все типы мониторов сразу без объединения:

smartscapeNodes HTTP_MONITOR, BROWSER_MONITOR, NETWORK_AVAILABILITY_MONITOR
| fields name, type, frequencyMinutes = frequency
| sort frequencyMinutes asc

Показать распределение мониторов по локациям

Отношения обходятся с помощью traverse, а не расширением поля. Начиная с мониторов и проходя по связи runs_on, каждая строка попадает на целевую ноду SYNTHETIC_LOCATION, атрибуты которой затем можно группировать. count() по локации даёт количество мониторов, выполняющихся там.

smartscapeNodes HTTP_MONITOR
| traverse edgeTypes: {runs_on}, targetTypes: {SYNTHETIC_LOCATION}
| summarize monitorCount = count(),
    by: {locationId = id, locationName = name,
        country = geo.country.name, city = geo.city.name, cloud = cloud.provider,
        longitude = geo.location.longitude, latitude = geo.location.latitude}
| sort monitorCount desc

Поля longitude и latitude позволяют отобразить результат непосредственно на карте в дашборде или ноутбуке.

Найти все мониторы, использующие конкретную запись хранилища учётных данных

Этот запрос полезен перед ротацией или удалением записи хранилища учётных данных, чтобы оценить зону влияния изменения. Тип связи определяет роль (uses = чтение, updates = запись), а getNodeName разрешает имена учётных данных и мониторов непосредственно — без обхода или соединения. Запрос выводит каждую связь монитор-учётные данные; раскомментируйте второй фильтр и укажите имя учётных данных, чтобы сузить до одной записи.

smartscapeEdges uses, updates
| filter target_type == "CREDENTIAL_VAULT_ENTRY"
// | filter getNodeName(target_id) == "my-credential-name"
| fieldsAdd credentialName = getNodeName(target_id),
    monitorName = getNodeName(source_id),
    role = if(type == "updates", "writes", else: "reads")
| fields credentialName, monitorName, monitorType = source_type, role
| sort credentialName asc

Поле source_type различает HTTP- и браузерные мониторы. Монитор, который одновременно читает и записывает одни и те же учётные данные, появляется дважды — один раз как чтение, один раз как запись.

Найти, с какими фронтенд-приложениями связаны мониторы

Мониторы связываются с RUM-фронтендом через связь is_assigned_to. Запросите связи и разрешите имена нод с помощью getNodeName — по одной строке на связь монитор-фронтенд:

smartscapeEdges is_assigned_to
| filter source_type == "HTTP_MONITOR"
| fields monitorName = getNodeName(source_id), frontendName = getNodeName(target_id)
| sort monitorName asc

Используйте BROWSER_MONITOR для браузерных мониторов. Чтобы получить одну строку на монитор с массивом фронтендов, добавьте | summarize frontends = collectArray(frontendName), by: {monitorName}. Обе связи динамические: они появляются только после выполнения монитора и разрешения целевой сущности. Связь is_assigned_to связывает монитор с назначенным фронтендом; связь monitors связывает его с целевой сущностью во время выполнения (HTTP-монитор → нода SERVICE, браузерный монитор → нода FRONTEND, монитор сетевой доступности → нода HOST). Любая из связей может отсутствовать, если монитор не запускался недавно. Прежде чем полагаться на них, проверьте, что существует:

smartscapeEdges "*" | filter type == "is_assigned_to" or type == "monitors" | summarize count(), by: {type, source_type, target_type}

Вывести шаги монитора по порядку

Шаги — это запрашиваемые ноды, поэтому вы можете перечислить действия или запросы, составляющие монитор, и отсортировать их по порядку. Пройдите по связи contains от монитора к его шагам. Чтобы ограничить запрос одним монитором, раскомментируйте фильтр и укажите его идентификатор (строка идентификатора должна быть обёрнута в toSmartscapeId).

smartscapeNodes BROWSER_MONITOR
// | filter id == toSmartscapeId("BROWSER_MONITOR-0000000000000000")
| traverse edgeTypes: {contains}, targetTypes: {BROWSER_MONITOR_STEP}
| fields stepId = id, name, sequence = step.sequence_number,
    stepType = dt.synthetic.step.type
| sort sequence asc

Для HTTP-мониторов используйте HTTP_MONITOR / HTTP_MONITOR_STEP и замените stepType на специфичные для HTTP поля url = step.url и method = http.request.method.

traverse возвращает только шаги, которые существуют как материализованные ноды. Ноды шагов HTTP-монитора (HTTP_MONITOR_STEP) материализуются не всегда — связи contains могут присутствовать, а ноды шагов отсутствовать — поэтому вариант для HTTP может не возвращать строк в некоторых окружениях, даже если у монитора есть шаги. Шаги браузерного монитора материализуются надёжно.

Запрос доступности

Метрики доступности синтетики содержат идентификатор ноды Smartscape в качестве размерности. Каждый тип монитора имеет свой ключ метрики и размерность:

Тип монитора	Метрика доступности	Размерность Smartscape
HTTP	dt.synthetic.http.availability	dt.smartscape.http_monitor
Браузерный	dt.synthetic.browser.availability	dt.smartscape.browser_monitor
Сетевая доступность	dt.synthetic.multi_protocol.availability	dt.smartscape.network_availability_monitor

Используйте средневзвешенное по количеству выполнений. Доступность монитора за временной интервал и по локации основана на разном количестве выполнений, поэтому усреднение средних значений по интервалам (avg от avg) приводит к завышению или занижению значений для разреженных интервалов. Вместо этого разделите сумму доступности на количество точек данных: sum(availability) / sum(availability, rollup: count). Это даёт равный вес каждому выполнению и показывает истинный процент доступности.

Примеры ниже используют HTTP-мониторы. Для браузерных или мониторов сетевой доступности замените dt.synthetic.http.availability на dt.synthetic.browser.availability или dt.synthetic.multi_protocol.availability соответственно.

Доступность по монитору

Этот запрос возвращает средневзвешенную доступность за последние 24 часа для каждого монитора, с именем и состоянием включения, разрешёнными непосредственно. Чтобы ограничить одним монитором, раскомментируйте фильтр и укажите свой идентификатор — размерность dt.smartscape.* является SmartscapeId, поэтому литерал должен быть обёрнут в toSmartscapeId(...).

timeseries {
  sumAv = sum(dt.synthetic.http.availability),
  dataPoints = sum(dt.synthetic.http.availability, rollup: count)
}, by: {monitorId = dt.smartscape.http_monitor}, from: now()-24h
// | filter monitorId == toSmartscapeId("HTTP_MONITOR-0000000000000000")
| fieldsAdd availability = arraySum(sumAv) / arraySum(dataPoints),
    name = getNodeName(monitorId),
    enabled = getNodeField(monitorId, "enabled")
| fields monitorId, name, enabled, availability
| sort availability asc

Чтобы сохранить значение как временной ряд по интервалам (для графика) вместо одного числа, замените fieldsAdd на | fieldsAdd availability = sumAv[] / dataPoints[].

Доступность отслеживаемого приложения

Метрики выполнения синтетики также содержат сущности, которые проверяет каждый монитор, в поле dt.synthetic.monitored_entity_ids, поэтому можно вычислить доступность с точки зрения отслеживаемого приложения (например, вместе с его метриками опыта). Сгруппируйте по этой размерности, разверните её и отфильтруйте по приложению:

timeseries avgAv = avg(dt.synthetic.browser.availability),
    by: {dt.synthetic.monitored_entity_ids},
    from: now()-24h
| expand dt.synthetic.monitored_entity_ids
// | filter dt.synthetic.monitored_entity_ids == "APPLICATION-0000000000000000"
| summarize chartData = avg(avgAv[]), by: {timeframe, interval, dt.synthetic.monitored_entity_ids}

Обратная совместимость

Существующие запросы DQL, которые используют классические размерности сущностей (dt.entity.http_check, dt.entity.synthetic_test, dt.entity.multiprotocol_monitor, dt.entity.synthetic_location), продолжат работать без изменений. Телеметрия синтетики обогащается как идентификатором ноды Smartscape, так и классическим идентификатором сущности, поэтому запросы к классическим сущностям остаются действительными и будут возвращать данные.

Запросы к классическим синтетическим сущностям в DQL объявлены устаревшими. Они остаются поддерживаемыми до тех пор, пока поддерживается Ключ-АСТРОМ Classic, так что вы можете переходить на новую модель в своём темпе. Новые функции, атрибуты и отношения добавляются только в модель Smartscape.

Запрос доступности во время перехода от классической модели к Smartscape

Этот раздел является временным пособием для периода миграции. Пропустите его, если вы запрашиваете доступность за временные диапазоны, которые не выходят за пределы миграции вашего окружения на Smartscape — для недавних данных приведённых выше запросов достаточно. Как только запрашиваемые диапазоны больше не будут пересекать границу миграции, этот раздел можно удалить без влияния на остальную часть страницы.

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

Модель с двумя идентификаторами

Метрики доступности синтетики публикуются с двумя семействами размерностей:

• Размерности Smartscape (dt.smartscape.http_monitor, dt.smartscape.browser_monitor, dt.smartscape.network_availability_monitor) — заполняются для выполнений после миграции на Smartscape.
• Классические размерности сущностей (dt.entity.http_check, dt.entity.synthetic_test, dt.entity.multiprotocol_monitor) — заполняются для всех выполнений, включая выполненные до миграции.

В переходный период оба семейства размерностей заполняются для одного и того же выполнения. Запрос, сгруппированный только по dt.smartscape.http_monitor, пропустит выполнения до миграции, а сгруппированный только по dt.entity.http_check вернёт всю историю, но в классическом формате идентификатора. Чтобы охватить диапазон, охватывающий миграцию, объедините их в один нормализованный идентификатор с помощью coalesce.

Каждая нода Smartscape предоставляет соответствующий классический идентификатор сущности через поле id_classic. Числовой суффикс одинаков в обоих форматах:

Идентификатор Smartscape	Классический идентификатор сущности
HTTP_MONITOR-1A2B3C4D	HTTP_CHECK-1A2B3C4D
HTTP_MONITOR_STEP-1A2B3C4D	HTTP_CHECK_STEP-1A2B3C4D
BROWSER_MONITOR-1A2B3C4D	SYNTHETIC_TEST-1A2B3C4D
BROWSER_MONITOR_STEP-1A2B3C4D	SYNTHETIC_TEST_STEP-1A2B3C4D
NETWORK_AVAILABILITY_MONITOR-1A2B3C4D	MULTIPROTOCOL_MONITOR-1A2B3C4D

Правила для объединяющих запросов

При написании объединяющих запросов соблюдайте четыре правила:

1. Помещайте coalesce в fieldsAdd, а не в предложение timeseries by:. Предложение by: принимает только простые размерности; выражение там вызовет ошибку MANDATORY_PARAMETER_HAS_TO_BE_FIELD_BUT_WAS_EXPRESSION. Сначала группируйте по обеим сырым размерностям, а затем получайте объединённый идентификатор. 2. Объединённый идентификатор имеет тип SmartscapeId, поэтому фильтруйте его с помощью toSmartscapeId(...), а не как простую строку — сравнение строк без преобразования не вернёт результатов. Сырая размерность dt.smartscape.* также является SmartscapeId, а классическая dt.entity.* — простая строка. 3. Суммы и счётчики завышены из-за двойного подсчёта; отношения не страдают. В переходный период оба семейства размерностей заполняются для одного выполнения, поэтому простое суммирование или подсчёт (например, общее количество выполнений) завышено. Средневзвешенное по выполнению sum(availability) / sum(count) не страдает, потому что дублирование масштабирует числитель и знаменатель одинаково. Если нужны точные общие количества выполнений, сначала дедуплицируйте — подробнее см. «Синтетические расчёты». 4. Не каждая нода шага материализована. В частности, ноды шагов HTTP-монитора могут отсутствовать, даже если связи contains существуют — см. раздел «Вывести шаги монитора по порядку».

Доступность за диапазон, включающий данные до миграции

Сгруппируйте как по размерности Smartscape, так и по классической, объедините их в единый monitorId с помощью coalesce и вычислите средневзвешенное по выполнению, чтобы результат был корректным, даже если оба семейства перекрываются. Функции toSmartscapeId и replaceString преобразуют классический идентификатор сущности в его эквивалент Smartscape. Запрос охватывает все HTTP-мониторы за 90 дней; раскомментируйте фильтр и укажите свой идентификатор, чтобы ограничить одним монитором.

timeseries {
  sumAv = sum(dt.synthetic.http.availability),
  dataPoints = sum(dt.synthetic.http.availability, rollup: count)
}, by: {dt.smartscape.http_monitor, dt.entity.http_check}, from: now()-90d
| fieldsAdd monitorId = coalesce(dt.smartscape.http_monitor,
    toSmartscapeId(replaceString(toString(dt.entity.http_check), "HTTP_CHECK", "HTTP_MONITOR")))
// | filter monitorId == toSmartscapeId("HTTP_MONITOR-0000000000000000")
| summarize sumAv = sum(sumAv[]), dataPoints = sum(dataPoints[]), by: {timeframe, interval, monitorId}
| fieldsAdd av = sumAv[] / dataPoints[], avg = arraySum(sumAv) / arraySum(dataPoints)
| fieldsRemove sumAv, dataPoints

Для браузерных мониторов и мониторов сетевой доступности замените ключ метрики и размерность Smartscape из справочника метрик доступности, а также классическую размерность и пару префиксов для replaceString из таблицы «Модель с двумя идентификаторами». Например, для браузерных мониторов используйте sum(dt.synthetic.browser.availability), группировку по {dt.smartscape.browser_monitor, dt.entity.synthetic_test} и replaceString(toString(dt.entity.synthetic_test), "SYNTHETIC_TEST", "BROWSER_MONITOR").

Долгосрочный отчёт по доступности для всего парка

Этот запрос вычисляет средневзвешенную доступность за 30 дней для каждого HTTP-монитора, обрабатывая как данные Smartscape, так и классические в одном запросе. getNodeName / getNodeField добавляют имя и состояние включения из объединённого monitorId непосредственно.

timeseries {
  sumAv = sum(dt.synthetic.http.availability),
  dataPoints = sum(dt.synthetic.http.availability, rollup: count)
}, by: {dt.smartscape.http_monitor, dt.entity.http_check}, from: now()-30d
| fieldsAdd monitorId = coalesce(dt.smartscape.http_monitor,
    toSmartscapeId(replaceString(toString(dt.entity.http_check), "HTTP_CHECK", "HTTP_MONITOR")))
| summarize sumAv = sum(sumAv[]), dataPoints = sum(dataPoints[]), by: {monitorId}
| fieldsAdd availability = arraySum(sumAv) / arraySum(dataPoints),
    name = getNodeName(monitorId), enabled = getNodeField(monitorId, "enabled")
| sort availability asc
| fields name, enabled, availability, monitorId

Мониторы, которые выполнялись только до миграции и больше не существуют как ноды Smartscape, всё равно отображаются (их доступность учтена), но getNodeName вернёт null — текущей ноды для разрешения нет.

Найти классический идентификатор монитора по его идентификатору Smartscape

Запрос выводит классический идентификатор для каждого монитора. Чтобы найти один, раскомментируйте фильтр и укажите его идентификатор Smartscape:

smartscapeNodes HTTP_MONITOR
// | filter id == toSmartscapeId("HTTP_MONITOR-0000000000000000")
| fields id, classicId = id_classic

Поле id имеет тип SmartscapeId, поэтому литерал фильтра должен быть обёрнут в toSmartscapeId(...). Поле id_classic, напротив, является простой строкой и фильтруется напрямую (см. следующий запрос).

Найти идентификатор Smartscape монитора по его классическому идентификатору

Запрос выводит идентификатор Smartscape для каждого монитора. Чтобы найти один, раскомментируйте фильтр и укажите его классический идентификатор (простая строка — toSmartscapeId не требуется):

smartscapeNodes HTTP_MONITOR
// | filter id_classic == "HTTP_CHECK-0000000000000000"
| fields id, id_classic, name