Мониторинг приложений и инфраструктуры (хост-модули) - История изменений

IKuznetsov в 13:48, 8 ноября 2024

2024-11-08T13:48:59Z

← Предыдущая версия		Версия от 13:48, 8 ноября 2024
Строка 1:		Строка 1:
	'''''Лицензирование / Мониторинг приложений и инфраструктуры (хост-модули)'''''		'''''[[Ресурсы мониторинга\|Лицензирование]] / Мониторинг приложений и инфраструктуры (хост-модули)'''''

	Мониторинг приложений и инфраструктуры АппОптима обеспечивается путем установки Единого агента АппОптима на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера).		Мониторинг приложений и инфраструктуры АппОптима обеспечивается путем установки Единого агента АппОптима на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера).

IKuznetsov в 13:47, 8 ноября 2024

2024-11-08T13:47:31Z

← Предыдущая версия		Версия от 13:47, 8 ноября 2024
Строка 1:		Строка 1:
	'''''~~[https://doc.ruscomtech.ru/index.php/Ресурсы_мониторинга~~ Лицензирование] / Мониторинг приложений и инфраструктуры (хост-модули)'''''		'''''Лицензирование / Мониторинг приложений и инфраструктуры (хост-модули)'''''

	Мониторинг приложений и инфраструктуры ~~Ключ-АСТРОМ~~ обеспечивается путем установки Единого агента ~~Ключ-АСТРОМ~~ на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера).		Мониторинг приложений и инфраструктуры АппОптима обеспечивается путем установки Единого агента АппОптима на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера).

	Однако не все хосты одинакового размера. Более крупные узлы потребляют больше лицензий, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько лицензий ЕА он потребляет). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой.		Однако не все хосты одинакового размера. Более крупные узлы потребляют больше лицензий, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько лицензий ЕА он потребляет). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой.

ENetrebin в 14:43, 16 сентября 2024

2024-09-16T14:43:37Z

← Предыдущая версия		Версия от 14:43, 16 сентября 2024
Строка 1:		Строка 1:
			'''''[https://doc.ruscomtech.ru/index.php/Ресурсы_мониторинга Лицензирование] / Мониторинг приложений и инфраструктуры (хост-модули)'''''

	Мониторинг приложений и инфраструктуры Ключ-АСТРОМ обеспечивается путем установки Единого агента Ключ-АСТРОМ на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера).		Мониторинг приложений и инфраструктуры Ключ-АСТРОМ обеспечивается путем установки Единого агента Ключ-АСТРОМ на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера).

ENetrebin в 19:31, 10 января 2023

2023-01-10T19:31:13Z

Внесённые изменения

ENetrebin в 16:24, 5 декабря 2021

2021-12-05T16:24:21Z

ENetrebin в 15:52, 5 декабря 2021

2021-12-05T15:52:53Z

ENetrebin в 13:22, 5 декабря 2021

2021-12-05T13:22:38Z

@@ Строка 8: / Строка 8: @@
 Обратитесь к таблице весовых коэффициентов хост-модулей ниже, чтобы узнать, сколько хост-модулей потребляется в зависимости от объема ОЗУ отслеживаемого сервера. Общее потребление хост-модулей рассчитывается на основе суммы всех хост-модулей всех режимов и отслеживаемых систем.
 {| class="wikitable"
-!Максимум. баран
+!Max. RAM
 !Хост-модули (Full-Stack *)
 !Хост-блоки (Инфраструктура **)
@@ Строка 73: / Строка 73: @@
 Пример расчета часов хоста
 Истинный параллелизм в расчетах часов хоста
 Часы работы хоста с бесплатной пробной версией
 Используйте часы хоста для всплесков спроса и выберите проекты
 Излишки и несколько сред
 == Бессерверные функции ==

ENetrebin: Новая страница: «Мониторинг приложений и инфраструктуры Dynatrace обеспечивается путем установки одного аге...»

2021-12-05T13:18:40Z

Новая страница: «Мониторинг приложений и инфраструктуры Dynatrace обеспечивается путем установки одного аге...»

Новая страница

Мониторинг приложений и инфраструктуры Dynatrace обеспечивается путем установки одного агента Dynatrace OneAgent на каждый отслеживаемый хост в вашей среде. OneAgent лицензируется для каждого хоста (виртуального или физического сервера).

Однако не все хосты одинакового размера. Более крупные узлы потребляют больше узлов, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько хост-единиц он включает). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой.

OneAgent может работать в двух разных режимах. По умолчанию OneAgent работает в режиме полного мониторинга . В качестве альтернативы вы можете использовать режим мониторинга инфраструктуры для мониторинга хостов, которым не требуется полная видимость стека. Режим инфраструктуры потребляет меньше узлов, чем режим Full-Stack.

== Хост-единицы ==
Обратитесь к таблице весовых коэффициентов хост-модулей ниже, чтобы узнать, сколько хост-модулей потребляется в зависимости от объема ОЗУ отслеживаемого сервера. Общее потребление хост-модулей рассчитывается на основе суммы всех хост-модулей всех режимов и отслеживаемых систем.
{| class="wikitable"
!Максимум. баран
!Хост-модули (Full-Stack *)
!Хост-блоки (Инфраструктура **)
|-
|1,6 ГБ
|0,10
|0,03
|-
|4ГБ
|0,25
|0,075
|-
|8 ГБ
|0,50
|0,15
|-
|16 гигабайт
|1.0
|0,3
|-
|32 ГБ
|2.0
|0,6
|-
|48 ГБ
|3.0
|0,9
|-
|64 ГБ
|4.0
|1.0
|-
|80 ГБ
|5.0
|1.0
|-
|96 ГБ
|6.0
|1.0
|-
|112 ГБ
|7.0
|1.0
|-
|nx16 ГБ
|п
|1.0
|}
<nowiki>*</nowiki> Когда объем ОЗУ на хосте оказывается между значениями, указанными в таблице выше, число округляется в большую сторону. Например, хост с 12 ГБ ОЗУ потребляет 1 хост-модуль, потому что 12 ГБ находятся между 8 ГБ и 16 ГБ.

<nowiki>**</nowiki> Для режима мониторинга инфраструктуры применяется тот же принцип округления, но количество единиц хоста, потребляемых хостом, ограничено 1,0. Если у вас есть существующее соглашение, которое не отражает <code>1.0</code>ограничение на количество хост-единиц на хост, обратитесь к торговому представителю Dynatrace .

Мониторинг только приложений - включая PaaS и некоторые бессерверные

=== Избыток основного блока (необязательно) ===
Если вы договорились о выделении узлов хоста для наблюдения за вашими хостами, и вы имеете право превысить это число (то есть для вашей учетной записи разрешены перерасходы), перерасходы будут рассчитываться в часах хоста. Например, если вы организовали мониторинг до 10 узлов (общий объем оперативной памяти не более 160 ГБ), и ваша учетная запись допускает избыточное количество узлов, при подключении другого узла, который соответствует 2 узлам узлов, у вас будет 12 узлов узлов в total и, следовательно, превысит вашу квоту на 2 хост-устройства. Если вы продолжите контролировать свои хосты, используя 12 хост-единиц в течение полной недели, у вас накопится перерасход в 336 хост-часов.

<code>2 (host units) x 24 (hours a day) x 7 (days) = 336 (host unit hours overage)</code>

Чтобы добавить или удалить излишки из своей учетной записи, обратитесь в Dynatrace Sales .

== Часы работы хоста ==
Час хоста представляет собой потребление хоста за период времени. 1 час хоста равен 1 хосту, потребляемому в течение 1 часа . Хост с 16 ГБ ОЗУ (то есть 1 хост-блок), работающий в течение полного дня, потребляет 24 часа хост-блока.

Пример расчета часов хоста

Истинный параллелизм в расчетах часов хоста

Часы работы хоста с бесплатной пробной версией

Используйте часы хоста для всплесков спроса и выберите проекты

Излишки и несколько сред

== Бессерверные функции ==
Примечание. Интеграции трассировки AWS CloudWatch, Azure Monitor и AWS Lambda используют DDU. Для получения дополнительной информации см. DDU для бессерверного мониторинга .

=== Интеграция трассировки функций Azure ===
Для интеграции OneAgent с функциями Azure Dynatrace поддерживает выделенный план (служба приложений) , который использует единицы узлов.

План использования функций Azure в настоящее время не поддерживается.

=== Сервисы бессерверных вычислений ===
Интеграция Dynatrace OneAgent для бессерверных вычислительных сервисов потребляет хост-единицы. Например:

* AWS Fargate ,
* Экземпляры контейнеров Azure
** Служба Azure Kubernetes ,
* Эластичные вычислительные услуги
** Сервис эластичных контейнеров ,
** AWS Elastic Beanstalk ,
** Эластичный сервис Kubernetes
* Служба приложений Azure .

== Мониторинг мэйнфреймов на IBM z / OS ==
Мониторинг модулей кода OneAgent , работающих в IBM z / OS (CICS, IMS и Java), основан на потреблении миллиона единиц обслуживания (MSU). Следовательно, мониторинг мэйнфрейма не влияет на потребление узлов или часов узлов.

MSU - это показатель объема рабочей нагрузки по обработке, которую мэйнфрейм IBM выполняет в час. Количество использованных MSU рассчитывается на основе пикового скользящего среднего значения MSU за 4 часа за последний месяц из данных IBM System Management Facility (SMF) для отслеживаемых логических разделов (LPAR) или продуктов.

Пиковое скользящее среднее значение MSU за 4 часа может быть получено из Dynatrace (для каждого контролируемого LPAR) или из раздела P5 отчета SCRT.

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

← Предыдущая версия		Версия от 16:24, 5 декабря 2021
Строка 1:		Строка 1:
	Мониторинг приложений и инфраструктуры ~~Dynatrace~~ обеспечивается путем установки одного агента ~~Dynatrace~~ ЕдиныйАгент на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера).		Мониторинг приложений и инфраструктуры Ключ-АСТРОМ обеспечивается путем установки одного агента Ключ-АСТРОМ ЕдиныйАгент на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера).

	Однако не все хосты одинакового размера. Более крупные узлы потребляют больше узлов, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько хост-единиц он включает). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой.		Однако не все хосты одинакового размера. Более крупные узлы потребляют больше узлов, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько хост-единиц он включает). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой.
Строка 58:		Строка 58:
	<nowiki>*</nowiki> Когда объем ОЗУ на хосте оказывается между значениями, указанными в таблице выше, число округляется в большую сторону. Например, хост с 12 ГБ ОЗУ потребляет 1 хост-модуль, потому что 12 ГБ находятся между 8 ГБ и 16 ГБ.		<nowiki>*</nowiki> Когда объем ОЗУ на хосте оказывается между значениями, указанными в таблице выше, число округляется в большую сторону. Например, хост с 12 ГБ ОЗУ потребляет 1 хост-модуль, потому что 12 ГБ находятся между 8 ГБ и 16 ГБ.

	<nowiki>**</nowiki> Для режима мониторинга инфраструктуры применяется тот же принцип округления, но количество единиц хоста, потребляемых хостом, ограничено 1,0. Если у вас есть существующее соглашение, которое не отражает <code>1.0</code>ограничение на количество хост-единиц на хост, обратитесь к торговому представителю ~~Dynatrace~~ .		<nowiki>**</nowiki> Для режима мониторинга инфраструктуры применяется тот же принцип округления, но количество единиц хоста, потребляемых хостом, ограничено 1,0. Если у вас есть существующее соглашение, которое не отражает <code>1.0</code>ограничение на количество хост-единиц на хост, обратитесь к торговому представителю Ключ-АСТРОМ .

	Мониторинг только приложений - включая PaaS и некоторые бессерверные		Мониторинг только приложений - включая PaaS и некоторые бессерверные
Строка 67:		Строка 67:
	<code>2 (host units) x 24 (hours a day) x 7 (days) = 336 (host unit hours overage)</code>		<code>2 (host units) x 24 (hours a day) x 7 (days) = 336 (host unit hours overage)</code>

	Чтобы добавить или удалить излишки из своей учетной записи, обратитесь в ~~Dynatrace~~ Sales .		Чтобы добавить или удалить излишки из своей учетной записи, обратитесь в Ключ-АСТРОМ Sales .

	== Часы работы хоста ==		== Часы работы хоста ==
Строка 84:		Строка 84:
	Истинный параллелизм в расчетах часов хоста		Истинный параллелизм в расчетах часов хоста

	Каждую минуту ~~Dynatrace~~ рассчитывает потребление узлов на основе истинного параллелизма. Это означает, что два хоста, работающие в течение одного часа, будут потреблять два хоста, если оба хоста работают одновременно. Часы хост-устройства считаются в календарных часах (например, с 10:00 до 11:00), а не в часах использования (например, с 10:23 до 11:23).		Каждую минуту Ключ-АСТРОМ рассчитывает потребление узлов на основе истинного параллелизма. Это означает, что два хоста, работающие в течение одного часа, будут потреблять два хоста, если оба хоста работают одновременно. Часы хост-устройства считаются в календарных часах (например, с 10:00 до 11:00), а не в часах использования (например, с 10:23 до 11:23).

	Если хост работает менее 5 минут, это не засчитывается в часовую квоту вашего хоста. Хост, работающий в течение 5 минут или дольше, округляется до <code>1 host unit hour</code>.		Если хост работает менее 5 минут, это не засчитывается в часовую квоту вашего хоста. Хост, работающий в течение 5 минут или дольше, округляется до <code>1 host unit hour</code>.
Строка 91:		Строка 91:

	=== Пример 1 ===		=== Пример 1 ===
	У вас есть хост с 16 ГБ ОЗУ (что соответствует 1 хост-устройству), работающий с 10:00 до 10:30. В 10:30 вы запускаете еще один хост такого же размера. ~~Dynatrace~~ считает это единым хостом, потому что хосты не работают одновременно.		У вас есть хост с 16 ГБ ОЗУ (что соответствует 1 хост-устройству), работающий с 10:00 до 10:30. В 10:30 вы запускаете еще один хост такого же размера. Ключ-АСТРОМ считает это единым хостом, потому что хосты не работают одновременно.

	=== Пример 2 ===		=== Пример 2 ===
	Вы запускаете первый хост в 10:00 и запускаете другой хост в 10:30. Затем оба хоста работают вместе в течение 30 минут и одновременно выключаются. ~~Dynatrace~~ считает, что это 2 хоста, потому что оба хоста работают одновременно.		Вы запускаете первый хост в 10:00 и запускаете другой хост в 10:30. Затем оба хоста работают вместе в течение 30 минут и одновременно выключаются. Ключ-АСТРОМ считает, что это 2 хоста, потому что оба хоста работают одновременно.

	=== Пример 3 ===		=== Пример 3 ===
Строка 118:		Строка 118:
	Часы работы хоста с бесплатной пробной версией		Часы работы хоста с бесплатной пробной версией

	Часы работы хоста используются для бесплатных пробных версий ~~Dynatrace~~. Когда вы подписываетесь на бесплатную пробную версию ~~Dynatrace~~, вы получаете определенное количество часов хоста для оценки ~~Dynatrace~~.		Часы работы хоста используются для бесплатных пробных версий Ключ-АСТРОМ. Когда вы подписываетесь на бесплатную пробную версию Ключ-АСТРОМ, вы получаете определенное количество часов хоста для оценки Ключ-АСТРОМ.

	Используйте часы хоста для всплесков спроса и выберите проекты		Используйте часы хоста для всплесков спроса и выберите проекты

	Если вы заранее знаете, что ваша базовая квота единиц хоста будет превышена из-за праздничного спроса или краткосрочного проекта (например, в Черную пятницу или во время инициативы разового тестирования), вы можете использовать часы хоста, а не хост-устройства для управления переменными пиками трафика. Например, если у вас есть пул из 9000 часов хоста и 100 единиц хоста, во время Черной пятницы вам понадобится больше хостов для увеличения объема трафика на вашем сайте. В таком случае у вас есть возможность использовать все 9000 часов хоста за один день. Это позволит вам подключить к ~~Dynatrace~~ дополнительно 375 хост-устройств (всего 475 хостов) на один день.		Если вы заранее знаете, что ваша базовая квота единиц хоста будет превышена из-за праздничного спроса или краткосрочного проекта (например, в Черную пятницу или во время инициативы разового тестирования), вы можете использовать часы хоста, а не хост-устройства для управления переменными пиками трафика. Например, если у вас есть пул из 9000 часов хоста и 100 единиц хоста, во время Черной пятницы вам понадобится больше хостов для увеличения объема трафика на вашем сайте. В таком случае у вас есть возможность использовать все 9000 часов хоста за один день. Это позволит вам подключить к Ключ-АСТРОМ дополнительно 375 хост-устройств (всего 475 хостов) на один день.

	<code>9,000 (host unit hours) / 24 (hours) + 100 (base quota of host units) = 475 (max. host units)</code>		<code>9,000 (host unit hours) / 24 (hours) + 100 (base quota of host units) = 475 (max. host units)</code>
Строка 136:		Строка 136:

	=== Интеграция трассировки функций Azure ===		=== Интеграция трассировки функций Azure ===
	Для интеграции ЕдиныйАгент с функциями Azure ~~Dynatrace~~ поддерживает выделенный план (служба приложений) , который использует единицы узлов.		Для интеграции ЕдиныйАгент с функциями Azure Ключ-АСТРОМ поддерживает выделенный план (служба приложений) , который использует единицы узлов.

	План использования функций Azure в настоящее время не поддерживается.		План использования функций Azure в настоящее время не поддерживается.

	=== Сервисы бессерверных вычислений ===		=== Сервисы бессерверных вычислений ===
	Интеграция ~~Dynatrace~~ ЕдиныйАгент для бессерверных вычислительных сервисов потребляет хост-единицы. Например:		Интеграция Ключ-АСТРОМ ЕдиныйАгент для бессерверных вычислительных сервисов потребляет хост-единицы. Например:

	* AWS Fargate ,		* AWS Fargate ,
Строка 157:		Строка 157:
	MSU - это показатель объема рабочей нагрузки по обработке, которую мэйнфрейм IBM выполняет в час. Количество использованных MSU рассчитывается на основе пикового скользящего среднего значения MSU за 4 часа за последний месяц из данных IBM System Management Facility (SMF) для отслеживаемых логических разделов (LPAR) или продуктов.		MSU - это показатель объема рабочей нагрузки по обработке, которую мэйнфрейм IBM выполняет в час. Количество использованных MSU рассчитывается на основе пикового скользящего среднего значения MSU за 4 часа за последний месяц из данных IBM System Management Facility (SMF) для отслеживаемых логических разделов (LPAR) или продуктов.

	Пиковое скользящее среднее значение MSU за 4 часа может быть получено из ~~Dynatrace~~ (для каждого контролируемого LPAR) или из раздела P5 отчета SCRT.		Пиковое скользящее среднее значение MSU за 4 часа может быть получено из Ключ-АСТРОМ (для каждого контролируемого LPAR) или из раздела P5 отчета SCRT.

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

← Предыдущая версия		Версия от 15:52, 5 декабря 2021
Строка 1:		Строка 1:
	Мониторинг приложений и инфраструктуры Dynatrace обеспечивается путем установки одного агента Dynatrace ~~OneAgent~~ на каждый отслеживаемый хост в вашей среде. ~~OneAgent~~ лицензируется для каждого хоста (виртуального или физического сервера).		Мониторинг приложений и инфраструктуры Dynatrace обеспечивается путем установки одного агента Dynatrace ЕдиныйАгент на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера).

	Однако не все хосты одинакового размера. Более крупные узлы потребляют больше узлов, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько хост-единиц он включает). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой.		Однако не все хосты одинакового размера. Более крупные узлы потребляют больше узлов, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько хост-единиц он включает). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой.

	~~OneAgent~~ может работать в двух разных режимах. По умолчанию ~~OneAgent~~ работает в режиме полного мониторинга . В качестве альтернативы вы можете использовать режим мониторинга инфраструктуры для мониторинга хостов, которым не требуется полная видимость стека. Режим инфраструктуры потребляет меньше узлов, чем режим Full-Stack.		ЕдиныйАгент может работать в двух разных режимах. По умолчанию ЕдиныйАгент работает в режиме полного мониторинга . В качестве альтернативы вы можете использовать режим мониторинга инфраструктуры для мониторинга хостов, которым не требуется полная видимость стека. Режим инфраструктуры потребляет меньше узлов, чем режим Full-Stack.

	== Хост-единицы ==		== Хост-единицы ==
Строка 136:		Строка 136:

	=== Интеграция трассировки функций Azure ===		=== Интеграция трассировки функций Azure ===
	Для интеграции ~~OneAgent~~ с функциями Azure Dynatrace поддерживает выделенный план (служба приложений) , который использует единицы узлов.		Для интеграции ЕдиныйАгент с функциями Azure Dynatrace поддерживает выделенный план (служба приложений) , который использует единицы узлов.

	План использования функций Azure в настоящее время не поддерживается.		План использования функций Azure в настоящее время не поддерживается.

	=== Сервисы бессерверных вычислений ===		=== Сервисы бессерверных вычислений ===
	Интеграция Dynatrace ~~OneAgent~~ для бессерверных вычислительных сервисов потребляет хост-единицы. Например:		Интеграция Dynatrace ЕдиныйАгент для бессерверных вычислительных сервисов потребляет хост-единицы. Например:

	* AWS Fargate ,		* AWS Fargate ,
Строка 153:		Строка 153:

	== Мониторинг мэйнфреймов на IBM z / OS ==		== Мониторинг мэйнфреймов на IBM z / OS ==
	Мониторинг модулей кода ~~OneAgent~~ , работающих в IBM z / OS (CICS, IMS и Java), основан на потреблении миллиона единиц обслуживания (MSU). Следовательно, мониторинг мэйнфрейма не влияет на потребление узлов или часов узлов.		Мониторинг модулей кода ЕдиныйАгент , работающих в IBM z / OS (CICS, IMS и Java), основан на потреблении миллиона единиц обслуживания (MSU). Следовательно, мониторинг мэйнфрейма не влияет на потребление узлов или часов узлов.

	MSU - это показатель объема рабочей нагрузки по обработке, которую мэйнфрейм IBM выполняет в час. Количество использованных MSU рассчитывается на основе пикового скользящего среднего значения MSU за 4 часа за последний месяц из данных IBM System Management Facility (SMF) для отслеживаемых логических разделов (LPAR) или продуктов.		MSU - это показатель объема рабочей нагрузки по обработке, которую мэйнфрейм IBM выполняет в час. Количество использованных MSU рассчитывается на основе пикового скользящего среднего значения MSU за 4 часа за последний месяц из данных IBM System Management Facility (SMF) для отслеживаемых логических разделов (LPAR) или продуктов.