|
|
| (не показаны 4 промежуточные версии 2 участников) |
| Строка 1: |
Строка 1: |
| Мониторинг приложений и инфраструктуры Dynatrace обеспечивается путем установки одного агента Dynatrace ЕдиныйАгент на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера). | | '''''[[Ресурсы мониторинга|Лицензирование]] / Мониторинг приложений и инфраструктуры (хост-модули)''''' |
|
| |
|
| Однако не все хосты одинакового размера. Более крупные узлы потребляют больше узлов, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько хост-единиц он включает). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой. | | Мониторинг приложений и инфраструктуры АппОптима обеспечивается путем установки Единого агента АппОптима на каждый отслеживаемый хост в вашей среде. ЕдиныйАгент лицензируется для каждого хоста (виртуального или физического сервера). |
| | |
| | Однако не все хосты одинакового размера. Более крупные узлы потребляют больше лицензий, чем узлы меньшего размера. Мы используем объем оперативной памяти на отслеживаемом сервере в качестве меры для определения размера хоста (то есть того, сколько лицензий ЕА он потребляет). Преимущество этого подхода заключается в его простоте - мы не принимаем во внимание факторы, зависящие от технологии (например, количество JVM или количество микросервисов, размещенных на сервере). Не имеет значения, является ли хост на основе .NET, Java или чего-то еще. У вас может быть 10 JVM или 1000 JVM; такие факторы не влияют на объем мониторинга, потребляемого средой. |
|
| |
|
| ЕдиныйАгент может работать в двух разных режимах. По умолчанию ЕдиныйАгент работает в режиме полного мониторинга . В качестве альтернативы вы можете использовать режим мониторинга инфраструктуры для мониторинга хостов, которым не требуется полная видимость стека. Режим инфраструктуры потребляет меньше узлов, чем режим Full-Stack. | | ЕдиныйАгент может работать в двух разных режимах. По умолчанию ЕдиныйАгент работает в режиме полного мониторинга . В качестве альтернативы вы можете использовать режим мониторинга инфраструктуры для мониторинга хостов, которым не требуется полная видимость стека. Режим инфраструктуры потребляет меньше узлов, чем режим Full-Stack. |
|
| |
|
| == Хост-единицы == | | == Единый Агент (ЕА) == |
| Обратитесь к таблице весовых коэффициентов хост-модулей ниже, чтобы узнать, сколько хост-модулей потребляется в зависимости от объема ОЗУ отслеживаемого сервера. Общее потребление хост-модулей рассчитывается на основе суммы всех хост-модулей всех режимов и отслеживаемых систем. | | Обратитесь к таблице весовых коэффициентов хост-модулей ниже, чтобы узнать, сколько хост-модулей потребляется в зависимости от объема ОЗУ отслеживаемого сервера. Общее потребление хост-модулей рассчитывается на основе суммы всех хост-модулей всех режимов и отслеживаемых систем. |
| {| class="wikitable" | | {| class="wikitable" |
| !Max. RAM | | !Max. RAM |
| !Хост-модули (Full-Stack *) | | !ЕА (Full-Stack *) |
| !Хост-блоки (Инфраструктура **) | | !ЕА (Инфраструктура **) |
| |- | | |- |
| |1,6 ГБ | | |1,6 ГБ |
| Строка 24: |
Строка 26: |
| |0,15 | | |0,15 |
| |- | | |- |
| |16 гигабайт | | |16 ГБ |
| |1.0 | | |1.0 |
| |0,3 | | |0,3 |
| Строка 56: |
Строка 58: |
| |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 .
| |
| | |
| Мониторинг только приложений - включая 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.
| |
|
| |
|
| == Высокая доступность премиум-класса ==
| | <nowiki>**</nowiki> Для режима мониторинга инфраструктуры применяется тот же принцип округления, но количество единиц хоста, потребляемых хостом, ограничено 1,0. |
| Модель развертывания с высокой доступностью Premium лицензируется отдельно только на основе ограничения количества одновременных узлов. Высокая доступность премиум-класса не влияет на потребление одновременных узлов или часов узлов.
| |
