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

Материал из Dynatrace
(Новая страница: «Мониторинг приложений и инфраструктуры Dynatrace обеспечивается путем установки одного аге...»)
 
 
(не показано 5 промежуточных версий этого же участника)
Строка 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) . В качестве альтернативы вы можете использовать режим мониторинга инфраструктуры (Infrastructure mode) для мониторинга хостов, которым не требуется полная видимость стека. Режим инфраструктуры потребляет меньше узлов, чем режим Full-Stack.


== Хост-единицы ==
== Единый Агент (ЕА) ==
Обратитесь к таблице весовых коэффициентов хост-модулей ниже, чтобы узнать, сколько хост-модулей потребляется в зависимости от объема ОЗУ отслеживаемого сервера. Общее потребление хост-модулей рассчитывается на основе суммы всех хост-модулей всех режимов и отслеживаемых систем.
Обратитесь к таблице весовых коэффициентов хост-модулей ниже, чтобы узнать, сколько хост-модулей потребляется в зависимости от объема ОЗУ отслеживаемого сервера. Общее потребление хост-модулей рассчитывается на основе суммы всех хост-модулей всех режимов и отслеживаемых систем.
{| class="wikitable"
{| class="wikitable"
!Максимум. баран
!Max. RAM
!Хост-модули (Full-Stack *)
!ЕА (Full-Stack *)
!Хост-блоки (Инфраструктура **)
!ЕА (Инфраструктура **)
|-
|-
|1,6 ГБ
|1,6 ГБ
Строка 24: Строка 24:
|0,15
|0,15
|-
|-
|16 гигабайт
|16 ГБ
|1.0
|1.0
|0,3
|0,3
Строка 56: Строка 56:
|1.0
|1.0
|}
|}
<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.
 
Мониторинг только приложений - включая 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 лицензируется отдельно только на основе ограничения количества одновременных узлов. Высокая доступность премиум-класса не влияет на потребление одновременных узлов или часов узлов.

Текущая версия на 09:58, 23 августа 2024

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

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

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

Единый Агент (ЕА)

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

Max. RAM ЕА (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

* Когда объем ОЗУ на хосте оказывается между значениями, указанными в таблице выше, число округляется в большую сторону. Например, хост с 12 ГБ ОЗУ потребляет 1 лицензию ЕА, потому что 12 ГБ находятся между 8 ГБ и 16 ГБ.

** Для режима мониторинга инфраструктуры применяется тот же принцип округления, но количество единиц хоста, потребляемых хостом, ограничено 1,0.