|
|
| (не показаны 3 промежуточные версии этого же участника) |
| Строка 1: |
Строка 1: |
| Мониторинг приложений и инфраструктуры Dynatrace обеспечивается путем установки одного агента Dynatrace ЕдиныйАгент на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера). | | Мониторинг приложений и инфраструктуры Dynatrace обеспечивается путем установки Единого агента Dynatrace на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера). |
|
| |
|
| Однако не все хосты одинакового размера. Более крупные узлы потребляют больше узлов, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько хост-единиц он включает). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой. | | Однако не все хосты одинакового размера. Более крупные узлы потребляют больше лицензий, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько лицензий ЕА он потребляет). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой. |
|
| |
|
| ЕдиныйАгент может работать в двух разных режимах. По умолчанию ЕдиныйАгент работает в режиме полного мониторинга . В качестве альтернативы вы можете использовать режим мониторинга инфраструктуры для мониторинга хостов, которым не требуется полная видимость стека. Режим инфраструктуры потребляет меньше узлов, чем режим Full-Stack. | | ЕдиныйАгент может работать в двух разных режимах. По умолчанию ЕдиныйАгент работает в режиме полного мониторинга (Full stack) . В качестве альтернативы вы можете использовать режим мониторинга инфраструктуры (Infrastructure mode) для мониторинга хостов, которым не требуется полная видимость стека. Режим инфраструктуры потребляет меньше узлов, чем режим Full-Stack. |
|
| |
|
| == Хост-единицы == | | == Единый Агент (ЕА) == |
| Обратитесь к таблице весовых коэффициентов хост-модулей ниже, чтобы узнать, сколько хост-модулей потребляется в зависимости от объема ОЗУ отслеживаемого сервера. Общее потребление хост-модулей рассчитывается на основе суммы всех хост-модулей всех режимов и отслеживаемых систем. | | Обратитесь к таблице весовых коэффициентов хост-модулей ниже, чтобы узнать, сколько хост-модулей потребляется в зависимости от объема ОЗУ отслеживаемого сервера. Общее потребление хост-модулей рассчитывается на основе суммы всех хост-модулей всех режимов и отслеживаемых систем. |
| {| class="wikitable" | | {| class="wikitable" |
| !Max. RAM | | !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 часа хост-блока.
| |
| | |
| Пример расчета часов хоста
| |
| | |
| Например, предположим, что у вас есть 1000 часов доступного хост-устройства и вы хотите контролировать хост с 64 ГБ ОЗУ (что соответствует 4 хост-модулям). Если вы держите хост в рабочем состоянии в течение всего дня, он будет использовать 96 часов работы хоста.
| |
| | |
| <code>4 (host units) x 24 (hours a day) = 96 (host unit hours)</code>
| |
| | |
| 1000 часов хоста будут израсходованы чуть более чем за 10 дней.
| |
| | |
| <code>4 (host units) x 24 (hours) x 10 (days) = 960 host unit hours</code>
| |
| | |
| Истинный параллелизм в расчетах часов хоста
| |
| | |
| Каждую минуту Dynatrace рассчитывает потребление узлов на основе истинного параллелизма. Это означает, что два хоста, работающие в течение одного часа, будут потреблять два хоста, если оба хоста работают одновременно. Часы хост-устройства считаются в календарных часах (например, с 10:00 до 11:00), а не в часах использования (например, с 10:23 до 11:23).
| |
| | |
| Если хост работает менее 5 минут, это не засчитывается в часовую квоту вашего хоста. Хост, работающий в течение 5 минут или дольше, округляется до <code>1 host unit hour</code>.
| |
| | |
| Когда мониторинг хоста прекращается по какой-либо причине, потребленные хост-единицы этого хоста освобождаются и становятся доступными для другого хоста в течение примерно пяти минут.
| |
| | |
| === Пример 1 ===
| |
| У вас есть хост с 16 ГБ ОЗУ (что соответствует 1 хост-устройству), работающий с 10:00 до 10:30. В 10:30 вы запускаете еще один хост такого же размера. Dynatrace считает это единым хостом, потому что хосты не работают одновременно.
| |
| | |
| === Пример 2 ===
| |
| Вы запускаете первый хост в 10:00 и запускаете другой хост в 10:30. Затем оба хоста работают вместе в течение 30 минут и одновременно выключаются. Dynatrace считает, что это 2 хоста, потому что оба хоста работают одновременно.
| |
| | |
| === Пример 3 ===
| |
| Один хост размером 16 ГБ ОЗУ запускается и останавливается трижды в течение часа:
| |
| | |
| <code>12:10 - Server start</code>
| |
| | |
| <code>12:20 - Server stop</code>
| |
| | |
| <code>12:30 - Server start</code>
| |
| | |
| <code>12:40 - Server stop</code>
| |
| | |
| <code>12:50 - Start</code>
| |
| | |
| <code>13:00 - Stop</code>
| |
| | |
| Такой сценарий приравнивается к тому, <code>1 host unit hour</code>что во внимание принимается истинный параллелизм.
| |
| | |
| === Пример 4 ===
| |
| У вас есть хост с 16 ГБ ОЗУ (что соответствует 1 хост-модулю), работающий с 10: 23-11: 23 AM. Поскольку хост работает в течение 2 календарных часов (с 10:00 до 11:00 и с 11:00 до 12:00), это равняется <code>2 host unit hours</code>.
| |
| | |
| Часы работы хоста с бесплатной пробной версией
| |
| | |
| Часы работы хоста используются для бесплатных пробных версий Dynatrace. Когда вы подписываетесь на бесплатную пробную версию Dynatrace, вы получаете определенное количество часов хоста для оценки Dynatrace.
| |
| | |
| Используйте часы хоста для всплесков спроса и выберите проекты
| |
| | |
| Если вы заранее знаете, что ваша базовая квота единиц хоста будет превышена из-за праздничного спроса или краткосрочного проекта (например, в Черную пятницу или во время инициативы разового тестирования), вы можете использовать часы хоста, а не хост-устройства для управления переменными пиками трафика. Например, если у вас есть пул из 9000 часов хоста и 100 единиц хоста, во время Черной пятницы вам понадобится больше хостов для увеличения объема трафика на вашем сайте. В таком случае у вас есть возможность использовать все 9000 часов хоста за один день. Это позволит вам подключить к Dynatrace дополнительно 375 хост-устройств (всего 475 хостов) на один день.
| |
| | |
| <code>9,000 (host unit hours) / 24 (hours) + 100 (base quota of host units) = 475 (max. host units)</code>
| |
| | |
| Излишки и несколько сред
| |
| | |
| Если в вашей учетной записи есть несколько сред мониторинга, например, одна для разработки, а другая - для производства, то излишки рассчитываются для каждой учетной записи, а не для каждой среды. Только при превышении квоты учетной записи возникают излишки.
| |
| | |
| Например, вы лицензировали 100 хост-единиц и у вас есть две среды: одна для производства, а другая - для тестирования. Вы назначаете 80 узлов сети производственной среде и 20 узлов сети тестовой среде. Ваша лицензия дает вам право на излишки (вы можете увидеть это в обзоре учетной записи под кружком хост-единиц). Если в производстве используется 70 хост-модулей, а при тестировании используется 30 хост-модулей, общая квота учетной записи в 100 хост-модулей не превышается, поэтому перерасход не возникает. Только если в обеих средах используется более 100 узлов хоста, возникают излишки.
| |
| | |
| == Бессерверные функции ==
| |
| Примечание. Интеграции трассировки AWS CloudWatch, Azure Monitor и AWS Lambda используют DDU. Для получения дополнительной информации см. DDU для бессерверного мониторинга .
| |
| | |
| === Интеграция трассировки функций Azure ===
| |
| Для интеграции ЕдиныйАгент с функциями Azure Dynatrace поддерживает выделенный план (служба приложений) , который использует единицы узлов.
| |
| | |
| План использования функций Azure в настоящее время не поддерживается.
| |
| | |
| === Сервисы бессерверных вычислений ===
| |
| Интеграция Dynatrace ЕдиныйАгент для бессерверных вычислительных сервисов потребляет хост-единицы. Например:
| |
| | |
| * AWS Fargate ,
| |
| * Экземпляры контейнеров Azure
| |
| ** Служба Azure Kubernetes ,
| |
| * Эластичные вычислительные услуги
| |
| ** Сервис эластичных контейнеров ,
| |
| ** AWS Elastic Beanstalk ,
| |
| ** Эластичный сервис Kubernetes
| |
| * Служба приложений Azure .
| |
| | |
| == Мониторинг мэйнфреймов на IBM z / OS ==
| |
| Мониторинг модулей кода ЕдиныйАгент , работающих в 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 лицензируется отдельно только на основе ограничения количества одновременных узлов. Высокая доступность премиум-класса не влияет на потребление одновременных узлов или часов узлов.
| |
Мониторинг приложений и инфраструктуры 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.
