Документация АппОптима - Вклад [ru]

Развертывания АппОптима

2022-04-04T10:48:27Z

YaPolkin:

Возможные сценарии развертывания Ключ-АСТРОМ Managed подробно описаны ниже. На каждой иллюстрации показаны различные задействованные компоненты и необходимые порты связи между компонентами. Направление стрелок на схемах указывает, какой компонент инициирует соединение.

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

Для общей диаграммы, показывающей все возможные подключения и порты, см. Поддерживаемые схемы подключения для АктивныйШлюзов.

== Сценарий 1: базовая настройка ==
После установки Ключ-АСТРОМ Managed и настройки одного или нескольких узлов кластера вы получите сценарий развертывания, показанный ниже.

[[Файл:Con-man-basic.jpg|альт=Базовый сценарий развертывания|Базовый сценарий развертывания]]

Без дополнительной настройки (в меню Ключ-АСТРОМ перейдите в '''Настройки > Общедоступные эндпоинты''') кластер доступен только для внутренних целей и предоставляет порты 443 для REST API, трафика ЕдиногоАгента и доступа к веб-интерфейсу (консоль управления кластером и пользовательский интерфейс среды). По умолчанию удаленный доступ к Mission Control включен. Это позволяет Ключ-АСТРОМ выполнять мониторинг и проверку работоспособности ваших кластеров Ключ-АСТРОМ Managed. Каждый канал связи защищен TLS.

== Сценарий 2: чистая настройка Ключ-АСТРОМ Managed ==
Сценарий развертывания, показанный ниже, позволяет кластеру Ключ-АСТРОМ получать данные мониторинга из внешних источников, таких как внешние ЕдиныеАгенты, внешние АктивныеШлюзы среды или службы Digital Experience Monitoring (DEM). Кроме того, для лучшей поддержки нескольких локальных ЕдиныхАгентов также используется АктивныйШлюз среды.

Услуги DEM могут включать:

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

Чтобы получать внешний трафик, вам необходимо открыть кластер Ключ-АСТРОМ для внешних сетей и настроить общедоступный IP-адрес. По соображениям безопасности не рекомендуется открывать кластер напрямую для внешних сетей. Поэтому мы предлагаем использовать один или несколько [[Установка кластерного АктивногоШлюза|кластерных АктивныхШлюзов]] в качестве посредников для предварительной обработки трафика ЕдиногоАгента и DEM. Кластерные АктивныеШлюзы распознаются кластером и могут быть настроены через консоль управления кластером, аналогично узлам кластера.

[[Файл:Con-man-pure.jpg|альт=Pure сценарий развертывания|Pure сценарий развертывания]]

Кластерный АктивныйШлюз требует:

* Общедоступный IP-адрес
* Доменное имя с действующим [[Установка собственного SSL-сертификата для ноды кластера|сертификатом SSL]], поскольку внешняя связь поддерживается только безопасным способом с использованием HTTPS (порт 443). Этот домен должен отличаться от домена веб-интерфейса Ключ-АСТРОМ. Вы можете предоставить домен и сертификат SSL самостоятельно или позволить Ключ-АСТРОМ сделать это за вас. Ключ-АСТРОМ может сгенерировать домен и действующий сертификат SSL от вашего имени.

Для высоконагруженных установок с множеством внешних хостов, приложений, сеансов и синтетических мониторов мы рекомендуем вам настроить несколько кластерных АктивныхШлюзов с балансировкой нагрузки с одним и тем же доменным именем и сертификатом.

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

'''В сценариях, где АктивныйШлюз среды использует кластерный АктивныйШлюз для подключения к кластеру Ключ-АСТРОМ, АктивныйШлюз среды начинает обмен данными с кластерным АктивнымШлюзом после установки. Следовательно, кластерный АктивныйШлюз должен быть в рабочем состоянии и доступен в это время, предоставляя подходящий (локальный или общедоступный) IP-адрес.'''

Чтобы настроить среду Ключ-АСТРОМ Managed, выполните следующие действия по развертыванию в следующем порядке:

* Настройте кластер Ключ-АСТРОМ Managed.
* Настройте АктивныйШлюз (АктивныеШлюзы) кластера и убедитесь, что они могут подключаться к кластеру Ключ-АСТРОМ Managed. Убедитесь, что кластерный АктивныйШлюз доступен из других ваших сетей или извне, в зависимости от ситуации, и имеет публичный IP-адрес, если это необходимо.
* Установите ваш АктивныйШлюз среды. Если АктивныйШлюз среды находится в другой сети/центре обработки данных, убедитесь, что адрес кластерного АктивногоШлюза доступен. Если АктивныйШлюз среды является внешней сетью, должен быть доступен общедоступный IP-адрес кластерного АктивногоШлюза ('''Консоль управления > Настройки > Общедоступные эндпоинты: URL кластерного АктивногоШлюза''').

'''Примечание:''' Трафик веб-интерфейса или администрирование кластера (через консоль управления кластером) должны оставаться локальными в вашей сети. Доступ к веб-интерфейсу осуществляется по протоколу HTTPS. Таким образом, требуется сертификат TLS. Допустимо использовать самозаверяющий сертификат, но вы, вероятно, захотите, чтобы трафик веб-интерфейса и администрирование кластера также выполнялись безопасным образом. В таких случаях вы можете указать доменное имя и действующий сертификат SSL, или они могут быть автоматически сгенерированы Ключ-АСТРОМ. По умолчанию каждый кластер получает субдомен <code>*.dynatrace-managed.com</code> с действующим сертификатом от Let's Encrypt. Также обратите внимание, что кластерные АктивныеШлюзы не поддерживают проксирование трафика веб-интерфейса.

== Сценарий 3: интеграция с существующим ИТ-ландшафтом ==
В более сложном сценарии вы можете захотеть встроить Ключ-АСТРОМ Managed в существующую ИТ-инфраструктуру с уже установленным рядом устройств. На изображении ниже показан балансировщик нагрузки, предоставляемый заказчиком, перед доменом кластерного АктивногоШлюза и предоставленный заказчиком прокси-сервер для исходящей связи с Mission Control.

[[Файл:Con-man-integr.jpg|альт=Сценарий развертывания с интеграцией|Сценарий развертывания с интеграцией]]

== Сценарий 4: глобально распределенная высокая доступность с автоматическим восстановлением ==
Ключ-АСТРОМ позволяет настроить развертывание высокой доступности в распределенных сетях в виде автономного готового решения, которое обеспечивает практически нулевое время простоя и позволяет продолжать мониторинг без потери данных в сценариях аварийного переключения. Это решение обеспечивает экономию затрат с точки зрения распределения вычислительных ресурсов и хранилища, устраняя необходимость в отдельных резервных хостах восстановления и соответствующей инфраструктуре для хранения и передачи данных резервного копирования. При планировании вместимости следует рассматривать узлы в дополнительном центре обработки данных как избыточные, а не как расширенные емкости, и запланируйте одинаковую балансировку обоих центров обработки данных. Дополнительные сведения о концепции нескольких центров обработки данных в развертываниях Ключ-АСТРОМ Managed см. в разделе Высокая доступность для нескольких центров обработки данных.

Для развертывания этого сценария у вас должна быть отдельная лицензия премиум высокая доступность (Premium High Availability).

* См. раздел Расчет потребления мониторинга Ключ-АСТРОМ.

[[Файл:Con-man-global.jpg|альт=Глобальный сценарий развертывания|Глобальный сценарий развертывания]]

=== Необходимая конфигурация для каждого случая трафика ===
В следующей таблице обобщена необходимая конфигурация для каждого случая дискретного трафика, указывая с помощью <code>+</code> , требуется ли общедоступный IP-адрес, действительный сертификат SSL, или и то, и другое. Обратите внимание, что мониторинг реального пользователя (RUM), безагентный RUM и мобильный RUM обычно связаны с трафиком ваших пользователей и активностью браузера, которые происходят за пределами вашей сети. Теоретически этот трафик также можно рассматривать как исходящий изнутри вашей сети, поэтому эти случаи также включены в следующую таблицу.
{| class="wikitable"
|+
!Тип трафика
!Общедоступный IP-адрес
!Действительный сертификат SSL
|-
|ЕдиныйАгент (on-premises)
|
|
|-
|ЕдиныйАгент (внешний)
| +
|
|-
|RUM (on-premises)
|
|
|-
|RUM (внешний)
|
|
|-
|Безагентный RUM (on-premises)
|
| +
|-
|Безагентный RUM (внешний)
| +
| +
|-
|Мобильный RUM (on-premises)
|
| +
|-
|Мобильный RUM (внешний)
| +
| +
|-
|Синтетический
| +
|
|-
|Расширение браузера RUM (on-premises)
|
| +
|-
|Расширение браузера RUM (внешний)
| +
| +
|}
'''Примечание:'''

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

Компоненты АппОптима

2022-04-01T16:53:56Z

YaPolkin:

Основные компоненты Ключ-АСТРОМ Managed показаны на изображении ниже.

[[Файл:Managed-general-architecture.jpg|альт=Общая архитектура Managed|Общая архитектура Managed|ссылка=http://doc.ruscomtech.ru/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Managed-general-architecture.jpg]]
== Кластер Ключ-АСТРОМ Managed ==
Ваш кластер Ключ-АСТРОМ Managed отвечает за мониторинг одной или нескольких сред. Он включает как минимум один узел с установленным Сервером Ключ-АСТРОМ (обычно вы создаете более одного узла в кластере). Каждый кластер Ключ-АСТРОМ Managed связан с одной консолью управления кластером. Таким образом, каждый кластер Ключ-АСТРОМ Managed связан с:
* Одним или несколькими узлами (и, следовательно, одним или несколькими экземплярами Ключ-АСТРОМ Сервер)
* Одной или несколькими контролируемыми средами (и, следовательно, одним или несколькими экземплярами Ключ-АСТРОМ ЕдиныйАгент)
* Одной консолью управления кластером
Каждый раз, когда вы хотите настроить новый кластер, вам необходимо [[Начало работы с Управлением Ключ-АСТРОМ|получать лицензию]]. Все ваши кластеры Ключ-АСТРОМ Managed взаимодействуют с Mission Control по вопросам обслуживания и лицензирования.
== Установщик Ключ-АСТРОМ Managed ==
Установщик Ключ-АСТРОМ Managed предоставляет все удобства, предлагаемые облаком Ключ-АСТРОМ, в вашей собственной инфраструктуре и позволяет отслеживать службы приложений, процессы и on-premises инфраструктуру. Программа установки Ключ-АСТРОМ Managed состоит из следующих компонентов:
* Ключ-АСТРОМ Сервер
* Cassandra
* Elasticsearch
* Встроенный АктивныйШлюз
* NGINX
Все перечисленные компоненты развертываются на первом узле, который вы создаете при [[Установка кластера|установке кластера]], а также на любом [[Добавление новой ноды кластера|дополнительном узле]].
== Консоль управления кластером ==
Для каждого установленного кластера Ключ-АСТРОМ Managed имеется отдельная консоль управления кластером. Консоль управления кластером - это веб-интерфейс пользователя для эффективного управления инфраструктурой Ключ-АСТРОМ Managed. Отсюда вы можете в любое время просмотреть состояние развертывания установки кластера Ключ-АСТРОМ Managed.

[[Файл:Managed-deployment.jpg|альт=Развертывание Managed|Развертывание Managed|ссылка=http://doc.ruscomtech.ru/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Managed-deployment.jpg]]

Консоль управления кластером позволяет:
* [[Группы пользователей, разрешения и политики|Создание учетных записей пользователей и групп]]
* [[Добавление новой ноды кластера|Добавить новые узлы кластера]]
* [[Управление окружениями мониторинга|Добавить новые среды мониторинга]]
== Mission Control ==
Ключ-АСТРОМ Mission Control обеспечивает проактивную поддержку по вопросам обслуживания и лицензирования. Благодаря автоматической поддержке со стороны нашей команды Ключ-АСТРОМ ONE ваша установка Ключ-АСТРОМ Managed обновляется автоматически. Вы можете обратиться к нашей команде Ключ-АСТРОМ ONE через службу поддержки в режиме реального времени, если вам нужна помощь или возникнут какие-либо проблемы.
== Ключ-АСТРОМ ЕдиныйАгент ==
Ключ-АСТРОМ ЕдиныйАгент устанавливается в каждой отслеживаемой среде. Ключ-АСТРОМ ЕдиныйАгент отвечает за сбор всех данных о производительности в отслеживаемой среде и отправку данных на Сервер Ключ-АСТРОМ.

Управление пользователями и группами через LDAP

2022-03-18T09:27:12Z

YaPolkin:

Вы можете подключить управляемый кластер Ключ-АСТРОМ к каталогу LDAP для аутентификации, управления пользователями и группами.

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

== Начало ==
1. В меню Ключ-АСТРОМ перейдите в меню «Аутентификация пользователя»> «Репозиторий пользователя».

2. Выберите Внешний сервер LDAP из списка.<blockquote>Откроется страница конфигурации LDAP.

* Пример страницы "Конфигурация LDAP"

[[Файл:Live-example-obfuscated.webp|альт=Пример страницы конфигурации LDAP|Пример страницы конфигурации LDAP]]

</blockquote>
----<blockquote>После перехода на аутентификацию LDAP

# Локальные учетные записи (кроме учетной записи администратора) перестанут работать: будет невозможно войти в систему с локальной учетной записью.
# Учетная запись администратора, созданная вами во время установки, будет продолжать работать независимо от выбранного провайдера аутентификации.
</blockquote>
----3. На странице конфигурации LDAP отображается трехэтапный процесс настройки.

# Конфигурация подключения
# Конфигурация запросов групп
# Конфигурация запросов пользователей

См. ниже подробные сведения о конфигурации.

== Конфигурация подключения ==
Пример раздела «Конфигурация подключения»

[[Файл:1-connection-configuration.webp|альт=Конфигурация подключения|Конфигурация подключения]]

1. Введите адрес вашего хоста LDAP.

* Чтобы включить шифрованную связь с сервером LDAP, выберите «Использовать SSL». Это приведет к автоматическому изменению номера порта, но затем вы можете настроить его на другое значение по мере необходимости.

2. При необходимости измените номер порта:

* 389 - это номер порта по умолчанию для стандартного соединения LDAP, но убедитесь, что ваш сервер LDAP действительно его использует.
* 636 - это номер порта по умолчанию для безопасного соединения LDAPS (LDAP через SSL).

3. Укажите Bind DN (отличительное имя) для учетной записи пользователя LDAP, например, в формате:

<code>CN=UserName,OU=OU-name,DC=DomainName,DC=DomainExtension</code>

или любая другая допустимая строка LDAP.
----<blockquote>'''Примечание:''' Bind DN обычно используется системным пользователем (а не физическим лицом) для подключения к серверу LDAP. С точки зрения сервера LDAP, это просто пользователь, который читает данные и, следовательно, не нуждается в доступе для записи, но ему нужен доступ для чтения ко всем данным, которые будут извлечены из LDAP сервером Ключ-АСТРОМ.</blockquote>
----4. Введите пароль, используемый пользователем LDAP, указанным в DN привязки.

5. [опционально] Если вы настроили рефералы на своем сервере LDAP, установите Максимальное количество переходов.

6. Выберите «Проверить соединение», чтобы проверить, может ли Ключ-АСТРОМ Managed подключиться к вашему серверу LDAP. Во время проверки подключения

# Ключ-АСТРОМ пытается распознать тип используемого вами LDAP-сервера.
# На основе предыдущего шага Ключ-АСТРОМ предоставляет вам настройки по умолчанию для групповых и пользовательских запросов.

Когда соединение установлено, вы готовы к настройке групп и пользователей.

* Группы должны создаваться администратором вручную.
* Пользователи создаются автоматически, но только после успешной попытки аутентификации.

== Конфигурация запросов групп ==
После успешного тестирования соединения становится активным шаг запроса Группы. Если вы хотите использовать интеграцию LDAP только для аутентификации (для управления группами и назначения разрешений в Ключ-АСТРОМ Managed), снимите флажок «Назначать пользователей группам автоматически на основе запроса LDAP» и перейдите к настройке запроса пользователей. В противном случае выполните следующие действия.

Пример раздела "Запрос групп"

[[Файл:2-groups-query.webp|альт=Запрос групп|Запрос групп]]

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

* Каталог LDAP имеет древовидную структуру. Базовое DN для запроса групп - это запись, содержащая поддерево, в котором существуют ваши группы. В приведенном ниже примере изображения есть два поддерева, содержащие группы пользователей <code>OU=Groups,DC=org</code> и <code>OU=Lab,DC=org</code>:

[[Файл:Ldapexample1.jpg|альт=LDAP пример 1|LDAP пример 1]]

Если вы хотите распределить пользователей по группам в обоих поддеревьях, вы должны указать базовое DN для запроса групп как <code>DC=org</code> (родительская запись). Чтобы назначать пользователей только в группы поддерева <code>OU=Lab,DC=org</code>, укажите это поддерево в качестве базового DN.

* Вы можете ввести строку фильтра LDAP, чтобы сократить количество возвращаемых групп. Фильтр должен содержать информацию о том, какой класс объектов имеет записи группы. Например, для Active Directory фильтр по умолчанию:

<blockquote><code>(objectClass=group)</code>

а для OpenLDAP фильтр по умолчанию:

<code>(objectClass=groupOfNames)</code>

Чтобы сузить количество используемых групп, вы можете расширить фильтр с помощью ограничений имени группы. Например, фильтр <code>(&(objectClass=group)(CN=PL_*))</code> сужает группы, используемые системой, до групп, которые имеют <code>group</code> как атрибут <code>objectClass</code> и атрибут <code>CN</code> (общее имя), начинающийся с <code>PL_</code>. Вы можете вставить сюда любой другой действительный запрос LDAP. Помните, что LDAP нечувствителен к регистру.</blockquote>

* Настройте атрибут Group Id. Этот атрибут используется только в особых случаях. Чтобы узнать больше, проверьте раздел «Соответствие пользователей и групп» ниже. Если не применимо, установите для него то же значение, что и для атрибута имени группы.
* Настройте атрибут имени группы. Это атрибут, содержащий имя группы, обычно называемое <code>name</code> (например, для Active Directory) или <code>cn</code> (например, для OpenLDAP). Значения атрибутов имени группы в вашем каталоге LDAP должны совпадать с именами групп LDAP на странице Группы пользователей. Помните, что LDAP нечувствителен к регистру.

----<blockquote><big>'''Пример'''</big>

Если соответствующая запись группы в вашем каталоге LDAP:
{| class="wikitable"
!Атрибут
!Значение
|-
|<code>name</code>
|<code>My_TestGroup1</code>
|}
Затем настройте следующее:

* В Ключ-АСТРОМ, Аутентификация пользователя> Репозиторий пользователей (страница конфигурации LDAP), на шаге запроса групп установите для атрибута имени группы значение <code>name</code> (имя атрибута).
* В Ключ-АСТРОМ, Проверка подлинности пользователя> Группы пользователей, отредактируйте или добавьте группу и добавьте <code>My_TestGroup1</code> (значение атрибута) в группы LDAP.
</blockquote>
----'''Примечание:''' Имя группы LDAP на странице «Группы пользователей» по умолчанию соответствует имени группы, которое вы указываете при создании группы.

* Настройте атрибут «Члены группы». Этот атрибут подробно рассматривается в разделе «Сопоставление пользователей и групп» ниже.

2. Выберите Протестировать запрос, чтобы проверить свои настройки и убедиться, что запрос работает.

== Конфигурация запросов пользователей ==
После успешного тестирования соединения становится активным шаг запроса Пользователи.

Пример раздела "Пользовательский запрос"

[[Файл:3-users-query.webp|альт=Запрос пользователей|Запрос пользователей]]

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

* Каталог LDAP имеет древовидную структуру. Базовое DN для запроса пользователей - это запись, содержащая поддерево, в котором существуют ваши пользователи. Например, на изображении ниже есть два поддерева, содержащие пользователей:

<blockquote><code>OU=Functional,OU=Accounts,DC=org</code> и <code>OU=Primary,OU=Accounts,DC=org</code></blockquote>

[[Файл:Ldapexample2.jpg|альт=LDAP пример 2|LDAP пример 2]]

Ссылаясь на пример дерева выше:

* Чтобы аутентифицировать пользователей из обоих поддеревьев (<code>OU=Functional</code> и <code>OU=Primary</code>), установите Base DN для родительской записи этих поддеревьев:

<blockquote><code>OU=Accounts,DC=org</code></blockquote>

* Чтобы аутентифицировать пользователей только из OU = Primary subtree of OU = Accounts, установите для Base DN значение:

<blockquote><code>OU=Primary,OU=Accounts,DC=org</code></blockquote>

* Чтобы еще больше ограничить пользователей системы поддеревом OU = EU из OU = Primary, установите для Base DN значение:

<blockquote><code>OU=EU,OU=Primary,OU=Accounts,DC=org</code></blockquote>

* Вы можете ввести строку фильтра LDAP, чтобы сократить количество возвращаемых пользователей. Фильтр должен содержать информацию о том, какой класс объектов имеет записи группы. Например, для Active Directory и OpenLDAP фильтр по умолчанию:

<blockquote><code>(objectClass=person)</code>

Чтобы сузить количество аутентифицированных пользователей, вы можете расширить фильтр с помощью любого допустимого запроса LDAP. Например, фильтр

<code>(&(objectClass=user)(|(department=101)(department=102)(department=103)))</code>

сужает количество прошедших аутентификацию пользователей до тех, у которых атрибут <code>user</code> as <code>objectClass</code> и атрибут <code>department</code> установлены на одно из указанных значений.

Помните, что LDAP нечувствителен к регистру.</blockquote>

* Настройте атрибут входа в систему. Этот атрибут используется для входа в систему.

* Если указанные атрибуты вам не подходят, настройте атрибуты «Имя», «Фамилия» и «Электронная почта».

* Настройте атрибут членства в группе. Этот атрибут подробно рассматривается в разделе «Сопоставление пользователей и групп» ниже.

2. Выберите Тестовый запрос, чтобы проверить свои настройки и убедиться, что запрос работает.

'''Примечание:'''

Параметры тестового запроса (как для групп, так и для пользователей) проверяют только правильность базовых DN, фильтров и обязательных атрибутов - атрибута имени группы для групп и атрибута входа в систему для пользователей.

* Тестовые запросы не вызывают ошибок, если необязательные атрибуты настроены неправильно.
* Тестовые запросы не проверяют, правильно ли распределены пользователи по группам.

== Соответствие пользователей и групп ==
Есть несколько способов сопоставить пользователей с группами на серверах каталогов LDAP. Просмотрите эти примеры, чтобы найти решение, которое лучше всего подходит для вас.

=== Пример соответствия 1 ===
Если атрибут участников группы (например, <code>member</code> или <code>uniqueMember</code>) в записи группы LDAP содержит DN пользователя:

* Настраивать атрибут Group Id не нужно. Вы можете настроить атрибут Group Id на то же значение, что и атрибут Group name.

=== Пример соответствия 2 ===
Если атрибут членства в группе (например, <code>memberOf</code> или <code>isMemberOf</code>) в записи пользователя содержит DN группы:

* Настройка атрибута Group Id также не требуется, поскольку DN группы используется для сопоставления пользователей и групп. Вы можете настроить атрибут Group Id на то же значение, что и атрибут Group name.

=== Пример соответствия 3 ===
Если атрибут членства в группе (например, <code>gid</code> или <code>group</code>) в записи пользователя содержит идентификатор группы:

* Атрибут Group Id должен быть настроен для атрибута, который хранит указанное значение.

Пример групповой записи в каталоге LDAP:
{| class="wikitable"
!Атрибут
!Значение
|-
|<code>gidNumber</code>
|<code>6380</code>
|}
Пример записи пользователя в каталоге LDAP:
{| class="wikitable"
!Атрибут
!Значение
|-
|<code>gid</code>
|<code>6380</code>
|}
Затем:

* Атрибут Group Id (в запросе групп) должен быть настроен на <code>gidNumber</code>
* Атрибут членства в группе (в запросе пользователей) должен быть настроен на <code>gid</code>

== Сопоставьте управляемые группы Ключ-АСТРОМ с группами LDAP ==
Для получения информации о разрешениях групп пользователей, доступных в Ключ-АСТРОМ Managed, см. Группы пользователей и разрешения.

После того, как вы успешно настроили группы и пользователей из LDAP, вам необходимо назначить роли среды мониторинга группам из вашего каталога пользователей. По умолчанию импортированным группам не предоставляются разрешения на среду мониторинга.
----'''Примечание:'''

Пользователи не смогут получить доступ к среде мониторинга, пока вы не выполните этот шаг.
----1. В меню навигации выберите Проверка подлинности пользователя> Группы пользователей.

2. В списке групп, импортированных из LDAP, выберите имена групп, которые вы хотите настроить.

3. Вы можете назначить права администратора кластера любой конкретной группе, включив Предоставить разрешения глобального администратора этой группе. Все учетные записи пользователей в этой группе будут иметь права администратора.

4. В разделе «Разрешения» вручную установите разрешения для каждой среды.

== Ограничения ==
Ключ-АСТРОМ не поддерживает несколько доменов для аутентификации пользователей LDAP.

Компоненты АппОптима

2022-03-18T09:26:13Z

YaPolkin:

Основные компоненты Ключ-АСТРОМ Managed показаны на изображении ниже.

[[Файл:Managed-general-architecture.jpg|альт=Общая архитектура Managed|Общая архитектура Managed]]

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

* Один или несколько узлов (и, следовательно, один или несколько экземпляров Ключ-АСТРОМ Server)
* Одна или несколько контролируемых сред (и, следовательно, один или несколько экземпляров Ключ-АСТРОМ ЕдиныйАгент)
* Консоль управления одним кластером

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

== Управляемый установщик Ключ-АСТРОМ ==
Управляемый установщик Ключ-АСТРОМ предоставляет все удобства, предлагаемые облаком Ключ-АСТРОМ, в вашей собственной инфраструктуре и позволяет отслеживать службы приложений, процессы и локальную инфраструктуру. Программа установки Ключ-АСТРОМ Managed состоит из следующих компонентов:

* Ключ-АСТРОМ Server
* Cassandra
* Elasticsearch
* Встроенный АктивныйШлюз
* NGINX

Все перечисленные компоненты развертываются на первом узле, который вы создаете при настройке кластера, а также на любом дополнительном узле.

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

[[Файл:Managed-deployment.jpg|альт=Развертывание Managed|Развертывание Managed]]

Консоль управления кластером позволяет:

* Создание учетных записей пользователей и групп
* Добавить новые узлы кластера
* Добавить новые среды мониторинга

== Управление полетами ==
Ключ-АСТРОМ Mission Control обеспечивает проактивную поддержку по вопросам обслуживания и лицензирования. Благодаря автоматической поддержке со стороны нашей команды Ключ-АСТРОМ ONE ваша управляемая установка Ключ-АСТРОМ обновляется автоматически. Если вам нужна помощь или возникнут какие-либо проблемы, вы можете связаться с нашей командой Ключ-АСТРОМ ONE в режиме реального времени прямо в продукте.

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

Развертывания АппОптима

2022-03-18T09:25:38Z

YaPolkin:

Возможные сценарии развертывания Ключ-АСТРОМ Managed подробно описаны ниже. На каждой иллюстрации показаны различные задействованные компоненты и необходимые порты связи между компонентами. Направление стрелок на схемах указывает, какой компонент инициирует соединение.

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

Для общей диаграммы, показывающей все возможные подключения и порты, см. Поддерживаемые схемы подключения для АктивныйШлюзов.

== Сценарий 1: базовая настройка ==
После установки Ключ-АСТРОМ Managed и настройки одного или нескольких узлов кластера вы получите сценарий развертывания, показанный ниже.

[[Файл:Con-man-basic.jpg|альт=Базовый сценарий развертывания|Базовый сценарий развертывания]]

Без дополнительной настройки (в меню Ключ-АСТРОМ перейдите в '''«Настройки»> «Общедоступные конечные точки»''') кластер доступен только для внутренних целей и предоставляет порты 443 для REST API, трафика ЕдиныйАгент и доступа к веб-интерфейсу (Консоль управления кластером и пользовательский интерфейс среды). По умолчанию удаленный доступ к Mission Control включен. Это позволяет Ключ-АСТРОМ выполнять мониторинг и проверку работоспособности ваших управляемых кластеров Ключ-АСТРОМ. Каждый канал связи защищен TLS.

== Сценарий 2: настройка Pure Ключ-АСТРОМ Managed ==
Сценарий развертывания, показанный ниже, позволяет кластеру Ключ-АСТРОМ получать данные мониторинга из внешних источников, таких как внешние агенты ЕдиныйАгенты, внешняя среда АктивныйШлюзов или службы Digital Experience Monitoring (DEM). Кроме того, для лучшей поддержки нескольких локальных агентов ЕдиныйАгент также используется Environment АктивныйШлюз.

Услуги DEM могут включать:

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

Чтобы получать внешний трафик, вам необходимо открыть кластер Ключ-АСТРОМ для внешних сетей и настроить общедоступный IP-адрес. По соображениям безопасности не рекомендуется открывать кластер напрямую для внешних сетей. Поэтому мы предлагаем использовать один или несколько Cluster АктивныйШлюзов в качестве посредников для предварительной обработки трафика ЕдиныйАгент и DEM. Cluster АктивныйШлюзы распознается кластером и может быть настроен через консоль управления кластером, аналогично узлам кластера.

[[Файл:Con-man-pure.jpg|альт=Pure сценарий развертывания|Pure сценарий развертывания]]

Cluster АктивныйШлюз требует:

* Общедоступный IP-адрес
* Доменное имя с действующим сертификатом SSL, поскольку внешняя связь поддерживается только безопасным способом с использованием HTTPS (порт 443). Этот домен должен отличаться от домена веб-интерфейса Ключ-АСТРОМ. Вы можете предоставить домен и сертификат SSL самостоятельно или позволить Ключ-АСТРОМ сделать это за вас. Ключ-АСТРОМ может сгенерировать домен и действующий сертификат SSL от вашего имени.

Для высоконагруженных установок с множеством внешних хостов, приложений, сеансов и синтетических мониторов мы рекомендуем вам настроить несколько кластерных шлюзов АктивныйШлюз с балансировкой нагрузки с одним и тем же доменным именем и сертификатом.

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

'''В сценариях, где Environment АктивныйШлюз использует Cluster АктивныйШлюз для подключения к кластеру Ключ-АСТРОМ, Environment АктивныйШлюз начинает обмен данными с Cluster АктивныйШлюз после установки. Следовательно, Cluster АктивныйШлюз должен быть в рабочем состоянии и доступен в это время, предоставляя подходящий (локальный или общедоступный) IP-адрес.'''

Чтобы настроить управляемую среду Ключ-АСТРОМ, выполните следующие действия по развертыванию в следующем порядке:

* Настройте управляемый кластер Ключ-АСТРОМ.
* Настройте АктивныйШлюз кластера и убедитесь, что они могут подключаться к управляемому кластеру Ключ-АСТРОМ. Убедитесь, что Cluster АктивныйШлюз доступен из других ваших сетей или извне, в зависимости от ситуации, и имеет публичный IP-адрес, если это необходимо.
* Установите ваш Environment АктивныйШлюз (s). Если Environment АктивныйШлюз находится в другой сети / центре обработки данных, убедитесь, что адрес Cluster АктивныйШлюз доступен. Если Environment АктивныйШлюз является внешней сетью, должен быть доступен общедоступный IP-адрес Cluster АктивныйШлюз ('''Консоль управления> Настройки> Общедоступные конечные точки: URL-адрес Cluster АктивныйШлюз''').

'''Примечание:'''

Трафик веб-интерфейса или администрирование кластера (через консоль управления кластером) должны оставаться локальными в вашей сети. Доступ к веб-интерфейсу осуществляется по протоколу HTTPS. Таким образом, требуется сертификат TLS. Допустимо использовать самозаверяющий сертификат, но вы, вероятно, захотите, чтобы трафик веб-интерфейса и администрирование кластера также выполнялись безопасным образом. В таких случаях вы можете указать доменное имя и действующий сертификат SSL, или они могут быть автоматически сгенерированы Ключ-АСТРОМ. По умолчанию каждый кластер получает субдомен * .Ключ-АСТРОМ-managed.com с действующим сертификатом от Let's Encrypt. Также обратите внимание, что Cluster АктивныйШлюзы не поддерживает проксирование трафика веб-интерфейса.

== Сценарий 3: интеграция с существующим ИТ-ландшафтом ==
В более сложном сценарии вы можете захотеть встроить Ключ-АСТРОМ Managed в существующую ИТ-инфраструктуру с уже установленным рядом устройств. На изображении ниже показан балансировщик нагрузки, предоставляемый заказчиком, перед доменом Cluster АктивныйШлюз и предоставленный заказчиком прокси-сервер для исходящей связи с Mission Control.

[[Файл:Con-man-integr.jpg|альт=Сценарий развертывания с интеграцией|Сценарий развертывания с интеграцией]]

== Сценарий 4: глобально распределенная высокая доступность с автоматическим восстановлением ==
Ключ-АСТРОМ позволяет настроить развертывание высокой доступности в распределенных сетях в виде автономного готового решения, которое обеспечивает практически нулевое время простоя и позволяет продолжать мониторинг без потери данных в сценариях аварийного переключения. Это решение обеспечивает экономию затрат с точки зрения распределения вычислительных ресурсов и хранилища, устраняя необходимость в отдельных резервных хостах восстановления и соответствующей инфраструктуре для хранения и передачи данных резервного копирования. При планировании емкости следует рассматривать узлы в дополнительном центре обработки данных как избыточные, а не как расширенные емкости, и запланируйте одинаковую балансировку обоих центров обработки данных. Дополнительные сведения о концепции центра обработки данных с несколькими центрами обработки данных в управляемых развертываниях Ключ-АСТРОМ см. В разделе Высокая доступность для центров обработки данных с несколькими центрами обработки данных.

Для развертывания этого сценария у вас должна быть отдельная лицензия Premium High Availability.

* См. Раздел Расчет потребления мониторинга Ключ-АСТРОМ.

[[Файл:Con-man-global.jpg|альт=Глобальный сценарий развертывания|Глобальный сценарий развертывания]]

=== Необходимая конфигурация для каждого случая дорожного движения ===
В следующей таблице суммируется необходимая конфигурация для каждого случая дискретного трафика, указывая с помощью x, требуется ли общедоступный IP-адрес, действительный сертификат SSL или и то, и другое. Обратите внимание, что мониторинг реального пользователя (RUM), RUM без агента и мобильный RUM обычно связаны с трафиком ваших пользователей и активностью браузера, которые происходят за пределами вашей сети. Теоретически этот трафик также можно рассматривать как исходящий изнутри вашей сети, поэтому эти случаи также включены в следующую таблицу.
{| class="wikitable"
|+
!Тип трафика
!Общедоступный IP-адрес
!Действительный сертификат SSL
|-
|ЕдиныйАгент (локально)
|
|
|-
|ЕдиныйАгент (внешний)
| +
|
|-
|RUM (локально)
|
|
|-
|RUM (внешний)
|
|
|-
|Безагентный RUM (локально)
|
| +
|-
|Безагентный RUM (внешний)
| +
| +
|-
|Mobile RUM (локально)
|
| +
|-
|Mobile RUM (внешний)
| +
| +
|-
|Синтетический
| +
|
|-
|Расширение браузера RUM (локально)
|
| +
|-
|Расширение браузера RUM (внешний)
| +
| +
|}
'''Примечание:'''

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

Файл:Managed-general-architecture.jpg

2022-03-18T09:23:17Z

YaPolkin:

Файл:Ldapexample2.jpg

2022-03-18T09:23:02Z

YaPolkin:

Файл:Ldapexample1.jpg

2022-03-18T09:22:48Z

YaPolkin:

Файл:Con-man-pure.jpg

2022-03-18T09:22:18Z

YaPolkin:

Файл:Con-man-integr.jpg

2022-03-18T09:22:01Z

YaPolkin:

Файл:Con-man-global.jpg

2022-03-18T09:21:32Z

YaPolkin:

Развертывания АппОптима

2022-03-17T06:32:54Z

YaPolkin:

Возможные сценарии развертывания Ключ-АСТРОМ Managed подробно описаны ниже. На каждой иллюстрации показаны различные задействованные компоненты и необходимые порты связи между компонентами. Направление стрелок на схемах указывает, какой компонент инициирует соединение.

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

Для общей диаграммы, показывающей все возможные подключения и порты, см. Поддерживаемые схемы подключения для АктивныйШлюзов.

== Сценарий 1: базовая настройка ==
После установки Ключ-АСТРОМ Managed и настройки одного или нескольких узлов кластера вы получите сценарий развертывания, показанный ниже.

[[Файл:Con-man-basic.jpg|альт=Базовый сценарий развертывания|Базовый сценарий развертывания]]

Без дополнительной настройки (в меню Ключ-АСТРОМ перейдите в '''«Настройки»> «Общедоступные конечные точки»''') кластер доступен только для внутренних целей и предоставляет порты 443 для REST API, трафика ЕдиныйАгент и доступа к веб-интерфейсу (Консоль управления кластером и пользовательский интерфейс среды). По умолчанию удаленный доступ к Mission Control включен. Это позволяет Ключ-АСТРОМ выполнять мониторинг и проверку работоспособности ваших управляемых кластеров Ключ-АСТРОМ. Каждый канал связи защищен TLS.

== Сценарий 2: настройка Pure Ключ-АСТРОМ Managed ==
Сценарий развертывания, показанный ниже, позволяет кластеру Ключ-АСТРОМ получать данные мониторинга из внешних источников, таких как внешние агенты ЕдиныйАгенты, внешняя среда АктивныйШлюзов или службы Digital Experience Monitoring (DEM). Кроме того, для лучшей поддержки нескольких локальных агентов ЕдиныйАгент также используется Environment АктивныйШлюз.

Услуги DEM могут включать:

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

Чтобы получать внешний трафик, вам необходимо открыть кластер Ключ-АСТРОМ для внешних сетей и настроить общедоступный IP-адрес. По соображениям безопасности не рекомендуется открывать кластер напрямую для внешних сетей. Поэтому мы предлагаем использовать один или несколько Cluster АктивныйШлюзов в качестве посредников для предварительной обработки трафика ЕдиныйАгент и DEM. Cluster АктивныйШлюзы распознается кластером и может быть настроен через консоль управления кластером, аналогично узлам кластера.

[[Файл:Con-man-pure.webp|альт=Pure сценарий развертывания|Pure сценарий развертывания]]

Cluster АктивныйШлюз требует:

* Общедоступный IP-адрес
* Доменное имя с действующим сертификатом SSL, поскольку внешняя связь поддерживается только безопасным способом с использованием HTTPS (порт 443). Этот домен должен отличаться от домена веб-интерфейса Ключ-АСТРОМ. Вы можете предоставить домен и сертификат SSL самостоятельно или позволить Ключ-АСТРОМ сделать это за вас. Ключ-АСТРОМ может сгенерировать домен и действующий сертификат SSL от вашего имени.

Для высоконагруженных установок с множеством внешних хостов, приложений, сеансов и синтетических мониторов мы рекомендуем вам настроить несколько кластерных шлюзов АктивныйШлюз с балансировкой нагрузки с одним и тем же доменным именем и сертификатом.

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

'''В сценариях, где Environment АктивныйШлюз использует Cluster АктивныйШлюз для подключения к кластеру Ключ-АСТРОМ, Environment АктивныйШлюз начинает обмен данными с Cluster АктивныйШлюз после установки. Следовательно, Cluster АктивныйШлюз должен быть в рабочем состоянии и доступен в это время, предоставляя подходящий (локальный или общедоступный) IP-адрес.'''

Чтобы настроить управляемую среду Ключ-АСТРОМ, выполните следующие действия по развертыванию в следующем порядке:

* Настройте управляемый кластер Ключ-АСТРОМ.
* Настройте АктивныйШлюз кластера и убедитесь, что они могут подключаться к управляемому кластеру Ключ-АСТРОМ. Убедитесь, что Cluster АктивныйШлюз доступен из других ваших сетей или извне, в зависимости от ситуации, и имеет публичный IP-адрес, если это необходимо.
* Установите ваш Environment АктивныйШлюз (s). Если Environment АктивныйШлюз находится в другой сети / центре обработки данных, убедитесь, что адрес Cluster АктивныйШлюз доступен. Если Environment АктивныйШлюз является внешней сетью, должен быть доступен общедоступный IP-адрес Cluster АктивныйШлюз ('''Консоль управления> Настройки> Общедоступные конечные точки: URL-адрес Cluster АктивныйШлюз''').

'''Примечание:'''

Трафик веб-интерфейса или администрирование кластера (через консоль управления кластером) должны оставаться локальными в вашей сети. Доступ к веб-интерфейсу осуществляется по протоколу HTTPS. Таким образом, требуется сертификат TLS. Допустимо использовать самозаверяющий сертификат, но вы, вероятно, захотите, чтобы трафик веб-интерфейса и администрирование кластера также выполнялись безопасным образом. В таких случаях вы можете указать доменное имя и действующий сертификат SSL, или они могут быть автоматически сгенерированы Ключ-АСТРОМ. По умолчанию каждый кластер получает субдомен * .Ключ-АСТРОМ-managed.com с действующим сертификатом от Let's Encrypt. Также обратите внимание, что Cluster АктивныйШлюзы не поддерживает проксирование трафика веб-интерфейса.

== Сценарий 3: интеграция с существующим ИТ-ландшафтом ==
В более сложном сценарии вы можете захотеть встроить Ключ-АСТРОМ Managed в существующую ИТ-инфраструктуру с уже установленным рядом устройств. На изображении ниже показан балансировщик нагрузки, предоставляемый заказчиком, перед доменом Cluster АктивныйШлюз и предоставленный заказчиком прокси-сервер для исходящей связи с Mission Control.

[[Файл:Con-man-integr.webp|альт=Сценарий развертывания с интеграцией|Сценарий развертывания с интеграцией]]

== Сценарий 4: глобально распределенная высокая доступность с автоматическим восстановлением ==
Ключ-АСТРОМ позволяет настроить развертывание высокой доступности в распределенных сетях в виде автономного готового решения, которое обеспечивает практически нулевое время простоя и позволяет продолжать мониторинг без потери данных в сценариях аварийного переключения. Это решение обеспечивает экономию затрат с точки зрения распределения вычислительных ресурсов и хранилища, устраняя необходимость в отдельных резервных хостах восстановления и соответствующей инфраструктуре для хранения и передачи данных резервного копирования. При планировании емкости следует рассматривать узлы в дополнительном центре обработки данных как избыточные, а не как расширенные емкости, и запланируйте одинаковую балансировку обоих центров обработки данных. Дополнительные сведения о концепции центра обработки данных с несколькими центрами обработки данных в управляемых развертываниях Ключ-АСТРОМ см. В разделе Высокая доступность для центров обработки данных с несколькими центрами обработки данных.

Для развертывания этого сценария у вас должна быть отдельная лицензия Premium High Availability.

* См. Раздел Расчет потребления мониторинга Ключ-АСТРОМ.

[[Файл:Con-man-global.webp|альт=Глобальный сценарий развертывания|Глобальный сценарий развертывания]]

=== Необходимая конфигурация для каждого случая дорожного движения ===
В следующей таблице суммируется необходимая конфигурация для каждого случая дискретного трафика, указывая с помощью x, требуется ли общедоступный IP-адрес, действительный сертификат SSL или и то, и другое. Обратите внимание, что мониторинг реального пользователя (RUM), RUM без агента и мобильный RUM обычно связаны с трафиком ваших пользователей и активностью браузера, которые происходят за пределами вашей сети. Теоретически этот трафик также можно рассматривать как исходящий изнутри вашей сети, поэтому эти случаи также включены в следующую таблицу.
{| class="wikitable"
|+
!Тип трафика
!Общедоступный IP-адрес
!Действительный сертификат SSL
|-
|ЕдиныйАгент (локально)
|
|
|-
|ЕдиныйАгент (внешний)
| +
|
|-
|RUM (локально)
|
|
|-
|RUM (внешний)
|
|
|-
|Безагентный RUM (локально)
|
| +
|-
|Безагентный RUM (внешний)
| +
| +
|-
|Mobile RUM (локально)
|
| +
|-
|Mobile RUM (внешний)
| +
| +
|-
|Синтетический
| +
|
|-
|Расширение браузера RUM (локально)
|
| +
|-
|Расширение браузера RUM (внешний)
| +
| +
|}
'''Примечание:'''

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

Управление окружениями мониторинга

2022-03-17T06:32:34Z

YaPolkin:

Вы можете легко создавать среды мониторинга и управлять ими с помощью консоли управления кластером.

[[Файл:Managed-deployment.jpg|альт=Развертывание Managed]]

== Создайте среду ==
1. В меню Ключ-АСТРОМ перейдите в Среды.

2. Нажмите кнопку + Добавить другую среду.

3. В текстовом поле Имя среды введите имя для своей среды.

4. [опционально] Вы можете отключить синтетические мониторы, установив переключатель «Включить синтетические мониторы» в положение «Выкл.».

5. Щелкните Сохранить.

== Настроить среду ==
После создания среды и нажатия кнопки «Сохранить» вы попадете на страницу конфигурации среды. Однако вы можете получить доступ к странице конфигурации среды в любое время. В меню Ключ-АСТРОМ перейдите в «Среды» и выберите среду, которую нужно настроить.

На странице конфигурации вы можете установить общую, а также месячную и годовую квоты для вашей среды.

=== Общие квоты окружения ===

* '''Единицы хоста''' - размер хоста для целей лицензирования (в зависимости от объема оперативной памяти, предоставляемой хостом). Для мониторинга полного стека хост с 16 ГБ ОЗУ (или любой ее частью) соответствует 1 хост-устройству. Для мониторинга облачной инфраструктуры хост с 16 ГБ ОЗУ (или любой ее частью) соответствует 0,3 единицы хоста. Для получения полной информации см. Как рассчитать отслеживаемое потребление.
* '''Пользовательские метрики''' - количество уникальных метрик таймсерий в 24-часовом скользящем окне. Для получения полной информации см. DDU для пользовательских показателей.

=== Месячные и годовые квоты ===

* '''Пользовательские сессии'''- количество пользовательских сеансов (т.е. "Сеансов RUM"), которые будут отслеживаться в месяц/год. Подробнее см. Единицы DEM - Мониторинг реального пользователя.
* '''Синтетические мониторы''' - количество синтетических мониторов, которые будут выполняться в месяц/год. Для получения дополнительной информации см. Как рассчитать отслеживаемое потребление.
* '''Средн. ежедневный объем журнала''' - объем трафика мониторинга журнала в месяц/год. Для получения дополнительной информации см. Как рассчитать отслеживаемое потребление.

Также вы можете настроить параметры хранилища, которые включают:

* '''Хранилище транзакций''' - объем дискового пространства, который будет зарезервирован для транзакций (например, для вызовов служб, стеков вызовов и операторов SQL).
* '''Файлы символов из мобильных приложений''' - объем памяти, который может быть использован файлами символов из мобильных приложений.
* '''Сохранение уровня запроса на обслуживание''' - время, в течение которого дисковое пространство для запроса на обслуживание должно сохраняться.
* '''Сохранение уровня служебного кода''' - время, в течение которого дисковое пространство для видимости на уровне кода должно сохраняться.
* '''Сохранение реального мониторинга пользователя''' - время, в течение которого дисковое пространство для пользовательских сеансов должно сохраняться.
* '''Сохранение синтетического мониторинга''' - время, в течение которого должно оставаться дисковое пространство для синтетических мониторов.
* '''Сохранение воспроизведения сеанса''' - количество времени, в течение которого дисковое пространство для данных воспроизведения сеанса должно сохраняться.
* '''Хранилище для мониторинга журналов''' - объем дискового пространства, который будет зарезервирован для мониторинга журналов.
* '''Сохранение хранилища для мониторинга журналов''' - время, в течение которого указанное дисковое пространство для мониторинга журналов должно сохраняться.

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

=== Назначьте разрешения среды для групп пользователей ===
Используйте эти элементы управления для назначения разрешений среды определенным группам пользователей.

Дополнительные сведения см. в разделе Управление группами пользователей и разрешениями.

== Переименовать среду ==
1. В меню Ключ-АСТРОМ перейдите в Среды.

2. Выберите среду, которую хотите переименовать.

3. Щелкните маленький значок карандаша рядом с названием среды.

4. Введите новое имя и нажмите кнопку с галочкой.

== Отключить/удалить среду ==
1. В меню Ключ-АСТРОМ перейдите в Среды.

2. Выберите среду, которую вы хотите отключить / удалить.

3. Нажмите кнопку «Обзор» (…) в правом верхнем углу.

4. Выберите Отключить среду или Удалить среду без возможности восстановления.

== Доступ к среде ==
Чтобы получить доступ к среде со страницы администрирования Ключ-АСТРОМ Managed:

1. В меню Ключ-АСТРОМ перейдите в Среды.

2. Выберите среду, к которой хотите получить доступ.

3. Нажмите кнопку «Перейти в среду» в правом верхнем углу.

Данные мониторинга, относящиеся к выбранной среде, отображаются на вашем дашборде.

[[Файл:Dashboard.webp|альт=Дашборд]]

Чтобы получить доступ к среде со страницы администрирования Ключ-АСТРОМ Managed другим способом:

1. Откройте меню «Пользователь», щелкнув значок «Пользователь» в правом верхнем углу.

2. Откройте раскрывающийся список Cluster Management.

3. Выберите среду, к которой хотите получить доступ.

Чтобы вернуться в консоль управления кластером в любое время:

1. На панели мониторинга откройте меню «Пользователь», щелкнув значок «Пользователь» в правом верхнем углу.

2. Щелкните имя среды, чтобы открыть раскрывающийся список.

3. Выберите Управление кластером.

== Переключение между средами ==
Находясь на панели инструментов, просматривая определенную среду

1. Откройте меню «Пользователь», щелкнув значок «Пользователь» в правом верхнем углу.

2. Щелкните имя среды, чтобы открыть раскрывающийся список.

3. Выберите другую среду, к которой хотите получить доступ.

Компоненты АппОптима

2022-03-17T06:32:20Z

YaPolkin:

Основные компоненты Ключ-АСТРОМ Managed показаны на изображении ниже.

[[Файл:Managed-general-architecture.webp|альт=Общая архитектура Managed|Общая архитектура Managed]]

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

* Один или несколько узлов (и, следовательно, один или несколько экземпляров Ключ-АСТРОМ Server)
* Одна или несколько контролируемых сред (и, следовательно, один или несколько экземпляров Ключ-АСТРОМ ЕдиныйАгент)
* Консоль управления одним кластером

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

== Управляемый установщик Ключ-АСТРОМ ==
Управляемый установщик Ключ-АСТРОМ предоставляет все удобства, предлагаемые облаком Ключ-АСТРОМ, в вашей собственной инфраструктуре и позволяет отслеживать службы приложений, процессы и локальную инфраструктуру. Программа установки Ключ-АСТРОМ Managed состоит из следующих компонентов:

* Ключ-АСТРОМ Server
* Cassandra
* Elasticsearch
* Встроенный АктивныйШлюз
* NGINX

Все перечисленные компоненты развертываются на первом узле, который вы создаете при настройке кластера, а также на любом дополнительном узле.

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

[[Файл:Managed-deployment.jpg|альт=Развертывание Managed|Развертывание Managed]]

Консоль управления кластером позволяет:

* Создание учетных записей пользователей и групп
* Добавить новые узлы кластера
* Добавить новые среды мониторинга

== Управление полетами ==
Ключ-АСТРОМ Mission Control обеспечивает проактивную поддержку по вопросам обслуживания и лицензирования. Благодаря автоматической поддержке со стороны нашей команды Ключ-АСТРОМ ONE ваша управляемая установка Ключ-АСТРОМ обновляется автоматически. Если вам нужна помощь или возникнут какие-либо проблемы, вы можете связаться с нашей командой Ключ-АСТРОМ ONE в режиме реального времени прямо в продукте.

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

Установка кластера

2022-03-17T06:31:23Z

YaPolkin:

Настройка управляемого Ключ-АСТРОМ кластера включает создание вашего первого узла кластера путем загрузки и установки Ключ-АСТРОМ Managed. Чтобы настроить управляемый кластер Ключ-АСТРОМ, выполните следующие действия.

== Прежде чем вы начнете ==
Убедитесь, что ваша система соответствует указанным требованиям к оборудованию и операционной системе.

'''Примечание:''' Установка хранилищ данных для различных компонентов Ключ-АСТРОМ Managed на сетевые/удаленные диски не рекомендуется из-за возможных проблем с производительностью и стабильностью обновлений.

== Шаг 1. Загрузите установщик ==
1. Войдите в систему Linux, на которой вы хотите установить Ключ-АСТРОМ Managed.

2. Скопируйте командную строку wget из полученного вами письма активации.

3. Вставьте командную строку wget в окно терминала. Дождитесь завершения загрузки и перейдите к шагу 2.

== Шаг 2. Проверьте установщик ==
Файл программы установки Ключ-АСТРОМ Managed имеет цифровую подпись. Файл подписи распространяется вместе с программой установки Ключ-АСТРОМ Managed. В сочетании с OpenSSL и корневым сертификатом Ключ-АСТРОМ файл подписи может использоваться для проверки подлинности установщика. Файл подписи имеет то же имя, что и программа установки, с расширением .sig.

== Шаг 3. Запустите установщик ==
1. Для установки Ключ-АСТРОМ Managed вам потребуются права root. Вы можете использовать su или sudo для запуска сценария установки.
----<big>''Не удаляйте и не перезаписывайте dtrun''</big>

Это требуется при установке и обновлении. Программа установки вызывает dtrun без аргументов, чтобы подтвердить, что у пользователя есть права администратора, но для нормальной работы Ключ-АСТРОМ вызывает dtrun с аргументами для фактического выполнения команд.
----2. Введите Принять, если вы согласны с Условиями использования Ключ-АСТРОМ Managed. Установка не будет продолжена, пока вы не завершите этот шаг. Чтобы выйти из установки, нажмите Ctrl + C.

3. Программа установки Ключ-АСТРОМ Managed работает в интерактивном режиме. Он отображает запросы для значений, таких как путь установки и учетная запись пользователя. Примите значения по умолчанию, нажав Enter. Чтобы изменить настройки, введите свой выбор в терминале и нажмите Enter.

'''Примечание:''' Имейте доступный лицензионный ключ Ключ-АСТРОМ Managed. Вы не можете завершить установку без лицензионного ключа.

'''Обойти интерактивный режим'''

Чтобы обойти все вопросы и установить с настройками по умолчанию, запустите установщик с параметром --install-silent. Обязательно укажите свой лицензионный ключ Ключ-АСТРОМ Managed в качестве значения параметра --license.

'''Что происходит при установке'''

Управляемый кластер Ключ-АСТРОМ - это набор специализированных компонентов, настроенных для размещения вашей среды мониторинга и данных мониторинга процессов.

Установщик настраивает следующие компоненты в каталоге установки:

* Предварительно настроенная среда выполнения Java (это не влияет на настройки вашей операционной системы). Не отображается в ваших альтернативных вариантах.
* Хранилище Hypercube на основе Cassandra
* Поисковая система на основе Elasticsearch
* Сервер Ключ-АСТРОМ
* Встроенный АктивныйШлюз

Установщик также оптимизирует настройки операционной системы:

* Своп отключен (со swapoff).
* Обратите внимание, что включение подкачки может привести к нежелательному поведению и поэтому не поддерживается.
* Правила iptables «PREROUTING» расширены, чтобы разрешить пересылку сообщений на сервер Ключ-АСТРОМ (через HTTPS на порт 8021). Чтобы увидеть точные правила, введите в терминал iptables -L -vt nat.
* Кэш страницы с опережающим чтением установлен на 512.
* Ограничения для пользователей изменены глобально (неограниченное заблокированное адресное пространство в памяти, неограниченное адресное пространство, увеличенное ограничение на количество процессов и открытых файлов). Подробнее см. /Etc/security/limits.conf.
* max_map_count изменен.

Следующие системные файлы и каталоги могут быть изменены во время установки Ключ-АСТРОМ Managed:

<code>/etc/hosts</code>

<code>/etc/sysctl.conf</code>

<code>/etc/pam.d/su</code>

<code>/etc/rc.local</code>

<code>/etc/security/limits.conf</code>

<code>/etc/security/limits.d/90-nproc.conf</code>

<code>/etc/sudoers</code>

<code>/etc/sudoers.d/</code>

<code>/etc/init.d/</code>

<code>/etc/init.d/rc*.d/</code>

<code>/etc/systemd/system/</code>

'''Журналы установки'''

Вы можете найти файл журнала управляемой установки Ключ-АСТРОМ в каталоге <code><install dir>/installer/</code>. Чтобы легко определить нужный файл журнала, поищите дату установки в имени файла. Например, файл журнала успешной установки, выполненной 30 сентября, будет иметь вид <code>20160930-173309-success-install-of-managed-installer.log</code>
----<big>''Параметры установки''</big>

Чтобы просмотреть список всех доступных параметров установки, запустите установщик с параметром --help.
----

== Шаг 4. Завершите настройку ==
1. Скопируйте URL-адрес среды, указанный в конце процесса установки. Вставьте адрес в свой браузер, чтобы завершить оставшуюся часть установки. Появится следующая страница.

[[Файл:After-server-installation.jpg|альт=После установки сервера|После установки сервера]]

2. Укажите имя для вашей первой среды мониторинга и настройте учетную запись администратора. По завершении щелкните Далее. Вы войдете в систему и будете перенаправлены в Консоль управления кластером. Создается домен по умолчанию, который следует использовать вместо IP-адреса для безопасного (HTTPS) соединения.

[[Файл:Managed-deployment.jpg|альт=Развертывание Managed|Развертывание Managed]]

3. В меню Ключ-АСТРОМ перейдите в «Среды», чтобы просмотреть вновь созданную среду. Выберите свою среду, а затем нажмите «Перейти к среде», чтобы получить доступ к веб-интерфейсу среды. Позже вы можете создать дополнительные среды.

Файл:Man-diag-enter.jpg

2022-03-17T06:30:20Z

YaPolkin:

Файл:Managed-deployment.jpg

2022-03-17T06:30:06Z

YaPolkin:

Файл:Con-man-basic.jpg

2022-03-17T06:29:46Z

YaPolkin:

Файл:Cluster-diags.jpg

2022-03-17T06:29:18Z

YaPolkin:

Установка кластера

2022-03-17T06:28:46Z

YaPolkin:

Настройка управляемого Ключ-АСТРОМ кластера включает создание вашего первого узла кластера путем загрузки и установки Ключ-АСТРОМ Managed. Чтобы настроить управляемый кластер Ключ-АСТРОМ, выполните следующие действия.

== Прежде чем вы начнете ==
Убедитесь, что ваша система соответствует указанным требованиям к оборудованию и операционной системе.

'''Примечание:''' Установка хранилищ данных для различных компонентов Ключ-АСТРОМ Managed на сетевые/удаленные диски не рекомендуется из-за возможных проблем с производительностью и стабильностью обновлений.

== Шаг 1. Загрузите установщик ==
1. Войдите в систему Linux, на которой вы хотите установить Ключ-АСТРОМ Managed.

2. Скопируйте командную строку wget из полученного вами письма активации.

3. Вставьте командную строку wget в окно терминала. Дождитесь завершения загрузки и перейдите к шагу 2.

== Шаг 2. Проверьте установщик ==
Файл программы установки Ключ-АСТРОМ Managed имеет цифровую подпись. Файл подписи распространяется вместе с программой установки Ключ-АСТРОМ Managed. В сочетании с OpenSSL и корневым сертификатом Ключ-АСТРОМ файл подписи может использоваться для проверки подлинности установщика. Файл подписи имеет то же имя, что и программа установки, с расширением .sig.

== Шаг 3. Запустите установщик ==
1. Для установки Ключ-АСТРОМ Managed вам потребуются права root. Вы можете использовать su или sudo для запуска сценария установки.
----<big>''Не удаляйте и не перезаписывайте dtrun''</big>

Это требуется при установке и обновлении. Программа установки вызывает dtrun без аргументов, чтобы подтвердить, что у пользователя есть права администратора, но для нормальной работы Ключ-АСТРОМ вызывает dtrun с аргументами для фактического выполнения команд.
----2. Введите Принять, если вы согласны с Условиями использования Ключ-АСТРОМ Managed. Установка не будет продолжена, пока вы не завершите этот шаг. Чтобы выйти из установки, нажмите Ctrl + C.

3. Программа установки Ключ-АСТРОМ Managed работает в интерактивном режиме. Он отображает запросы для значений, таких как путь установки и учетная запись пользователя. Примите значения по умолчанию, нажав Enter. Чтобы изменить настройки, введите свой выбор в терминале и нажмите Enter.

'''Примечание:''' Имейте доступный лицензионный ключ Ключ-АСТРОМ Managed. Вы не можете завершить установку без лицензионного ключа.

'''Обойти интерактивный режим'''

Чтобы обойти все вопросы и установить с настройками по умолчанию, запустите установщик с параметром --install-silent. Обязательно укажите свой лицензионный ключ Ключ-АСТРОМ Managed в качестве значения параметра --license.

'''Что происходит при установке'''

Управляемый кластер Ключ-АСТРОМ - это набор специализированных компонентов, настроенных для размещения вашей среды мониторинга и данных мониторинга процессов.

Установщик настраивает следующие компоненты в каталоге установки:

* Предварительно настроенная среда выполнения Java (это не влияет на настройки вашей операционной системы). Не отображается в ваших альтернативных вариантах.
* Хранилище Hypercube на основе Cassandra
* Поисковая система на основе Elasticsearch
* Сервер Ключ-АСТРОМ
* Встроенный АктивныйШлюз

Установщик также оптимизирует настройки операционной системы:

* Своп отключен (со swapoff).
* Обратите внимание, что включение подкачки может привести к нежелательному поведению и поэтому не поддерживается.
* Правила iptables «PREROUTING» расширены, чтобы разрешить пересылку сообщений на сервер Ключ-АСТРОМ (через HTTPS на порт 8021). Чтобы увидеть точные правила, введите в терминал iptables -L -vt nat.
* Кэш страницы с опережающим чтением установлен на 512.
* Ограничения для пользователей изменены глобально (неограниченное заблокированное адресное пространство в памяти, неограниченное адресное пространство, увеличенное ограничение на количество процессов и открытых файлов). Подробнее см. /Etc/security/limits.conf.
* max_map_count изменен.

Следующие системные файлы и каталоги могут быть изменены во время установки Ключ-АСТРОМ Managed:

<code>/etc/hosts</code>

<code>/etc/sysctl.conf</code>

<code>/etc/pam.d/su</code>

<code>/etc/rc.local</code>

<code>/etc/security/limits.conf</code>

<code>/etc/security/limits.d/90-nproc.conf</code>

<code>/etc/sudoers</code>

<code>/etc/sudoers.d/</code>

<code>/etc/init.d/</code>

<code>/etc/init.d/rc*.d/</code>

<code>/etc/systemd/system/</code>

'''Журналы установки'''

Вы можете найти файл журнала управляемой установки Ключ-АСТРОМ в каталоге <code><install dir>/installer/</code>. Чтобы легко определить нужный файл журнала, поищите дату установки в имени файла. Например, файл журнала успешной установки, выполненной 30 сентября, будет иметь вид <code>20160930-173309-success-install-of-managed-installer.log</code>
----<big>''Параметры установки''</big>

Чтобы просмотреть список всех доступных параметров установки, запустите установщик с параметром --help.
----

== Шаг 4. Завершите настройку ==
1. Скопируйте URL-адрес среды, указанный в конце процесса установки. Вставьте адрес в свой браузер, чтобы завершить оставшуюся часть установки. Появится следующая страница.

[[Файл:After-server-installation.jpg|альт=После установки сервера|После установки сервера]]

2. Укажите имя для вашей первой среды мониторинга и настройте учетную запись администратора. По завершении щелкните Далее. Вы войдете в систему и будете перенаправлены в Консоль управления кластером. Создается домен по умолчанию, который следует использовать вместо IP-адреса для безопасного (HTTPS) соединения.

[[Файл:Managed-deployment.webp|альт=Развертывание Managed|Развертывание Managed]]

3. В меню Ключ-АСТРОМ перейдите в «Среды», чтобы просмотреть вновь созданную среду. Выберите свою среду, а затем нажмите «Перейти к среде», чтобы получить доступ к веб-интерфейсу среды. Позже вы можете создать дополнительные среды.

Файл:After-server-installation.jpg

2022-03-17T06:27:56Z

YaPolkin:

Файл:After-server-installation.webp

2022-03-17T06:25:35Z

YaPolkin: YaPolkin загрузил новую версию Файл:After-server-installation.webp

Файл:After-server-installation.webp

2022-03-17T06:24:39Z

YaPolkin: YaPolkin вернул Файл:After-server-installation.webp к старой версии

Файл:After-server-installation.webp

2022-03-17T06:24:10Z

YaPolkin: YaPolkin загрузил новую версию Файл:After-server-installation.webp

Группы пользователей, разрешения и политики

2022-03-17T05:39:48Z

YaPolkin:

Вам необходимо настроить группы пользователей в Ключ-АСТРОМ Managed, чтобы разрешить доступ к вашей среде мониторинга или вашему серверу Ключ-АСТРОМ.

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

Вы можете управлять пользователями и группами через Консоль управления кластером. В меню Ключ-АСТРОМ перейдите в раздел «Аутентификация пользователя» в меню навигации.

=== Создать группу ===
1. В меню навигации выберите Аутентификация пользователя> Группы пользователей.

2. Выберите Добавить новую группу.

3. Назначьте разрешения только что созданной группе

* Чтобы назначить права администратора группе, установите для параметра Предоставить разрешения глобального администратора этой группе значение Вкл. Группа будет иметь права доступа ко всем средам.
* Чтобы назначить индивидуальные права доступа для каждой среды, введите разделенный запятыми список имен групп LDAP, которые должны быть сопоставлены этой группе пользователей.

=== Создать пользователя ===
1. Выберите Аутентификация пользователя> Учетные записи пользователей в меню навигации.

2. Выберите Добавить нового пользователя.<blockquote>'''Примечание:''' Этот параметр доступен только в том случае, если вы используете внутреннюю базу данных, а не LDAP.</blockquote>

=== Распределить пользователя по группам ===
1. Выберите Аутентификация пользователя> Учетные записи пользователей в меню навигации.

2. Выберите пользователя.

3. Выберите «Добавить» в разделе «Добавить групповые назначения».<blockquote>'''Примечание:''' Группа не может быть назначена, если для нее не указаны разрешения.</blockquote>

== Разрешения ==
Вы можете назначить группе предопределенный набор разрешений. Как только группа определена, вы можете добавлять в нее пользователей. Пользователи могут принадлежать более чем к одной группе и наследовать разрешения групп, к которым они принадлежат. Вы можете изменять или создавать группы в соответствии с вашими потребностями.

=== Разрешения кластера ===
Пользователи, назначенные в группы с этим разрешением, автоматически получают права доступа администратора для всех сред. У них есть доступ к консоли управления кластером и они могут управлять вашей средой мониторинга и сервером Ключ-АСТРОМ. Пользователи, назначенные в группы с этим разрешением, также могут:

* Добавить новые узлы Ключ-АСТРОМ Server
* Обновите сервер Ключ-АСТРОМ
* Управление управляемыми пользователями и группами пользователей Ключ-АСТРОМ
* Установите Ключ-АСТРОМ ЕдиныйАгент в любую среду мониторинга
* Настраивать параметры мониторинга для любой среды мониторинга

=== Разрешения среды ===
Ключ-АСТРОМ предоставляет следующие разрешения на уровне среды. Выбрать все, что подходит:

* Среда доступа: разрешает доступ к среде только для чтения. Вы не можете изменять настройки или устанавливать ЕдиныйАгент только с этим разрешением.

----<blockquote>'''<big>Важно</big>'''

Разрешение среды доступа требуется для любых других разрешений среды, поэтому среда доступа автоматически выбирается для среды, когда вы выбираете любое другое разрешение среды.

*
</blockquote>
----

* Изменить настройки мониторинга: позволяет изменять все настройки среды. Чтобы установить ЕдиныйАгент, вы должны предоставить разрешение на скачивание и установку ЕдиныйАгент.
* Загрузить и установить ЕдиныйАгент: позволяет загружать ЕдиныйАгент и устанавливать его на хостах. Чтобы изменить / отредактировать настройки, вы должны предоставить разрешение на изменение настроек мониторинга.
* Просмотр журналов: разрешает доступ к конфиденциальным данным файла журнала на вкладке «Журналы».
* Просмотр конфиденциальных данных запроса: позволяет просматривать потенциально личные данные, захваченные Ключ-АСТРОМ, включая загрузку дампов памяти. Пользователи, у которых нет этого разрешения, видят, что точка данных существует, но личные данные замаскированы звездочками (*****). Также позволяет вручную запускать дампы памяти.
* Настроить данные захвата запроса: позволяет настроить правила захвата атрибутов запроса. Их можно использовать для захвата таких элементов, как заголовки HTTP или параметры публикации, для хранения, фильтрации и поиска. Когда вы устанавливаете это разрешение, изменение настроек мониторинга включается автоматически.
* Воспроизведение данных сеанса: позволяет воспроизводить записанные пользовательские сеансы с правилами маскирования воспроизведения, применяемыми во время воспроизведения. Обратите внимание, что любые данные, замаскированные во время записи, никогда не захватываются и, следовательно, всегда маскируются во время воспроизведения.
* Воспроизведение данных сеанса без маскирования: позволяет воспроизводить записанные сеансы пользователя без применения правил маскирования воспроизведения. Обратите внимание, что любые данные, замаскированные во время записи, всегда маскируются во время воспроизведения.
* Управление проблемами безопасности: позволяет управлять проблемами, о которых сообщает Ключ-АСТРОМ Application Security.
* Управление заявками в службу поддержки: разрешает доступ ко всем заявкам в службу поддержки, созданным для этой среды.

=== Разрешения зоны управления ===
Имена зон управления добавляются к именам среды и отображаются, например, как <code>Env1::mz1</code>, <code>Env1::mz2</code>, <code>Env2::mza</code>, or <code>Env2::mzb</code>. Ключ-АСТРОМ предоставляет следующие разрешения на уровне зоны управления. (Загрузить и установить ЕдиныйАгент и Настроить данные захвата запросов выделены серым цветом, поскольку они не применяются к зонам управления.) Выберите все подходящие варианты:

* Среда доступа: разрешает доступ только для чтения к объектам в зоне управления. Чтобы изменить / отредактировать настройки, вы должны предоставить разрешение на изменение настроек мониторинга.

----<blockquote><big>'''Важно'''</big>

Разрешение среды доступа требуется для любых других разрешений зоны управления, поэтому среда доступа автоматически выбирается для зоны управления при выборе любого другого разрешения зоны управления.

*
</blockquote>
----

* Изменить настройки мониторинга: позволяет изменять настройки зоны управления, например, возможность записывать или редактировать синтетические мониторы.
* Просмотр журналов: разрешает доступ к конфиденциальным данным файла журнала на вкладке «Журналы» для хостов, явно включенных в зону управления. Обратите внимание, что недостаточно предоставить доступ на уровне зоны управления к группам хостов, к которым они принадлежат - подробности см. В Правилах зоны управления.
* Просмотр конфиденциальных данных запроса: позволяет просматривать потенциально личные данные, захваченные Ключ-АСТРОМ, для объектов в зоне управления. Пользователи, у которых нет этого разрешения, видят, что точка данных существует, но личные данные замаскированы звездочками (*****) - см. Также Разрешения среды выше.
* Воспроизведение данных сеанса: позволяет воспроизводить записанные пользовательские сеансы с правилами маскирования воспроизведения, применяемыми во время воспроизведения. Обратите внимание, что любые данные, замаскированные во время записи, никогда не захватываются и, следовательно, всегда маскируются во время воспроизведения.
* Воспроизведение данных сеанса без маскирования: позволяет воспроизводить записанные сеансы пользователя без применения правил маскирования воспроизведения. Обратите внимание, что любые данные, замаскированные во время записи, всегда маскируются во время воспроизведения.

----<blockquote><big>'''Важно'''</big>

Чтобы разрешения на воспроизведение сеанса работали в зоне управления, пользователь также должен иметь доступ к необходимым приложениям.

* Если сеанс пользователя охватывает несколько приложений, не все из которых назначены зоне управления, пользователи по-прежнему могут видеть и воспроизводить сеанс. Однако действия пользователя, связанные с приложением, к которому у вас нет доступа, маскируются, и соответствующая часть воспроизведения не отображается.
* Кнопки воспроизведения неактивны для пользователей, которые имеют доступ к приложениям, но не имеют разрешения на воспроизведение сеансов.

Дополнительные сведения о зонах управления см. В разделе Зоны управления.</blockquote>
----

* Управление проблемами безопасности: позволяет управлять проблемами, о которых сообщает Ключ-АСТРОМ Application Security.

=== Взаимосвязь между средой и разрешениями зоны управления ===
----<blockquote><big>'''Важно'''</big>

Когда вы предоставляете любое разрешение, кроме среды доступа на уровне среды, среда доступа автоматически включается также и для среды. Аналогичным образом, когда вы предоставляете любое разрешение, кроме среды доступа на уровне зоны управления, среда доступа автоматически включается для зоны управления.

*</blockquote>
----Зоны управления предназначены для обеспечения целевого и ограниченного доступа к определенным объектам в среде. Если вы хотите предоставить разрешение пользователям, имеющим доступ к зоне управления, мы рекомендуем использовать разрешения на уровне зоны управления. Любые разрешения, которые вы предоставляете на уровне среды, заменяют разрешения на уровне зоны управления и дополняют их. Другими словами, разрешения зоны управления не могут использоваться для ограничения разрешений, уже предоставленных на уровне среды.

Возьмем, к примеру, зону управления, содержащую три хоста из пяти хостов в среде. Если вы предоставите разрешение «Просмотр журналов» для зоны управления, зрители смогут увидеть вкладку «Журналы» с информацией для трех хостов в зоне управления. Однако, если вы удалите такое же разрешение на уровне зоны управления и предоставите его на уровне среды, пользователи смогут:

* Получите доступ ко всем зонам управления из фильтра зон управления в строке меню.
* См. Вкладку «Журналы» для всех пяти хостов в среде при просмотре «Все зоны управления».
* См. Вкладку «Журналы» для трех хостов в назначенной зоне управления, когда они переключаются на нее.

== Политика IAM ==
Разрешениями пользователей также можно управлять с помощью политик IAM, которые обеспечивают более детальный контроль доступа. С помощью политик вы можете создавать свои собственные разрешения на доступ и назначать их группам пользователей на уровне кластера или среды, как и в случае с механизмом разрешений.

Дополнительные сведения см. в разделе Управление политиками и группами с помощью Ключ-АСТРОМ IAM.

Развертывание АппОптима с учетом стойки

2022-03-15T15:27:40Z

YaPolkin:

В стандартном управляемом развертывании Ключ-АСТРОМ с высокой доступностью вы защищены от потери данных, если:

* один узел выходит из строя при развертывании трех или четырех узлов
* один или два узла выходят из строя при развертывании пяти или более узлов

[[Файл:S-man-cluster-no-data-loss.webp|альт=Малый кластер Managed без потери данных]]

''Небольшие управляемые развертывания Ключ-АСТРОМ допускают отказ одного узла.''

[[Файл:L-man-cluster-no-data-loss.webp|альт=Большой кластер Ключ-АСТРОМ Managed без потери данных]]

''Крупные управляемые развертывания Ключ-АСТРОМ допускают отказ двух узлов.''

Развертывание Ключ-АСТРОМ Managed с поддержкой стойки позволяет сгруппировать узлы кластера в три домена сбоя (т. Е. Стойки). Такое развертывание устойчиво к отключению всех узлов в стойке.
----''<big>Должен ли я использовать распознавание стойки?</big>''

Вы должны использовать функцию распознавания стойки только в следующих случаях:

* Окончательное количество стоек - три, что соответствует коэффициенту репликации хранилища данных Ключ-АСТРОМ.
* Стойки отражают базовое физическое расположение узлов.

В противном случае вы можете потерять данные и иметь проблемы с доступностью кластера.
----

== Развертывание с учетом стойки ==
Развертывание с учетом стойки гарантирует, что никакие реплики не будут храниться с избыточностью внутри единственной стойки, поэтому реплики распространяются по стойкам. В случае отказа одной стойки становятся доступны две другие полные реплики, что обеспечивает согласованность и доступность данных. Например, в приведенном ниже развертывании управляемый кластер Ключ-АСТРОМ может обрабатывать до трех отказов узлов в стойке до потери данных.

[[Файл:L-ra-man-cluster-no-data-loss.webp|альт=Большой кластер Ключ-АСТРОМ Managed с учетом стойки без потери данных]]

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

Та же концепция применима к управляемым развертываниям с высокой доступностью премиум-класса. Использование управляемых кластеров с поддержкой стойки в отдельных центрах обработки данных повышает устойчивость к потере данных.

[[Файл:Man-ha-no-data-loss.webp|альт=Высокая доступность премиум-класса Managed развертывание без потери данных]]

''Премиум высокодоступное Managed развертывание''

[[Файл:Man-ha-ra-no-data-loss.webp|альт=Высокая доступность премиум-класса с поддержкой стойки Managed развертывание без потери данных]]

''Премиум высокодоступное Managed развертывание с учетом стойки''

Для обеспечения максимальной доступности и избыточности используйте развертывание с высокой доступностью Premium с поддержкой стойки.

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

<code>dynatrace-managed.sh --rack-name az-1 --rack-dc datacenter1</code>

== Преобразование в режим с учетом стойки ==
Используйте либо расширение кластера, либо метод восстановления кластера, чтобы преобразовать существующее управляемое развертывание.

=== Расширение кластера (без простоя кластера) ===
Вы можете вертикально масштабировать узлы в двух местах, чтобы они могли выдерживать дополнительную нагрузку, когда вы завершаете третье место и переустанавливаете его с настройками, ориентированными на стойку. См. Раздел «Преобразование с учетом стойки с использованием репликации».
----''<big>Метрический размер хранилища</big>''

Если ваше текущее хранилище метрик (база данных Cassandra) на узел превышает 1 ТБ, используйте метод восстановления кластера. Хотя метод расширения кластера будет работать, загрузка Cassandra, необходимая для этого метода, может занять неоправданно много времени.
----

=== Восстановление кластера (время простоя кластера во время восстановления) ===
Вы можете выполнять резервное копирование и восстановление с настройками с учетом стойки. См. раздел «Преобразование с учетом стойки с использованием восстановления».

Обновление кластерного АктивногоШлюза

2022-03-07T10:47:13Z

YaPolkin:

Чтобы просмотреть список установленных АктивныхШлюзов, выберите '''Статус развертывания''' > '''АктивныеШлюзы''' в меню навигации. Для каждого АктивногоШлюза список показывает текущую '''версию''' АктивногоШлюза и '''статус обновления''' (обновлено до последней версии, ожидается или производится).

[[Файл:Warn-yellow-exclamation-icon.webp|альт=Желтый восклицательный знак предупреждения]]Желтый значок предупреждения указывает на то, что ваш АктивныйШлюз отстает более чем на пять версий. Вам следует как можно скорее обновить эти АктивныеШлюзы.

Чтобы управлять функциями обновления определенного АктивногоШлюза в списке, выберите АктивныйШлюз, чтобы развернуть сведения:

* '''Автоматическое обновление'''

(Ключ-АСТРОМ версии 1.213+) Чтобы использовать функцию автоматического обновления, убедитесь, что переключатель <code>Автоматическое обновление</code> для АктивногоШлюза включен. Это означает, что когда станет доступна новая версия АктивногоШлюза, новый установочный пакет будет загружен на конкретный хост, и будет установлена новая версия АктивногоШлюза. Это установлено по умолчанию для новых сред. Для существующих сред этот параметр остается неизменным.

Проверка доступности выполняется с 30-минутным интервалом.

* '''Обновление в один клик'''

Чтобы выполнить обновление немедленно, выберите <code>Обновить АктивныйШлюз</code>. Эта функция доступна только в том случае, если переключатель <code>Автоматическое обновление</code> отключен для конкретного АктивногоШлюза.

* '''Ручная загрузка и обновление'''

'''Примечание:''' АктивныеШлюзы в контейнерах развертываются и загружаются с помощью облачных инструментов. Например, Kubernetes использует пользовательские определения ресурсов.

Вы также можете загрузить и обновить АктивныйШлюз вручную. Вам не нужно удалять текущую версию АктивногоШлюза. Просто установите новую версию поверх старой, и конфигурация АктивногоШлюза будет перенесена.

* Установите АктивныйШлюз окружения.
* [[Установка кластерного АктивногоШлюза|Установите кластерный АктивныйШлюз]].

Во время обновления ваша конфигурация АктивногоШлюза сохраняется в файлах <code>custom.properties</code> и <code>launcheruserconfig.conf</code>. Эти два файла не будут перезаписаны во время обновления, но рекомендуется сделать их резервную копию перед обновлением АктивногоШлюза.

* См. раздел Настройка АктивногоШлюза для получения информации о свойствах файла <code>custom.properties</code>.
* См. раздел Настройка лаунчера АктивногоШлюза для получения информации о свойствах <code>launcheruserconfig.conf</code>.

== Статус обновления ==
Состояние обновления для АктивногоШлюза, указанное на странице '''Статус развертывания''', может принимать следующие значения:

'''Обновлено до последней версии'''

Последняя доступная версия АктивногоШлюза установлена на соответствующем хосте.

'''Доступно обновление'''

Для этой версии АктивногоШлюза доступно обновление.

'''Ожидается обновление'''

Сразу после выбора '''Обновить АктивныйШлюз''' статус меняется на '''Ожидается обновление''' и остается в этом статусе до начала процесса обновления. Статус также может быть указан как <code>ожидается</code> , если:

* Кластер в настоящее время обновляется.
* Достигнуто максимальное количество одновременных загрузок обновлений, и АктивныйШлюз ожидает возобновления загрузки.

'''Производится обновление'''

АктивныйШлюз запросил и загрузил новый установочный пакет с сервера и в настоящее время находится в процессе его установки или повторного подключения к серверу.

'''Проблема с обновлением'''

В этом случае вы увидите старый номер версии, отображаемый для АктивногоШлюза.

Возможные проблемы:

* АктивныйШлюз загрузил новый установщик, но установка не была предпринята или не была выполнена успешно; следовательно, АктивныйШлюз всё ещё находится в старой версии. Проверьте журналы автообновления АктивногоШлюза и журналы установщика, чтобы выяснить, почему установка не была предпринята или не удалась.
* АктивныйШлюз загрузил новый установщик, но затем не смог повторно подключиться к серверу (был потерян). Проверьте журналы установщика АктивногоШлюза, чтобы выяснить, почему установка не удалась.
* Для АктивногоШлюза нет инсталляторов.
* Обновление приостановлено, поскольку в другой среде возникли проблемы с обновлением предлагаемой версии АктивногоШлюза.

'''Неизвестно'''

Соединение с этим АктивнымШлюзом было потеряно, и статус не может быть определен.

Этот статус также может отображаться, если АктивныйШлюз был успешно удален: в этом случае статус развертывания будет продолжать отображать неустановленный АктивныйШлюз со статусом обновления <code>Неизвестно</code> в течение семи дней.

Механизм аварийного переключения АппОптима

2022-03-07T10:16:37Z

YaPolkin:

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

Для достижения наилучшего отказоустойчивого развертывания мы рекомендуем следующее:

=== Резервирование ===
Запланируйте развертывание минимум трех узлов на кластер. В таких кластерах все узлы автоматически реплицируют данные между узлами, поэтому обычно есть две реплики в дополнение к первичному шарду.
----<blockquote>''<big>Избегайте проблем с синхронизацией split-brain</big>''

Хотя кластеры с двумя узлами технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большей части для согласованности данных, поэтому двухузловой кластер уязвим для split-brain и должен рассматриваться как временное состояние при переходе на три или более узлов. Запуск двух узлов может создать несогласованность доступности или данных из двух отдельных наборов данных (одноузловых кластеров), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.</blockquote>
----Вся конфигурация кластера Ключ-АСТРОМ и его сред (включая все события, пользовательские сеансы и метрики) хранится на каждом узле, поэтому Ключ-АСТРОМ может продолжать работать полностью функционально после потери узла:

* Кластер с тремя узлами может пережить потерю одного узла
* Кластер с пятью или более узлами может пережить потерю до двух узлов. Задержка между узлами должна составлять около 10 мс или меньше.

Данные событий Log Monitoring v2 реплицируются в хранилище Elasticsearch для достижения высокой доступности и оптимизации затрат хранилища. В результате, если узел выходит из строя, Ключ-АСТРОМ сохраняет резервную копию на другом узле. Однако отказ двух узлов делает некоторые события журнала недоступными. Если узлы вернутся, данные снова будут доступны. В противном случае данные будут потеряны.

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

Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом из них. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о метриках и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.

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

См. Высокая доступность для нескольких центров обработки данных.

=== Аппаратное обеспечение ===
Чтобы предотвратить потерю данных мониторинга, разверните каждый узел на отдельном физическом диске. Чтобы свести к минимуму потерю производительности, развертывайте узлы в системах с одинаковыми характеристиками оборудования. В случае аппаратного сбоя затрагиваются только данные на отказавшей машине; нет потери данных мониторинга, потому что все узлы реплицируют данные мониторинга. Потеря производительности сведена к минимуму, поскольку все узлы работают на одном и том же типе оборудования с равномерно распределенной рабочей нагрузкой.

=== Мощность обработки ===
Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование.
----Если узел выходит из строя, NGINX, который балансирует нагрузку в системе, автоматически перенаправляет весь трафик ЕдиногоАгента на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла.

Требования АппОптима к оборудованию

2022-03-07T10:14:42Z

YaPolkin:

В этом разделе описывается оборудование для установки Ключ-АСТРОМ Managed. Другие требования Ключ-АСТРОМ Managed см. в разделах [[Требования Managed к системе]] и Рекомендации по оборудованию для облачных развертываний Managed.
----<blockquote><big>''Соображения по размеру''</big>

Калибровка обычно состоит из следующих элементов:

* Генеральная планировка
* Требования к оборудованию
* Рекомендации по хранилищу
* Рекомендации по Log Monitoring 2.0

Обязательно изучите каждый элемент, прежде чем продолжить.</blockquote>
----

== Генеральная планировка ==
Не всегда возможно подготовить узлы с точным размером, особенно если ваша среда подвержена постоянно растущим уровням трафика. Хотя предварительный анализ необходимого размера полезен, важнее иметь возможность увеличить емкость кластера Ключ-АСТРОМ Managed, если в будущем потребности мониторинга возрастут. Чтобы воспользоваться всеми преимуществами архитектуры Ключ-АСТРОМ Managed, будьте готовы к масштабированию по следующим параметрам:

* По горизонтали, добавив больше узлов. Мы поддерживаем установку до 30 узлов кластера.
* По вертикали за счет выделения большего количества ОЗУ/ЦП на узел.
* Что касается хранения данных, то есть возможность изменять размер дисковых томов по мере необходимости (рекомендации по настройке дисков смотрите ниже).

Для облачных развертываний используйте рекомендованные эквиваленты виртуальных машин для Рекомендаций по оборудованию для облачных развертываний Managed

== Требования к оборудованию ==
Требования к оборудованию, приведенные в следующей таблице, являются приблизительными, основанными на типичных средах и схемах нагрузки. Требования для отдельных сред могут отличаться. При оценке конкретных столбцов учитывается следующее:

* '''Минимальные спецификации узла'''
** ЦП и ОЗУ должны быть доступны исключительно для Ключ-АСТРОМ. Режим энергосбережения для ЦП должен быть отключен. Процессоры должны работать с тактовой частотой не менее 2 ГГц, а хосту должно быть назначено не менее 32 ГБ ОЗУ.

* '''Хранилище транзакций'''
** Данные транзакций распределяются по всем узлам и не хранятся избыточно. В кластерах с несколькими узлами хранилище данных транзакций делится на количество узлов.

* '''Хранилище долгосрочных метрик'''
** Для многоузловых установок сохраняются три копии хранилища метрик. Для четырех или более узлов требования к хранилищу на каждый узел снижаются.
**Требование 4 ТБ для узла XБольшой следует рассматривать как максимально допустимый размер. Если вам нужна дополнительная емкость, подумайте о добавлении ещё одного узла. Планируйте свое хранилище долгосрочных метрик так, чтобы данные занимали не более 50% доступного дискового пространства. Таким образом, 4 ТБ пространства будут обрабатывать 2 ТБ данных вашего долгосрочного хранилища метрик. Хотя возможны хранилища размером более 4 ТБ, они могут затруднить обслуживание базы данных.

=== Ключ-АСТРОМ Managed ===
{| class="wikitable"
!Тип узла
!Макс. хостов

под наблюдением

(на узел)
!Пиковое количество пользовательских

действий/мин

(на узел)
!'''Минимальные спецификации узла'''
!Диск IOPS

(на узел)
!'''Хранилище'''
транзакций

(видимость кода 10 дней)
!'''Хранилище долгосрочных'''
'''метрик'''

(на узел)
!Elasticsearch

(на узел)

(Срок хранения 35 дней)
|-
|Микро
|50
|1000
|4 виртуальных ЦП,
32 ГБ ОЗУ
|500
|50 ГБ
|100 ГБ
|50 ГБ
|-
|Небольшой
|300
|10000
|8 виртуальных ЦП,
64 ГБ ОЗУ
|3000
|300 ГБ
|500 ГБ
|500 ГБ
|-
|Средний
|600
|25000
|16 виртуальных ЦП,
128 ГБ ОЗУ
|5000
|600 ГБ
|1 ТБ
|1.5 ТБ
|-
|Большой
|1250
|50000
|32 виртуальных ЦП,
256 ГБ ОЗУ
|7500
|1 ТБ
|2 ТБ
|1.5 ТБ
|-
|XБольшой1
|2500
|100000
|64 виртуальных ЦП,
512 ГБ ОЗУ
|10000
|2 ТБ
|4 ТБ
|3 ТБ
|}
1 Хотя Ключ-АСТРОМ Managed устойчиво работает на экземплярах с 1+ ТБ ОЗУ/128 ядрами (2XБольшой) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Большой или XБольшой).

==== Примеры ====

* Чтобы мониторить до 7500 хостов с пиковой нагрузкой 300 000 действий пользователя в минуту, вам понадобятся 3 очень больших (XБольшой) узла с объемом хранилища 9 ТБ каждый, разделенным на типы хранилищ.
* Для мониторинга 500 хостов с пиковой нагрузкой 30 000 действий пользователя в минуту вам потребуется 3 небольших узла с объемом хранилища 1,3 ТБ каждый, разделенным на типы хранилищ соответственно. В качестве альтернативы вы также можете использовать 1 средний узел с объемом хранилища 2,1 ТБ. Мы рекомендуем настроить аварийное переключение минимум на 3 узла вместо одиночных узлов, которые менее устойчивы.

=== Ключ-АСТРОМ Managed Премиум высокой доступности ===
{| class="wikitable"
!Тип узла
!Макс хостов

под наблюдением

(на узел)
!Максимальный пользователь

действий / мин

(на узел)
!Мин узел

технические характеристики
!Диск IOPS

(на узел)
!Хранение транзакций

(Видимость кода 10 дней)
!Долгосрочное

Магазин метрик

(на узел)
!Elasticsearch

(на узел)

(Срок хранения 35 дней)
|-
|Большой
|600
|25000
|32 виртуальных ЦП,
256 ГБ ОЗУ
|7500
|1 ТБ
|2 ТБ
|1.5 ТБ
|-
|XБольшой1
|1250
|50000
|64 виртуальных ЦП,
512 ГБ ОЗУ
|10000
|2 ТБ
|4 ТБ
|3 ТБ
|}
1 Хотя Ключ-АСТРОМ Managed устойчиво работает на экземплярах с 1+ ТБ ОЗУ/128 ядрами (2XБольшой) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Большой или XБольшой).

==== Пример ====
Для мониторинга 7500 хостов с пиковой нагрузкой 300 000 действий пользователя в минуту в развертывании Премиум высокой доступности вам потребуется 6 очень больших (XБольшой) узлов - 3 узла в одном центре обработки данных и 3 узла во втором центре обработки данных, каждый узел с хранилищем 9 ТБ, разделенным соответственно на типы хранилищ.

== Рекомендации по хранилищу ==
Ключ-АСТРОМ Managed хранит несколько типов данных мониторинга в зависимости от варианта использования.

Мы рекомендуем:

* Хранение двоичных файлов Ключ-АСТРОМ и хранилища данных в отдельных точках монтирования, что позволяет изменять размер хранилища данных независимо.
* Не хранить данные Ключ-АСТРОМ в корневом томе, чтобы избежать дополнительных сложностей при изменении размера диска позже, если это потребуется.
* Монтирование различных типов хранилищ данных на отдельных дисковых томах для максимальной гибкости и производительности.
* Создание разделов диска с изменяемым размером (например, с помощью менеджера логических томов [LVM]).

==== Пути к каталогам по умолчанию и необходимое свободное место на диске для установки и обновления ====
Пути к каталогам, включенные в следующую таблицу, являются путями по умолчанию. Фактические пути могут отличаться, если вы установили в собственный каталог.
----<big>'''''Пользовательские каталоги'''''</big>

Если вы настроили места хранения, <code>SERVER_DATASTORE_PATH</code>, <code>CASSANDRA_DATASTORE_PATH</code>, <code>ELASTICSEARCH_DATASTORE_PATH</code> следует поместить в отдельные каталоги, и они не должны быть подкаталогами другого каталога.
----
{| class="wikitable"
!Символ каталога
!Путь к каталогу
!Описание
!Необходимое

свободное

место на диске

для установки
!Необходимое

свободное

место на диске

для обновления
|-
|PRODUCT_PATH
|<code>/opt/dynatrace-managed</code>
|Главный каталог для двоичных файлов Ключ-АСТРОМ Managed
|7 ГБ
|5 ГБ
|-
|DATASTORE_PATH
|<code>/var/opt/dynatrace-managed</code>
|Главный каталог для данных Ключ-АСТРОМ Managed
|24 ГБ
|3 ГБ
|-
|LOG_PATH
|<code>DATASTORE_PATH/log</code>
|Журналы всех компонентов, сервисов и инструментов Ключ-АСТРОМ Managed
|2 ГБ
|1 ГБ
|-
|CASSANDRA_DATASTORE_PATH
|<code>DATASTORE_PATH/cassandra</code>
|Репозиторий метрик
|25 ГБ
|1 ГБ
|-
|ELASTICSEARCH_DATASTORE_PATH
|<code>DATASTORE_PATH/elasticsearch</code>
|Хранилище Elasticsearch
|3 ГБ
|1 ГБ
|-
|SERVER_DATASTORE_PATH
|<code>DATASTORE_PATH/server/tenantData</code>
|Хранилище транзакций
|14 ГБ
|1 ГБ
|-
|SERVER_REPLAY_DATASTORE_PATH
|<code>DATASTORE_PATH/server/replayData</code>
|Хранилище повторов сессий
|14 ГБ
|1 ГБ
|-
|AGENT_BUILD_UNITS_PATH
|<code>DATASTORE_PATH/agents</code>
|Установочные пакеты ЕдиногоАгента и АктивногоШлюза (если они загружены сервером Ключ-АСТРОМ или установлены из отдельных пакетов)
|20 ГБ
|1 ГБ
|-
|SERVER_BUILD_UNITS_PATH
|<code>DATASTORE_PATH/installer</code>
|Установщик Ключ-АСТРОМ Managed для добавления узлов в кластер, подготовленный во время установки/обновления
|2 ГБ
|1 ГБ
|-
|SELFMON_AGENT_INSTALL_PATH

Также см. Дисковое пространство для ЕдиногоАгента
|<code>/opt/dynatrace</code>
|Главный каталог для самоконтроля двоичных файлов ЕдиногоАгента.
|4.8 ГБ
|1.4 ГБ
|}
----<blockquote><big>''ЕдиныйАгент opt-out''</big>

Самоконтроль ЕдиногоАгента включен по умолчанию. Доступен установочный параметр opt-out:

<code>--install-agent <on|off></code></blockquote>
----

=== Поддерживаемые файловые системы ===
Ключ-АСТРОМ Managed работает со всеми распространенными файловыми системами. Мы рекомендуем вам выбрать быстрое локальное хранилище, подходящее для рабочих нагрузок базы данных. Удаленные тома с высокой задержкой, такие как NFS или CIFS, не рекомендуются. Хотя файловых систем NFS достаточно для резервного копирования, мы не рекомендуем их в качестве основного хранилища.
----<blockquote><big>''Amazon Elastic File System''</big>

Мы не поддерживаем и не рекомендуем Amazon Elastic File System (EFS) в качестве основного хранилища для Elasticsearch. Такие файловые системы не обеспечивают поведение, требуемое Elasticsearch, и это может привести к повреждению индексов.</blockquote>
----

== Рекомендации по Log Monitoring v2 ==
Требования для Log Monitoring v2:

* Все узлы кластера должны иметь не менее 64 ГБ ОЗУ общей памяти хоста.

Дополнительные рекомендации по установке:

* Для более надежной конфигурации лучше добавить больше узлов кластера, чем увеличивать оборудование на каждом узле.
* Распределите дополнительное хранилище Elasticsearch поровну между узлами кластера.
* Добавьте ЦП и ОЗУ к существующим узлам кластера, чтобы узлы оставались одинакового размера.
*Используйте REST API (Обновление событий журнала для каждого кластера для Log Monitoring), чтобы обновить предел загрузки кластера на основе доступных ресурсов для кластера.
* Для каждых ста миллионов (100 000 000) событий журнала в день (70 000 событий в минуту в среднем и 140 000 событий в минуту во время пиков) в вашем кластере добавьте дополнительные ресурсы, '''распределенные по всем узлам кластера''':
** 5 ядер ЦП
** Диск емкостью 3,3 ТБ (содержит реплики данных для высокой доступности)

Например, для обработки трехсот миллионов (300 000 000) событий журнала в день вам потребуются дополнительные 15 ЦП, 9,9 ТБ диска и 19,5 ГБ ОЗУ. В существующем кластере из трех узлов среднего размера вы можете выполнить одно из следующих действий:

* [рекомендуется] Добавить два дополнительных узла среднего размера, чтобы сформировать кластер из пяти узлов. Кроме того, увеличьте хранилище Elasticsearh на каждом узле на 2 ТБ (в этом случае каждый узел хранит 40% дважды реплицированных данных).

* Добавьте 3,3 ТБ дискового хранилища (включая репликацию), 8 ЦП и 16 ГБ ОЗУ на каждый узел.

'''Примечание:'''

* Эти рекомендации дополняют любые требования от других источников трафика.
* События журнала хранятся в хранилище Elasticsearch.
* События журнала хранятся в 2 экземплярах.
* Имейте в виду, что время хранения событий журнала составляет 35 дней.

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

* Иметь такую же конфигурацию оборудования
* Быть синхронизированным с NTP
* Быть в том же часовом поясе
* Уметь общаться через частную сеть на [[Порты ноды кластера|нескольких портах]]
* Задержка между узлами должна быть около 10 мс или меньше.
* Системные пользователи, созданные для Ключ-АСТРОМ Managed, должны иметь одинаковые идентификаторы UID:GID на всех узлах.

----<blockquote><big>''Избегайте проблем с синхронизацией split-brain''</big>

Хотя кластеры из двух узлов технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большинства для согласованности данных. Вот почему двухузловой кластер уязвим для проблемы split-brain и должен рассматриваться как временное состояние при переходе на 3 или более узлов. Запуск двух узлов может привести к несогласованности доступности или данных из двух отдельных наборов данных (кластеры с одним узлом), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.</blockquote>
----

Механизм аварийного переключения АппОптима

2022-03-07T07:27:10Z

YaPolkin:

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

Для достижения наилучшего отказоустойчивого развертывания мы рекомендуем следующее:

=== Резервирование ===
Запланируйте развертывание минимум трех узлов на кластер. В таких кластерах все узлы автоматически реплицируют данные между узлами, поэтому обычно есть две реплики в дополнение к первичному шарду.
----''<big>Избегайте проблем с синхронизацией split-brain</big>''

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

* Кластер с тремя узлами может пережить потерю одного узла
* Кластер с пятью или более узлами может пережить потерю до двух узлов. Задержка между узлами должна составлять около 10 мс или меньше.

Данные событий Log Monitoring v2 реплицируются в хранилище Elasticsearch для достижения высокой доступности и оптимизации затрат хранилища. В результате, если узел выходит из строя, Ключ-АСТРОМ сохраняет резервную копию на другом узле. Однако отказ двух узлов делает некоторые события журнала недоступными. Если узлы вернутся, данные снова будут доступны. В противном случае данные будут потеряны.

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

Если вы планируете размещать узлы в отдельных центрах обработки данных, не следует развертывать более двух узлов в каждом из них. Таким образом, коэффициент репликации, равный трем, гарантирует, что в каждом центре обработки данных будут все данные о метриках и событиях. Кроме того, для бесперебойной работы вам потребуется как минимум три центра обработки данных, один из которых может выйти из строя.

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

См. Высокая доступность для нескольких центров обработки данных.

=== Аппаратное обеспечение ===
Чтобы предотвратить потерю данных мониторинга, разверните каждый узел на отдельном физическом диске. Чтобы свести к минимуму потерю производительности, развертывайте узлы в системах с одинаковыми характеристиками оборудования. В случае аппаратного сбоя затрагиваются только данные на отказавшей машине; нет потери данных мониторинга, потому что все узлы реплицируют данные мониторинга. Потеря производительности сведена к минимуму, поскольку все узлы работают на одном и том же типе оборудования с равномерно распределенной рабочей нагрузкой.

=== Мощность обработки ===
Постройте свой кластер с учетом дополнительной емкости и возможного отказа узла. Кластеры, которые работают на 100% своей вычислительной мощности, не имеют вычислительной мощности для компенсации потерянного узла и, таким образом, подвержены отбрасыванию данных в случае отказа узла. Развертывания, запланированные на случай отказа узлов, должны иметь вычислительную мощность на треть выше, чем их типичное использование.
----Если узел выходит из строя, NGINX, который балансирует нагрузку в системе, автоматически перенаправляет весь трафик ЕдиногоАгента на оставшиеся рабочие узлы, и нет необходимости в каких-либо действиях пользователя, кроме замены отказавшего узла.

Требования АппОптима к оборудованию

2022-03-07T06:56:53Z

YaPolkin:

В этом разделе описывается оборудование для установки Ключ-АСТРОМ Managed. Другие требования Ключ-АСТРОМ Managed см. в разделах [[Требования Managed к системе]] и Рекомендации по оборудованию для облачных развертываний Managed.
----<big>''Соображения по размеру''</big>

Калибровка обычно состоит из следующих элементов:

* Генеральная планировка
* Требования к оборудованию
* Рекомендации по хранилищу
* Рекомендации по Log Monitoring 2.0

Обязательно изучите каждый элемент, прежде чем продолжить.
----

== Генеральная планировка ==
Не всегда возможно подготовить узлы с точным размером, особенно если ваша среда подвержена постоянно растущим уровням трафика. Хотя предварительный анализ необходимого размера полезен, важнее иметь возможность увеличить емкость кластера Ключ-АСТРОМ Managed, если в будущем потребности мониторинга возрастут. Чтобы воспользоваться всеми преимуществами архитектуры Ключ-АСТРОМ Managed, будьте готовы к масштабированию по следующим параметрам:

* По горизонтали, добавив больше узлов. Мы поддерживаем установку до 30 узлов кластера.
* По вертикали за счет выделения большего количества ОЗУ/ЦП на узел.
* Что касается хранения данных, то есть возможность изменять размер дисковых томов по мере необходимости (рекомендации по настройке дисков смотрите ниже).

Для облачных развертываний используйте рекомендованные эквиваленты виртуальных машин для Рекомендаций по оборудованию для облачных развертываний Managed

== Требования к оборудованию ==
Требования к оборудованию, приведенные в следующей таблице, являются приблизительными, основанными на типичных средах и схемах нагрузки. Требования для отдельных сред могут отличаться. При оценке конкретных столбцов учитывается следующее:

* '''Минимальные спецификации узла'''
** ЦП и ОЗУ должны быть доступны исключительно для Ключ-АСТРОМ. Режим энергосбережения для ЦП должен быть отключен. Процессоры должны работать с тактовой частотой не менее 2 ГГц, а хосту должно быть назначено не менее 32 ГБ ОЗУ.

* '''Хранилище транзакций'''
** Данные транзакций распределяются по всем узлам и не хранятся избыточно. В кластерах с несколькими узлами хранилище данных транзакций делится на количество узлов.

* '''Хранилище долгосрочных метрик'''
** Для многоузловых установок сохраняются три копии хранилища метрик. Для четырех или более узлов требования к хранилищу на каждый узел снижаются.
**Требование 4 ТБ для узла XБольшой следует рассматривать как максимально допустимый размер. Если вам нужна дополнительная емкость, подумайте о добавлении ещё одного узла. Планируйте свое хранилище долгосрочных метрик так, чтобы данные занимали не более 50% доступного дискового пространства. Таким образом, 4 ТБ пространства будут обрабатывать 2 ТБ данных вашего долгосрочного хранилища метрик. Хотя возможны хранилища размером более 4 ТБ, они могут затруднить обслуживание базы данных.

=== Ключ-АСТРОМ Managed ===
{| class="wikitable"
!Тип узла
!Макс. хостов

под наблюдением

(на узел)
!Пиковое количество пользовательских

действий/мин

(на узел)
!'''Минимальные спецификации узла'''
!Диск IOPS

(на узел)
!'''Хранилище'''
транзакций

(видимость кода 10 дней)
!'''Хранилище долгосрочных'''
'''метрик'''

(на узел)
!Elasticsearch

(на узел)

(Срок хранения 35 дней)
|-
|Микро
|50
|1000
|4 виртуальных ЦП,
32 ГБ ОЗУ
|500
|50 ГБ
|100 ГБ
|50 ГБ
|-
|Небольшой
|300
|10000
|8 виртуальных ЦП,
64 ГБ ОЗУ
|3000
|300 ГБ
|500 ГБ
|500 ГБ
|-
|Средний
|600
|25000
|16 виртуальных ЦП,
128 ГБ ОЗУ
|5000
|600 ГБ
|1 ТБ
|1.5 ТБ
|-
|Большой
|1250
|50000
|32 виртуальных ЦП,
256 ГБ ОЗУ
|7500
|1 ТБ
|2 ТБ
|1.5 ТБ
|-
|XБольшой1
|2500
|100000
|64 виртуальных ЦП,
512 ГБ ОЗУ
|10000
|2 ТБ
|4 ТБ
|3 ТБ
|}
1 Хотя Ключ-АСТРОМ Managed устойчиво работает на экземплярах с 1+ ТБ ОЗУ/128 ядрами (2XБольшой) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Большой или XБольшой).

==== Примеры ====

* Чтобы мониторить до 7500 хостов с пиковой нагрузкой 300 000 действий пользователя в минуту, вам понадобятся 3 очень больших (XБольшой) узла с объемом хранилища 9 ТБ каждый, разделенным на типы хранилищ.
* Для мониторинга 500 хостов с пиковой нагрузкой 30 000 действий пользователя в минуту вам потребуется 3 небольших узла с объемом хранилища 1,3 ТБ каждый, разделенным на типы хранилищ соответственно. В качестве альтернативы вы также можете использовать 1 средний узел с объемом хранилища 2,1 ТБ. Мы рекомендуем настроить аварийное переключение минимум на 3 узла вместо одиночных узлов, которые менее устойчивы.

=== Ключ-АСТРОМ Managed Премиум высокой доступности ===
{| class="wikitable"
!Тип узла
!Макс хостов

под наблюдением

(на узел)
!Максимальный пользователь

действий / мин

(на узел)
!Мин узел

технические характеристики
!Диск IOPS

(на узел)
!Хранение транзакций

(Видимость кода 10 дней)
!Долгосрочное

Магазин метрик

(на узел)
!Elasticsearch

(на узел)

(Срок хранения 35 дней)
|-
|Большой
|600
|25000
|32 виртуальных ЦП,
256 ГБ ОЗУ
|7500
|1 ТБ
|2 ТБ
|1.5 ТБ
|-
|XБольшой1
|1250
|50000
|64 виртуальных ЦП,
512 ГБ ОЗУ
|10000
|2 ТБ
|4 ТБ
|3 ТБ
|}
1 Хотя Ключ-АСТРОМ Managed устойчиво работает на экземплярах с 1+ ТБ ОЗУ/128 ядрами (2XБольшой) и позволяет отслеживать больше объектов, это не оптимальный способ использования оборудования. Вместо этого мы рекомендуем использовать экземпляры меньшего размера (Большой или XБольшой).

==== Пример ====
Для мониторинга 7500 хостов с пиковой нагрузкой 300 000 действий пользователя в минуту в развертывании Премиум высокой доступности вам потребуется 6 очень больших (XБольшой) узлов - 3 узла в одном центре обработки данных и 3 узла во втором центре обработки данных, каждый узел с хранилищем 9 ТБ, разделенным соответственно на типы хранилищ.

== Рекомендации по хранилищу ==
Ключ-АСТРОМ Managed хранит несколько типов данных мониторинга в зависимости от варианта использования.

Мы рекомендуем:

* Хранение двоичных файлов Ключ-АСТРОМ и хранилища данных в отдельных точках монтирования, что позволяет изменять размер хранилища данных независимо.
* Не хранить данные Ключ-АСТРОМ в корневом томе, чтобы избежать дополнительных сложностей при изменении размера диска позже, если это потребуется.
* Монтирование различных типов хранилищ данных на отдельных дисковых томах для максимальной гибкости и производительности.
* Создание разделов диска с изменяемым размером (например, с помощью менеджера логических томов [LVM]).

==== Пути к каталогам по умолчанию и необходимое свободное место на диске для установки и обновления ====
Пути к каталогам, включенные в следующую таблицу, являются путями по умолчанию. Фактические пути могут отличаться, если вы установили в собственный каталог.
----<big>'''''Пользовательские каталоги'''''</big>

Если вы настроили места хранения, <code>SERVER_DATASTORE_PATH</code>, <code>CASSANDRA_DATASTORE_PATH</code>, <code>ELASTICSEARCH_DATASTORE_PATH</code> следует поместить в отдельные каталоги, и они не должны быть подкаталогами другого каталога.
----
{| class="wikitable"
!Символ каталога
!Путь к каталогу
!Описание
!Необходимое

свободное

место на диске

для установки
!Необходимое

свободное

место на диске

для обновления
|-
|PRODUCT_PATH
|<code>/opt/dynatrace-managed</code>
|Главный каталог для двоичных файлов Ключ-АСТРОМ Managed
|7 ГБ
|5 ГБ
|-
|DATASTORE_PATH
|<code>/var/opt/dynatrace-managed</code>
|Главный каталог для данных Ключ-АСТРОМ Managed
|24 ГБ
|3 ГБ
|-
|LOG_PATH
|<code>DATASTORE_PATH/log</code>
|Журналы всех компонентов, сервисов и инструментов Ключ-АСТРОМ Managed
|2 ГБ
|1 ГБ
|-
|CASSANDRA_DATASTORE_PATH
|<code>DATASTORE_PATH/cassandra</code>
|Репозиторий метрик
|25 ГБ
|1 ГБ
|-
|ELASTICSEARCH_DATASTORE_PATH
|<code>DATASTORE_PATH/elasticsearch</code>
|Хранилище Elasticsearch
|3 ГБ
|1 ГБ
|-
|SERVER_DATASTORE_PATH
|<code>DATASTORE_PATH/server/tenantData</code>
|Хранилище транзакций
|14 ГБ
|1 ГБ
|-
|SERVER_REPLAY_DATASTORE_PATH
|<code>DATASTORE_PATH/server/replayData</code>
|Хранилище повторов сессий
|14 ГБ
|1 ГБ
|-
|AGENT_BUILD_UNITS_PATH
|<code>DATASTORE_PATH/agents</code>
|Установочные пакеты ЕдиногоАгента и АктивногоШлюза (если они загружены сервером Ключ-АСТРОМ или установлены из отдельных пакетов)
|20 ГБ
|1 ГБ
|-
|SERVER_BUILD_UNITS_PATH
|<code>DATASTORE_PATH/installer</code>
|Установщик Ключ-АСТРОМ Managed для добавления узлов в кластер, подготовленный во время установки/обновления
|2 ГБ
|1 ГБ
|-
|SELFMON_AGENT_INSTALL_PATH

Также см. Дисковое пространство для ЕдиногоАгента
|<code>/opt/dynatrace</code>
|Главный каталог для самоконтроля двоичных файлов ЕдиногоАгента.
|4.8 ГБ
|1.4 ГБ
|}
----<big>''ЕдиныйАгент opt-out''</big>

Самоконтроль ЕдиногоАгента включен по умолчанию. Доступен установочный параметр opt-out:

<code>--install-agent <on|off></code>
----

=== Поддерживаемые файловые системы ===
Ключ-АСТРОМ Managed работает со всеми распространенными файловыми системами. Мы рекомендуем вам выбрать быстрое локальное хранилище, подходящее для рабочих нагрузок базы данных. Удаленные тома с высокой задержкой, такие как NFS или CIFS, не рекомендуются. Хотя файловых систем NFS достаточно для резервного копирования, мы не рекомендуем их в качестве основного хранилища.
----<big>''Amazon Elastic File System''</big>

Мы не поддерживаем и не рекомендуем Amazon Elastic File System (EFS) в качестве основного хранилища для Elasticsearch. Такие файловые системы не обеспечивают поведение, требуемое Elasticsearch, и это может привести к повреждению индексов.
----

== Рекомендации по Log Monitoring v2 ==
Требования для Log Monitoring v2:

* Все узлы кластера должны иметь не менее 64 ГБ ОЗУ общей памяти хоста.

Дополнительные рекомендации по установке:

* Для более надежной конфигурации лучше добавить больше узлов кластера, чем увеличивать оборудование на каждом узле.
* Распределите дополнительное хранилище Elasticsearch поровну между узлами кластера.
* Добавьте ЦП и ОЗУ к существующим узлам кластера, чтобы узлы оставались одинакового размера.
*Используйте REST API (Обновление событий журнала для каждого кластера для Log Monitoring), чтобы обновить предел загрузки кластера на основе доступных ресурсов для кластера.
* Для каждых ста миллионов (100 000 000) событий журнала в день (70 000 событий в минуту в среднем и 140 000 событий в минуту во время пиков) в вашем кластере добавьте дополнительные ресурсы, '''распределенные по всем узлам кластера''':
** 5 ядер ЦП
** Диск емкостью 3,3 ТБ (содержит реплики данных для высокой доступности)

Например, для обработки трехсот миллионов (300 000 000) событий журнала в день вам потребуются дополнительные 15 ЦП, 9,9 ТБ диска и 19,5 ГБ ОЗУ. В существующем кластере из трех узлов среднего размера вы можете выполнить одно из следующих действий:

* [рекомендуется] Добавить два дополнительных узла среднего размера, чтобы сформировать кластер из пяти узлов. Кроме того, увеличьте хранилище Elasticsearh на каждом узле на 2 ТБ (в этом случае каждый узел хранит 40% дважды реплицированных данных).

* Добавьте 3,3 ТБ дискового хранилища (включая репликацию), 8 ЦП и 16 ГБ ОЗУ на каждый узел.

'''Примечание:'''

* Эти рекомендации дополняют любые требования от других источников трафика.
* События журнала хранятся в хранилище Elasticsearch.
* События журнала хранятся в 2 экземплярах.
* Имейте в виду, что время хранения событий журнала составляет 35 дней.

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

* Иметь такую же конфигурацию оборудования
* Быть синхронизированным с NTP
* Быть в том же часовом поясе
* Уметь общаться через частную сеть на [[Порты ноды кластера|нескольких портах]]
* Задержка между узлами должна быть около 10 мс или меньше.
* Системные пользователи, созданные для Ключ-АСТРОМ Managed, должны иметь одинаковые идентификаторы UID:GID на всех узлах.

----<big>''Избегайте проблем с синхронизацией split-brain''</big>

Хотя кластеры из двух узлов технически возможны, мы не рекомендуем этого делать. Наши системы хранения основаны на консенсусе и требуют большинства для согласованности данных. Вот почему двухузловой кластер уязвим для проблемы split-brain и должен рассматриваться как временное состояние при переходе на 3 или более узлов. Запуск двух узлов может привести к несогласованности доступности или данных из двух отдельных наборов данных (кластеры с одним узлом), которые перекрываются и не обмениваются данными и не синхронизируют свои данные друг с другом.
----

Требования АппОптима к системе

2022-03-07T05:14:51Z

YaPolkin:

В этом разделе объясняются требования к операционной системе для установки Ключ-АСТРОМ Managed. Другие требования Ключ-АСТРОМ Managed см. в разделе [[Требования Managed к оборудованию]].

* Вам понадобится выделенный хост для установки Ключ-АСТРОМ Managed. На этом хосте не должны запускаться другие службы, интенсивно использующие ЦП или память, или открывающие [[Порты ноды кластера|порты, используемые Ключ-АСТРОМ Managed]].
* Вам нужен '''64-битный''' дистрибутив Linux (см. поддерживаемые дистрибутивы Linux ниже). Обратите внимание, что поддерживается установка как на физических, так и на виртуальных хостах, но установка в контейнерах не поддерживается.
* Сервер Ключ-АСТРОМ требует фиксированного IP-адреса.
* Убедитесь, что вы правильно настроили [[Порты ноды кластера|параметры брандмауэра]].
* Библиотеки, устанавливаемые вместе с Ключ-АСТРОМ Managed, учитывают региональные стандарты. Для правильного отображения текста и символов не забудьте установить языковой стандарт системы вашей среды на английский (например, <code>LANG = en_US.UTF-8</code>).

== Поддерживаемые операционные системы ==
{| class="wikitable"
!Дистрибутив Linux
!Версии
!Архитектура процессора
|-
|Amazon Linux 2
|все версии
|x86-64
|-
|Amazon Linux AMI
|2018.x
|x86-64
|-
|CentOS
|7.9
|x86-64
|-
|CentOS Stream
|8
|x86-64
|-
|Debian
|9, 10
|x86-64
|-
|Oracle Linux
|7.9, 8.4
|x86-64
|-
|Red Hat Enterprise Linux
|7.9, 8.4
|x86-64
|-
|SUSE Enterprise Linux
|11.4, 12.3, 12.4, 12.5, 15.0, 15.1, 15.2, 15.3
|x86-64
|-
|Ubuntu
|16.04 LTS, 18.04 LTS, 20.04 LTS
|x86-64
|}

== Изменение поддержки ==

=== Текущие изменения поддержки операционных систем Ключ-АСТРОМ Managed ===

===== Следующие операционные системы больше не будут поддерживаться с 1 мая 2022 г. =====
* Linux: CentOS 7.6, 8.1
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.232
* Linux: Red Hat Enterprise Linux 7.6, 8.1
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.232
* Linux: Oracle Linux 7.6, 8.1
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.232

===== Следующие операционные системы больше не будут поддерживаться с 1 июня 2022 г. =====
* Linux: Ubuntu 20.10
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.234

=== Будущие изменения поддержки операционных систем Ключ-АСТРОМ Managed ===

===== Следующие операционные системы больше не будут поддерживаться с 1 августа 2022 г. =====

* Linux: CentOS 7.7
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.238
* Linux: Red Hat Enterprise Linux 7.7
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.238
* Linux: Oracle Linux 7.7
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.238

===== Следующие операционные системы больше не будут поддерживаться с 1 октября 2022 г. =====

* Linux: SUSE Enterprise Linux 11.4
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2022 г. =====

* Linux: Ubuntu 21.04
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.244

===== Следующие операционные системы больше не будут поддерживаться с 1 января 2023 г. =====

* Linux: Debian 9
** x86 (только 64 бит)
** [https://wiki.debian.org/DebianReleases Объявление производителя]
* Linux: SUSE Enterprise Linux 12.3
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 марта 2023 г. =====

* Linux: CentOS 8.2
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.252
* Linux: Red Hat Enterprise Linux 8.2
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.252
* Linux: Oracle Linux 8.2
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.252

===== Следующие операционные системы больше не будут поддерживаться с 1 июля 2023 г. =====

* Linux: SUSE Enterprise Linux 15.0
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 января 2024 г. =====

* Linux: SUSE Enterprise Linux 12.4
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 августа 2024 г. =====

* Linux: SUSE Enterprise Linux 15.1
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2024 г. =====

* Linux: Ubuntu 16.04 LTS
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 декабря 2024 г. =====

* Linux: CentOS Stream 8
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 января 2025 г. =====

* Linux: Debian 10
** x86 (только 64 бит)
** [https://wiki.debian.org/DebianReleases Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 мая 2028 г. =====

* Linux: SUSE Enterprise Linux 12.5
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2028 г. =====

* Linux: Ubuntu 18.04 LTS
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2030 г. =====

* Linux: Ubuntu 20.04 LTS
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]

=== Прошлые изменения поддержки операционных систем Ключ-АСТРОМ Managed ===

===== Следующие операционные системы больше не поддерживаются с 1 декабря 2020 г. =====
* Linux: SUSE Enterprise Linux 12.1
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.208

===== Следующие операционные системы больше не поддерживаются с 1 сентября 2021 г. =====
* Linux: Amazon Linux AMI 2017.x
** x86 (только 64 бит)
** [https://aws.amazon.com/amazon-linux-ami/ Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.212
* Linux: openSUSE 12.x, 13.x, 14.x, 15.0
** x86 (только 64 бит)
** [https://en.opensuse.org/openSUSE:Roadmap Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.212

===== Следующие операционные системы больше не поддерживаются с 1 октября 2021 г. =====

* Linux: CentOS 6.x
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: Red Hat Enterprise Linux 6.x
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: openSUSE 15.1
** x86 (только 64 бит)
** [https://en.opensuse.org/openSUSE:Roadmap Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: Oracle Linux 6.x
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: SUSE Enterprise Linux 12.2
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.222

===== Следующие операционные системы больше не поддерживаются с 1 ноября 2021 г. =====
* Linux: openSUSE 15.2+
** x86 (только 64 бит)
** [https://en.opensuse.org/openSUSE:Roadmap Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.216

===== Следующие операционные системы больше не поддерживаются с 1 февраля 2022 г. =====
* Linux: CentOS 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226
* Linux: Debian 8
** x86 (только 64 бит)
** [https://wiki.debian.org/DebianReleases Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226
* Linux: Red Hat Enterprise Linux 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226
* Linux: Oracle Linux 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226

===== Следующие операционные системы больше не поддерживаются с 1 марта 2022 г. =====

* Linux: CentOS 8.3
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.228
* Linux: Red Hat Enterprise Linux 8.3
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.228
* Linux: Oracle Linux 8.3
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.228

Требования АппОптима к системе

2022-03-07T05:14:07Z

YaPolkin:

В этом разделе объясняются требования к операционной системе для установки Ключ-АСТРОМ Managed. Другие требования Ключ-АСТРОМ Managed см. в разделе [[Требования Managed к оборудованию]].

* Вам понадобится выделенный хост для установки Ключ-АСТРОМ Managed. На этом хосте не должны запускаться другие службы, интенсивно использующие ЦП или память, или открывающие [[Порты ноды кластера|порты, используемые Ключ-АСТРОМ Managed]].
* Вам нужен '''64-битный''' дистрибутив Linux (см. поддерживаемые дистрибутивы Linux ниже). Обратите внимание, что поддерживается установка как на физических, так и на виртуальных хостах, но установка в контейнерах не поддерживается.
* Сервер Ключ-АСТРОМ требует фиксированного IP-адреса.
* Убедитесь, что вы правильно настроили [[Порты ноды кластера|параметры брандмауэра]].
* Библиотеки, устанавливаемые вместе с Ключ-АСТРОМ Managed, учитывают региональные стандарты. Для правильного отображения текста и символов не забудьте установить языковой стандарт системы вашей среды на английский (например, <code>LANG = en_US.UTF-8</code>).

== Поддерживаемые операционные системы ==
{| class="wikitable"
!Дистрибутив Linux
!Версии
!Архитектура процессора
|-
|Amazon Linux 2
|все версии
|x86-64
|-
|Amazon Linux AMI
|2018.x
|x86-64
|-
|CentOS
|7.9
|x86-64
|-
|CentOS Stream
|8
|x86-64
|-
|Debian
|9, 10
|x86-64
|-
|Oracle Linux
|7.9, 8.4
|x86-64
|-
|Red Hat Enterprise Linux
|7.9, 8.4
|x86-64
|-
|SUSE Enterprise Linux
|11.4, 12.3, 12.4, 12.5, 15.0, 15.1, 15.2, 15.3
|x86-64
|-
|Ubuntu
|16.04 LTS, 18.04 LTS, 20.04 LTS
|x86-64
|}

== Поддержка изменений ==

=== Текущие изменения поддержки операционных систем Ключ-АСТРОМ Managed ===

===== Следующие операционные системы больше не будут поддерживаться с 1 мая 2022 г. =====
* Linux: CentOS 7.6, 8.1
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.232
* Linux: Red Hat Enterprise Linux 7.6, 8.1
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.232
* Linux: Oracle Linux 7.6, 8.1
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.232

===== Следующие операционные системы больше не будут поддерживаться с 1 июня 2022 г. =====
* Linux: Ubuntu 20.10
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.234

=== Будущие изменения поддержки операционных систем Ключ-АСТРОМ Managed ===

===== Следующие операционные системы больше не будут поддерживаться с 1 августа 2022 г. =====

* Linux: CentOS 7.7
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.238
* Linux: Red Hat Enterprise Linux 7.7
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.238
* Linux: Oracle Linux 7.7
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.238

===== Следующие операционные системы больше не будут поддерживаться с 1 октября 2022 г. =====

* Linux: SUSE Enterprise Linux 11.4
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2022 г. =====

* Linux: Ubuntu 21.04
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.244

===== Следующие операционные системы больше не будут поддерживаться с 1 января 2023 г. =====

* Linux: Debian 9
** x86 (только 64 бит)
** [https://wiki.debian.org/DebianReleases Объявление производителя]
* Linux: SUSE Enterprise Linux 12.3
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 марта 2023 г. =====

* Linux: CentOS 8.2
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.252
* Linux: Red Hat Enterprise Linux 8.2
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.252
* Linux: Oracle Linux 8.2
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.252

===== Следующие операционные системы больше не будут поддерживаться с 1 июля 2023 г. =====

* Linux: SUSE Enterprise Linux 15.0
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 января 2024 г. =====

* Linux: SUSE Enterprise Linux 12.4
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 августа 2024 г. =====

* Linux: SUSE Enterprise Linux 15.1
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2024 г. =====

* Linux: Ubuntu 16.04 LTS
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 декабря 2024 г. =====

* Linux: CentOS Stream 8
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 января 2025 г. =====

* Linux: Debian 10
** x86 (только 64 бит)
** [https://wiki.debian.org/DebianReleases Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 мая 2028 г. =====

* Linux: SUSE Enterprise Linux 12.5
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2028 г. =====

* Linux: Ubuntu 18.04 LTS
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2030 г. =====

* Linux: Ubuntu 20.04 LTS
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]

=== Прошлые изменения поддержки операционных систем Ключ-АСТРОМ Managed ===

===== Следующие операционные системы больше не поддерживаются с 1 декабря 2020 г. =====
* Linux: SUSE Enterprise Linux 12.1
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.208

===== Следующие операционные системы больше не поддерживаются с 1 сентября 2021 г. =====
* Linux: Amazon Linux AMI 2017.x
** x86 (только 64 бит)
** [https://aws.amazon.com/amazon-linux-ami/ Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.212
* Linux: openSUSE 12.x, 13.x, 14.x, 15.0
** x86 (только 64 бит)
** [https://en.opensuse.org/openSUSE:Roadmap Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.212

===== Следующие операционные системы больше не поддерживаются с 1 октября 2021 г. =====

* Linux: CentOS 6.x
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: Red Hat Enterprise Linux 6.x
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: openSUSE 15.1
** x86 (только 64 бит)
** [https://en.opensuse.org/openSUSE:Roadmap Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: Oracle Linux 6.x
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: SUSE Enterprise Linux 12.2
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.222

===== Следующие операционные системы больше не поддерживаются с 1 ноября 2021 г. =====
* Linux: openSUSE 15.2+
** x86 (только 64 бит)
** [https://en.opensuse.org/openSUSE:Roadmap Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.216

===== Следующие операционные системы больше не поддерживаются с 1 февраля 2022 г. =====
* Linux: CentOS 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226
* Linux: Debian 8
** x86 (только 64 бит)
** [https://wiki.debian.org/DebianReleases Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226
* Linux: Red Hat Enterprise Linux 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226
* Linux: Oracle Linux 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226

===== Следующие операционные системы больше не поддерживаются с 1 марта 2022 г. =====

* Linux: CentOS 8.3
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.228
* Linux: Red Hat Enterprise Linux 8.3
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.228
* Linux: Oracle Linux 8.3
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.228

Требования АппОптима к системе

2022-03-03T08:30:34Z

YaPolkin:

В этом разделе объясняются требования к операционной системе для установки Ключ-АСТРОМ Managed. Другие требования Ключ-АСТРОМ Managed см. в разделе [[Требования Managed к оборудованию]].

* Вам понадобится выделенный хост для установки Ключ-АСТРОМ Managed. На этом хосте не должны запускаться другие службы, интенсивно использующие ЦП или память, или открывающие [[Порты ноды кластера|порты, используемые Ключ-АСТРОМ Managed]].
* Вам нужен '''64-битный''' дистрибутив Linux (см. поддерживаемые дистрибутивы Linux ниже). Обратите внимание, что поддерживается установка как на физических, так и на виртуальных хостах, но установка в контейнерах не поддерживается.
* Сервер Ключ-АСТРОМ требует фиксированного IP-адреса.
* Убедитесь, что вы правильно настроили [[Порты ноды кластера|параметры брандмауэра]].
* Библиотеки, устанавливаемые вместе с Ключ-АСТРОМ Managed, учитывают региональные стандарты. Для правильного отображения текста и символов не забудьте установить языковой стандарт системы вашей среды на английский (например, <code>LANG = en_US.UTF-8</code>).

== Поддерживаемые операционные системы ==
{| class="wikitable"
!Дистрибутив Linux
!Версии
!Архитектура процессора
|-
|Amazon Linux 2
|все версии
|x86-64
|-
|Amazon Linux AMI
|2018.x
|x86-64
|-
|CentOS
|7.9
|x86-64
|-
|CentOS Stream
|8
|x86-64
|-
|Debian
|9, 10
|x86-64
|-
|Oracle Linux
|7.9, 8.4
|x86-64
|-
|Red Hat Enterprise Linux
|7.9, 8.4
|x86-64
|-
|SUSE Enterprise Linux
|11.4, 12.3, 12.4, 12.5, 15.0, 15.1, 15.2, 15.3
|x86-64
|-
|Ubuntu
|16.04 LTS, 18.04 LTS, 20.04 LTS
|x86-64
|}

== Поддержка изменений ==

=== Будущие управляемые операционные системы Ключ-АСТРОМ поддерживают изменения ===

===== Следующие операционные системы больше не будут поддерживаться с 1 февраля 2022 г. =====

* Linux: CentOS 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226
* Linux: Debian 8
** x86 (только 64 бит)
** [https://wiki.debian.org/DebianReleases Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226
* Linux: Red Hat Enterprise Linux 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226
* Linux: Oracle Linux 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.226

===== Следующие операционные системы больше не будут поддерживаться с 1 марта 2022 г. =====

* Linux: CentOS 8.3
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.228
* Linux: Red Hat Enterprise Linux 8.3
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.228
* Linux: Oracle Linux 8.3
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.228

===== Следующие операционные системы больше не будут поддерживаться с 1 мая 2022 г. =====

* Linux: CentOS 7.6, 8.1
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.232
* Linux: Red Hat Enterprise Linux 7.6, 8.1
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.232
* Linux: Oracle Linux 7.6, 8.1
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.232

===== Следующие операционные системы больше не будут поддерживаться с 1 июня 2022 г. =====

* Linux: Ubuntu 20.10
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.234

===== Следующие операционные системы больше не будут поддерживаться с 1 августа 2022 г. =====

* Linux: CentOS 7.7
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.238
* Linux: Red Hat Enterprise Linux 7.7
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.238
* Linux: Oracle Linux 7.7
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.238

===== Следующие операционные системы больше не будут поддерживаться с 1 октября 2022 г. =====

* Linux: SUSE Enterprise Linux 11.4
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2022 г. =====

* Linux: Ubuntu 21.04
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.244

===== Следующие операционные системы больше не будут поддерживаться с 1 января 2023 г. =====

* Linux: Debian 9
** x86 (только 64 бит)
** [https://wiki.debian.org/DebianReleases Объявление производителя]
* Linux: SUSE Enterprise Linux 12.3
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 марта 2023 г. =====

* Linux: CentOS 8.2
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.252
* Linux: Red Hat Enterprise Linux 8.2
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.252
* Linux: Oracle Linux 8.2
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.252

===== Следующие операционные системы больше не будут поддерживаться с 1 июля 2023 г. =====

* Linux: SUSE Enterprise Linux 15.0
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 января 2024 г. =====

* Linux: SUSE Enterprise Linux 12.4
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 августа 2024 г. =====

* Linux: SUSE Enterprise Linux 15.1
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2024 г. =====

* Linux: Ubuntu 16.04 LTS
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 декабря 2024 г. =====

* Linux: CentOS Stream 8
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 января 2025 г. =====

* Linux: Debian 10
** x86 (только 64 бит)
** [https://wiki.debian.org/DebianReleases Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 мая 2028 г. =====

* Linux: SUSE Enterprise Linux 12.5
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2028 г. =====

* Linux: Ubuntu 18.04 LTS
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]

===== Следующие операционные системы больше не будут поддерживаться с 1 ноября 2030 г. =====

* Linux: Ubuntu 20.04 LTS
** x86 (только 64 бит)
** [https://ubuntu.com/about/release-cycle Объявление производителя]

=== Прошлые управляемые операционные системы Ключ-АСТРОМ поддерживают изменения ===

===== Следующие операционные системы больше не поддерживаются с 1 ноября 2021 г. =====

* Linux: openSUSE 15.2+
** x86 (только 64 бит)
** [https://en.opensuse.org/openSUSE:Roadmap Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.216

===== Следующие операционные системы больше не поддерживаются с 1 октября 2021 г. =====

* Linux: CentOS 6.x
** x86 (только 64 бит)
** [https://wiki.centos.org/FAQ/General Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: Red Hat Enterprise Linux 6.x
** x86 (только 64 бит)
** [https://access.redhat.com/support/policy/updates/errata Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: openSUSE 15.1
** x86 (только 64 бит)
** [https://en.opensuse.org/openSUSE:Roadmap Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: Oracle Linux 6.x
** x86 (только 64 бит)
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.214
* Linux: SUSE Enterprise Linux 12.2
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.222

===== Следующие операционные системы больше не поддерживаются с 1 сентября 2021 г. =====

* Linux: Amazon Linux AMI 2017.x
** x86 (только 64 бит)
** [https://aws.amazon.com/amazon-linux-ami/ Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.212
* Linux: openSUSE 12.x, 13.x, 14.x, 15.0
** x86 (только 64 бит)
** [https://en.opensuse.org/openSUSE:Roadmap Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.212

===== Следующие операционные системы больше не поддерживаются с 1 декабря 2020 г. =====

* Linux: SUSE Enterprise Linux 12.1
** x86 (только 64 бит)
** [https://www.suse.com/lifecycle/ Объявление производителя]
** Последняя совместимая версия Ключ-АСТРОМ Managed: 1.208

Изменение местоположения хранилища

2022-02-14T03:27:23Z

YaPolkin:

Ключ-АСТРОМ Managed хранит несколько типов данных мониторинга, которые различаются в зависимости от варианта использования. Существуют места хранения по умолчанию, указанные в [[Требования Managed к оборудованию|требованиях к оборудованию и системе Ключ-АСТРОМ Managed]].

Вам может потребоваться изменить существующие пути для мест хранения, если:

* Хранилище тома заполнено, и вам необходимо перейти на больший том.
* Текущее место хранения находится на временном томе, и вы должны перенести его на другой том.
* Текущее место хранения находится на общем томе, и вы хотите переместить данные на выделенный том.

Чтобы изменить пути к этим местам хранения

1. Сделайте резервную копию ваших данных.
----<blockquote><big>''Важно''</big>

*

Ошибка в этой процедуре может привести к потере данных. Мы советуем вам сделать резервную копию всех файлов хранилища в безопасном месте, прежде чем продолжить. Если возможно, сначала выполните эту процедуру при тестовом развертывании.</blockquote>
----2. Остановите все службы Ключ-АСТРОМ на узле.

По умолчанию сценарий находится в <code><PRODUCT_PATH>/launcher/</code>. Убедитесь, что у сценария <code>dynatrace.sh</code> есть разрешения на выполнение. После выполнения дождитесь завершения сценария и убедитесь, что не запущены службы Ключ-АСТРОМ.

<code>[root@host]# <PRODUCT_PATH>/launcher/dynatrace.sh stop</code>

3. Переместите хранилище данных в новое место.

Имейте в виду, что вы не можете вкладывать хранилища данных друг в друга. Например, хранилище Cassandra не может быть подкаталогом хранилища сеансов.

<code>[root@host]# cp -pR /old_location/cassandra/* /new_location/cassandra</code>

4. Убедитесь, что пользователь <code>dynatrace:dynatrace</code> является владельцем этого нового каталога.

<code>[root@host]# chown -R dynatrace:dynatrace /new_location</code>

5. Обновите новое расположение данных в <code>/etc/dynatrace.conf</code>.

Местоположение должно быть либо абсолютным путем, либо значением на основе предопределенных переменных. Это должен быть каталог, а не символическая ссылка.

Обновите следующий раздел:

<code># Paths to directories with component's data</code>

<code>DATASTORE_PATH = /var/opt/dynatrace-managed</code>

<code>CASSANDRA_DATASTORE_PATH = DATASTORE_PATH/CASSANDRA_DIR</code>

<code>ELASTICSEARCH_DATASTORE_PATH = DATASTORE_PATH/ELASTICSEARCH_DIR</code>

<code>SERVER_DATASTORE_PATH = DATASTORE_PATH/SERVER_DIR</code>

<code>SERVER_REPLAY_DATASTORE_PATH = SERVER_DATASTORE_PATH/replayData</code>

<code>NODEKEEPER_DATASTORE_PATH = DATASTORE_PATH/NODEKEEPER_DIR</code>

6. Запустите перенастройку через установщик. Используйте команду <code>nohup</code>, чтобы предотвратить прерывание выполнения сценария (например, отключение сеанса) во время важных операций.

<code>[root@host]# nohup <PRODUCT_PATH>/installer/reconfigure.sh --no-start &</code>

Этот шаг имеет решающее значение для распространения изменений из <code>/etc/dynatrace.conf</code> на все соответствующие файлы конфигурации. Флаг <code>--no-start</code> позволит вам окончательно проверить изменения перед запуском любой из служб Ключ-АСТРОМ.

Результат скрипта должен выглядеть примерно так:

<code>Reconfiguration completed successfully after 1 minute 9 seconds.</code>

<code> </code>

<code>Dynatrace binaries are located in directory /opt/dynatrace-managed</code>

<code>Dynatrace data is located in directory /new_location</code>

<code>Dynatrace metrics repository is located in directory /new_location/cassandra</code>

<code>Dynatrace Elasticsearch store is located in directory /new_location/elasticsearch</code>

<code>Dynatrace server store is located in directory /new_location/sessionstorage</code>

<code>Dynatrace session replay store is located in directory /new_location/replayData</code>

<code>Don't forget to start Dynatrace Server and log in at https://<your_ip></code>

7. Запустите все службы Ключ-АСТРОМ.

<code>[root@host]# <PRODUCT_PATH>/launcher/dynatrace.sh start</code>

8. Проверьте журналы, чтобы убедиться, что все службы запускаются без проблем.

Удаление ноды кластера

2022-02-14T03:15:39Z

YaPolkin:

Вы можете легко удалить узел кластера с помощью консоли управления кластером Ключ-АСТРОМ Managed. Однако, поскольку удаление узла кластера по существу означает удаление Ключ-АСТРОМ Managed, вы также можете использовать командную строку для удаления узла кластера. Оба подхода описаны ниже.

== Удалите узел кластера с помощью командной строки ==
Войдите в систему Linux, на которой установлена Ключ-АСТРОМ Managed. Используя root-права, выполните следующую команду:

<code>/bin/sh dynatrace-managed.sh --uninstall</code>

Все данные Ключ-АСТРОМ Managed будут удалены с устройства после успешного выполнения сценария.

== Удалите узел кластера с помощью консоли управления кластером ==
Прежде чем вы сможете удалить узел из кластера Ключ-АСТРОМ Managed, необходимо сначала отключить трафик ЕдиногоАгента, чтобы предотвратить поток данных к узлу во время его удаления.

=== Отключить трафик ЕдиногоАгента ===
Чтобы отключить узел кластера

1. Авторизуйтесь как администратор. Используйте свой URL-адрес Ключ-АСТРОМ Managed или узел кластера, который вы хотите сохранить (вы не можете удалить узел, пока вы находитесь в нем).

2. В меню Ключ-АСТРОМ перейдите в раздел '''Статус развертывания'''.

3. Выберите '''Ноды кластера''' и в списке узлов выберите узел, на котором вы хотите отключить трафик ЕдиногоАгента.

4. Выберите '''Настроить''', чтобы просмотреть страницу конфигурации узла.

5. Нажмите кнопку обзора ('''…''') в правом верхнем углу.

6. Выберите '''Отключить трафик ЕдиногоАгента''', чтобы остановить обработку данных мониторинга на узле. Если вы хотите временно исключить узел из кластера, остановите здесь и включите узел позже. Ключ-АСТРОМ Managed будет продолжать работать на устройстве, но не будет обрабатывать данные мониторинга.

=== Удалить отключенный узел кластера ===
Прежде чем приступить к удалению узла, рекомендуется подождать, по крайней мере, в течение периода хранения данных в хранилище транзакций (до 35 дней). Это связано с тем, что, хотя все метрики реплицируются в кластере, необработанные данные транзакций не хранятся дополнительно. Удаление узла до истечения срока хранения данных в хранилище транзакций может повлиять на анализ данных на уровне кода и сеанса пользователя.

Удаляйте не более одного узла за раз. Чтобы избежать потери данных, подождите 24 часа, прежде чем удалять любые последующие узлы. Это связано с тем, что для автоматического перераспределения реплик долгосрочных метрик на оставшиеся узлы требуется до 24 часов.

Если у вас включено резервное копирование кластера и вы удаляете узел, файлы резервных копий для этого узла останутся в вашем резервном пространстве. Если вы хотите удалить резервную копию специально для удаленного узла, удалите папку <code><path-to-backup>/<UUID>/node_<node_id></code>.<blockquote>Пример удаления конкретной резервной копии ноды

В этом примере путь:

<code>rmdir -r /mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_3/</code>

части пути следующие:

* <code>/mnt/backup/bckp/</code> = <code><path-to-backup></code>
* <code>c9dd47f0-87d7-445e-bbeb-26429fac06c6</code> = <code><UUID></code>
* <code>3</code> = <code><node_id></code>
</blockquote>После удаления существующего узла кластера необходимо подождать 72 часа, прежде чем устанавливать новый узел на хосте с тем же IP (то есть при повторной установке на том же хосте).

Чтобы удалить отключенный узел кластера

1. Авторизуйтесь как администратор. Используйте свой URL-адрес Ключ-АСТРОМ Managed или узел кластера, который вы хотите сохранить (вы не можете удалить узел, пока вы находитесь в нем).

2. В меню Ключ-АСТРОМ перейдите на '''Домашнюю''', чтобы перейти на страницу узлов кластера Ключ-АСТРОМ Managed.

3. Выберите узел кластера, который вы хотите удалить, чтобы получить доступ к странице общего представления узла.

4. Нажмите кнопку обзора ('''…''') в правом верхнем углу.

5. Выберите '''Удалить ноду'''. Затем узел остановится и будет полностью удален с вашего экземпляра сервера.
----<blockquote>''<big>Мертвые ноды</big>''

Ключ-АСТРОМ Managed показывает мертвые и удаленные узлы в течение 7 дней. Однако даже если мертвый узел больше не отображается на странице кластеров, он все равно регистрируется. Чтобы полностью удалить узел, используйте вызов API Ключ-АСТРОМ. Вы можете выполнить вызов API управления кластером для следующего эндпоинта: <code>onpremise/nodeManagement/deadNodeCleaning</code>.

Подробнее см. в обозревателе API Ключ-АСТРОМ в CMC.

# В правом верхнем углу CMC откройте меню пользователя и выберите '''Cluster Management API (API кластера)'''.
# Разверните '''Ноду кластера''' и '''УДАЛИТЕ''' раздел <code>/nodeManagement/deadNodeCleaning</code> , чтобы опробовать его.
</blockquote>

Настройка страницы входа

2022-02-14T02:46:58Z

YaPolkin:

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

Чтобы настроить страницу входа, в меню Ключ-АСТРОМ перейдите в раздел '''Аутентификация пользователя''' > '''Экран входа в систему''' и измените сообщения по умолчанию (все сообщения опциональны):

* '''Заголовок''' - текст, отображаемый в разделе "Ключ-АСТРОМ Managed".
* '''Описание''' - текст, отображаемый более мелким шрифтом под заголовком.
* '''Подробности''' - изначально свернутый текст, который может быть развернут пользователем. Может быть установлен, только если определено '''Описание'''.

Настройка и управление сессиями пользователей

2022-02-14T02:40:39Z

YaPolkin:

Доступ к Ключ-АСТРОМ Managed могут получить многие пользователи, принадлежащие к разным группам. Количество одновременных сеансов на одну учетную запись пользователя должно быть ограничено до минимума, необходимого для выполнения рабочих обязанностей. Ключ-АСТРОМ Managed дает вам возможность контролировать и ограничивать количество одновременных пользовательских сеансов для каждой учетной записи пользователя.

В меню Ключ-АСТРОМ выберите '''Аутентификация пользователя''' > '''Пользовательские сессии''', чтобы просмотреть или завершить любые текущие сеансы пользователя. В представлении сеансов пользователя указывается тип входа, время входа и IP-адрес или устройство, с которого вход был выполнен.

Типы входа:

* <code>LOCAL</code> - Пользователи, которые существуют только в базе данных кластера и являются локальными по отношению к кластеру.
* <code>LDAP</code> - пользователи LDAP
* <code>SSO</code> - вход от вашего поставщика удостоверений
* <code>DEVOPSTOKEN</code> - вход через проактивную службу поддержки Mission Control

Чтобы завершить сеанс, выберите [[Файл:Remove-icon.png|альт=Удалить]] и подтвердите действие. Сеанс немедленно завершится, и пользователь выйдет из системы.

Чтобы изменить количество разрешенных одновременных пользовательских сеансов, выберите '''Настроить пользовательские сессии'''. Вы можете установить разные лимиты для обычных пользователей и администраторов. Учетные записи администраторов - это пользователи, которые принадлежат к любой группе с глобальными разрешениями администратора кластера.

Чтобы снять все ограничения сеансов для учетных записей администраторов и обычных пользователей, включите '''Неограниченное количество одновременных пользовательских сессий'''.

Используйте REST API для обновления политики автоматического выхода из системы. По умолчанию автоматический выход из системы для пользователей, которые остаются на автоматически обновляемых страницах, отсутствует. См. раздел Обновление конфигурации пользовательских сеансов кластера.

Возможности ноды кластера

2022-02-14T02:36:05Z

YaPolkin:

Для некоторых развертываний может потребоваться, чтобы определенные узлы обслуживали только трафик пользовательского интерфейса, а не обрабатывали данные ЕдиногоАгента. Или наоборот, когда узлы обрабатывают только данные ЕдиногоАгента и не обслуживают трафик пользовательского интерфейса. Настроив один или другой из этих параметров, вы можете добиться более высокой стабильности, лучшего поведения кеша и более быстрого времени отклика пользовательского интерфейса.
----<blockquote><big>''Трафик веб-интерфейса''</big>

*

Чтобы повысить производительность балансировки нагрузки DNS, начиная с Ключ-АСТРОМ Managed 1.214, трафик веб-интерфейса по умолчанию отключен при установке 13-го и последующих узлов (или 7-го и последующих узлов в центре обработки данных для Premium HA). Вы можете включить/отключить трафик веб-интерфейса для узла через Cluster REST API (кластерный REST API).

* Примечания к релизу Ключ-АСТРОМ Managed версии 1.214
</blockquote>
----Чтобы включить или отключить трафик ЕдиногоАгента на узле, вы можете использовать веб-интерфейс, командную строку или вызов API.

== Включение/отключение трафика ЕдиногоАгента через пользовательский интерфейс консоли управления кластером ==
Чтобы отключить трафик ЕдиногоАгента (т.е. установить узел кластера в режим ожидания)

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

Чтобы включить трафик ЕдиногоАгента на узле, повторите первые три шага выше, затем выберите '''Включить трафик ЕдиногоАгента''', чтобы начать обработку данных мониторинга на узле.

== Включение/отключение трафика веб-интерфейса через интерфейс консоли управления кластером ==
Чтобы отключить трафик веб-интерфейса (т.е. установить узел кластера в режим ожидания)

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

Чтобы включить трафик веб-интерфейса на узле, повторите первые три шага, описанные выше, затем выберите '''Включить трафик веб-интерфейса''', чтобы начать обработку данных мониторинга на узле.

== Включение/отключение трафика ЕдиногоАгента или веб-интерфейса с помощью вызова API ==
Вы можете настроить эту опцию с помощью вызова API. См. раздел Настройка обязанностей узлов кластера.

=== Аутентификация ===
Чтобы выполнить этот запрос, вам необходимо разрешение на '''управление токенами кластера''', назначенное вашему токену API. Если у вас нет токена API, вы можете его сгенерировать:

# В меню навигации выберите '''Настройки''' и перейдите к '''Токенам API'''.
# Нажмите кнопку '''Создать токен''' и введите имя для своего токена.
# Выберите разрешения '''API поставщика услуг''' и нажмите '''Сгенерировать'''.

Используйте сгенерированный токен API для выполнения вызовов API.

=== Эндпоинт ===
Вы можете выполнить <code>POST</code> в эндпоинт <code>/api/v1.0/onpremise/cluster/configuration</code> со следующими параметрами:
{| class="wikitable"
!Параметр
!Тип
!Описание
!В
!Необходимость
|-
|ID
|integer
|ID ноды
|body
|требуется
|-
|webUI
|boolean
|Устанавливает webUI для этой ноды. Определите, следует ли использовать этот узел для обслуживания запросов WebUI (<code>true</code>/<code>false</code>).
|body
|требуется
|-
|OneAgent
|boolean
|Устанавливает трафик ЕдиногоАгента для этой ноды. Определите, должен ли этот узел получать трафик ЕдиногоАгента (<code>true</code>/<code>false</code>).
|body
|требуется
|-
|datacenter
|string
|не используется.
|body
|не требуется
|}
Пример полезной нагрузки JSON для вызова API:

<code>{</code>

<code> "clusterNodes": [</code>

<code> {</code>

<code> "id": 1,</code>

<code> "webUI": true,</code>

<code> "agent": true,</code>

<code> "datacenter": "dc-1"</code>

<code> },</code>

<code> {</code>

<code> "id": 2,</code>

<code> "webUI": true,</code>

<code> "agent": true,</code>

<code> "datacenter": "dc-1"</code>

<code> }</code>

<code> ]</code>

<code>}</code>

Настройка подключения к SMTP-серверу

2022-02-14T02:21:44Z

YaPolkin:

Используйте эти настройки, чтобы определить, как Ключ-АСТРОМ доставляет пользователям и администраторам уведомления по электронной почте, отчеты и другие сообщения.

1. В меню Ключ-АСТРОМ зайдите в '''Настройки'''.

2. Разверните '''Emails''' и выберите '''сервер''' '''SMTP''', чтобы отобразить страницу настройки '''SMTP-сервера'''.

3. Начните с выбора способа доставки электронной почты.

* '''SMTP-сервер с резервным режимом Mission Control''' (настройка по умолчанию)

<blockquote>Выберите это, чтобы SMTP-сервер доставлял электронную почту, но использовался Mission Control в качестве резервного метода доставки.

** Пока ваш SMTP-сервер доступен, ваша SMTP-конфигурация определяет, как отправляется электронная почта (почтовый сервер, безопасность соединения и т.д.).
** Если ваш SMTP-сервер становится недоступным, Mission Control доставит ваше письмо с отправляющим адресом <code>noreply@dynatrace-managed.com</code>.
</blockquote>

* '''SMTP-сервер'''

<blockquote>Выберите это, чтобы SMTP-сервер доставлял электронную почту (без резервного метода доставки).

** Ваша конфигурация SMTP определяет, как отправляется ваша электронная почта (почтовый сервер, безопасность соединения и т.д.).
** Если ваш SMTP-сервер станет недоступен, ваше письмо не будет отправлено.
</blockquote>

* '''Mission Control'''

<blockquote>Выберите это, чтобы Mission Control отправлял все электронные письма.

** Все шаги настройки SMTP-сервера, описанные ниже, недоступны, потому что вам не нужно настраивать SMTP-сервер. Ключ-АСТРОМ обо всем позаботится за вас.
** Адрес отправки: <code>noreply@dynatrace-managed.com</code>.
</blockquote>4. Установите для параметра '''Безопасность подключения''' значение протокола безопасности, который вы хотите использовать для своего SMTP-сервера. По умолчанию <code>Без шифрования</code> на порту <code>25</code>.
----<blockquote>
* Если вы измените '''Безопасность подключения''', настройка '''порта''' автоматически изменится, чтобы соответствовать стандартному номеру порта для этого протокола (см. номера портов по умолчанию ниже).
* Если вы вручную измените номер '''порта''', ваши предпочтения запомнятся, и изменение протокола '''Безопасности подключения''' не приведет к автоматическому изменению номера '''порта'''.
</blockquote>
----

* <code>Без шифрования</code>: Небезопасно. Порт по умолчанию: <code>25</code>.

<blockquote>Отправляется электронное письмо в незашифрованном виде. Используйте эту опцию, только если SMTP-сервер не поддерживает никаких других опций.</blockquote>

* <code>Требуется SSL/TLS</code>: Безопасно. Порт по умолчанию: <code>465</code>.
** Если соединение SSL/TLS может быть установлено, отправляется зашифрованное электронное письмо с помощью SSL/TLS.
** Если соединение SSL/TLS не может быть установлено, электронное письмо не отправляется.

* <code>STARTTLS необязательно</code>: Небезопасно. Порт по умолчанию: <code>587</code>.
** Если соединение STARTTLS может быть установлено, отправляется зашифрованное электронное письмо с помощью STARTTLS.
** Если соединение STARTTLS не может быть установлено, отправляется электронное письмо без шифрования.

* <code>Требуется STARTTLS</code>: Безопасно. Порт по умолчанию: <code>587</code>.
** Если соединение STARTTLS может быть установлено, отправляется зашифрованное электронное письмо с помощью STARTTLS.
** Если соединение STARTTLS не может быть установлено, электронное письмо не отправляется.

5. Установите '''Почтовый сервер''' на адрес почтового SMTP-сервера.

6. В поле '''Порт''' укажите номер порта почтового сервера SMTP. Дополнительные сведения см. в разделе '''Безопасность подключения''' выше.

7. Установите '''Имя пользователя''' и '''Пароль''', если сервер требует аутентификации.

8. Установите '''Email''' '''отправителя''' на адрес, который должен отображаться как адрес электронной почты отправителя.

9. Установите '''Тестовый Email''' на адрес, на который вы хотите отправлять тестовые сообщения.

10. Выберите '''Отправить тестовое сообщение''', чтобы проверить конфигурацию SMTP, отправив тестовое сообщение на '''Тестовый Email'''.

* Через некоторое время отобразится сообщение о состоянии <code>Sending succeeded</code> , если отправка прошла успешно.
* Проверьте почтовый ящик учетной записи '''Тестового Email''', чтобы убедиться, что он получил сообщение "Dynatrace Managed: Mail server setup" с ожидаемым адресом электронной почты отправителя.

11. Выберите '''Сохранить изменения''', если конфигурация верна.

Запуск/остановка/перезапуск кластера

2022-02-09T12:40:31Z

YaPolkin:

Программное обеспечение Ключ-АСТРОМ Managed состоит из ряда служб Ключ-АСТРОМ, которые зависят друг от друга и должны быть остановлены или запущены в определенном порядке. Вы можете использовать официальный сценарий <code>dynatrace.sh</code> с дополнительными параметрами для правильного запуска, остановки или перезапуска служб Ключ-АСТРОМ. По умолчанию сценарий находится в <code>/opt/dynatrace-managed/launcher/</code>. Убедитесь, что у сценария <code>dynatrace.sh</code> есть разрешения на выполнение.

Вы можете выполнить сценарий <code>dynatrace.sh</code> с параметром (<code>start</code>, <code>stop</code>, <code>restart</code>, <code>status</code>, <code>check</code>, <code>pid</code>), как описано ниже.

* start

Запускает все необходимые службы Ключ-АСТРОМ Managed в рекомендованном порядке.

<code>[root@localhost]# ./dynatrace.sh start</code>

* stop

Останавливает все необходимые службы Ключ-АСТРОМ Managed в рекомендованном порядке.

<code>[root@localhost]# ./dynatrace.sh stop</code>

* restart

Перезапускает все необходимые службы Ключ-АСТРОМ Managed в рекомендованном порядке.

<code>[root@localhost]# ./dynatrace.sh restart</code>

* status

Отображает список необходимых служб Ключ-АСТРОМ и состояние каждой из них, включая подробную информацию о каждой службе:

<code>[root@localhost]# ./dynatrace.sh status</code>

Пример вывода статуса dynatrace.sh

# <code>● dynatrace-firewall.service - Dynatrace Firewall settings</code>
# <code> Loaded: loaded (/etc/systemd/system/dynatrace-firewall.service; enabled; vendor preset: enabled)</code>
# <code> Active: active (exited) since Tue 2019-07-09 08:34:54 UTC; 1 months 3 days ago</code>
# <code>Main PID: 12967 (code=exited, status=0/SUCCESS)</code>
# <code> Tasks: 0</code>
# <code> Memory: 0B</code>
# <code> CPU: 0</code>
# <code> CGroup: /system.slice/dynatrace-firewall.service</code>
# <code>Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.</code>
# <code>● dynatrace-nodekeeper.service - Dynatrace Nodekeeper</code>
# <code> Loaded: loaded (/etc/systemd/system/dynatrace-nodekeeper.service; enabled; vendor preset: enabled)</code>
# <code> Active: active (running) since Tue 2019-07-09 08:30:02 UTC; 1 months 3 days ago</code>
# <code> Tasks: 69 (limit: 32768)</code>
# <code> Memory: 389.2M</code>
# <code> CPU: 2h 9min 51.936s</code>
# <code> CGroup: /system.slice/dynatrace-nodekeeper.service</code>
# <code> ├─ 552 /opt/managed/nodekeeper/jre/bin/java -Xms239M -Xmx239M -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60 -Duser.language=EN -Djava.io.tmpdir=...</code>
# <code> ├─ 966 /bin/sh /opt/managed/nodekeeper/services/watchdog.sh watch /opt/managed/nodekeeper/services/nodekeeper.sh</code>
# <code> └─22167 sleep 60</code>
# <code>Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.</code>
# <code>● dynatrace-cassandra.service - Dynatrace Cassandra</code>
# <code> Loaded: loaded (/etc/systemd/system/dynatrace-cassandra.service; enabled; vendor preset: enabled)</code>
# <code> Active: active (running) since Tue 2019-07-09 08:37:52 UTC; 1 months 3 days ago</code>
# <code> Tasks: 199 (limit: 32768)</code>
# <code> Memory: 3.2G</code>
# <code> CPU: 17h 1min 32.540s</code>
# <code> CGroup: /system.slice/dynatrace-cassandra.service</code>
# <code> ├─13690 /opt/managed/jre/bin/java -javaagent:/opt/managed/cassandra/bin/../lib/jamm-0.3.0.jar -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities -XX:ThreadPr...</code>
# <code> ├─13721 /bin/sh /opt/managed/services/watchdog.sh watch /opt/managed/services/cassandra.sh</code>
# <code> └─22197 sleep 60</code>
# <code>Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.</code>
# <code>● dynatrace-elasticsearch.service - Dynatrace Elasticsearch</code>
# <code> Loaded: loaded (/etc/systemd/system/dynatrace-elasticsearch.service; enabled; vendor preset: enabled)</code>
# <code> Active: active (running) since Tue 2019-07-09 08:38:15 UTC; 1 months 3 days ago</code>
# <code> Tasks: 58 (limit: 32768)</code>
# <code> Memory: 884.6M</code>
# <code> CPU: 6h 59min 48.051s</code>
# <code> CGroup: /system.slice/dynatrace-elasticsearch.service</code>
# <code> ├─14802 /opt/managed/jre/bin/java -Xms558M -Xmx558M -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+AlwaysP...</code>
# <code> ├─14834 /bin/sh /opt/managed/services/watchdog.sh watch /opt/managed/services/elasticsearch.sh</code>
# <code> └─21975 sleep 60</code>
# <code>Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.</code>
# <code>● dynatrace-server.service - Dynatrace Server</code>
# <code> Loaded: loaded (/etc/systemd/system/dynatrace-server.service; enabled; vendor preset: enabled)</code>
# <code> Active: active (running) since Tue 2019-07-09 08:39:01 UTC; 1 months 3 days ago</code>
# <code>Main PID: 2927 (code=exited, status=0/SUCCESS)</code>
# <code> Tasks: 475 (limit: 32768)</code>
# <code> Memory: 1.6G</code>
# <code> CPU: 1d 3h 10min 18.812s</code>
# <code> CGroup: /system.slice/dynatrace-server.service</code>
# <code> ├─15294 /opt/managed/server/dynatraceserver -vm=/opt/managed/jre/bin/java -vmargs -Xms2873M -Xmx2873M -XX:-OmitStackTraceInFastThrow -XX:+UseConcMarkSweepGC -XX:...</code>
# <code> └─15302 /opt/managed/jre/bin/java -Dcom.compuware.apm.WatchDogPort=50004 -classpath :/opt/managed/server/lib/ace-1.4.4-dt-2.0.jar:/opt/managed/server/lib/acme4j-...</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[20856]: pam_unix(sudo:session): session closed for user root</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[21125]: dynaman : TTY=unknown ; PWD=/opt/managed/server ; USER=root ; COMMAND=/opt/dtrun/dtrun service dynatrace-cassandra status</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[21125]: pam_unix(sudo:session): session opened for user root by (uid=0)</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[21125]: pam_unix(sudo:session): session closed for user root</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[21389]: dynaman : TTY=unknown ; PWD=/opt/managed/server ; USER=root ; COMMAND=/opt/dtrun/dtrun service dynatrace-security-gateway status</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[21389]: pam_unix(sudo:session): session opened for user root by (uid=0)</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[21389]: pam_unix(sudo:session): session closed for user root</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[21665]: dynaman : TTY=unknown ; PWD=/opt/managed/server ; USER=root ; COMMAND=/opt/dtrun/dtrun service dynatrace-server status</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[21665]: pam_unix(sudo:session): session opened for user root by (uid=0)</code>
# <code>Aug 12 13:04:05 ip-10-176-32-69 sudo[21665]: pam_unix(sudo:session): session closed for user root</code>
# <code>Hint: Some lines were ellipsized, use -l to show in full.</code>
# <code>● dynatrace-security-gateway.service - Dynatrace Active Gate</code>
# <code> Loaded: loaded (/etc/systemd/system/dynatrace-security-gateway.service; enabled; vendor preset: enabled)</code>
# <code> Active: active (running) since Tue 2019-07-09 08:39:37 UTC; 1 months 3 days ago</code>
# <code>Main PID: 16173 (dynatracegatewa)</code>
# <code> Tasks: 247 (limit: 32768)</code>
# <code> Memory: 410.7M</code>
# <code> CPU: 3h 44min 58.189s</code>
# <code> CGroup: /system.slice/dynatrace-security-gateway.service</code>
# <code> ├─16173 /opt/managed/security-Gateway/launcher/dynatracegateway -bg -vm=/opt/managed/jre/bin/java -vmargs -Xms638M -Xmx638M -XX:+UseConcMarkSweepGC -XX:CMSInitia...</code>
# <code> └─16182 /opt/managed/jre/bin/java -Dcom.compuware.apm.WatchDogPort=50005 -classpath /opt/managed/security-Gateway/lib/* -XX:ErrorFile=/var/opt/managed/log/securi...</code>
# <code>Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.</code>
# <code>● dynatrace-nginx.service - Dynatrace NGINX</code>
# <code> Loaded: loaded (/etc/systemd/system/dynatrace-nginx.service; enabled; vendor preset: enabled)</code>
# <code> Active: active (running) since Tue 2019-07-09 08:39:46 UTC; 1 months 3 days ago</code>
# <code> Tasks: 14 (limit: 32768)</code>
# <code> Memory: 92.7M</code>
# <code> CPU: 40min 38.507s</code>
# <code> CGroup: /system.slice/dynatrace-nginx.service</code>
# <code> ├─17152 nginx: OneAgent companion process</code>
# <code> ├─17153 nginx: master process /opt/managed/nginx/sbin/nginx -c /opt/managed/nginx/conf/nginx.conf</code>
# <code> ├─17155 nginx: worker process</code>
# <code> ├─17156 nginx: worker process</code>
# <code> ├─17164 /bin/bash /opt/managed/services/logs-watcher.sh watch-nginx /var/opt/managed/log/nginx/access.log /var/opt/managed/log/nginx/error.log</code>
# <code> └─19214 sleep 600</code>
# <code>Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.</code>
# <code>All services are OK</code>
*check

Проверяет состояние правил iptable и процессов для Nodekeeper, Cassandra, Elasticsearch, АктивногоШлюза, Watcher и NGINX.

<code>[root@localhost]# ./dynatrace.sh check</code>

Пример вывода статуса dynatrace.sh

# <code>Checking rules in iptables ...</code>
# <code>Rule is present in 'filter': INPUT -p tcp -m tcp -m multiport --ports 443,5701:5711,7000:7001,7199,8018:8022,8443,9042,9200,9300,9998 -j DROP</code>
# <code>Rule is present in 'filter': OUTPUT -p tcp -m tcp -m multiport --ports 443,5701:5711,7000:7001,7199,8018:8022,8443,9042,9200,9300,9998 -j ACCEPT</code>
# <code>Rule is present in 'filter': INPUT -p tcp -m addrtype --src-type LOCAL -m tcp -m multiport --ports 443,5701:5711,7000:7001,7199,8018:8022,8443,9042,9200,9300,9998 -j ACCEPT</code>
# <code>Rule is present in 'filter': INPUT -s 10.10.10.10/32 -p tcp -m tcp -m multiport --ports 5701:5711,7000:7001,7199,8019,9042,9200,9300 -j ACCEPT</code>
# <code>Rule is present in 'filter': INPUT -p tcp -m tcp -m multiport --ports 443,8020:8022,8443,9998 -j ACCEPT</code>
# <code>Rule is present in 'filter': FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT</code>
# <code>Rule is present in 'nat': PREROUTING -p tcp -m addrtype --dst-type LOCAL -m tcp --dport 443 -j REDIRECT --to-ports 8022</code>
# <code>Rule is present in 'nat': OUTPUT -p tcp -m addrtype --dst-type LOCAL -m tcp --dport 443 -j REDIRECT --to-ports 8022</code>
# <code>All rules are active.</code>
# <code>Nodekeeper is running at launcher PID: 966, main PID: 552, listening on ports 8018</code>
# <code>Cassandra is running at launcher PID: 13721, main PID: 13690, listening on ports 9042</code>
# <code>Elasticsearch is running at launcher PID: 14834, main PID: 14802, listening on ports 9200,9300</code>
# <code>{</code>
# <code> "cluster_name" : "11bc1cd1e1-c222-33e3-4f44-0e0bc0dcdc0d",</code>
# <code> "status" : "yellow",</code>
# <code> "timed_out" : false,</code>
# <code> "number_of_nodes" : 1,</code>
# <code> "number_of_data_nodes" : 1,</code>
# <code> "active_primary_shards" : 299,</code>
# <code> "active_shards" : 299,</code>
# <code> "relocating_shards" : 0,</code>
# <code> "initializing_shards" : 0,</code>
# <code> "unassigned_shards" : 598,</code>
# <code> "delayed_unassigned_shards" : 0,</code>
# <code> "number_of_pending_tasks" : 0,</code>
# <code> "number_of_in_flight_fetch" : 0,</code>
# <code> "task_max_waiting_in_queue_millis" : 0,</code>
# <code> "active_shards_percent_as_number" : 33.33333333333333</code>
# <code>}</code>
# <code>Server is running at launcher PID: 15294, main PID: 15302, listening on ports 8021</code>
# <code>ActiveGate is running at launcher PID: 16173, main PID: 16182, listening on ports 8443</code>
# <code>Command to run as user dynaman: /opt/managed/services/logs-watcher.sh status</code>
# <code>Watcher is running, reporting in log: /var/opt/managed/log/logs-watcher-for-nginx-logs.log</code>
# <code>NGINX is running at launcher PID: 17153, main PID: 17155 17156, listening on ports 8022</code>
# <code>All processes are OK</code>
*pid

Отображает идентификатор процесса для всех необходимых служб Ключ-АСТРОМ, которые были запущены с помощью скрипта <code>dynatrace.sh</code>.

<code>[root@localhost]# ./dynatrace.sh pid</code>

Пример pid статуса dynatrace.sh

<code>966 552 13721 13690 14834 14802 15294 15302 16173 16182 17153 17155 17156</code>

Удаление кластера

2022-02-09T12:35:32Z

YaPolkin:

Чтобы удалить кластер, вам необходимо удалить все узлы кластера. Другими словами, вы должны [[Удаление ноды кластера|удалить Ключ-АСТРОМ Сервер с каждого узла]]. Чтобы освободить лицензию, используйте параметр <code>--unregister</code> хотя бы один раз при удалении узлов кластера.

'''Примечание:''' При использовании параметра <code>--unregister</code> лицензия освобождается, но кластер всё ещё настроен и потенциально может быть связан с новой лицензией.

Примерный размер резервной копии кластера

2022-02-09T12:33:07Z

YaPolkin:

Следуйте приведенным ниже инструкциям, чтобы оценить размер резервной копии кластера для хранилища метрик и хранилища Elasticsearch. Общий размер резервной копии кластера можно приблизительно оценить как сумму ваших примерных размеров резервной копии для хранилища метрик и хранилища Elasticsearch.

=== Общая формула ===
Оцените размер резервной копии хранилища метрик.

Обычно это 20% от суммы хранилища метрик на всех узлах. Количество узлов не влияет на формулу.
----<blockquote>''<big>Доступное место для хранения резервных копий</big>''

*

Текущая резервная копия хранилища метрик сохраняется до завершения следующего резервного копирования и создания новой резервной копии. Таким образом, до тех пор, пока не будет удалена первая резервная копия, объем дискового пространства, необходимый для резервной копии хранилища метрик, будет вдвое больше фактического размера вашей резервной копии. По этой причине мы рекомендуем удвоить предполагаемое пространство, необходимое для резервного копирования хранилища метрик.</blockquote>
----1. Оцените размер резервной копии хранилища Elasticsearch.

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

2. Оцените размер резервной копии кластера.

Основываясь на предыдущих оценках, рассчитайте предполагаемый размер резервной копии как 20% хранилища метрик + хранилище Elasticsearch.

=== Пример оценки ===
Например, предположим, что вы хотите оценить размер резервной копии для трехузлового кластера:

1. Рассчитайте хранилище метрик для всего кластера.

Проверьте размер хранилища метрик на диске на каждом узле. Размер должен незначительно отличаться между узлами.

<code>du -sh /var/opt/dynatrace-managed/cassandra/</code>

<code>885GB</code>

В нашем примере кластер имеет три узла, и один узел имеет 885 ГБ хранилища метрик, поэтому мы можем оценить хранилище метрик как: <code>3 * 885 ГБ = 2,6 ТБ</code>.

2. Рассчитайте хранилище Elasticsearch для всего кластера.

Проверьте размер хранилища Elasticsearch на диске на '''каждом узле'''. Размер должен незначительно отличаться между узлами.

<code>du -sh /var/opt/dynatrace-managed/elasticsearch/</code>

<code>1.5TB</code>

В нашем примере кластер имеет три узла, и один узел имеет 1,5 ТБ хранилища Elasticsearch, поэтому мы можем оценить хранилище Elasticsearch как: <code>3 * 1,5 ТБ = 4,5 ТБ</code>.

3. Теперь, когда у нас есть примерные значения для хранилища метрик и Elasticsearch, мы можем оценить размер резервной копии как 20% хранилища метрик + хранилище Elasticsearch: <code>(2,6 ТБ * 0,2) + 4,5 ТБ = 5,02 ТБ</code>.

Размер одной резервной копии оценивался в 5,02 ТБ. Чтобы оценить '''минимальный размер, который следует выделить для этой резервной копии''', необходимо удвоить резервную копию хранилища метрик. Итого это <code>4,5 ТБ + ((2,6 ТБ * 0,2) * 2) = 5,54 ТБ</code>.
----<blockquote><big>''Точность оценки''</big>

*

Эта оценка не будет точной, если она будет рассчитана на новом кластере, который только что начал хранить данные. По мере роста хранилища на диске будет увеличиваться и размер резервной копии.</blockquote>
----

=== Резервное копирование только конфигурации ===
Занимает до 10% хранилища метрик вместо 20% (это на 50% меньше хранилища метрик).

=== Исключение пользовательских сессий ===
В высокоинтенсивных средах RUM (50 тыс. пользовательских сеансов в минуту) пользовательские сеансы могут занимать до 99% всего хранилища Elasticsearch. Следовательно, их исключение может убрать оценку резервного копирования Elasticsearch из общей формулы. В других средах трудно оценить уменьшение размера резервной копии. Вы можете обратиться за помощью к специалисту по продукции Ключ-АСТРОМ ONE.

Применение патчей операционной системы к ноде

2022-02-09T12:22:21Z

YaPolkin:

Мы рекомендуем вам выполнять обновление операционной системы узла или исправлять приложение по одному узлу за раз. Программное обеспечение узла Ключ-АСТРОМ Managed состоит из ряда служб Ключ-АСТРОМ, которые зависят друг от друга и должны быть остановлены или запущены в определенном порядке. Используйте официальную команду <code>dynatrace.sh</code> с параметром для правильного запуска, остановки или перезапуска служб Ключ-АСТРОМ.

Чтобы применить патч операционной системы к узлу Ключ-АСТРОМ

1. Как пользователь root войдите в систему Linux, на которой установлен узел Ключ-АСТРОМ Managed.

2. Выполните команду <code>dynatrace.sh</code> с соответствующим параметром (<code>start</code>, <code>stop</code>, или <code>restart</code>).

По умолчанию скрипт находится в <code>/opt/dynatrace-managed/launcher</code>.

<code>[root@localhost]# ./dynatrace.sh stop</code>

3. Примените все необходимые патчи к операционной системе узла.
----<blockquote>''<big>Перезагрузка системы</big>''

*

Для некоторых патчей операционной системы может потребоваться перезагрузка системы. Имейте в виду, что при перезапуске системы служба Ключ-АСТРОМ будет работать. Если вы планируете установить дополнительные исправления после перезагрузки, вам следует снова остановить службы Ключ-АСТРОМ, прежде чем применять дополнительные исправления.</blockquote>
----4. Если перезагрузка системы не потребовалась, перезапустите службы Ключ-АСТРОМ.

<code>[root@localhost]# ./dynatrace.sh start</code>

Настройка страницы входа

2022-02-09T12:13:19Z

YaPolkin:

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

Чтобы настроить страницу входа, в меню Ключ-АСТРОМ перейдите в раздел '''Аутентификация пользователя''' > '''Экран входа в систему''' и измените сообщения по умолчанию (все сообщения опциональны):

* '''Заголовок''' - текст, отображаемый в разделе "Ключ-АСТРОМ Managed".
* '''Введение''' - текст, отображаемый более мелким шрифтом под заголовком.
* '''Подробности''' - изначально свернутый текст, который может быть развернут пользователем. Может быть установлен, только если определено '''Введение'''.

Правила сложности пароля

2022-02-09T12:08:40Z

YaPolkin:

На этой странице описаны подробные сведения о конфигурации, лучшие практики и значения по умолчанию для параметра <code>Обязательное соответствие пароля требованиям к сложности</code> политики безопасности. Правила сложности пароля применяются только к встроенной учетной записи администратора и внутренним учетным записям пользователей (см. [[Группы пользователей, разрешения и политики|Группы пользователей и разрешения]]). При обновлении политики паролей всем пользователям предлагается обновить свои пароли при следующем входе в систему.

Параметр политики <code>Обязательное соответствие пароля требованиям к сложности</code> заставляет пароли соответствовать ряду рекомендаций по надежным паролям. Вы можете настроить пароли в соответствии со следующими требованиями:

1. Пароль содержит минимальное количество буквенно-цифровых символов.

2. Пароль содержит минимальное количество символов из следующих категорий:

* Прописные буквы латинского алфавита (от <code>A</code> до <code>Z</code>, с диакритическими знаками)
* Строчные буквы латинского алфавита (от <code>a</code> до <code>z</code>, с диакритическими знаками)
* Базовые 10 цифр (от <code>0</code> до <code>9</code>)
* Не алфавитно-цифровые символы (специальные символы): (<code>~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/</code>) Символы валюты, такие как евро или фунт не считается специальным символом для этого параметра политики.

Требования к сложности применяются при изменении или создании паролей.

== Значения по умолчанию ==
В следующей таблице перечислены фактические и действующие значения политики по умолчанию. Значения по умолчанию также перечислены на странице свойств политики. Диапазон значений для свойств политики составляет от <code>8</code> до <code>128</code> для свойства <code>Минимальная длина пароля</code> и от <code>0</code> до <code>128</code> для других свойств политики.
{| class="wikitable"
!Имя свойства политики
!Значение по умолчанию
!Рекомендуется
|-
|Минимальная длина пароля
|<code>8</code> для существующих кластеров, установленных до 1.206

<code>12</code> для новых кластеров, установленных в версии 1.206 или позже.
|<code>12</code>
|-
|Минимальное количество символов в верхнем регистре
|<code>1</code>
|<code>1</code>
|-
|Минимальное количество символов в нижнем регистре
|<code>1</code>
|<code>1</code>
|-
|Минимальное количество цифр
|<code>1</code>
|<code>1</code>
|-
|Минимальное количество не буквенно-цифровых символов
|<code>0</code>
|<code>любое</code>
|}

== Лучшие практики ==
С 2013 года «Специальная публикация NIST 800-63. Приложение A» рекомендует включать в пароли неправильное использование заглавных букв, специальные символы и хотя бы одну цифру. Также рекомендуется регулярно менять пароли, по крайней мере, каждые 90 дней. Этому совету следует большинство систем, и он был включен в ряд стандартов, которым должны следовать предприятия.

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

Настройка и управление сессиями пользователей

2022-02-09T12:02:24Z

YaPolkin:

Доступ к Ключ-АСТРОМ Managed могут получить многие пользователи, принадлежащие к разным группам. Количество одновременных сеансов на одну учетную запись пользователя должно быть ограничено до минимума, необходимого для выполнения рабочих обязанностей. Ключ-АСТРОМ Managed дает вам возможность контролировать и ограничивать количество одновременных пользовательских сеансов для каждой учетной записи пользователя.

В меню Ключ-АСТРОМ выберите '''Аутентификация пользователя''' > '''Пользовательские сессии''', чтобы просмотреть или завершить любые текущие сеансы пользователя. В представлении сеансов пользователя указывается тип входа, время входа и IP-адрес или устройство, с которого вход был выполнен.

Типы входа:

* <code>LOCAL</code> - Пользователи, которые существуют только в базе данных кластера и являются локальными по отношению к кластеру.
* <code>LDAP</code> - пользователи LDAP
* <code>SSO</code> - вход от вашего поставщика удостоверений
* <code>DEVOPSTOKEN</code> - вход через проактивную службу поддержки Mission Control

Чтобы завершить сеанс, выберите [[Файл:Remove-icon.png|альт=Удалить]] и подтвердите действие. Сеанс немедленно завершится, и пользователь выйдет из системы.

Чтобы изменить количество разрешенных одновременных пользовательских сеансов, выберите '''Настроить одновременные сеансы'''. Вы можете установить разные лимиты для обычных пользователей и администраторов. Учетные записи администраторов - это пользователи, которые принадлежат к любой группе с глобальными разрешениями администратора кластера.

Чтобы снять все ограничения сеансов для учетных записей администраторов и обычных пользователей, включите '''Неограниченное количество одновременных сеансов'''.

Используйте REST API для обновления политики автоматического выхода из системы. По умолчанию автоматический выход из системы для пользователей, которые остаются на автоматически обновляемых страницах, отсутствует. См. раздел Обновление конфигурации пользовательских сеансов кластера.

Возможности ноды кластера

2022-02-09T11:57:28Z

YaPolkin:

Для некоторых развертываний может потребоваться, чтобы определенные узлы обслуживали только трафик пользовательского интерфейса, а не обрабатывали данные ЕдиногоАгента. Или наоборот, когда узлы обрабатывают только данные ЕдиногоАгента и не обслуживают трафик пользовательского интерфейса. Настроив один или другой из этих параметров, вы можете добиться более высокой стабильности, лучшего поведения кеша и более быстрого времени отклика пользовательского интерфейса.
----<blockquote><big>''Трафик веб-интерфейса''</big>

*

Чтобы повысить производительность балансировки нагрузки DNS, начиная с Ключ-АСТРОМ Managed 1.214, трафик веб-интерфейса по умолчанию отключен при установке 13-го и последующих узлов (или 7-го и последующих узлов в центре обработки данных для Premium HA). Вы можете включить/отключить трафик веб-интерфейса для узла через Cluster REST API (кластерный REST API).

* Примечания к релизу Ключ-АСТРОМ Managed версии 1.214
</blockquote>
----Чтобы включить или отключить трафик ЕдиногоАгента на узле, вы можете использовать веб-интерфейс, командную строку или вызов API.

== Включение/отключение трафика ЕдиногоАгента через пользовательский интерфейс консоли управления кластером ==
Чтобы отключить трафик ЕдиногоАгента (т.е. установить узел кластера в режим ожидания)

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

Чтобы включить трафик ЕдиногоАгента на узле, повторите первые три шага выше, затем выберите '''Включить трафик ЕдиногоАгента''', чтобы начать обработку данных мониторинга на узле.

== Включение/отключение трафика веб-интерфейса через интерфейс консоли управления кластером ==
Чтобы отключить трафик веб-интерфейса (т.е. установить узел кластера в режим ожидания)

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

Чтобы включить трафик веб-интерфейса на узле, повторите первые три шага, описанные выше, затем выберите '''Включить трафик веб-интерфейса''', чтобы начать обработку данных мониторинга на узле.

== Включение/отключение трафика ЕдиногоАгента или веб-интерфейса с помощью вызова API ==
Вы можете настроить эту опцию с помощью вызова API. См. раздел Настройка обязанностей узлов кластера.

=== Аутентификация ===
Чтобы выполнить этот запрос, вам необходимо разрешение на '''управление токеном кластера''', назначенное вашему токену API. Если у вас нет токена API, вы можете его сгенерировать:

# В меню навигации выберите '''Настройки''' и перейдите к '''токенам API'''.
# Нажмите кнопку '''Сгенерировать токен''' и введите имя для своего токена.
# Выберите разрешения '''API поставщика услуг''' и нажмите '''Сгенерировать'''.

Используйте сгенерированный токен API для выполнения вызовов API.

=== Эндпоинт ===
Вы можете выполнить <code>POST</code> в эндпоинт <code>/api/v1.0/onpremise/cluster/configuration</code> со следующими параметрами:
{| class="wikitable"
!Параметр
!Тип
!Описание
!В
!Необходимость
|-
|ID
|integer
|ID ноды
|body
|требуется
|-
|webUI
|boolean
|Устанавливает webUI для этой ноды. Определите, следует ли использовать этот узел для обслуживания запросов WebUI (<code>true</code>/<code>false</code>).
|body
|требуется
|-
|OneAgent
|boolean
|Устанавливает трафик ЕдиногоАгента для этой ноды. Определите, должен ли этот узел получать трафик ЕдиногоАгента (<code>true</code>/<code>false</code>).
|body
|требуется
|-
|datacenter
|string
|не используется.
|body
|не требуется
|}
Пример полезной нагрузки JSON для вызова API:

<code>{</code>

<code> "clusterNodes": [</code>

<code> {</code>

<code> "id": 1,</code>

<code> "webUI": true,</code>

<code> "agent": true,</code>

<code> "datacenter": "dc-1"</code>

<code> },</code>

<code> {</code>

<code> "id": 2,</code>

<code> "webUI": true,</code>

<code> "agent": true,</code>

<code> "datacenter": "dc-1"</code>

<code> }</code>

<code> ]</code>

<code>}</code>

Настройка подключения к SMTP-серверу

2022-02-09T11:38:08Z

YaPolkin:

Используйте эти настройки, чтобы определить, как Ключ-АСТРОМ доставляет пользователям и администраторам уведомления по электронной почте, отчеты и другие сообщения.

1. В меню Ключ-АСТРОМ зайдите в '''Настройки'''.

2. Разверните '''Emails''' и выберите '''SMTP-сервер''', чтобы отобразить страницу '''Настройка SMTP-сервера'''.

3. Начните с выбора способа доставки электронной почты.

* '''SMTP-сервер с резервным режимом Mission Control''' (настройка по умолчанию)

<blockquote>Выберите это, чтобы SMTP-сервер доставлял электронную почту, но использовался Mission Control в качестве резервного метода доставки.

** Пока ваш SMTP-сервер доступен, ваша SMTP-конфигурация определяет, как отправляется электронная почта (почтовый сервер, безопасность соединения и т.д.).
** Если ваш SMTP-сервер становится недоступным, Mission Control доставит ваше письмо с отправляющим адресом <code>noreply@dynatrace-managed.com</code>.
</blockquote>

* '''SMTP-сервер'''

<blockquote>Выберите это, чтобы SMTP-сервер доставлял электронную почту (без резервного метода доставки).

** Ваша конфигурация SMTP определяет, как отправляется ваша электронная почта (почтовый сервер, безопасность соединения и т.д.).
** Если ваш SMTP-сервер станет недоступен, ваше письмо не будет отправлено.
</blockquote>

* '''Mission Control'''

<blockquote>Выберите это, чтобы Mission Control отправлял все электронные письма.

** Все шаги настройки SMTP-сервера, описанные ниже, недоступны, потому что вам не нужно настраивать SMTP-сервер. Ключ-АСТРОМ обо всем позаботится за вас.
** Адрес отправки: <code>noreply@dynatrace-managed.com</code>.
</blockquote>4. Установите для параметра '''Безопасность подключения''' значение протокола безопасности, который вы хотите использовать для своего SMTP-сервера. По умолчанию <code>Без шифрования</code> на порту <code>25</code>.
----<blockquote>
* Если вы измените '''Безопасность подключения''', настройка '''порта''' автоматически изменится, чтобы соответствовать стандартному номеру порта для этого протокола (см. номера портов по умолчанию ниже).
* Если вы вручную измените номер '''порта''', ваши предпочтения запомнятся, и изменение протокола '''Безопасности подключения''' не приведет к автоматическому изменению номера '''порта'''.
</blockquote>
----

* <code>Без шифрования</code>: Небезопасно. Порт по умолчанию: <code>25</code>.

<blockquote>Отправляется электронное письмо в незашифрованном виде. Используйте эту опцию, только если SMTP-сервер не поддерживает никаких других опций.</blockquote>

* <code>Требуется SSL/TLS</code>: Безопасно. Порт по умолчанию: <code>465</code>.
** Если соединение SSL/TLS может быть установлено, отправляется зашифрованное электронное письмо с помощью SSL/TLS.
** Если соединение SSL/TLS не может быть установлено, электронное письмо не отправляется.

* <code>Опционально STARTTLS</code>: Небезопасно. Порт по умолчанию: <code>587</code>.
** Если соединение STARTTLS может быть установлено, отправляется зашифрованное электронное письмо с помощью STARTTLS.
** Если соединение STARTTLS не может быть установлено, отправляется электронное письмо без шифрования.

* <code>Требуется STARTTLS</code>: Безопасно. Порт по умолчанию: <code>587</code>.
** Если соединение STARTTLS может быть установлено, отправляется зашифрованное электронное письмо с помощью STARTTLS.
** Если соединение STARTTLS не может быть установлено, электронное письмо не отправляется.

5. Установите '''Почтовый сервер''' на адрес почтового SMTP-сервера.

6. В поле '''Порт''' укажите номер порта почтового сервера SMTP. Дополнительные сведения см. в разделе '''Безопасность подключения''' выше.

7. Установите '''имя пользователя''' и '''пароль''', если сервер требует аутентификации.

8. Установите '''адрес электронной почты отправителя''' на адрес, который должен отображаться как адрес электронной почты отправителя.

9. Установите '''тестовый адрес электронной почты''' на адрес, на который вы хотите отправлять тестовые сообщения.

10. Выберите '''Отправить тестовое сообщение''', чтобы проверить конфигурацию SMTP, отправив тестовое сообщение на '''тестовый адрес электронной почты'''.

* Через некоторое время отобразится сообщение о состоянии <code>Sending succeeded</code> , если отправка прошла успешно.
* Проверьте почтовый ящик учетной записи '''тестового адреса электронной почты''', чтобы убедиться, что он получил сообщение "Dynatrace Managed: Mail server setup" с ожидаемым адресом электронной почты отправителя.

11. Выберите '''Сохранить изменения''', если конфигурация верна.

Порты ноды кластера

2022-02-08T19:43:34Z

YaPolkin:

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

Обязательно настройте вашу сеть и брандмауэр так, чтобы все порты, перечисленные ниже, были доступны. Обратите внимание, что порты должны быть открыты для двунаправленной связи. Для типичного развертывания мы рекомендуем, чтобы все порты между узлами кластера были открыты.
----<blockquote><big>''Входящие порты''</big>

*

Порт <code>443</code> должен оставаться открытым, чтобы пропускать входящий трафик из вашего центра обработки данных.</blockquote>
----
{| class="wikitable"
!Порт
!Используется
!Примечания
|-
|<code>443</code>
|Ключ-АСТРОМ Managed UI, ЕдиныйАгент и REST API
|Направлено на локальный порт <code>8022</code> с использованием правила предварительной маршрутизации iptables. Этот порт должен оставаться открытым. Вся связь Ключ-АСТРОМ с кластером осуществляется через защищенное соединение HTTPS через сокет (порт 443) с надежной криптографией, чтобы гарантировать конфиденциальность ваших данных.
|-
|<code>8443</code>1
|Данные мониторинга от ЕдиногоАгента, узлов в кластере Ключ-АСТРОМ Managed
|ЕдиныйАгент только отправляет исходящие данные на сервер Ключ-АСТРОМ - он не открывает порт прослушивания. Каждое отслеживаемое устройство с установленным на нем ЕдинымАгентом должно иметь доступ к этому порту. Этот порт должен оставаться открытым для связи между узлами в развертываниях Ключ-АСТРОМ Managed.
|-
|<code>8018</code>
|Nodekeeper
|Этот порт может быть закрыт для трафика, идущего извне кластера Ключ-АСТРОМ. Если вы используете кластер Ключ-АСТРОМ Managed, доступ к этому порту требуется только вашим узлам кластера.
|-
|<code>8019</code>
|Upgrade UI
|Этот порт может быть закрыт для трафика, идущего извне кластера Ключ-АСТРОМ. Если вы используете кластер Ключ-АСТРОМ Managed, доступ к этому порту требуется только вашим узлам кластера.
|-
|<code>8020</code> , <code>8021</code>
|Ключ-АСТРОМ Managed UI и REST API
|Эти порты могут быть закрыты для трафика, идущего извне кластера Ключ-АСТРОМ. Если вы используете кластер Ключ-АСТРОМ Managed, доступ к этим портам требуется только вашим узлам кластера.
|-
|<code>8022</code>
|Ключ-АСТРОМ Managed UI и REST API (NGINX)
|Порт 8022 может быть закрыт для трафика, поступающего извне кластера Ключ-АСТРОМ. Этот порт может использоваться как эквивалент 443, если требуется использование непривилегированного порта.
|-
|<code>5701</code> - <code>5711</code>
|Платформа сетки данных в оперативной памяти Hazelcast
|Отвечает за равномерное распределение данных между узлами кластера. Позволяет горизонтально масштабировать обработку и хранение. Эти порты могут быть закрыты для трафика, идущего извне кластера Ключ-АСТРОМ. Если вы используете кластер Ключ-АСТРОМ Managed, доступ к этим портам требуется только вашим узлам кластера.
|-
|<code>9042</code> , <code>7000</code> , <code>7001</code> , <code>7199</code>
|Хранилище Hypercube на основе Cassandra
|Эти порты могут быть закрыты для трафика, идущего извне кластера Ключ-АСТРОМ. Если вы используете кластер Ключ-АСТРОМ Managed, доступ к этим портам требуется только вашим узлам кластера.
|-
|<code>9200</code> , <code>9300</code>
|Поисковая система на основе Elasticsearch
|Эти порты могут быть закрыты для трафика, идущего извне кластера Ключ-АСТРОМ. Если вы используете кластер Ключ-АСТРОМ Managed, доступ к этим портам требуется только вашим узлам кластера.
|}
1 Среды Ключ-АСТРОМ с версией кластера более ранней, чем 1.166, используют порт <code>8443</code>. В новых средах Ключ-АСТРОМ по-прежнему используется порт <code>8443</code> , но этот порт не нужно открывать для внешних узлов кластера. В обновленных средах Ключ-АСТРОМ сохранены настройки порта из предыдущей версии. В результате можно получить обновленную среду Ключ-АСТРОМ, которая по-прежнему использует порт <code>8443</code>.

=== Исходящая связь с Ключ-АСТРОМ Mission Control ===
Все узлы в кластере должны иметь возможность связываться с Mission Control для получения обновлений программного обеспечения и облегчения обмена данными, используя следующие адреса:

<code>52.5.224.56</code> ,

<code>52.200.165.10</code> ,

<code>13.228.109.33</code> ,

<code>52.221.165.63</code> ,

<code>46.137.81.205</code> ,

<code>52.48.91.146</code>

Используемые домены: <code>mcsvc.dynatrace.com</code> , <code>mcsvc-us.dynatrace.com</code> , <code>mcsvc-eu.dynatrace.com</code> , <code>mcsvc-ap.dynatrace.com</code>.

Все данные кластера, полученные Mission Control через указанные выше эндпоинты, размещаются в регионах США.

Чтобы обеспечить соблюдение ограничений2 США, в случае, если вы сейчас или в любое время в будущем планируете разместить кластер Ключ-АСТРОМ Managed или отслеживать любую технологию с помощью облачных сервисов Huawei (или любой услуги хостинга, предоставляемой аффилированным лицом Huawei Technologies), то вам следует связаться со специалистом по продукту Ключ-АСТРОМ ONE, чтобы установить правильный эндпоинт - Европа или Азия/Тихоокеанский регион.

Сетевая связь устанавливается по протоколам HTTPS и WSS через <code>порт 443</code> и на основе TLS v1.2. Он в основном используется для проверки лицензии, мониторинга работоспособности, автоматических обновлений и удаленного доступа.

Связь между кластерами Ключ-АСТРОМ Managed и Mission Control также можно маршрутизировать через прокси-сервер, но прокси-сервер должен разрешать веб-сокеты и поддерживать расширение SNI TLS и WebSockets.

2 Программное обеспечение Ключ-АСТРОМ нельзя экспортировать или реэкспортировать из США в (a) любую страну Группы E, указанную в ПРИЛОЖЕНИИ №. 1 К ЧАСТИ 740 – ГРУППЫ СТРАН (в настоящее время Сирия, Северная Корея, Иран и Куба) или Крымский регион Украины, или (b) любую компанию, юридическое или физическое лицо, указанное в качестве заинтересованной стороны, находящееся [https://2016.export.gov/ecr/eg_main_023148.asp здесь] (в настоящее время включая Huawei Technologies и ее филиалы по всему миру), или (3) для любого конечного использования, связанного с разработкой, производством или использованием ядерного, химического или биологического оружия или ракет. Наши контракты с нашими клиентами требуют соблюдения этих и других законов об экспортном контроле.