Требования для частных Synthetic-локаций
- 15-min read
Убедитесь, что хост, который вы хотите использовать для частной локации, соответствует следующим требованиям.
Информация о прекращении поддержки
Новых версий Chromium для Red Hat/Oracle Linux/Rocky Linux 8 выше версии 133 не будет. По соображениям безопасности и стабильности мы приняли решение прекратить поддержку установки Synthetic-enabled ActiveGate на Red Hat/Oracle Linux/Rocky Linux 8 начиная с версии ActiveGate 1.325.
Для обеспечения непрерывности и безопасности ваших синтетических мониторов рекомендуем перенести Synthetic-enabled ActiveGate на одну из поддерживаемых операционных систем, например на Red Hat/Oracle Linux/Rocky Linux 9.
ActiveGate версии 1.325 является последней Synthetic-enabled ActiveGate, поддерживаемой на Red Hat/Oracle Linux/Rocky Linux 8.
Кроме того, начиная с Dynatrace версии 1.326, мы планируем ввести механизмы, препятствующие обновлению Synthetic-enabled ActiveGate на Red Hat/Oracle Linux/Rocky Linux 8 выше версии 1.325.
Дополнительные примечания о поддержке
- Разработка Chromium для Amazon Linux 2 прекратилась на версии 126. По соображениям безопасности и стабильности мы приняли решение прекратить поддержку установки Synthetic-enabled ActiveGate на Amazon Linux 2 начиная с версии ActiveGate 1.307. ActiveGate версии 1.307 является последней Synthetic-enabled ActiveGate с поддержкой Amazon Linux 2. Кроме того, начиная с Dynatrace версии 1.308, введены механизмы, препятствующие обновлению Synthetic-enabled ActiveGate на Amazon Linux 2 выше версии 1.307.
-
Разработка Chromium для Red Hat/CentOS 7 прекратилась на версии 126. По соображениям безопасности и стабильности мы приняли решение прекратить поддержку установки Synthetic-enabled ActiveGate на Red Hat/CentOS 7 начиная с версии ActiveGate 1.305. ActiveGate версии 1.305 является последней Synthetic-enabled ActiveGate с поддержкой Red Hat/CentOS 7. Кроме того, начиная с Dynatrace версии 1.306, введены механизмы, препятствующие обновлению Synthetic-enabled ActiveGate на Red Hat/CentOS 7 выше версии 1.305.
-
Поскольку Red Hat Enterprise Linux 7 достиг окончания основной поддержки 30 июня 2024 года, все его пакеты были заархивированы. Это означает, что поиск необходимых зависимостей для обновления может оказаться невозможным. Подробнее см. статус Red Hat Enterprise Linux 7
- Проверьте последние примечания к выпуску ActiveGate для получения информации о старейших поддерживаемых версиях ActiveGate.
Антивирусное программное обеспечение и ПО для защиты от вредоносных программ¶
Антивирусное программное обеспечение и ПО для защиты от вредоносных программ могут негативно влиять на возможности синтетического мониторинга Dynatrace. Такое программное обеспечение может блокировать браузер или процессы Dynatrace, выполняющие синтетические мониторы, вызывать сбои при установке или обновлении Synthetic-enabled ActiveGate, мешать сетевому взаимодействию и влиять на надёжность измерений.
Для обеспечения стабильности и производительности рекомендуем добавить перечисленные ниже каталоги и процессы в список разрешённых или исключить их из политики проверки. Учтите, что исключения антивируса, как правило, отключают сканирование файлов, но не поведенческий мониторинг и хуки на уровне ядра. Они остаются активными и могут влиять на взаимодействие Synthetic Engine и браузера с системными библиотеками. В результате даже исключённые процессы могут испытывать нарушения доступа или повреждение кучи.
Перед обращением в службу поддержки Dynatrace для устранения проблем с частными Synthetic-локациями убедитесь, что антивирусное программное обеспечение или ПО для защиты от вредоносных программ не является возможной причиной.
Это минимальный список процессов и каталогов, необходимых для работы Dynatrace Synthetic. Корректная работа сервиса только с этими исключениями не гарантируется. Взаимодействуйте с вашим поставщиком, чтобы убедиться, что все ожидаемые действия Dynatrace корректно разрешены.
Каталоги:
- Все каталоги, в пути которых присутствует слово
synthetic. Обзор используемых каталогов см. в разделе Каталоги ActiveGate.
Процессы:
- chrome
- vucwrapper
- java
Требования к операционной системе¶
Свежеустановленный ActiveGate может запускать частные синтетические мониторы (как HTTP, так и браузерные) на следующих операционных системах.
Windows¶
Поддерживаемые операционные системы¶
| Операционная система Windows | Версии |
|---|---|
| Windows Server | 2016, 2019, 2022 |
Версии браузера на Windows¶
На Windows пакет установщика ActiveGate включает браузер Chromium, используемый для запуска браузерных мониторов. В таблице ниже показаны версии Chromium, входящие в состав соответствующих версий ActiveGate.
| Версия ActiveGate | Версия браузера в комплекте |
|---|---|
| 1.331 | 143 |
| 1.329 | 142 |
| 1.327 | 141 |
| 1.325 | 140 |
| 1.323 | 139 |
| 1.321 | 138 |
| 1.319 | 138 |
| 1.317 | 137 |
| 1.315 | 136 |
| 1.313 | 135 |
| 1.311 | 134 |
| 1.309 | 133 |
| 1.307 | 132 |
Неподдерживаемые версии Windows только для тестирования¶
Если вы хотите протестировать частные Synthetic-локации на непроизводственном хосте, например на собственном рабочем столе, можно установить Synthetic-enabled ActiveGate на неподдерживаемых версиях Windows, таких как Windows 10 или Windows 11.
Начиная с версии ActiveGate 1.263+, Synthetic-enabled ActiveGate больше не работает на Windows Server 2012 в тестовых целях. Google прекратила поддержку Windows 2012 Server в Chromium 110, который включён в пакет установки ActiveGate версии 1.263.
Linux¶
Поддерживаемые операционные системы¶
| Дистрибутив Linux | Версии |
|---|---|
| Red Hat Enterprise Linux1 | 9.2, 9.4, 9.6, 9.7 |
| Ubuntu | 20.04, 22.04, 24.04 |
| Amazon Linux | 2023 |
| Oracle Linux2 | 9.6, 9.7 |
| Rocky Linux3 | 9.7 |
1
Установщик Synthetic можно установить на все минорные выпуски Red Hat Enterprise Linux 9. Тем не менее рекомендуем использовать версии, указанные в этой таблице, поскольку они имеют Extended Life-cycle Support (ELS) согласно Red Hat Enterprise Linux Life Cycle.
2
Установщик Synthetic можно установить на все минорные выпуски Oracle Linux 9. Тем не менее рекомендуем использовать последние актуальные версии согласно документации Oracle Linux 9.
3
Установщик Synthetic можно установить на все минорные выпуски Rocky Linux 9. Тем не менее рекомендуем использовать последние актуальные версии согласно Руководству по выпускам и версиям Rocky Linux.
Устаревшие операционные системы¶
| Дистрибутив Linux | Версии |
|---|---|
| Red Hat Enterprise Linux | 7.91 |
| CentOS | 7.91 |
| Amazon Linux | 22 |
| Red Hat Enterprise Linux | 8.83 |
| Red Hat Enterprise Linux | 8.103 |
| Oracle Linux | 8.103 |
| Rocky Linux | 8.103 |
1
ActiveGate версии 1.305 является последней Synthetic-enabled ActiveGate с поддержкой Red Hat/CentOS 7.
2
ActiveGate версии 1.307 является последней Synthetic-enabled ActiveGate с поддержкой Amazon Linux 2.
3
ActiveGate версии 1.325 является последней Synthetic-enabled ActiveGate с поддержкой Red Hat/Oracle Linux/Rocky Linux 8.
Версии браузера на Linux¶
Настоятельно рекомендуем поддерживать актуальность версий Synthetic-enabled ActiveGate и браузера на Linux — Dynatrace поддерживает версии браузера, отстающие не более чем на две версии от последней поддерживаемой Dynatrace версии для конкретного выпуска ActiveGate. Например, если последняя поддерживаемая версия браузера — 103, Dynatrace поддерживает вплоть до версии браузера 101. Если предоставленная версия браузера значительно устарела для конкретной ОС, поддерживается только эта версия. Информацию об обновлении браузера см. в разделах автоматически и вручную.
На Linux установщик ActiveGate загружает зависимости браузера, необходимые для работы Synthetic engine. На Red Hat и Rocky необходимо включить определённые репозитории, из которых установщик загружает зависимости. Веб-интерфейс Dynatrace предоставляет все необходимые команды. Подробные инструкции см. в разделе Создание частной Synthetic-локации.
При установке ActiveGate и браузера из пользовательского локального репозитория необходимо самостоятельно разрешить все зависимости и включить нужные репозитории; пользовательский репозиторий можно использовать только для пакетов браузера, но не их зависимостей. Поместите архив пакета браузера и файл подписи в пользовательский репозиторий для установки. Если ваш файл архива пакета — https://synthetic-packages.s3.amazonaws.com/Chrome/chrome-for-testing-linux64/chrome-for-testing-linux64-143.0.7499.192.zip (Chrome for Testing 143 для Ubuntu в ActiveGate версии 1.333), файл подписи можно найти, добавив .sig к URL: https://synthetic-packages.s3.amazonaws.com/Chrome/chrome-for-testing-linux64/chrome-for-testing-linux64-143.0.7499.192.zip.sig.
-
Разработка Chromium для Red Hat/CentOS 7 и Amazon Linux 2 прекратилась на версии 126.
-
Поскольку Red Hat Enterprise Linux 7 достиг окончания основной поддержки 30 июня 2024 года, все его пакеты были заархивированы. Это означает, что поиск необходимых зависимостей для обновления может оказаться невозможным. Подробнее см. статус Red Hat Enterprise Linux 7
В связи с изменениями в доступности пакета libdav1d.so.6 версии Chromium старше 130 нельзя установить на Red Hat/Rocky Linux 9.
Подробности см. в руководстве по устранению неполадок.
| Версия ActiveGate | Последняя поддерживаемая версия Chromium Red Hat, CentOS, Oracle Linux 8 | Последняя поддерживаемая версия Chrome for Testing Amazon Linux 2023, Ubuntu, Oracle Linux 9 |
|---|---|---|
| 1.3313 | 143 Red Hat/Rocky Linux 9 | 143 |
1
Добавлена поддержка Ubuntu 24.
2
Добавлена поддержка Oracle Linux 9.
3
Ubuntu Server 20.04 и 22.04 перенесены на использование Chrome for Testing.
Платформа File Access Policy Daemon (fapolicyd)¶
При неправильной настройке платформа File Access Policy Daemon (fapolicyd) может негативно влиять на возможности синтетического мониторинга Dynatrace. Аналогично антивирусному ПО, fapolicyd может блокировать браузер или процессы Dynatrace, ответственные за выполнение синтетических мониторов.
Для обеспечения надлежащей стабильности и производительности рекомендуем добавить каталоги и процессы в список разрешённых или исключить их из политики. Дополнительную информацию см. в документации Red Hat по fapolicyd. Перед обращением в службу поддержки Dynatrace для устранения проблем с частными Synthetic-локациями убедитесь, что fapolicyd исключён как источник проблем.
Платформу File Access Policy Daemon можно запустить в режиме отладки, при котором все отказы записываются в журнал, что упрощает поиск отсутствующих правил и устранение неполадок. Дополнительную информацию о режиме отладки см. в документации по устранению проблем, связанных с fapolicyd
Требования к оборудованию¶
Общие соображения¶
- Обратите внимание, что Synthetic-enabled ActiveGate предъявляет более высокие требования к оборудованию и системным ресурсам, чем обычный Environment или Cluster ActiveGate. Настоятельно рекомендуем использовать Synthetic-enabled ActiveGate исключительно для целей синтетического мониторинга.
- При планировании выделения ресурсов необходимо учитывать любые дополнительные компоненты, работающие на хосте. Например, если локация отслеживается с помощью OneAgent или другого решения глубокого мониторинга, требования к оперативной памяти (RAM) возрастут.
- Для изменения размера Synthetic-enabled ActiveGate необходимо его удалить и переустановить — например, после увеличения ресурсов ActiveGate размера S до требований размера M. Переустановка необходима для использования обновлённых ресурсов в синтетическом мониторинге; в противном случае ActiveGate по-прежнему будет отображаться как размер S (Synthetic Node size) в Deployment Status и будет подчиняться ограничениям выполнения размера S.
Руководство по выбору размера¶
В зависимости от количества тестов, выполняемых в час, Synthetic-enabled ActiveGate должен соответствовать следующим требованиям к оборудованию.
Предельные значения
Приблизительные пределы, указанные в таблице ниже, были определены в ходе внутреннего тестирования. Фактические значения могут варьироваться в зависимости от сложности ваших мониторов.
Узел XS
Узел S
Узел M
Узел L
Узел XS
Хотя узлы XS можно использовать на ActiveGate на базе Windows Server, они могут не подходить оптимально из-за более высоких требований браузера к оборудованию. Для оптимальной производительности и подготовки к будущим улучшениям рекомендуем иметь не менее 8 ГБ ОЗУ и 25 ГБ свободного дискового пространства.
На системах Linux с объёмом ОЗУ всего 4 ГБ растущие требования браузера к ресурсам в сочетании с установкой сторонних инструментов на хосте могут приводить к периодической нехватке памяти. Настоятельно рекомендуем увеличить объём ОЗУ до 8 ГБ для обеспечения более стабильной и надёжной работы.
| Узел с поддержкой браузерных мониторов | Узел без браузера | |
|---|---|---|
| Минимальное количество процессоров | 2 vCPU | 1 vCPU |
| Минимальное свободное дисковое пространство | 20 ГБ | 17 ГБ |
| Минимальный объём ОЗУ | 4 ГБ | 4 ГБ |
| Минимальный свободный объём ОЗУ | 3 ГБ | 2,7 ГБ |
| Минимальный IOPS диска (Windows) | 100 | 100 |
| Приблизительное максимальное количество выполнений HTTP-мониторов/ч1 | 300k | 300k |
| Приблизительное максимальное количество выполнений высокоресурсных HTTP-мониторов2/ч | 10k | 10k |
| Приблизительное максимальное количество выполнений браузерных мониторов/ч | 300 | - |
| Приблизительное максимальное количество пакетов NAM ICMP-монитора/ч3 5 | 500k | 500k |
| Приблизительное максимальное количество запросов NAM TCP-монитора/ч4 6 | 1M | 1M |
| Приблизительное максимальное количество запросов NAM DNS-монитора/ч4 7 | 100k | 100k |
Примечания
1
Рассчитано как 5000 выполнений монитора (максимум для одной среды) с периодичностью раз в минуту (максимальная частота).
2
Это HTTP-мониторы на частных локациях с любым из следующих параметров: скрипты до/после выполнения, авторизация OAuth2, аутентификация Kerberos.
3
Для NAM-мониторов с типом запроса ICMP ёмкость связана с количеством ICMP echo-запросов (пакетов), отправляемых в ходе выполнения мониторов. Поскольку это количество пакетов может существенно варьироваться среди настроенных мониторов, использование количества выполнений мониторов в качестве предела ёмкости было бы неточным.
4
Для NAM-мониторов с типами запросов TCP и DNS ёмкость связана с количеством сетевых подключений (запросов), отправляемых в ходе выполнения мониторов. Поскольку это количество запросов может существенно варьироваться среди настроенных мониторов, использование количества выполнений мониторов в качестве предела ёмкости было бы неточным.
5
В ходе нагрузочных тестов для определения пределов ёмкости NAM ICMP-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию и один пакет на запрос) и запускались каждую 1 минуту. В тестах использовалось несколько целевых хостов; все они отвечали корректно со средним RTT около 200 мс.
6
В ходе нагрузочных тестов для определения пределов ёмкости NAM TCP-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию) и запускались каждую 1 минуту. В тестах использовалось несколько целевых хостов и портов; все они отвечали корректно со средним временем TCP-соединения около 200 мс.
7
В ходе нагрузочных тестов для определения пределов ёмкости NAM DNS-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Обратите внимание, что DNS-сервер, используемый при разрешении, должен справляться с входящими запросами и не рассматривать входящий трафик как подлежащий ограничению или отклонению (например, из-за обнаружения как бот-активности). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию и UDP в качестве транспорта) и запускались каждую 1 минуту. В тестах использовалось несколько целей разрешения; все они разрешались корректно со средним временем DNS-разрешения около 10 мс. Использовались общедоступные DNS-серверы: Google (8.8.8.8 и 8.8.4.4) и Cloudflare (1.1.1.1 и 1.1.1.2)
| Узел с поддержкой браузерных мониторов | Узел без браузера | |
|---|---|---|
| Минимальное количество процессоров | 4 vCPU | 2 vCPU |
| Минимальное свободное дисковое пространство | 25 ГБ | 22 ГБ |
| Минимальный объём ОЗУ | 8 ГБ | 8 ГБ |
| Минимальный свободный объём ОЗУ | 5 ГБ | 4 ГБ |
| Минимальный IOPS диска (Windows) | 200 | 200 |
| Приблизительное максимальное количество выполнений HTTP-мониторов/ч1 | 300k | 300k |
| Приблизительное максимальное количество выполнений высокоресурсных HTTP-мониторов2/ч | 20k | 20k |
| Приблизительное максимальное количество выполнений браузерных мониторов/ч | 650 | - |
| Приблизительное максимальное количество пакетов NAM ICMP-монитора/ч3 5 | 1M | 1M |
| Приблизительное максимальное количество запросов NAM TCP-монитора/ч4 6 | 2M | 2M |
| Приблизительное максимальное количество запросов NAM DNS-монитора/ч4 7 | 200k | 200k |
Примечания
1
Рассчитано как 5000 выполнений монитора (максимум для одной среды) с периодичностью раз в минуту (максимальная частота).
2
Это HTTP-мониторы на частных локациях с любым из следующих параметров: скрипты до/после выполнения, авторизация OAuth2, аутентификация Kerberos.
3
Для NAM-мониторов с типом запроса ICMP ёмкость связана с количеством ICMP echo-запросов (пакетов), отправляемых в ходе выполнения мониторов. Поскольку это количество пакетов может существенно варьироваться среди настроенных мониторов, использование количества выполнений мониторов в качестве предела ёмкости было бы неточным.
4
Для NAM-мониторов с типами запросов TCP и DNS ёмкость связана с количеством сетевых подключений (запросов), отправляемых в ходе выполнения мониторов. Поскольку это количество запросов может существенно варьироваться среди настроенных мониторов, использование количества выполнений мониторов в качестве предела ёмкости было бы неточным.
5
В ходе нагрузочных тестов для определения пределов ёмкости NAM ICMP-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию и один пакет на запрос) и запускались каждую 1 минуту. В тестах использовалось несколько целевых хостов; все они отвечали корректно со средним RTT около 200 мс.
6
В ходе нагрузочных тестов для определения пределов ёмкости NAM TCP-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию) и запускались каждую 1 минуту. В тестах использовалось несколько целевых хостов и портов; все они отвечали корректно со средним временем TCP-соединения около 200 мс.
7
В ходе нагрузочных тестов для определения пределов ёмкости NAM DNS-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Обратите внимание, что DNS-сервер, используемый при разрешении, должен справляться с входящими запросами и не рассматривать входящий трафик как подлежащий ограничению или отклонению (например, из-за обнаружения как бот-активности). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию и UDP в качестве транспорта) и запускались каждую 1 минуту. В тестах использовалось несколько целей разрешения; все они разрешались корректно со средним временем DNS-разрешения около 10 мс. Использовались общедоступные DNS-серверы: Google (8.8.8.8 и 8.8.4.4) и Cloudflare (1.1.1.1 и 1.1.1.2)
| Узел с поддержкой браузерных мониторов | Узел без браузера | |
|---|---|---|
| Минимальное количество процессоров | 8 vCPU | 4 vCPU |
| Минимальное свободное дисковое пространство | 30 ГБ | 23 ГБ |
| Минимальный объём ОЗУ | 16 ГБ | 16 ГБ |
| Минимальный свободный объём ОЗУ | 8 ГБ | 6,5 ГБ |
| Минимальный IOPS диска (Windows) | 400 | 400 |
| Приблизительное максимальное количество выполнений HTTP-мониторов/ч1 | 300k | 300k |
| Приблизительное максимальное количество выполнений высокоресурсных HTTP-мониторов2/ч | 60k | 60k |
| Приблизительное максимальное количество выполнений браузерных мониторов/ч | 1200 | - |
| Приблизительное максимальное количество пакетов NAM ICMP-монитора/ч3 5 | 1.5M | 1.5M |
| Приблизительное максимальное количество запросов NAM TCP-монитора/ч4 6 | 3M | 3M |
| Приблизительное максимальное количество запросов NAM DNS-монитора/ч4 7 | 300k | 300k |
Примечания
1
Рассчитано как 5000 выполнений монитора (максимум для одной среды) с периодичностью раз в минуту (максимальная частота).
2
Это HTTP-мониторы на частных локациях с любым из следующих параметров: скрипты до/после выполнения, авторизация OAuth2, аутентификация Kerberos.
3
Для NAM-мониторов с типом запроса ICMP ёмкость связана с количеством ICMP echo-запросов (пакетов), отправляемых в ходе выполнения мониторов. Поскольку это количество пакетов может существенно варьироваться среди настроенных мониторов, использование количества выполнений мониторов в качестве предела ёмкости было бы неточным.
4
Для NAM-мониторов с типами запросов TCP и DNS ёмкость связана с количеством сетевых подключений (запросов), отправляемых в ходе выполнения мониторов. Поскольку это количество запросов может существенно варьироваться среди настроенных мониторов, использование количества выполнений мониторов в качестве предела ёмкости было бы неточным.
5
В ходе нагрузочных тестов для определения пределов ёмкости NAM ICMP-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию и один пакет на запрос) и запускались каждую 1 минуту. В тестах использовалось несколько целевых хостов; все они отвечали корректно со средним RTT около 200 мс.
6
В ходе нагрузочных тестов для определения пределов ёмкости NAM TCP-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию) и запускались каждую 1 минуту. В тестах использовалось несколько целевых хостов и портов; все они отвечали корректно со средним временем TCP-соединения около 200 мс.
7
В ходе нагрузочных тестов для определения пределов ёмкости NAM DNS-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Обратите внимание, что DNS-сервер, используемый при разрешении, должен справляться с входящими запросами и не рассматривать входящий трафик как подлежащий ограничению или отклонению (например, из-за обнаружения как бот-активности). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию и UDP в качестве транспорта) и запускались каждую 1 минуту. В тестах использовалось несколько целей разрешения; все они разрешались корректно со средним временем DNS-разрешения около 10 мс. Использовались общедоступные DNS-серверы: Google (8.8.8.8 и 8.8.4.4) и Cloudflare (1.1.1.1 и 1.1.1.2)
| Узел с поддержкой браузерных мониторов | Узел без браузера | |
|---|---|---|
| Минимальное количество процессоров | 16 vCPU | 8 vCPU |
| Минимальное свободное дисковое пространство | 40 ГБ | 25 ГБ |
| Минимальный объём ОЗУ | 32 ГБ | 32 ГБ |
| Минимальный свободный объём ОЗУ | 12 ГБ | 10 ГБ |
| Минимальный IOPS диска (Windows) | 750 | 750 |
| Приблизительное максимальное количество выполнений HTTP-мониторов/ч1 | 300k | 300k |
| Приблизительное максимальное количество выполнений высокоресурсных HTTP-мониторов2/ч | 100k | 100k |
| Приблизительное максимальное количество выполнений браузерных мониторов/ч | 2200 | - |
| Приблизительное максимальное количество пакетов NAM ICMP-монитора/ч3 5 | 2M | 2M |
| Приблизительное максимальное количество запросов NAM TCP-монитора/ч4 6 | 4M | 4M |
| Приблизительное максимальное количество запросов NAM DNS-монитора/ч4 7 | 400k | 400k |
Примечания
1
Рассчитано как 5000 выполнений монитора (максимум для одной среды) с периодичностью раз в минуту (максимальная частота).
2
Это HTTP-мониторы на частных локациях с любым из следующих параметров: скрипты до/после выполнения, авторизация OAuth2, аутентификация Kerberos.
3
Для NAM-мониторов с типом запроса ICMP ёмкость связана с количеством ICMP echo-запросов (пакетов), отправляемых в ходе выполнения мониторов. Поскольку это количество пакетов может существенно варьироваться среди настроенных мониторов, использование количества выполнений мониторов в качестве предела ёмкости было бы неточным.
4
Для NAM-мониторов с типами запросов TCP и DNS ёмкость связана с количеством сетевых подключений (запросов), отправляемых в ходе выполнения мониторов. Поскольку это количество запросов может существенно варьироваться среди настроенных мониторов, использование количества выполнений мониторов в качестве предела ёмкости было бы неточным.
5
В ходе нагрузочных тестов для определения пределов ёмкости NAM ICMP-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию и один пакет на запрос) и запускались каждую 1 минуту. В тестах использовалось несколько целевых хостов; все они отвечали корректно со средним RTT около 200 мс.
6
В ходе нагрузочных тестов для определения пределов ёмкости NAM TCP-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию) и запускались каждую 1 минуту. В тестах использовалось несколько целевых хостов и портов; все они отвечали корректно со средним временем TCP-соединения около 200 мс.
7
В ходе нагрузочных тестов для определения пределов ёмкости NAM DNS-мониторы были единственными, запланированными на локации; мониторы имели следующие характеристики. Фактическая ёмкость может отличаться для других сред (например, там, где целевые объекты мониторинга отвечают медленнее, не предоставляют ответ в пределах тайм-аута или одновременно выполняются мониторы других типов). Обратите внимание, что DNS-сервер, используемый при разрешении, должен справляться с входящими запросами и не рассматривать входящий трафик как подлежащий ограничению или отклонению (например, из-за обнаружения как бот-активности). Мониторы использовали настройки по умолчанию (включая настройки тайм-аутов по умолчанию и UDP в качестве транспорта) и запускались каждую 1 минуту. В тестах использовалось несколько целей разрешения; все они разрешались корректно со средним временем DNS-разрешения около 10 мс. Использовались общедоступные DNS-серверы: Google (8.8.8.8 и 8.8.4.4) и Cloudflare (1.1.1.1 и 1.1.1.2)
Хранилище и права доступа к файловой системе¶
В таблице ниже показаны расположения по умолчанию (Linux и Windows) различных каталогов ActiveGate и минимальные требования к размеру. Эта информация взята из раздела Каталоги ActiveGate.
1
Для XS ActiveGate — для ActiveGate большего размера требуется больше места для журналов выполнения.
Права доступа к /tmp¶
Synthetic-enabled ActiveGate требует доступа на запись в каталог /tmp во время выполнения. Его зависимости, включая xvfb, используют /tmp для хранения временных файлов и данных времени выполнения.
Отсутствие прав на запись в этот каталог может привести к непредвиденным сбоям или ухудшению функциональности.
Убедитесь, что среда хоста предоставляет достаточные права доступа и свободное место в /tmp для надёжной поддержки этих операций.
Связанные темы¶
- Каталоги ActiveGate