Dynatrace - Вклад [ru]

ВысокаяДоступность — восстановление дата-центра через другой дата-центр

2023-01-26T20:58:30Z

YaPolkin:

Кратковременные отключения (до трех часов) одного ЦОД не требуют никаких действий по восстановлению. Когда недоступный центр обработки данных снова станет доступным, кластер Dynatrace Managed автоматически синхронизирует данные и восстановит работу кластера. Для более длительных отключений (до трех дней) сначала убедитесь, что ноды кластера работают, а затем выполните следующую команду последовательно на всех нодах в восстанавливающемся центре обработки данных:
<code>/opt/astromkey-managed/utils/repair-cassandra-data.sh</code>
При отключении второго дата-центра более чем на три дня часть данных теряется и восстановлению не подлежит. В результате необходимо выполнить восстановление либо из рабочего дата-центра, либо [[ВысокаяДоступность — восстановление дата-центра через резервную копию|из резервной копии]].

== Восстановление дата-центра из другого дата-центра ==
Чтобы восстановить центр обработки данных из другого центра обработки данных, вам необходимо:

# Удалить недоступные ноды из кластера.
# Обновите существующую (уцелевшую) конфигурацию дата-центра.
# Переустановите узлы в восстановленном центре обработки данных.
# Перенесите Cassandra в восстановленный центр обработки данных.
# Перенесите Elasticsearch в восстановленный центр обработки данных.
# Пересоздайте сервер, запустите ActiveGate и NGINX в восстановленном центре обработки данных..
# Включите восстановленный центр обработки данных.

Подробную процедуру см. в разделе [[ВысокаяДоступность — восстановление дата-центра через резервную копию|Восстановление центра обработки данных через резервную копию]].

ВысокаяДоступность — восстановление дата-центра через резервную копию

2023-01-26T20:57:26Z

YaPolkin:

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

* '''DC-1''' - Исходный (уцелевший) ЦОД, в котором расположен кластер.
* '''DC-2''' - Целевой (утерянный) центр обработки данных, предназначенный для восстановления.
* '''Начальный узел''' - Любой узел в '''Исходном-DC''' , который будет использоваться для выполнения задач установки и распространения конфигурации.

Процедура включает миграцию и миграцию управляемых компонентов по отдельности, чтобы они были готовы к миграции данных между двумя центрами обработки данных. См. [https://doc.ruscomtech.ru/index.php/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D1%8B_Managed Компоненты Managed].
==Подготовка==
Убедитесь, что ваша система соответствует указанным требованиям к оборудованию и операционной системе.
===Сбор информации===
Команды будут использовать эти переменные при выполнении вызовов REST API. Для этого вам понадобится следующая информация:
*<code><seed-node-ip></code> - IP-адрес начального узла от '''DC-1'''. Это может быть любой узел, работающий в существующем центре обработки данных, который будет использоваться для выполнения задач установки и распространения конфигурации.
*<code><nodes-ips></code> - Список адресов IPV4 новых узлов в '''DC-2'''. Например, <code>"176.16.0.5", "176.16.0.6", "176.16.0.7"</code>
*<code><api-token></code> - Действительный токен Cluster API (требуется область действия ServiceProviderAPI). Вы можете сгенерировать его в консоли управления управляемым кластером Dynatrace.
*<code><AstromKey-directory></code> - Каталог, в котором установлен Dynatrace Managed на начальном узле. Каталог управляемой установки Dynatrace по умолчанию располагается в директории: <code>/opt/AstromKey-managed</code>
*<code><datacenter-1></code> - Имя '''DC-1''' должно совпадать с именем ЦОД Cassandra. Имя ЦОД Cassandra по умолчанию: <code>datacenter1</code>.
*<code><datacenter-2></code> - Имя '''DC-2''' может быть любой строкой, которая начинается и заканчивается буквенно-цифровым символом и не длиннее 80 символов. В имени разрешены символы подчеркивания и тире. Например, <code>dc-us-east-2</code>.
===Получение название дата-центра===
Чтобы получить имя контроллера домена, выполните эту команду '''на начальном узле''' перед началом миграции:
<code>sudo <AstromKey-directory>/utils/cassandra-nodetool.sh status</code>
Вы получите ответ, содержащий имя '''DC-1'''. Пример для контроллера домена с названием <code>datacenter1</code>:
<code>Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.176.42.20 65.54 GB 256 100.0% f053dd8d-ecf3-7834-b099-68542439817b rack1
UN 10.176.42.244 65.47 GB 256 100.0% 2aa7e790-a423-9273-88f9-45bcd158dd6e rack1
UN 10.176.42.168 65.47 GB 256 100.0% 48543bca-41f5-26d3-b2fd-6cfdf5c0f3b2 rack1</code>
===Установка переменных===
Чтобы упростить многочисленные вызовы REST API во время развертывания, задайте переменные среды на каждом узле в '''DC-1''' и '''DC-2'''.
<code>SEED_IP=<seed-ip>
DT_DIR=<AstromKey-directory>
NODES_IPS=$(echo '[<nodes-ips]')
API_TOKEN=<api-token>
SDC_NAME=<datacenter-1>
TDC_NAME=<datacenter-2></code>
Например,
<code>SEED_IP=10.176.37.201
DT_DIR=/opt/AstromKey-managed
NODES_IPS=$(echo '["10.176.37.218", "10.176.37.227", "10.176.37.120"]')
API_TOKEN=R_SZOpV4RTOmjr9fFmK4x
SDC_NAME=datacenter1
TDC_NAME=dc-us-east-2</code>
===Проверка дополнительных настроек===
Если ваш кластер Cassandra или Elasticsearch настроен с <code>custom.settings</code> которые включают поддержку стойки, свяжитесь с командой Dynatrace, чтобы применить эти пользовательские настройки, прежде чем продолжить установку '''DC-2'''.

Чтобы проверить, применяются ли пользовательские настройки, выполните '''на начальном узле''':
<code>ls $DT_DIR/installer/custom.settings</code>
Если файл <code>custom.settings</code> существует, вы используете пользовательские настройки.
==Установка==

=== Удаление Dynatrace Managed на всех работающих узлах. ===
Следуйте официальной процедуре удаления узла кластера с помощью командной строки или консоли управления кластером. См. [[Удаление ноды кластера]].

=== Восстановление ЦОД из резервной копии ===
Следуйте официальной процедуре восстановления центра обработки данных из резервной копии. См. [[Резервное копирование и восстановление кластера]].
=== Удаление потерянного дата-центра из конфигурации ===
Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/lostDatacenterCleanUp?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code> и в ответе не предлагаются следующие шаги, свяжитесь с командой Dynatrace.

=== Копирование установщика ===
На этом шаге вы скопируете установщик узла на каждый узел в '''DC-2'''.
#Войти в '''Консоль Менеджмента Кластера'''.
#В меню выберите '''Домашняя страница'''.
#Щелкните '''Добавить новый узел кластера'''.
#Скопируйте командную строку <code>wget</code> из текстового поля '''Выполнить эту команду на целевом хосте'''. ''Важно! Не запускайте скрипт установки''.
#Вставьте и выполните <code>wget</code> в окне терминала.
===Подготовка данных кластера для миграции===
Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clustermigratePreparation?Api-Token=$API_TOKEN</nowiki></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с командой Dynatrace.
====Проверка статуса подготовки кластера====
Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clustermigratePreparation?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json"</code>
Если код состояния этого звонка не равен <code>200</code>, повторите попытку через несколько минут.
===Создание топологии центра обработки данных===
На этом шаге вы создадите конфигурацию, определяющую, какой узел принадлежит какому центру обработки данных.

Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST -d "{\"newDatacenterName\" : \"$DC2_NAME\", \"nodesIp\" :$NODES_IPS}" <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/datacenterTopology?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с командой Dynatrace.
===Открытие правил брандмауэра===
====Открытие портов====
Чтобы открыть порты для трафика с новых узлов '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST -d "$NODES_IPS" <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния правил брандмауэра.

Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с командой Dynatrace.
====Подтверждение правил брандмауэра====
Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<topology-configuration-request-id></code>
Чтобы проверить состояние правил брандмауэра, выполните следующий вызов API кластера '''только на начальном узле:'''
<code>curl -ikS <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния этого звонка не равен <code>200</code>, повторите попытку через несколько минут.
===Установка нод в Целевой-DC===
Выполните следующую команду на каждом узле в '''DC-2'''. Следуйте инструкциям на экране, так как это будет обычная установка узла.
<code>sudo /bin/sh ./managed-installer.sh --install-new-dc --premium-ha on --datacenter $DC2_NAME --seed-auth $API_TOKEN</code>
Эта операция должна занять от 3 до 5 минут, а ожидаемый результат должен быть примерно таким:
<code>Installation in new data center completed successfully after 2 minutes 51 seconds.</code>
====Проверка Nodekeeper в DC-2====
Выполните следующий вызов API кластера '''только на начальном узле''', когда все узлы в '''DC-2''' закончат установку:
<code>curl -ikS <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/nodekeeper/healthCheck?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
===Миграция Cassandra===
На этом шаге вы перенастроите Cassandra в '''DC-1''' и '''DC-2''' для миграции между центрами обработки данных, инициируете синхронизацию данных, перестроите данные Cassandra и проверите состояние Cassandra.

Это может занять от нескольких минут до нескольких часов, в зависимости от размера хранилища метрик.
====Миграция Cassandra в DC-1====
Чтобы запустить миграцию Cassandra в центре обработки данных '''DC-1''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния миграции. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<migration-old-datacenter-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.
====Проверка статуса миграции====
Чтобы проверить состояние миграции, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
====Миграция Cassandra в DC-2====
Чтобы запустить миграцию Cassandra в центре обработки данных '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния миграции. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<migration-new-datacenter-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.
====Проверка статуса миграции====
Чтобы проверить состояние миграции, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
====Восстановление данных Cassandra====
Чтобы перестроить Cassandra, последовательно выполните следующую команду на каждом новом узле '''DC-2'''. Используйте команду nohup, чтобы предотвратить прерывание выполнения сценария (например, отключение сеанса) во время важных операций.
<code>sudo nohup $DT_DIR/utils/cassandra-nodetool.sh rebuild -- $DC1_NAME &</code>
=====Проверка прогресса и статуса=====
Чтобы проверить ход выполнения и статус, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/rebuildStatus?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку примерно через 15 минут. Помните, что процесс восстановления может занять много времени.
====Проверка состояния Кассандры====
Чтобы проверить состояние кластера Cassandra, выполните <code>cassandra-nodetool.sh</code> с параметром состояния '''только на начальном узле''':
<code>sudo $DT_DIR/utils/cassandra-nodetool.sh status</code>
Результат должен выглядеть примерно так:
<code>Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.176.41.167 18.82 GB 256 100.0% 3af25127-4f99-4f43-afc3-216d7a2c10f8 rack1
UN 10.176.41.154 19.44 GB 256 100.0% 5a618559-3a73-42ec-83f0-32d28e08beec rack1
UN 10.176.41.43 19.58 GB 256 100.0% 191f3b30-949a-4cf2-b620-68a40eebf31e rack1
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.176.42.54 19.18 GB 256 100.0% 852ce236-a430-400a-92a6-daeed99acf68 rack1
UN 10.176.42.104 19.12 GB 256 100.0% 84479219-b64d-442c-a807-a832db9aae18 rack1
UN 10.176.42.234 19.4 GB 256 100.0% 507b377c-5bfc-4667-b251-a9b7c453ed22 rack1</code>
Значение '''нагрузки''' не должно существенно различаться между узлами, а '''состояние''' должно быть <code>UN</code> на всех узлах.
===Миграция Elasticsearch===
Чтобы запустить миграцию Elasticsearch в центр обработки данных '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния миграции. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<migration-elasticsearch-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.
====Проверка прогресса и статуса====
Чтобы проверить состояние миграции Elasticsearch, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/restore/elasticsearch/recover/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
====Проверка миграции данных====
Чтобы проверить миграцию миграции данных Elasticsearch, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch/indexMigrationStatus?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
===Перенос сервера===
Запустите управляемый кластер Dynatrace в '''DC-2''', выполнив следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/restore/server/recovery?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки готовности кластера. Установите '''переменную среды идентификатора запроса''' '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<migration-server-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.
====Проверить готовность кластера====
Чтобы проверить, готов ли кластер, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/server/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
===Включение нового дата-центра===
#Включите трафик OneAgent.
#Включите резервное копирование в центрах обработки данных. Ваша резервная копия отключена после переноса.

ВысокаяДоступность — переустановка дата-центра

2023-01-26T20:52:32Z

YaPolkin:

В данной восстановительной процедуре следующие термины обозначаются следующим образом:
*'''DC-1''' - Исходный (уцелевший) ЦОД, в котором расположен кластер.
*'''DC-2''' - Целевой (утерянный) центр обработки данных, предназначенный для восстановления.
*'''Начальный узел''' - Любой узел в '''Исходном-DC''' , который будет использоваться для выполнения задач установки и распространения конфигурации.
Процедура включает миграцию и миграцию управляемых компонентов по отдельности, чтобы они были готовы к миграции данных между двумя центрами обработки данных. См. [https://doc.ruscomtech.ru/index.php/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D1%8B_Managed Компоненты Managed].
==Подготовка==
Убедитесь, что ваша система соответствует указанным требованиям к оборудованию и операционной системе.
===Сбор информации===
Команды будут использовать эти переменные при выполнении вызовов REST API. Для этого вам понадобится следующая информация:
*<code><seed-node-ip></code> - IP-адрес начального узла от '''DC-1'''. Это может быть любой узел, работающий в существующем центре обработки данных, который будет использоваться для выполнения задач установки и распространения конфигурации.
*<code><nodes-ips></code> - Список адресов IPV4 новых узлов в '''DC-2'''. Например, <code>"176.16.0.5", "176.16.0.6", "176.16.0.7"</code>
*<code><api-token></code> - Действительный токен Cluster API (требуется область действия ServiceProviderAPI). Вы можете сгенерировать его в консоли управления управляемым кластером Dynatrace.
*<code><AstromKey-directory></code> - Каталог, в котором установлен Dynatrace Managed на начальном узле. Каталог управляемой установки Dynatrace по умолчанию располагается в директории: <code>/opt/AstromKey-managed</code>
*<code><datacenter-1></code> - Имя '''DC-1''' должно совпадать с именем ЦОД Cassandra. Имя ЦОД Cassandra по умолчанию: <code>datacenter1</code>.
*<code><datacenter-2></code> - Имя '''DC-2''' может быть любой строкой, которая начинается и заканчивается буквенно-цифровым символом и не длиннее 80 символов. В имени разрешены символы подчеркивания и тире. Например, <code>dc-us-east-2</code>.
===Получение название дата-центра===
Чтобы получить имя контроллера домена, выполните эту команду '''на начальном узле''' перед началом миграции:
<code>sudo <AstromKey-directory>/utils/cassandra-nodetool.sh status</code>
Вы получите ответ, содержащий имя '''DC-1'''. Пример для контроллера домена с названием <code>datacenter1</code>:
<code>Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.176.42.20 65.54 GB 256 100.0% f053dd8d-ecf3-7834-b099-68542439817b rack1
UN 10.176.42.244 65.47 GB 256 100.0% 2aa7e790-a423-9273-88f9-45bcd158dd6e rack1
UN 10.176.42.168 65.47 GB 256 100.0% 48543bca-41f5-26d3-b2fd-6cfdf5c0f3b2 rack1</code>
===Установка переменных===
Чтобы упростить многочисленные вызовы REST API во время развертывания, задайте переменные среды на каждом узле в '''DC-1''' и '''DC-2'''.
<code>SEED_IP=<seed-ip>
DT_DIR=<AstromKey-directory>
NODES_IPS=$(echo '[<nodes-ips]')
API_TOKEN=<api-token>
SDC_NAME=<datacenter-1>
TDC_NAME=<datacenter-2></code>
Например,
<code>SEED_IP=10.176.37.201
DT_DIR=/opt/AstromKey-managed
NODES_IPS=$(echo '["10.176.37.218", "10.176.37.227", "10.176.37.120"]')
API_TOKEN=R_SZOpV4RTOmjr9fFmK4x
SDC_NAME=datacenter1
TDC_NAME=dc-us-east-2</code>
===Проверка дополнительных настроек===
Если ваш кластер Cassandra или Elasticsearch настроен с <code>custom.settings</code> которые включают поддержку стойки, свяжитесь с командой Dynatrace, чтобы применить эти пользовательские настройки, прежде чем продолжить установку '''DC-2'''.

Чтобы проверить, применяются ли пользовательские настройки, выполните '''на начальном узле''':
<code>ls $DT_DIR/installer/custom.settings</code>
Если файл <code>custom.settings</code> существует, вы используете пользовательские настройки.
==Установка==

=== Коды ответов API ===
Каждый из вызовов REST API будет возвращать код HTTP. Переходите к следующему шагу, только если возвращаемый код равен <code>200</code>. Все коды возврата:

<code>200</code> - переходите к следующему шагу, текущий шаг выполнен успешно.

<code>207</code> - Запрос обрабатывается, повторите шаг через несколько минут.

<code>40x</code> - Измените путь и аргументы запроса и повторите запрос..

<code>5xx</code> - Свяжитесь с поддержкой.

=== Остановка работы недоступного дата-центра ===
Остановите все необходимые службы Dynatrace Managed в рекомендованном порядке. См. раздел [[Запуск/остановка/перезапуск кластера]].

=== Удаление узлов ===

# Перейдите в Консоль Менеджмента Кластера.
# Для каждого узла в недоступном центре обработки данных перейдите на страницу сведений об узле и удалите узел..

Дополнительные сведения о других способах удаления узла см. в разделе [[Удаление ноды кластера]].

===Удаление потерянного дата-центра из конфигурации===
Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/lostDatacenterCleanUp?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code> и в ответе не предлагаются следующие шаги, свяжитесь с командой Dynatrace.
===Копирование установщика===
На этом шаге вы скопируете установщик узла на каждый узел в '''DC-2'''.
#Войти в '''Консоль Менеджмента Кластера'''.
#В меню выберите '''Домашняя страница'''.
#Щелкните '''Добавить новый узел кластера'''.
#Скопируйте командную строку <code>wget</code> из текстового поля '''Выполнить эту команду на целевом хосте'''. ''Важно! Не запускайте скрипт установки''.
#Вставьте и выполните <code>wget</code> в окне терминала.
===Подготовка данных кластера для миграции===
Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clustermigratePreparation?Api-Token=$API_TOKEN</nowiki></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с командой Dynatrace.
====Проверка статуса подготовки кластера====
Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clustermigratePreparation?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json"</code>
Если код состояния этого звонка не равен <code>200</code>, повторите попытку через несколько минут.
===Создание топологии центра обработки данных===
На этом шаге вы создадите конфигурацию, определяющую, какой узел принадлежит какому центру обработки данных.

Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST -d "{\"newDatacenterName\" : \"$DC2_NAME\", \"nodesIp\" :$NODES_IPS}" <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/datacenterTopology?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с командой Dynatrace.
===Открытие правил брандмауэра===
====Открытие портов====
Чтобы открыть порты для трафика с новых узлов '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST -d "$NODES_IPS" <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния правил брандмауэра.

Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с командой Dynatrace.
====Подтверждение правил брандмауэра====
Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<topology-configuration-request-id></code>
Чтобы проверить состояние правил брандмауэра, выполните следующий вызов API кластера '''только на начальном узле:'''
<code>curl -ikS <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния этого звонка не равен <code>200</code>, повторите попытку через несколько минут.
===Установка нод в Целевой-DC===
Выполните следующую команду на каждом узле в '''DC-2'''. Следуйте инструкциям на экране, так как это будет обычная установка узла.
<code>sudo /bin/sh ./managed-installer.sh --install-new-dc --premium-ha on --datacenter $DC2_NAME --seed-auth $API_TOKEN</code>
Эта операция должна занять от 3 до 5 минут, а ожидаемый результат должен быть примерно таким:
<code>Installation in new data center completed successfully after 2 minutes 51 seconds.</code>
====Проверка Nodekeeper в DC-2====
Выполните следующий вызов API кластера '''только на начальном узле''', когда все узлы в '''DC-2''' закончат установку:
<code>curl -ikS <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/nodekeeper/healthCheck?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
===Миграция Cassandra===
На этом шаге вы перенастроите Cassandra в '''DC-1''' и '''DC-2''' для миграции между центрами обработки данных, инициируете синхронизацию данных, перестроите данные Cassandra и проверите состояние Cassandra.

Это может занять от нескольких минут до нескольких часов, в зависимости от размера хранилища метрик.
====Миграция Cassandra в DC-1====
Чтобы запустить миграцию Cassandra в центре обработки данных '''DC-1''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния миграции. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<migration-old-datacenter-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.
====Проверка статуса миграции====
Чтобы проверить состояние миграции, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
====Миграция Cassandra в DC-2====
Чтобы запустить миграцию Cassandra в центре обработки данных '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния миграции. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<migration-new-datacenter-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.
====Проверка статуса миграции====
Чтобы проверить состояние миграции, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
====Восстановление данных Cassandra====
Чтобы перестроить Cassandra, последовательно выполните следующую команду на каждом новом узле '''DC-2'''. Используйте команду nohup, чтобы предотвратить прерывание выполнения сценария (например, отключение сеанса) во время важных операций.
<code>sudo nohup $DT_DIR/utils/cassandra-nodetool.sh rebuild -- $DC1_NAME &</code>
=====Проверка прогресса и статуса=====
Чтобы проверить ход выполнения и статус, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/rebuildStatus?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку примерно через 15 минут. Помните, что процесс восстановления может занять много времени.
====Проверка состояния Кассандры====
Чтобы проверить состояние кластера Cassandra, выполните <code>cassandra-nodetool.sh</code> с параметром состояния '''только на начальном узле''':
<code>sudo $DT_DIR/utils/cassandra-nodetool.sh status</code>
Результат должен выглядеть примерно так:
<code>Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.176.41.167 18.82 GB 256 100.0% 3af25127-4f99-4f43-afc3-216d7a2c10f8 rack1
UN 10.176.41.154 19.44 GB 256 100.0% 5a618559-3a73-42ec-83f0-32d28e08beec rack1
UN 10.176.41.43 19.58 GB 256 100.0% 191f3b30-949a-4cf2-b620-68a40eebf31e rack1
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.176.42.54 19.18 GB 256 100.0% 852ce236-a430-400a-92a6-daeed99acf68 rack1
UN 10.176.42.104 19.12 GB 256 100.0% 84479219-b64d-442c-a807-a832db9aae18 rack1
UN 10.176.42.234 19.4 GB 256 100.0% 507b377c-5bfc-4667-b251-a9b7c453ed22 rack1</code>
Значение '''нагрузки''' не должно существенно различаться между узлами, а '''состояние''' должно быть <code>UN</code> на всех узлах.
===Миграция Elasticsearch===
Чтобы запустить миграцию Elasticsearch в центр обработки данных '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния миграции. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<migration-elasticsearch-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.
====Проверка прогресса и статуса====
Чтобы проверить состояние миграции Elasticsearch, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/restore/elasticsearch/recover/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
====Проверка миграции данных====
Чтобы проверить миграцию миграции данных Elasticsearch, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch/indexMigrationStatus?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
===Перенос сервера===
Запустите управляемый кластер Dynatrace в '''DC-2''', выполнив следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/restore/server/recovery?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки готовности кластера. Установите '''переменную среды идентификатора запроса''' '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<migration-server-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.
====Проверить готовность кластера====
Чтобы проверить, готов ли кластер, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/server/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.
===Включение нового дата-центра===
#Включите трафик OneAgent.
#Включите резервное копирование в центрах обработки данных. Ваша резервная копия отключена после переноса.

ВысокаяДоступность — репликация нод между дата-центрами

2023-01-26T20:51:40Z

YaPolkin:

Для развертывания ВысокойДоступности необходим избыточный набор узлов в исходном развертывании кластера. Такие развертывания ВысокойДоступности охватывают несколько центров обработки данных. Dynatrace Managed позволяет добавлять зеркальные узлы, расположенные в другом центре обработки данных.

В этой статье применяются следующие термины:

* '''DC-1''' — центр обработки данных, в котором расположен исходный управляемый кластер.
* '''DC-2''' — дополнительный центр обработки данных, предназначенный для развертывания Dynatrace ВысокаяДоступность.
* '''Начальный узел''' — любой узел в DC-1, который будет использоваться для выполнения задач установки и распространения конфигурации.

Процедура включает миграцию и репликацию управляемых компонентов по отдельности, чтобы они были готовы к репликации данных между двумя центрами обработки данных. См. [[Компоненты Managed]].

== Требования ==

* Лицензия Высокая Доступность. См. [[Расчет потребления мониторинга]].
* Версия кластера '''DC-1''' должна быть 1.222+.
* В кластере '''DC-1''' необходимо отключить резервное копирование перед началом процедуры миграции. Мы рекомендуем создать новую резервную копию кластера и отключить резервную копию кластера незадолго до развертывания дополнительного центра обработки данных.
* Миграция не должна занимать более четырех недель. Если ваша миграция продлится более четырех недель, свяжитесь с командой Dynatrace .
* Перед началом процедуры миграции необходимо отключить автоматическое обновление кластера '''DC-1'''. Кластер нельзя обновлять во время миграции. См. [[Обновление Ключ-АСТРОМ Managed|Автоматическое обновление]]. Свяжитесь с командой Dynatrace, если опция автоматического обновления отключена.
* Убедитесь, что машины подготовлены для кластера в '''DC-2'''. Поскольку '''DC-2''' будет реплицировать данные '''DC-1''', мы рекомендуем назначить такое же количество узлов с тем же оборудованием, включая дисковое хранилище. Все узлы в '''DC-1''' и '''DC-2''' должны быть синхронизированы по времени. Этого можно добиться, настроив сетевой протокол времени (NTP).

* Для развертывания ВысокойДоступности требуется как минимум три узла в '''DC-1''' и три соответствующих узла в '''DC-2'''.
* Убедитесь, что все узлы в обоих центрах обработки данных могут взаимодействовать друг с другом. Чтобы проверить, доступен ли узел в '''DC-1''' с хоста в '''DC-2''', вы можете выполнить вызов REST для проверки работоспособности. Например, выполните следующую команду с хоста в '''DC-2''':

<code>curl -k https://<DC-1-node-IP>/rest/health</code>
где <code><DC-1-node-IP></code> — IP-адрес любого узла в '''DC-1'''. Вы должны получить <code>«RUNNING»</code> в ответ, если соединение может быть установлено успешно.

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

=== Сбор информации ===
Команды будут использовать эти переменные при выполнении вызовов REST API. Для этого вам понадобится следующая информация:

* <code><seed-node-ip></code> - IP-адрес начального узла от '''DC-1'''. Это может быть любой узел, работающий в существующем центре обработки данных, который будет использоваться для выполнения задач установки и распространения конфигурации.
* <code><nodes-ips></code> - Список адресов IPV4 новых узлов в '''DC-2'''. Например, <code>"176.16.0.5", "176.16.0.6", "176.16.0.7"</code>
* <code><api-token></code> - Действительный токен Cluster API (требуется область действия ServiceProviderAPI). Вы можете сгенерировать его в консоли управления управляемым кластером Dynatrace.
* <code><AstromKey-directory></code> - Каталог, в котором установлен Dynatrace Managed на начальном узле. Каталог управляемой установки Dynatrace по умолчанию располагается в директории: <code>/opt/AstromKey-managed</code>
* <code><datacenter-1></code> - Имя '''DC-1''' должно совпадать с именем ЦОД Cassandra. Имя ЦОД Cassandra по умолчанию: <code>datacenter1</code>.
* <code><datacenter-2></code> - Имя '''DC-2''' может быть любой строкой, которая начинается и заканчивается буквенно-цифровым символом и не длиннее 80 символов. В имени разрешены символы подчеркивания и тире. Например, <code>dc-us-east-2</code>.

=== Получение название дата-центра ===
Чтобы получить имя контроллера домена, выполните эту команду '''на начальном узле''' перед началом миграции:
<code>sudo <AstromKey-directory>/utils/cassandra-nodetool.sh status</code>
Вы получите ответ, содержащий имя '''DC-1'''. Пример для контроллера домена с названием <code>datacenter1</code>:
<code>Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.176.42.20 65.54 GB 256 100.0% f053dd8d-ecf3-7834-b099-68542439817b rack1
UN 10.176.42.244 65.47 GB 256 100.0% 2aa7e790-a423-9273-88f9-45bcd158dd6e rack1
UN 10.176.42.168 65.47 GB 256 100.0% 48543bca-41f5-26d3-b2fd-6cfdf5c0f3b2 rack1</code>

=== Установка переменных ===
Чтобы упростить многочисленные вызовы REST API во время развертывания, задайте переменные среды на каждом узле в '''DC-1''' и '''DC-2'''.
<code>SEED_IP=<seed-ip>
DT_DIR=<AstromKey-directory>
NODES_IPS=$(echo '[<nodes-ips]')
API_TOKEN=<api-token>
DC1_NAME=<datacenter-1>
DC2_NAME=<datacenter-2></code>
Например,
<code>SEED_IP=10.176.37.201
DT_DIR=/opt/AstromKey-managed
NODES_IPS=$(echo '["10.176.37.218", "10.176.37.227", "10.176.37.120"]')
API_TOKEN=R_SZOpV4RTOmjr9fFmK4x
DC1_NAME=datacenter1
DC2_NAME=dc-us-east-2</code>

=== Проверка дополнительных настроек ===
Если ваш кластер Cassandra или Elasticsearch настроен с <code>custom.settings</code> которые включают поддержку стойки, свяжитесь с командой Dynatrace, чтобы применить эти пользовательские настройки, прежде чем продолжить установку '''DC-2'''.

Чтобы проверить, применяются ли пользовательские настройки, выполните '''на начальном узле''':
<code>ls $DT_DIR/installer/custom.settings</code>
Если файл <code>custom.settings</code> существует, вы используете пользовательские настройки.

== Установка ==

=== Обновление Elasticsearch ===
Обновите Elasticsearch до нужной версии. Последовательно выполните следующую команду на каждом существующем узле '''DC-1''':
<code>sudo nohup $DT_DIR/installer/reconfigure.sh --only els --premium-ha on &</code>

=== Копирование установщика ===
На этом шаге вы скопируете установщик узла на каждый узел в '''DC-2'''.

# Войти в '''Консоль Менеджмента Кластера'''.
# В меню выберите '''Домашняя страница'''.
# Щелкните '''Добавить новый узел кластера'''.
# Скопируйте командную строку <code>wget</code> из текстового поля '''Выполнить эту команду на целевом хосте'''. ''Важно! Не запускайте скрипт установки''.
# Вставьте и выполните <code>wget</code> в окне терминала.

=== Подготовка данных кластера для репликации ===
Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterReplicationPreparation?Api-Token=$API_TOKEN</nowiki></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с командой Dynatrace.

==== Проверка статуса подготовки кластера ====
Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterReplicationPreparation?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json"</code>
Если код состояния этого звонка не равен <code>200</code>, повторите попытку через несколько минут.

=== Создание топологии центра обработки данных ===
На этом шаге вы создадите конфигурацию, определяющую, какой узел принадлежит какому центру обработки данных.

Выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST -d "{\"newDatacenterName\" : \"$DC2_NAME\", \"nodesIp\" :$NODES_IPS}" <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/datacenterTopology?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с командой Dynatrace.

=== Открытие правил брандмауэра ===

==== Открытие портов ====
Чтобы открыть порты для трафика с новых узлов '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST -d "$NODES_IPS" <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния правил брандмауэра.

Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с командой Dynatrace.

==== Подтверждение правил брандмауэра ====
Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<topology-configuration-request-id></code>
Чтобы проверить состояние правил брандмауэра, выполните следующий вызов API кластера '''только на начальном узле:'''
<code>curl -ikS <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния этого звонка не равен <code>200</code>, повторите попытку через несколько минут.

=== Установка нод в DC-2 ===
Выполните следующую команду на каждом узле в '''DC-2'''. Следуйте инструкциям на экране, так как это будет обычная установка узла.
<code>sudo /bin/sh ./managed-installer.sh --install-new-dc --premium-ha on --datacenter $DC2_NAME --seed-auth $API_TOKEN</code>
Эта операция должна занять от 3 до 5 минут, а ожидаемый результат должен быть примерно таким:
<code>Installation in new data center completed successfully after 2 minutes 51 seconds.</code>

==== Проверка Nodekeeper в DC-2 ====
Выполните следующий вызов API кластера '''только на начальном узле''', когда все узлы в '''DC-2''' закончат установку:
<code>curl -ikS <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/nodekeeper/healthCheck?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

=== Репликация Cassandra ===
На этом шаге вы перенастроите Cassandra в '''DC-1''' и '''DC-2''' для репликации между центрами обработки данных, инициируете синхронизацию данных, перестроите данные Cassandra и проверите состояние Cassandra.

Это может занять от нескольких минут до нескольких часов, в зависимости от размера хранилища метрик.

==== Репликация Cassandra в DC-1 ====
Чтобы запустить репликацию Cassandra в центре обработки данных '''DC-1''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния репликации. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<replication-old-datacenter-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.

==== Проверка статуса репликации ====
Чтобы проверить состояние репликации, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

==== Репликация Cassandra в DC-2 ====
Чтобы запустить репликацию Cassandra в центре обработки данных '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния репликации. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<replication-new-datacenter-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.

==== Проверка статуса репликации ====
Чтобы проверить состояние репликации, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

==== Восстановление данных Cassandra ====
Чтобы перестроить Cassandra, последовательно выполните следующую команду на каждом новом узле '''DC-2'''. Используйте команду nohup, чтобы предотвратить прерывание выполнения сценария (например, отключение сеанса) во время важных операций.
<code>sudo nohup $DT_DIR/utils/cassandra-nodetool.sh rebuild -- $DC1_NAME &</code>

===== Проверка прогресса и статуса =====
Чтобы проверить ход выполнения и статус, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/rebuildStatus?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку примерно через 15 минут. Помните, что процесс восстановления может занять много времени.

==== Проверка состояния Кассандры ====
Чтобы проверить состояние кластера Cassandra, выполните <code>cassandra-nodetool.sh</code> с параметром состояния '''только на начальном узле''':
<code>sudo $DT_DIR/utils/cassandra-nodetool.sh status</code>
Результат должен выглядеть примерно так:
<code>Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.176.41.167 18.82 GB 256 100.0% 3af25127-4f99-4f43-afc3-216d7a2c10f8 rack1
UN 10.176.41.154 19.44 GB 256 100.0% 5a618559-3a73-42ec-83f0-32d28e08beec rack1
UN 10.176.41.43 19.58 GB 256 100.0% 191f3b30-949a-4cf2-b620-68a40eebf31e rack1
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.176.42.54 19.18 GB 256 100.0% 852ce236-a430-400a-92a6-daeed99acf68 rack1
UN 10.176.42.104 19.12 GB 256 100.0% 84479219-b64d-442c-a807-a832db9aae18 rack1
UN 10.176.42.234 19.4 GB 256 100.0% 507b377c-5bfc-4667-b251-a9b7c453ed22 rack1</code>
Значение '''нагрузки''' не должно существенно различаться между узлами, а '''состояние''' должно быть <code>UN</code> на всех узлах.

=== Репликация Elasticsearch ===
Чтобы запустить репликацию Elasticsearch в центр обработки данных '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния репликации. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<replication-elasticsearch-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.

==== Проверка прогресса и статуса ====
Чтобы проверить состояние репликации Elasticsearch, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

==== Проверка репликации данных ====
Чтобы проверить репликацию репликации данных Elasticsearch, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch/indexMigrationStatus?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

=== Перенос сервера ===
Запустите управляемый кластер Dynatrace в '''DC-2''', выполнив следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/server?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки готовности кластера. Установите '''переменную среды идентификатора запроса''' '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
<code>REQ_ID=<replication-server-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Dynatrace.

==== Проверить готовность кластера ====
Чтобы проверить, готов ли кластер, выполните следующий вызов API кластера '''только на начальном узле''':
<code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/server/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

=== Включение нового дата-центра ===

# Включите трафик OneAgent.
# Включите резервное копирование в центрах обработки данных. Ваша резервная копия отключена после переноса.

=== Реконфигурация DC-1 ===
Выполните следующую команду последовательно на каждом узле только в '''DC-1'''.
<code>sudo nohup $DT_DIR/installer/reconfigure.sh &</code>

ВысокаяДоступность для дата-центров

2023-01-26T20:47:20Z

YaPolkin:

'''Dynatrace ВысокаяДоступность''' — это готовое автономное решение, обеспечивающее почти нулевое время простоя и позволяющее продолжать мониторинг без потери данных в сценариях отработки отказа.

Это решение обеспечивает экономию средств с точки зрения выделения вычислительных ресурсов и хранилища за счет устранения необходимости в отдельных резервных хостах аварийного восстановления и соответствующей инфраструктуре для хранения и передачи данных резервного копирования. Хотя дополнительные узлы в одноранговом центре обработки данных (ЦОД) положительно влияют на вычислительную мощность, доступную для кластера, это влияние нелинейно.

При планировании емкости узлы в дополнительном дата-центре следует рассматривать как избыточные, а не как узлы с увеличенной емкостью. Это связано с тем, что дополнительный дата-центр будет иметь копию всех данных Cassandra и Elasticsearch из исходного дата-центра.

'''Максимальное количество узлов, поддерживаемых кластерами''' высокой доступности Dynatrace, равно 30 (15 узлов на дата-центр).

'''Эффективный минимум''' — 6 узлов (3 узла на дата-центр). Оба дата-центра в кластере должны иметь симметричный размер.

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

Короткие, до 3 часов, сбои в сети между центрами обработки данных восстанавливаются автоматически. Чтобы избежать несогласованности данных, в случае более длительных простоев мы рекомендуем отключать серверную службу на всех узлах в затронутом центре обработки данных. Вы можете запустить службы, когда сетевое подключение снова станет стабильным.

Чтобы справиться с ситуацией, когда одна часть кластера недоступна, Dynatrace Контроллер Задач отслеживает работоспособность всех узлов и автоматически назначает одну часть кластера основной (выживающей). Во время восстановления это обозначение используется для определения способа повторной синхронизации всех частей кластера. Это означает, что Dynatrace ВысокаяДоступность не поддерживается для полностью автономных управляемых кластеров.

== Разделение и репликация данных ==
Используя виртуальные стойки, Dynatrace ВысокаяДоступность хранит три копии всех данных конфигурации, метрик и сеансов пользователей в каждом дата-центре. Это обеспечивает оптимальную производительность и надежность в сценариях отработки отказа.

Необработанные данные транзакций (такие как распределенные трассировки, стеки вызовов и операторы базы данных) распределяются случайным образом по всем дата-центрам, поэтому на каждом дата-центре всегда доступен набор данных. Данные синхронизируются асинхронно между дата-центрами. Это устраняет требование к задержке в 10 мс, которое применяется ко всем кластерам с несколькими дата-центрами.

Синхронизация данных спроектирована таким образом, чтобы свести к минимуму использование полосы пропускания между контроллерами домена и предотвратить потерю данных в случае выхода из строя одного из контроллеров домена. Во время перерывов в работе менее трех часов Dynatrace ВысокаяДоступность автоматически и прозрачно повторно синхронизирует данные между контроллерами домена. При простоях продолжительностью до трех дней команда Dynatrace Контроль Задач инициирует необходимые работы по ремонту и синхронизации. После этого неисправную часть кластера необходимо переустановить.

== Маршрутизация данных телеметрии ==
Сетевые зоны можно использовать для управления потоком данных телеметрии к узлам кластера в различных дата-центрах. Несмотря на то, что Dynatrace ВысокаяДоступность реализует различные оптимизации для уменьшения трафика между дата-центрами, мы рекомендуем для избыточности данных разрешить ActiveGate'ам отправлять данные на оба дата-центра. OneAgent'ы и ActiveGate'ы можно настроить так, чтобы они предпочитали определенные сетевые зоны, сохраняя при этом возможность аварийного переключения на другую часть кластера в случае сбоя дата-центра. Обратите внимание, что для этой цели также можно использовать балансировщики нагрузки. Для активно-пассивных развертываний приложений мы рекомендуем не отключать ActiveGate'ы в пассивных частях развертывания. Это поддерживает работу всех частей инфраструктуры Dynatrace в случае аварийного восстановления и обеспечивает аварийное переключение без повторной настройки или повторного обнаружения.

== Технические подробности ==
Для ВысокойДоступности требуется ОС, поддерживающая <code>cgroups</code> версии 1.0 и <code>systemd</code> версии 219 или более поздней (например, RHEL/CentOS 7+).

Различные ноды будут продолжать взаимодействовать друг с другом через обычные порты, как описано ранее. Суть в том, что порты, которые необходимо открыть между нодами в одном контроллере домена, — это те же порты, которые необходимо открыть внутри кластера, если кластер охватывает два контроллера домена.

Соединения между нодами в разных дата-центрах должны быть зашифрованы. Dynatrace не создает и не устанавливает необходимые сертификаты для обеспечения этого — вам нужно будет сделать это вручную. Поддерживается двусторонняя задержка сети до 100 мс. Потребление полосы пропускания зависит от множества факторов.

Кластер с одним дата-центром (или кластер с несколькими дата-центрами, не зависящий от дата-центра) можно перенести на кластер высокой доступности с двумя дата-центрами. Для такого развертывания требуется лицензия. См. раздел [[Мониторинг приложений и инфраструктуры (хост-модули)]].

Dynatrace использует двоичный файл Elasticsearch Enterprise, встроенный в платформу. Для Elasticsearch Enterprise требуется подписка Elasticsearch Platinum.

ВысокаяДоступность для дата-центров

2023-01-26T20:45:52Z

YaPolkin:

'''Dynatrace ВысокаяДоступность''' — это готовое автономное решение, обеспечивающее почти нулевое время простоя и позволяющее продолжать мониторинг без потери данных в сценариях отработки отказа.

Это решение обеспечивает экономию средств с точки зрения выделения вычислительных ресурсов и хранилища за счет устранения необходимости в отдельных резервных хостах аварийного восстановления и соответствующей инфраструктуре для хранения и передачи данных резервного копирования. Хотя дополнительные узлы в одноранговом центре обработки данных (ЦОД) положительно влияют на вычислительную мощность, доступную для кластера, это влияние нелинейно.

При планировании емкости узлы в дополнительном дата-центре следует рассматривать как избыточные, а не как узлы с увеличенной емкостью. Это связано с тем, что дополнительный дата-центр будет иметь копию всех данных Cassandra и Elasticsearch из исходного дата-центра.

'''Максимальное количество узлов, поддерживаемых кластерами''' высокой доступности Ключа-Астром, равно 30 (15 узлов на дата-центр).

'''Эффективный минимум''' — 6 узлов (3 узла на дата-центр). Оба дата-центра в кластере должны иметь симметричный размер.

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

Короткие, до 3 часов, сбои в сети между центрами обработки данных восстанавливаются автоматически. Чтобы избежать несогласованности данных, в случае более длительных простоев мы рекомендуем отключать серверную службу на всех узлах в затронутом центре обработки данных. Вы можете запустить службы, когда сетевое подключение снова станет стабильным.

Чтобы справиться с ситуацией, когда одна часть кластера недоступна, Dynatrace Контроллер Задач отслеживает работоспособность всех узлов и автоматически назначает одну часть кластера основной (выживающей). Во время восстановления это обозначение используется для определения способа повторной синхронизации всех частей кластера. Это означает, что Dynatrace ВысокаяДоступность не поддерживается для полностью автономных управляемых кластеров.

== Разделение и репликация данных ==
Используя виртуальные стойки, Dynatrace ВысокаяДоступность хранит три копии всех данных конфигурации, метрик и сеансов пользователей в каждом дата-центре. Это обеспечивает оптимальную производительность и надежность в сценариях отработки отказа.

Необработанные данные транзакций (такие как распределенные трассировки, стеки вызовов и операторы базы данных) распределяются случайным образом по всем дата-центрам, поэтому на каждом дата-центре всегда доступен набор данных. Данные синхронизируются асинхронно между дата-центрами. Это устраняет требование к задержке в 10 мс, которое применяется ко всем кластерам с несколькими дата-центрами.

Синхронизация данных спроектирована таким образом, чтобы свести к минимуму использование полосы пропускания между контроллерами домена и предотвратить потерю данных в случае выхода из строя одного из контроллеров домена. Во время перерывов в работе менее трех часов Dynatrace ВысокаяДоступность автоматически и прозрачно повторно синхронизирует данные между контроллерами домена. При простоях продолжительностью до трех дней команда Dynatrace Контроль Задач инициирует необходимые работы по ремонту и синхронизации. После этого неисправную часть кластера необходимо переустановить.

== Маршрутизация данных телеметрии ==
Сетевые зоны можно использовать для управления потоком данных телеметрии к узлам кластера в различных дата-центрах. Несмотря на то, что Dynatrace ВысокаяДоступность реализует различные оптимизации для уменьшения трафика между дата-центрами, мы рекомендуем для избыточности данных разрешить ActiveGate'ам отправлять данные на оба дата-центра. OneAgent'ы и ActiveGate'ы можно настроить так, чтобы они предпочитали определенные сетевые зоны, сохраняя при этом возможность аварийного переключения на другую часть кластера в случае сбоя дата-центра. Обратите внимание, что для этой цели также можно использовать балансировщики нагрузки. Для активно-пассивных развертываний приложений мы рекомендуем не отключать ActiveGate'ы в пассивных частях развертывания. Это поддерживает работу всех частей инфраструктуры Dynatrace в случае аварийного восстановления и обеспечивает аварийное переключение без повторной настройки или повторного обнаружения.

== Технические подробности ==
Для ВысокойДоступности требуется ОС, поддерживающая <code>cgroups</code> версии 1.0 и <code>systemd</code> версии 219 или более поздней (например, RHEL/CentOS 7+).

Различные ноды будут продолжать взаимодействовать друг с другом через обычные порты, как описано ранее. Суть в том, что порты, которые необходимо открыть между нодами в одном контроллере домена, — это те же порты, которые необходимо открыть внутри кластера, если кластер охватывает два контроллера домена.

Соединения между нодами в разных дата-центрах должны быть зашифрованы. Dynatrace не создает и не устанавливает необходимые сертификаты для обеспечения этого — вам нужно будет сделать это вручную. Поддерживается двусторонняя задержка сети до 100 мс. Потребление полосы пропускания зависит от множества факторов.

Кластер с одним дата-центром (или кластер с несколькими дата-центрами, не зависящий от дата-центра) можно перенести на кластер высокой доступности с двумя дата-центрами. Для такого развертывания требуется лицензия. См. раздел [[Мониторинг приложений и инфраструктуры (хост-модули)]].

Dynatrace использует двоичный файл Elasticsearch Enterprise, встроенный в платформу. Для Elasticsearch Enterprise требуется подписка Elasticsearch Platinum.

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

2023-01-26T20:44:29Z

YaPolkin:

Этот метод универсален и может работать для больших кластеров и более сложных изменений топологии. Однако процесс восстановления занимает много времени, и из-за ежедневного резервного копирования происходит некоторая потеря данных. Хранилище транзакций (PurePaths) не содержится в резервной копии.

[[Файл:Man-conversion-restore.webp|альт=Процесс преобразования Managed кластера в кластер с учетом стойки с помощью резервного копирования и восстановления]]

== Подготовка ==

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

== Восстановление кластера в новые стойки ==
Восстановить кластер в новые стойки

1. Остановите существующий кластер, чтобы два кластера с одинаковым идентификатором не могли подключиться к Dynatrace Mission Control.

См. Запуск/остановка/перезапуск кластера.

2. Выполните официальную процедуру восстановления кластера (резервное копирование и восстановление кластера), используя следующий измененный шаг:
----'''Запустите восстановление Dynatrace на каждом узле'''

Параллельно на каждом узле запустите программу установки Dynatrace Managed со следующими параметрами:

* <code>--rack-name</code> - определяет стойку, к которой будет принадлежать этот узел.
* <code>--rack-dc</code> - определяет дата-центр, которому будет принадлежать этот узел.
* <code>--restore</code> - переводит программу установки в режим восстановления.
* <code>--cluster-ip</code> - IPv4-адрес узла, на котором вы запускаете установщик.
* <code>--cluster-nodes</code> - разделенный запятыми список идентификаторов и IP-адресов всех узлов в кластере, включая тот, на котором вы запускаете установщик, в следующем формате <code><node_id>:<node_ip>,<node_id>:<node_ip></code>.
* <code>--seed-ip</code> - IPv4-адрес исходного узла.
* <code>backup-file</code> - путь к файлу резервной копии <code>*.tar</code> , который включает путь к монтированию общего файлового хранилища, идентификатор кластера, идентификатор узла, версию резервной копии и файл резервной копии <code>*.tar</code> в следующем формате:

<code><path-to-backup>/<UUID>/node_<node_id>/files/<backup_version_number>/<backup_file></code>
----<blockquote>Пример резервного пути

В этом примере пути: <code>/mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar</code> части пути следующие:

* <code><path-to-backup></code> = <code>/mnt/backup/bckp/</code>
* <code><UUID></code> = <code>c9dd47f0-87d7-445e-bbeb-26429fac06c6</code>
* <code><node_id></code> = <code>1</code>
* <code><backup_version_number></code> = <code>19</code>

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

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

Номер версии резервной копии увеличивается при каждом выполнении резервного копирования.</blockquote>
----Получите идентификаторы и IP-адреса из инвентаря, который вы создали перед началом работы.

Например:

<code>10.176.41.168</code> - IP-адрес восстанавливаемого узла

<code>1: 10.176.41.168, 3: 10.176.41.169, 5: 10.176.41.170</code> - идентификаторы узлов и новые IP-адреса всех узлов в кластере

# <code>sudo ./tmp/{backup-instaler-name}.sh</code>
# <code>--rack-name rack2</code>
# <code>--rack-dc datacenter1</code>
# <code>--restore</code>
# <code>--cluster-ip "10.176.41.168"</code>
# <code>--cluster-nodes "1:10.176.41.168,3:10.176.41.169,5:10.176.41.170"</code>
# <code>--seed-ip "10.176.41.169"</code>
# <code>--backup-file /mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar</code>

----3. Когда вы загружаете данные как часть процесса восстановления, они уже помещены в целевые стойки.

Когда преобразование будет завершено, вы увидите стойки на странице состояния развертывания в консоли управления кластером:

[[Файл:Cmcstatus.webp|альт=Страница состояния развертывания CMC кластера с учетом стойки]]

Преобразование с использованием репликации с учетом стойки

2023-01-26T20:43:59Z

YaPolkin:

Этот метод полезен для небольших управляемых кластеров Dynatrace, где один узел может содержать полную реплику. Если ваше текущее хранилище метрик (база данных Cassandra) на узел превышает 1 ТБ, используйте метод восстановления кластера. Вы можете использовать существующие узлы для постепенной (один за другим) их переустановки с параметром «поддержка стойки». При желании вы можете использовать дополнительное оборудование в качестве новых узлов и удалить один узел при установке нового узла с параметром «поддержка стойки».

Преимущество этого подхода заключается в том, что он не влияет на доступность кластера, однако для поддержания доступности кластера необходимо разрешить управляемому кластеру использовать собственные методы репликации для обеспечения сохранения данных. Следует учитывать, что удаление и добавление узла в кластер требует времени. Это время зависит от размера вашего метрического хранилища и скорости вашего диска или сети. Некоторые операции с кластером могут занять даже один-два дня. Управляемый кластер предотвратит все другие операции кластера в течение этого времени (добавление и удаление узлов, обновление и резервное копирование). Если вы решили выполнить переустановку на существующем хосте, подождите 72 часа, прежде чем повторно подключать этот хост к кластеру.

[[Файл:Man-conversion-ra.webp|альт=Процесс преобразования Managed кластера в кластер с учетом стойки.]]

== Подготовка ==

* Подготовьте базу данных Cassandra для распространения реплик по кластеру (требуется Python 2.7).

На одном из существующих узлов измените пространство клавиш, чтобы изменить настройки снитча, используя Cassandra CQL:

<code>sudo <managed-installation-dir>/cassandra/bin/cqlsh <node_IP></code>

Где <code><managed-installation-dir></code> - это каталог управляемых двоичных файлов Dynatrace, а <code><node-IP></code> - это IP-адрес текущего узла (узел, который вы используете в данный момент).

В результате вы попадете в оболочку CQL:

<code>Connected to 00aa0a0a-1ab1-11a1-aaa1-0a0a0aa1a1aa at xx.xxx.xx.xxx:9042.</code>

<code>[cqlsh 5.0.1 | Cassandra 3.0.23 | CQL spec 3.4.0 | Native protocol v4]</code>

<code>Use HELP for help. </code>

<code>cqlsh></code>

Затем выполните:

<code>ALTER KEYSPACE ruxitdb WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'datacenter1':3};</code>

Когда закончите, введите: <code>exit</code>

* Подготовьте кластер для добавления узлов в разные стойки.

На каждом из существующих узлов отредактируйте <code>/etc/<conf-name>.conf</code> и настройте следующие параметры:

<code>CASSANDRA_NODE_RACK = rack1</code>

<code>CASSANDRA_NODE_RACK_DC = datacenter1 </code>

<code>ELASTICSEARCH_NODE_RACK = rack1</code>

Выполните <code>sudo reconfigure.sh</code> , чтобы применить изменения конфигурации для узла кластера.

* Подготовьте новую(ые) ноду(ы).

Убедитесь, что раздел диска, выделенный для хранилища Cassandra на новом узле, достаточен для размещения всей базы данных Cassandra (с запасом для сжатия и новых данных). Размер диска должен быть как минимум вдвое больше объединенных хранилищ Cassandra всех существующих узлов кластера. Рекомендуется размещать данные Cassandra на отдельном томе, чтобы избежать проблем с дисковым пространством, связанных с различными типами данных.

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

== Расширение кластера на новые стойки ==
Во время первоначального развертывания Dynatrace Managed все узлы кластера по умолчанию сгруппированы в единую стойку по умолчанию, размещенную в центре обработки данных по умолчанию. Даже если ваше развертывание не поддерживает стойки, все узлы уже находятся в <code>datacenter1</code> <code>rack1</code>. Чтобы избежать добавления нового узла в стойку по умолчанию, не используйте <code>rack1</code> в качестве значения параметра <code>--rack-name</code> для новой стойки.

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

Расширить кластер на новые стойки

1. Добавьте в кластер новый узел с параметрами стойки.

Используйте процедуру Добавить новый узел кластера и добавьте параметры <code>--rack-name</code> и <code>--rack-dc</code> к команде установки. Например:

<code>/bin/sh <managed-installer-name>.sh --seed-auth abcdefjhij1234567890 --rack-name rack2 --rack-dc datacenter1</code>

Подождите, пока узел полностью не присоединится к кластеру. В зависимости от размера вашей базы данных, загрузка Cassandra может занять несколько дней.
----''<big>Подсказка</big>''

Если узел испытывает трудности с поддержанием загрузки данных, вы можете временно остановить процесс сервера Dynatrace на этом узле и освободить больше циклов ЦП для Cassandra.
----2. Добавьте еще один узел в ту же стойку с такими же параметрами стойки.

На этот раз ожидается, что загрузка Cassandra будет быстрее.

3. Продолжайте добавлять новые узлы в <code>rack2</code>. Как только у вас будет достаточное количество узлов в <code>rack2</code> (1/3 размера целевого кластера), начните добавлять новые узлы с параметрами стойки в <code>rack3</code> , учитывая требования к дисковому пространству.

4. Как только у вас будет достаточное количество узлов в стойке <code>rack3</code> , начните удаление исходных узлов, которые были настроены без поддержки стойки (расположены в стойке по умолчанию <code>rack1</code>).

Когда преобразование будет завершено, вы увидите стойки на странице состояния развертывания в консоли управления кластером:

[[Файл:Cmcstatus.webp|альт=Страница состояния развертывания CMC кластера с учетом стойки]]

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

2023-01-26T20:43:23Z

YaPolkin:

В стандартном управляемом развертывании Dynatrace с высокой доступностью вы защищены от потери данных, если:

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

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

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

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

''Крупные управляемые развертывания Dynatrace допускают отказ двух узлов.''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Экспорт данных о лицензировании

2023-01-26T20:42:15Z

YaPolkin:

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

Скачанный архив включает:

* ZIP-архив с файлами данных об использовании лицензий в формате JSON
* Файл подписи
* Файл журнала, содержащий информацию о создании и загрузке архива

Файлы JSON содержат следующую информацию:

=== ConsumptionExport ===
{| class="wikitable"
!Имя свойства
!Описание
|-
|clusterUuid
|Идентификатор кластера
|-
|timeFrameStart
|Начало периода экспорта данных о потреблении
|-
|timeFrameEnd
|Окончание периода экспорта данных о потреблении
|-
|environmentBillingEntries
|Список объектов '''EnvironmentUsage'''
|}

=== EnvironmentUsage ===
{| class="wikitable"
!Имя свойства
!Описание
|-
|environmentUuid
|Идентификатор среды
|-
|visits
|Количество использованных пользовательских сеансов
|-
|mobileSessions
|Количество использованных сеансов мобильных пользователей
|-
|totalRUMUserPropertiesUsed
|Количество определенных свойств сеанса пользователя
|-
|newProblems
|Не используется, устарело
|-
|hostUsages
|Список объектов '''HostUsage'''
|-
|downloads
|Не используется, устарело
|-
|syntheticUsages
|Не используется, устарело
|-
|syntheticBillingUsage
|Список объектов '''SyntheticUsage'''
|-
|customMetrics
|Список объектов '''CustomMetricsUsage'''
|-
|davisDataUnits
|Список объектов '''DDUUsage'''
|-
|trial
|Если пробная версия среды
|-
|logStorageUsageBytes
|Счетчик использования хранилища для мониторинга журналов в байтах
|-
|logUploadVolumeBytes
|Счетчик объема загрузки журнала мониторинга в байтах
|-
|sessionReplays
|Количество использованных повторов сеанса пользователя
|-
|mobileSessionReplays
|Количество использованных повторов сеанса мобильного пользователя
|}

=== HostUsage ===
{| class="wikitable"
!Имя свойства
!Описание
|-
|osiId
|Идентификатор кластера
|-
|hostName
|Не используется
|-
|hostCategory
|Устарело
|-
|agentUsages
|Список объектов '''AgentUsage'''
|-
|infrastructureOnly
|При работе в режиме мониторинга инфраструктуры
|-
|paas
|Если приложение PaaS
|-
|passMemoryLimit
|Ограничение ОЗУ приложения PaaS в байтах; Для приложений, отличных от PaaS, это значение null
|-
|vendorTypeId
|Идентификатор поставщика PaaS. Для приложений, отличных от PaaS, это значение null
|-
|hostMemoryBytes
|RAM хоста в байтах
|-
|premiumLogAnalytics
|Если на хосте включен мониторинг Premium Log
|-
|hasContainers
|Если хост виртуализации (например, хост Docker)
|}

=== AgentUsage ===
{| class="wikitable"
!Имя свойства
!Описание
|-
|networkTraffic
|Не используется, устарело
|-
|agentId
|Уникальный идентификатор модуля OneAgent
|-
|agentTypeId
|ID типа модуля OneAgent; 1 для модуля ОС
|-
|agentUsageRecords
|Список объектов '''AgentUsageRecord'''
|}

=== AgentUsageRecord ===
{| class="wikitable"
!Имя свойства
!Описание
|-
|startTime
|Время начала работы модуля OneAgent в пределах таймфрейма ConsumingExport
|-
|endTime
|Время окончания работы агента в пределах таймфрейма ConsumingExport
|}

=== SyntheticUsage ===
{| class="wikitable"
!Имя свойства
!Описание
|-
|monitorTypeId
|Идентификатор типа синтетического монитора; 1 для браузерного монитора, 2 для монитора HTTP
|-
|testId
|Уникальный идентификатор синтетического монитора
|-
|publicExecutions
|Количество исполнений из публичных локаций
|-
|privateExecutions
|Количество исполнений из частных локаций
|}

=== CustomMetricsUsage ===
{| class="wikitable"
!Имя свойства
!Описание
|-
|source
|Имя источника определения пользовательской метрики (например, <code>JMX</code>)
|-
|total
|Количество определений пользовательских метрик
|}

=== DDUUsage ===
{| class="wikitable"
!Имя свойства
!Описание
|-
|pool
|Имя пула DDU (например, "Metrics")
|-
|total
|Количество использованных единиц данных AI
|}

Запуск/остановка/перезапуск кластера

2023-01-26T20:40:51Z

YaPolkin:

Программное обеспечение Dynatrace Managed состоит из ряда служб Dynatrace, которые зависят друг от друга и должны быть остановлены или запущены в определенном порядке. Вы можете использовать официальный сценарий <code><name>.sh</code> с дополнительными параметрами для правильного запуска, остановки или перезапуска служб Dynatrace. По умолчанию сценарий находится в <code><install dir>/launcher/</code>. Убедитесь, что у сценария <code><name>.sh</code> есть разрешения на выполнение.

Вы можете выполнить сценарий <code><name>.sh</code> с параметром (<code>start</code>, <code>stop</code>, <code>restart</code>, <code>status</code>, <code>check</code>, <code>pid</code>), как описано ниже.

* start

Запускает все необходимые службы Dynatrace Managed в рекомендованном порядке.

* stop

Останавливает все необходимые службы Dynatrace Managed в рекомендованном порядке.

* restart

Перезапускает все необходимые службы Dynatrace Managed в рекомендованном порядке.

* status

Отображает список необходимых служб Dynatrace и состояние каждой из них, включая подробную информацию о каждой службе:

#
*check

Проверяет состояние правил iptable и процессов для Nodekeeper, Cassandra, Elasticsearch, ActiveGate, Watcher и NGINX.

Пример вывода статуса

# <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

Отображает идентификатор процесса для всех необходимых служб Dynatrace, которые были запущены с помощью скрипта.

Пример pid статуса:

<code>966 552 13721 13690 14834 14802 15294 15302 16173 16182 17153 17155 17156</code>

Запуск/остановка/перезапуск ноды

2023-01-26T20:39:47Z

YaPolkin:

Dynatrace 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>) по примеру ниже.

== '''Запуск кластера''' ==
Запуск всех служб Dynatrace Managed в рекомендуемом порядке.
<code>[root@localhost]# ./Dynatrace.sh start</code>

== '''Остановка кластера''' ==
Остановка всех служб Dynatrace Managed в рекомендуемом порядке.
<code>[root@localhost]# ./Dynatrace.sh stop</code>

== '''Перезапуск кластера''' ==
Перезапуск всех служб Dynatrace Managed в рекомендуемом порядке.
<code>[root@localhost]# ./Dynatrace.sh restart</code>

== '''Состояние кластера''' ==
Отображение списка всех служб Dynatrace и их состояний с подробной информацией.
<code>[root@localhost]# ./Dynatrace.sh status</code>

== '''Состояние процессов кластера''' ==
Проверка состояний iptables и процессов для Nodekeeper, Cassandra, Elasticsearch, ActiveGate, Watcher и NGINX.
<code>[root@localhost]# ./Dynatrace.sh check</code>

== '''Идентификатор процесса''' ==
Отображение идентификатора процесса всех служб Dynatrace, запущенных со скриптом.
<code>[root@localhost]# ./Dynatrace.sh pid</code>

Диагностические архивы для установок Ключ-АСТРОМ Managed

2023-01-26T20:19:36Z

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

#перенаправление [[Диагностические архивы для установок Dynatrace Managed]]

Диагностические архивы для установок Dynatrace Managed

2023-01-26T20:19:36Z

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

* '''Автоматический анализ:''' Dynatrace Managed собирает данные диагностики кластера и автоматически отправляет их в Dynatrace, где наши специалисты Dynatrace ONE могут использовать эти данные для быстрого и эффективного анализа вашего запроса в службу поддержки.
* '''Собирайте и просматривайте локально:''' Dynatrace Managed собирает данные диагностики кластера, после чего вы можете проанализировать данные самостоятельно и, при желании, прикрепить их к заявке в службу поддержки для просмотра в Dynatrace ONE.

== Анализировать автоматически ==
По умолчанию Dynatrace собирает диагностические данные для кластера и немедленно их анализирует.
----<blockquote>Если вы предпочитаете собирать и просматривать данные перед их отправкой в Dynatrace вручную для анализа, см. Сбор и просмотр на месте.</blockquote>
----1. На домашней странице Dynatrace Managed выберите Дополнительно (…)> Выполнить диагностику кластера.

Пример выбора меню

[[Файл:Man-diag-enter.jpg|альт=Пример меню выбора]]

2. На странице "Выполнить диагностику кластера" кратко опишите, что с вашей точки зрения не работает должным образом.

Пример страницы диагностики кластера

[[Файл:Cluster-diags.jpg|альт=Пример страницы диагностики кластера]]

3. [опционально] По умолчанию для анализа собираются данные за 7 дней. Если вам нужны дополнительные данные, выберите ссылку «Дополнительные параметры», измените количество дней и нажмите «Применить».

4. Выберите Начать анализ.

=== Что произойдет дальше ===
Dynatrace делает следующее:

* Собирает диагностические данные за последние 7 дней (если вы не меняли значение по умолчанию) затронутых узлов кластера и ActiveGate'ов.
* Хранит собранные диагностические данные
* Загружает диагностические данные в региональное хранилище управления полетами для дальнейшего анализа.

Столбец Состояние описывает текущую фазу процесса.
----<blockquote>Состояние не обновляется автоматически. Выберите «Обновить», чтобы проверить изменение состояния.</blockquote>
----''Сбор''

Сбор данных продолжается. При сборе данных вы можете:

* Обновите страницу, чтобы обновить прогресс.
* Отменить сбор диагностических данных.

''Собрано''

Dynatrace завершил сбор диагностических данных. После сбора данных вы можете:

* Анализировать, чтобы отправить собранные данные в Dynatrace для анализа.
* Загрузите собранные данные локально для проверки.
* Удалите проблему, включая собранные диагностические данные.

''Отправка в процессе''

Диагностические данные передаются в Dynatrace для анализа. При отправке данных вы можете:

* Обновите страницу, чтобы обновить прогресс.
* Загрузите собранные диагностические данные.
* Удалите проблему, включая собранные диагностические данные.

''Отправлено в облако Dynatrace''

Диагностические данные переданы в Dynatrace для анализа.

''Анализируя''

Dynatrace сейчас анализирует диагностические данные.

Анализируя данные, вы можете:

* Обновите страницу, чтобы обновить прогресс.
* Загрузите собранные диагностические данные.
* Удалите проблему, включая собранные диагностические данные.

''Проанализировано''

Анализ сделан. Количество связанных предупреждений указано в скобках.

После анализа вы сможете:

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

''Выполняется удаление''

Данные диагностики удаляются. При удалении данных вы можете:

* Обновите страницу, чтобы обновить прогресс.

''Удалено''

Данные диагностики удалены. Dynatrace хранит лишь небольшой набор информации о том, кто, когда, где и почему были собраны диагностические данные.

''Отменено''

Процесс диагностики был отменен вручную до его завершения.

=== Просмотрите анализ Dynatrace ===
По завершении анализа Dynatrace отправляет результаты обратно в ваш кластер. Если потенциальное решение обнаружено, Dynatrace перечисляет его в разделе «Предупреждения».

== Собирайте и просматривайте локально ==
Эта процедура описывает, как собирать диагностические данные для хоста или процесса локально. Используйте эту опцию, если вы предпочитаете собирать и просматривать данные перед их отправкой в Dynatrace вручную для анализа.
----<blockquote>Если вместо этого вы хотите собирать данные и автоматически отправлять их в Dynatrace для анализа, см. раздел «Анализировать автоматически».</blockquote>
----1. На управляемой домашней странице Dynatrace выберите Дополнительно (…)> Выполнить диагностику кластера.

Пример выбора меню

[[Файл:Man-diag-enter.jpg|альт=Пример меню выбора]]

2. На странице "Выполнить диагностику кластера" кратко опишите, что с вашей точки зрения не работает должным образом.

Пример страницы диагностики кластера

[[Файл:Cluster-diags.jpg|альт=Пример страницы диагностики кластера]]

3. Щелкните ссылку Дополнительные параметры.

4. Выбрать и хранить на месте.

Находясь здесь, вы также можете изменить количество дней для сбора данных (по умолчанию = 7 дней).

5. Выберите Применить.

6. Выберите Начать сбор, чтобы собрать диагностические данные и сохранить их локально.

=== Что произойдет дальше ===
Dynatrace сейчас:

* Собирает диагностические данные за последние 7 дней (если вы не меняли значение по умолчанию) затронутых узлов кластера и ActiveGate'ов.
* Хранит собранные диагностические данные

Столбец Состояние описывает текущую фазу процесса.
----<blockquote>Состояние не обновляется автоматически. Выберите «Обновить», чтобы проверить изменение состояния.</blockquote>
----''Сбор''

Сбор данных продолжается. При сборе данных вы можете:

* Обновите страницу, чтобы обновить прогресс.
* Отменить сбор диагностических данных.

''Собрано''

Dynatrace завершил сбор диагностических данных. После сбора данных вы можете:

* Анализировать, чтобы отправить собранные данные в Dynatrace для анализа.
* Загрузите собранные данные локально для проверки.
* Удалите проблему, включая собранные диагностические данные.

=== Что делать с собранными данными ===
Теперь, когда данные собраны, вы можете:

* Загрузите собранные данные.
** Вы можете просмотреть данные. См. Раздел «Содержание диагностических данных» для обзора загружаемых материалов.
** Вы можете добавить данные в свой запрос в службу поддержки.

* Проанализируйте данные.
* Удалите проблему, включая собранные диагностические данные.

== Обзор диагностики кластера ==
Для обзора всех запусков устранения неполадок кластера в вашей среде

1. На управляемой домашней странице Dynatrace выберите Дополнительно (…)> Выполнить диагностику кластера.

2. На странице «Выполнить диагностику кластера» перечислены все действия по диагностике в вашем кластере.

* Разверните любую запись, чтобы увидеть подробности.
* Если данные не были удалены (все диагностические данные удаляются автоматически через 30 дней), вы можете загрузить или удалить их.

== Содержание диагностических данных ==
Все собранные диагностические данные сжимаются в ZIP-файл <code>SupportArchive<ID number></code> , который включает следующие папки и файлы:

* <code>COLLECTOR</code> (ActiveGate'ы)

Содержит список всех ActiveGate'ов для кластера. Данные диагностики находятся в отдельной папке для каждого ActiveGate. Папки ActiveGate названы в честь UUID ActiveGate. Каждая папка ActiveGate содержит следующие подпапки:
{| class="wikitable"
!Папка
!Описание
|-
|<code>autoupdater</code>
|Содержит журналы процесса автоматического обновления.
|-
|<code>config</code>
|Содержит снимок каталога конфигурации ActiveGate.
|-
|<code>debugui</code>
|Содержит снимок конфигурации внутренней среды, связанной с ActiveGate.
|-
|<code>install</code>
|Содержит журналы установки ActiveGate.
|-
|<code>log</code>
|Содержит снимок каталога журналов ActiveGate.
|}

* <code>SERVER</code> (ноды)

Содержит список всех узлов кластера. Данные диагностики находятся в отдельной папке для узла. Папки узлов названы по уникальному номеру узла. Каждая папка узла содержит следующие подпапки:
{| class="wikitable"
!Папка
!Описание
|-
|<code>autoupdater</code>
|Содержит журналы процесса автоматического обновления.
|-
|<code>config</code>
|Содержит файлы конфигурации компонентов узлов кластера.
|-
|<code>log</code>
|Содержит файлы журналов, включая журналы аудита серверного процесса.
|-
|<code>managed-logs</code>
|Содержит файлы журналов других компонентов узла кластера, сгруппированные в отдельные папки.
|-
|<code>nginx-error-logs</code>
|Содержит журналы ошибок с сервера NGINX.
|}

* <code>download details.txt</code> (TXT)

Содержит информацию и статистику о диагностическом архиве, включая количество файлов и размер для каждой папки.

== Конфиденциальность данных ==
В соответствии с региональными правилами защиты данных и конфиденциальности Dynatrace делает следующее:

* Автоматически маскирует некоторые личные данные (например, IBAN и учетные данные URI) перед их сохранением.
* Автоматически удаляет все диагностические данные через 30 дней после их сбора. Это относится к данным в вашей среде Dynatrace и в кластере Dynatrace.

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

Дополнительные сведения о конфиденциальности данных Dynatrace см. В следующих разделах:

* Персональные данные, собираемые Dynatrace
* Срок хранения данных
* Соответствие Dynatrace требованиям GDPR для граждан ЕС

== Устранение проблем ==
''Статус: «Сбор диагностических данных невозможен в течение 20 минут».''

* Если Dynatrace не может собрать диагностические данные в течение 20 минут, она автоматически повторяет попытку.
* Если повторная попытка также не удалась, мы рекомендуем вам связаться со службой поддержки Dynatrace в чате.

''`State` кажется замороженным.''

Состояние не обновляется автоматически. Выберите «Обновить», чтобы проверить изменение состояния.

Диагностические архивы для установок Dynatrace Managed

2023-01-26T20:19:01Z

YaPolkin:

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

2023-01-26T20:11:54Z

YaPolkin:

Чтобы удалить кластер, вам необходимо удалить все узлы кластера. Другими словами, вы должны [[Удаление ноды кластера|удалить Dynatrace Сервер с каждого узла]]. Чтобы освободить лицензию, используйте параметр <code>--unregister</code> хотя бы один раз при удалении узлов кластера.

'''Примечание:''' При использовании параметра <code>--unregister</code> лицензия освобождается, но кластер всё ещё настроен и потенциально может быть связан с новой лицензией.

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

2023-01-26T20:11:02Z

YaPolkin:

Вы можете легко удалить узел кластера с помощью консоли управления кластером Dynatrace Managed. Однако, поскольку удаление узла кластера по существу означает удаление Dynatrace Managed, вы также можете использовать командную строку для удаления узла кластера. Оба подхода описаны ниже.

== Удалите узел кластера с помощью командной строки ==
Войдите в систему Linux, на которой установлена Dynatrace Managed. Используя root-права, выполните следующую команду:

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

Все данные Dynatrace Managed будут удалены с устройства после успешного выполнения сценария.

== Удалите узел кластера с помощью консоли управления кластером ==
Прежде чем вы сможете удалить узел из кластера Dynatrace Managed, необходимо сначала отключить трафик OneAgent, чтобы предотвратить поток данных к узлу во время его удаления.

=== Отключить трафик OneAgent ===
Чтобы отключить узел кластера

1. Авторизуйтесь как администратор. Используйте свой URL-адрес Dynatrace Managed или узел кластера, который вы хотите сохранить (вы не можете удалить узел, пока вы находитесь в нем).

2. В меню Dynatrace перейдите в раздел '''Статус развертывания'''.

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

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

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

6. Выберите '''Отключить трафик OneAgent''', чтобы остановить обработку данных мониторинга на узле. Если вы хотите временно исключить узел из кластера, остановите здесь и включите узел позже. Dynatrace 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-адрес Dynatrace Managed или узел кластера, который вы хотите сохранить (вы не можете удалить узел, пока вы находитесь в нем).

2. В меню Dynatrace перейдите на '''Домашнюю''', чтобы перейти на страницу узлов кластера Dynatrace Managed.

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

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

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

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

Подробнее см. в обозревателе API Dynatrace в CMC.

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

Примерный размер резервной копии кластера

2023-01-26T20:01:57Z

YaPolkin:

Резервное копирование и восстановление кластера

2023-01-26T19:59:00Z

YaPolkin:

'''''<code>[[Установка и настройка]] / [[Ключ-АСТРОМ Managed|Dynatrace Managed]] / [https://doc.ruscomtech.ru/index.php/%D0%9A%D0%BB%D1%8E%D1%87-%D0%90%D0%A1%D0%A2%D0%A0%D0%9E%D0%9C_Managed#.D0.AD.D0.BA.D1.81.D0.BF.D0.BB.D1.83.D0.B0.D1.82.D0.B0.D1.86.D0.B8.D1.8F Эксплуатация] / Резервное копирование и восстановление кластера</code>'''''

Чтобы настроить автоматическое резервное копирование для управляемого кластера Dynatrace

1. В меню Dynatrace выберите «Настройки»> «Резервное копирование».

2. Включите резервное копирование кластера и выберите область действия:

* Пользовательские сеансы могут содержать конфиденциальную информацию.

'''Исключите сеансы пользователей из резервной копии, чтобы соответствовать требованиям GDPR.'''

* Исключите данные метрик таймсерий из резервной копии, если ваши исторические данные не актуальны и вы хотите сохранить только данные конфигурации.
* Включите резервную копию событий Log Monitoring v2.

3. (Необязательно) Выберите центр обработки данных. Этот шаг требуется только в том случае, если у вас есть развертывание с несколькими центрами обработки данных (развертывание с высокой доступностью Premium). Дополнительные сведения о развертываниях высокой доступности Premium см. В разделах Высокая доступность для нескольких центров обработки данных и Аварийное восстановление из резервной копии.

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

5. Настройте время начала.

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

* Каждый узел должен быть подключен к общей файловой системе, а общая файловая система должна быть смонтирована в одном и том же общем каталоге на каждом узле.
* Пользователю, запускающему службы Dynatrace, необходимы разрешения на чтение и запись для общей файловой системы.
* Подключение к общей файловой системе должно быть доступно при перезапуске системы.
* Вы можете добавить точку монтирования в <code>fstab</code> или использовать инструмент управления дисками, чтобы сделать монтирование общей файловой системы постоянным.
* Протокол, используемый для передачи данных, зависит от вашей конфигурации. Мы рекомендуем NFSv4. Из-за низкой производительности и отказоустойчивости мы не рекомендуем CIFS.

----<blockquote>''<big>Точка монтирования общей файловой системы при загрузке системы</big>''

*

Если точка монтирования общей файловой системы недоступна при загрузке системы, Dynatrace не запустится на этом узле. Это может привести к недоступности кластера. Чтобы запустить Dynatrace, необходимо вручную отключить резервное копирование.</blockquote>
----

=== Хранилище метрик и конфигурации ===
Dynatrace сохраняет предыдущую резервную копию, пока не будет создана новая.

'''Характеристики резервного копирования'''

* Снимок выполняется ежедневно.
* Любые данные, которые реплицируются между узлами, также хранятся в резервной копии (дедупликации нет).
* Dynatrace исключает наиболее часто изменяющиеся семейства столбцов (исключенные семейства столбцов составляют около 80% от общего объема памяти) в дополнение к данным с разрешением 1 и 5 минут.

=== Elasticsearch ===
Файлы Elasticsearch хранятся в несжатом двоичном формате. Хотя данные реплицируются между узлами и есть две реплики в дополнение к основному осколку, резервная копия исключает реплицированные данные.

'''Характеристики резервного копирования'''

* По умолчанию моментальный снимок создается каждые 2 часа и является инкрементным. Первоначально Dynatrace копирует весь набор данных, а затем создает моментальные снимки различий. Старые снимки постепенно удаляются, когда им исполняется шесть (6) месяцев. Dynatrace сохраняет как минимум один снимок в месяц.
* Поскольку Dynatrace хранит некоторые из старых снимков состояния, размер резервной копии увеличивается независимо от текущего размера на диске. Моментальные снимки являются инкрементными, но Elasticsearch со временем объединяет сегменты данных, что приводит к возникновению определенных дубликатов в резервной копии.

----<blockquote>''<big>Нет резервной копии хранилища транзакций</big>''

*

Данные хранилища транзакций не копируются, поэтому при восстановлении резервных копий вы можете увидеть пробелы в данных глубокого мониторинга (например, PurePaths и трассировки на уровне кода). По умолчанию данные хранилища транзакций хранятся только 10 дней. В долгосрочной перспективе нет необходимости включать данные хранилища транзакций в резервные копии.</blockquote>
----

== Восстановление кластера ==
Чтобы восстановить кластер, выполните следующие действия.

=== Прежде чем вы начнете ===

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

----<blockquote>''<big>Мы рекомендуем</big>''

*

Мы рекомендуем восстановить в кластере то же количество узлов, что и в резервном кластере. В исключительных случаях можно выполнить восстановление в кластер, в котором до двух узлов меньше, чем в кластере, для которого создана резервная копия. Вы рискуете потерять конфигурацию кластера, если попытаетесь восстановить кластер, в котором более чем на два узла меньше исходной резервной копии кластера.</blockquote>
----

* Убедитесь, что существующий кластер остановлен, чтобы два кластера с одинаковым идентификатором не могли подключиться к Dynatrace Mission Control. См. Запуск / остановка / перезапуск кластера.

* Убедитесь, что системные пользователи, созданные для Dynatrace Managed, имеют одинаковые идентификаторы UID: GID на всех узлах.
* На каждом целевом узле смонтируйте хранилище резервных копий, например, в <code>/mnt/backup</code>. Этот путь упоминается как <code><path-to-backup></code> в приведенных ниже шагах.
* Убедитесь, что у установщика есть разрешения на чтение NFS.
* Создайте инвентарь кластера. Эта информация понадобится вам во время восстановления.
** Идентификаторы узлов в кластере - резервная копия каждого узла хранится в выделенном каталоге, названном по его идентификатору, в формате <code>node_ <node_id></code> (например, <code>node_1</code> , <code>node_5</code> и т.д.).
** IPv4-адреса новых машин.
** Решите, какой будет целевой компьютер для каждого узла.
** Решите, какой узел станет начальным узлом в кластере.

=== Восстановить из резервной копии ===
Чтобы восстановить кластер, выполните следующие действия:

1. '''Скопируйте установщик на целевые узлы'''

Для восстановления кластера необходимо использовать ту же версию установщика, что и в исходной. Скопируйте программу установки из <code><path-to-backup>/<UUID>/node_<node_id>/</code> на локальный диск на каждом целевом узле.

2. '''Запустите восстановление Dynatrace на каждом узле'''

Параллельно на каждом узле запустите программу установки Dynatrace Managed со следующими параметрами:

* <code>--restore</code> - переводит программу установки в режим восстановления.
* <code>--cluster-ip</code> - IPv4-адрес узла, на котором вы запускаете установщик.
* <code>--cluster-nodes</code> - разделенный запятыми список идентификаторов и IP-адресов всех узлов в кластере, включая тот, на котором вы запускаете установщик, в следующем формате <code><node_id>:<node_ip>,<node_id>:<node_ip></code>.
* <code>--seed-ip</code> - IPv4-адрес исходного узла.
* <code>backup-file</code> - путь к файлу резервной копии <code>*.tar</code> , который включает путь к монтированию общего файлового хранилища, идентификатор кластера, идентификатор узла, версию резервной копии и файл резервной копии <code>*.tar</code> в следующем формате:

<code><path-to-backup>/<UUID>/node_<node_id>/files/<backup_version_number>/<backup_file></code>

Пример резервного пути

В этом примере пути: <code>/mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar</code> части пути следующие:

* <code><path-to-backup></code> = <code>/mnt/backup/bckp/</code>

* <code><UUID></code> = <code>c9dd47f0-87d7-445e-bbeb-26429fac06c6</code>

* <code><node_id></code> = <code>1</code>

* <code><backup_version_number></code> = <code>19</code>

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

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

Номер версии резервной копии увеличивается при каждом выполнении резервного копирования.

Получите идентификаторы и IP-адреса из инвентаря, который вы создали перед началом работы.

Например:

<code>10.176.41.168</code> - IP-адрес восстанавливаемого узла

<code>1: 10.176.41.168, 3: 10.176.41.169, 5: 10.176.41.170</code> - идентификаторы узлов и новые IP-адреса всех узлов в кластере

<code>sudo /tmp/<backup-managed-installer-name>.sh</code>

<code>--restore</code>

<code>--cluster-ip "10.176.41.168"</code>

<code>--cluster-nodes "1:10.176.41.168,3:10.176.41.169,5:10.176.41.170"</code>

<code>--seed-ip "10.176.41.169"</code>

<code>--backup-file /mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar</code>

3. '''Запустите брандмауэр, Cassandra и Elasticsearch'''

На каждом узле последовательно запустите брандмауэр, Cassandra и Elasticsearch, используя скрипт запуска:

4. '''Проверить состояние Cassandra'''

На каждом узле проверьте, запущена ли Cassandra. Выполните команду:

<code><install-dir>/utils/cassandra-nodetool.sh status</code>

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

<code>Status = Up</code>

<code>State = Normal</code>

5. '''Проверить состояние Elasticsearch'''

На каждом узле проверьте, работает ли Elasticsearch. Выполните команду:

<code>curl -s -N -XGET '<nowiki>http://localhost:9200/_cluster/health?pretty'</nowiki> | grep status</code>

Вы должны получить следующий ответ:

<code>"status" : "green"</code>

или для настройки одного узла:

<code>"status" : "yellow"</code>

6. '''Восстановить базу данных Elasticsearch'''

На начальном узле выполните следующую команду: <code><install-dir>/utils/restore-elasticsearch-data.sh <path-to-backup>/<UUID></code>

7. '''Восстановление файлов метрик и данных конфигурации'''

На каждом узле последовательно, начиная с начального узла, выполните следующую команду:

<code><install-dir>/utils/restore-cassandra-data.sh <path-to-backup>/<UUID>/node_<node_id>/files/backup-001.tar</code>

Подождите, пока Cassandra полностью не настроит свой кластер. Используйте команду:

<code><install-dir>/utils/cassandra-nodetool.sh status</code>

* Вы должны получить следующий ответ:

<code>Status = Up</code>

<code>State = Normal</code>

8. [опционально] '''Почините Cassandra'''

Последовательно на всех узлах запустить восстановление Cassandra:

<code><install-dir>/utils/repair-cassandra-data.sh</code>

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

9. '''Запустить Dynatrace'''

На каждом узле последовательно, начиная с начального узла, выполните следующую команду:

<code><install-dir>/launcher/<main-script>.sh start</code>

Подождите, пока вы не сможете войти в Консоль управления кластером.

10. [опционально] '''Удалить оставшиеся ссылки на старые узлы'''

Если вы решили восстановить меньше узлов, чем в исходном кластере, удалите узлы, помеченные как <code>Offline</code> в консоли управления кластером. Дополнительные сведения см. В разделе Удаление узла кластера.

11. '''Переключите OneAgent'ы на новый адрес кластера'''

Если вы изначально настроили кластер с DNS для OneAgent'ов, вам нужно только обновить записи DNS, как описано в следующем шаге.

В противном случае вы должны настроить Cluster ActiveGate'ы (или OneAgent'ы, если ActiveGate'ы не используются) с новым целевым адресом и перезапустить их. Если нет кластерных ActiveGate'ов, но есть ActiveGate'ы окружения, это следует сделать на ActiveGate'ах окружения.

В противном случае необходимо настроить и перезапустить Cluster ActiveGate'ы (или OneAgent'ы, если ActiveGate'ы не используются) с новым целевым адресом.

Чтобы настроить новый целевой адрес на ActiveGate:

# Остановите службу ActiveGate.
# Обновите параметр <code>seedServerUrl</code> в <code>config.properties</code>.
# Обновите <code>cluster.properties</code> новыми URL-адресами.
# Удалите файл <code>connectivity_history.properties</code>.

Выполните следующий вызов API кластера для каждого узла, заменив <code><node-id></code> на идентификатор узла, <code><node-ip></code> на IPV4-адрес узла и <code><Api-Token></code> на действительный токен Cluster API.

<code>curl -ikS -X PUT -d <node-ip> https://<node_ip>:8021/api/v1.0/onpremise/endpoint/publicIp/agents/<node-id>?Api-Token=<Api-Token> -H "accept: application/json" -H "Content-Type: application/json"</code>

Вы должны получить ответ <code>200</code> , как в примере ниже:

<code>HTTP/1.1 200 OK</code>

<code>Date: Tue, 19 Feb 2019 17:49:06 GMT</code>

<code>X-Robots-Tag: noindex</code>

<code>Server: ruxit server</code>

<code>Content-Length: 0</code>

12. [опционально] '''Обновить записи DNS кластера'''

Если восстановление кластера привело к изменению IP-адресов, обновите записи DNS.

* Если вы используете автоматическое управление доменами и сертификатами, выполните следующий вызов API кластера для каждого узла, заменив <code><node-id></code> на идентификатор узла, <code><node-ip></code> на IPV4-адрес узла и <code><Api-Token></code> на действительный Токен API.

<code>curl -ikS -X PUT -d <node-ip> https://<Node-ip>:8021/api/v1.0/onpremise/endpoint/publicIp/domain/<node-id>?Api-Token=<Api-Token> -H "accept: application/json" -H "Content-Type: application/json"</code>

Вы должны получить ответ <code>200</code> , как в примере ниже:

<code>HTTP/1.1 200 OK</code>

<code>Date: Tue, 19 Feb 2019 17:49:06 GMT</code>

<code>X-Robots-Tag: noindex</code>

<code>Server: ruxit server</code>

<code>Content-Length: 0</code>

* Если вы используете собственный DNS, обновите домен кластера на новый IP-адрес.

13. '''Включить резервное копирование'''

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

# В меню Dynatrace выберите «Настройки»> «Резервное копирование».
# Включите параметр «Включить резервное копирование кластера», подтвердите полный путь к архиву резервных копий и запланируйте время ежедневного резервного копирования.

=== Отключить резервное копирование вручную ===
В некоторых ситуациях необходимо вручную отключить резервное копирование кластера. Например, если точка монтирования общей файловой системы недоступна при загрузке системы, Dynatrace не запустится на этом узле. В этом случае необходимо вручную отключить резервное копирование, чтобы запустить Dynatrace.

1. Отредактируйте файл <code><install-dir>/elasticsearch/config/elasticsearch.yml</code>.

2. Удалите строку с параметром <code>path.repo:</code>

3. Сохраните файл и перезапустите систему. См. раздел Запуск/остановка/перезапуск кластера

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

2023-01-26T19:53:26Z

YaPolkin: YaPolkin переименовал страницу Обновление кластерного АктивногоШлюза в Обновление кластерного ActiveGate

#перенаправление [[Обновление кластерного ActiveGate]]

Обновление кластерного ActiveGate

2023-01-26T19:53:26Z

YaPolkin: YaPolkin переименовал страницу Обновление кластерного АктивногоШлюза в Обновление кластерного ActiveGate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Последняя доступная версия ActiveGate установлена на соответствующем хосте.

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

Для этой версии ActiveGate доступно обновление.

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

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

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

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

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

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

В этом случае вы увидите старый номер версии, отображаемый для ActiveGate.

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

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

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

Соединение с этим ActiveGate было потеряно, и статус не может быть определен.

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

Обновление кластерного ActiveGate

2023-01-26T19:52:48Z

YaPolkin:

Применение патчей операционной системы к ноде

2023-01-26T19:32:19Z

YaPolkin:

Мы рекомендуем вам выполнять обновление операционной системы узла или исправлять приложение по одному узлу за раз. Программное обеспечение узла Dynatrace Managed состоит из ряда служб Dynatrace, которые зависят друг от друга и должны быть остановлены или запущены в определенном порядке. Используйте официальную команду скрипта с параметром для правильного запуска, остановки или перезапуска служб Dynatrace.

Чтобы применить патч операционной системы к узлу Dynatrace

1. Как пользователь root войдите в систему Linux, на которой установлен узел Dynatrace Managed.

2. Выполните команду скрипта с соответствующим параметром (<code>start</code>, <code>stop</code>, или <code>restart</code>).

По умолчанию скрипт находится в <code>/<install dir>/launcher</code>.

<code>[root@localhost]# ./<script-name>.sh stop</code>

3. Примените все необходимые патчи к операционной системе узла.
----<blockquote>''<big>Перезагрузка системы</big>''

*

Для некоторых патчей операционной системы может потребоваться перезагрузка системы. Имейте в виду, что при перезапуске системы служба Dynatrace будет работать. Если вы планируете установить дополнительные исправления после перезагрузки, вам следует снова остановить службы Dynatrace, прежде чем применять дополнительные исправления.</blockquote>
----4. Если перезагрузка системы не потребовалась, перезапустите службы Dynatrace.

<code>[root@localhost]# ./<script-name>.sh start</code>

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

2023-01-26T19:31:47Z

YaPolkin:

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

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

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

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

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

*

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

По умолчанию сценарий находится в <code><PRODUCT_PATH>/launcher/</code>. Убедитесь, что у сценария есть разрешения на выполнение. После выполнения дождитесь завершения сценария и убедитесь, что не запущены службы Dynatrace.

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

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

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

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

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

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

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

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

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

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

<code>DATASTORE_PATH = /var/opt/<name>-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/<name>.conf</code> на все соответствующие файлы конфигурации. Флаг <code>--no-start</code> позволит вам окончательно проверить изменения перед запуском любой из служб Dynatrace.

7. Запустите все службы Dynatrace.

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

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

2023-01-26T19:25:51Z

YaPolkin:

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

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

== Создайте среду ==
1. В меню Dynatrace перейдите в Среды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Переименовать среду ==
1. В меню Dynatrace перейдите в Среды.

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

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

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

== Отключить/удалить среду ==
1. В меню Dynatrace перейдите в Среды.

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

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

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

== Доступ к среде ==
Чтобы получить доступ к среде со страницы администрирования Dynatrace Managed:

1. В меню Dynatrace перейдите в Среды.

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

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

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

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

Чтобы получить доступ к среде со страницы администрирования Dynatrace Managed другим способом:

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

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

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

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

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

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

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

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

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

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

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

Перенос кластера

2023-01-26T19:24:24Z

YaPolkin:

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

Используйте процедуры резервного копирования и восстановления кластера

Используйте встроенный механизм репликации узлов

У каждого метода есть преимущества и недостатки, описанные ниже.

== Метод резервного копирования ==
Этот вариант включает в себя резервное копирование исходного кластера, перенос данных резервного копирования и восстановление данных в целевой кластер.

Прежде чем выбрать этот вариант миграции, примите во внимание следующее:

'''Преимущества'''

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

'''Недостатки'''

* Мониторинг будет недоступен с момента начала резервного копирования кластера до завершения восстановления кластера на целевом кластере.
* По умолчанию резервное копирование Cassandra выполняется ежедневно, поэтому точка восстановления кластера будет последней выполненной резервной копией, что потенциально может привести к резервному копированию данных на срок до 24 часов. Вы можете запланировать миграцию ближе к времени резервного копирования, чтобы минимизировать потерю данных, однако, учитывая время, необходимое для переноса данных вручную и восстановления нового кластера, всегда будет некоторая потеря данных.
* Поскольку хранилище транзакций (данные PurePath со стандартным сроком хранения 10 дней) не включается в резервную копию, данные хранилища транзакций теряются при этом методе миграции.

=== Перенести кластер с помощью резервного копирования и восстановления ===
Чтобы перенести управляемые узлы Dynatrace с помощью метода резервного копирования и восстановления:

1. Настройте целевые узлы и всю необходимую сеть в целевом развертывании.

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

2. Создайте резервную копию текущего управляемого кластера Dynatrace.

* См. раздел Резервное копирование кластера

3. Остановите текущий управляемый кластер Dynatrace.

4. Выполните восстановление из резервной копии в целевой управляемый кластер Dynatrace.

* См. Восстановление кластера

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

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

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

Поскольку кластеру требуется постоянное межузловое соединение, сетевая связь между центрами обработки данных должна быть стабильной и безопасной. Имейте в виду, что трафик внутри кластеров (т. Е. Между узлами) не зашифрован. В результате для трафика между центрами обработки данных требуется зашифрованное соединение, например, с использованием VPN.</blockquote>
----'''Преимущества'''

* Без простоев и без потери данных.

'''Недостатки'''

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

=== Перенести кластер с помощью репликации ===
Чтобы выполнить миграцию узлов Dynatrace Managed с помощью метода репликации:

1. Настройте целевые узлы и всю необходимую сеть.

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

* См. Какие сетевые порты использует Dynatrace Server?

2. Добавляйте новые узлы Dynatrace Managed в целевой кластер по одному.

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

3. Отключите трафик OneAgent на исходных узлах, но продолжайте их работу до завершения репликации данных и до истечения срока хранения нереплицированных данных в хранилище транзакций.

Чтобы проверить прогресс репликации данных только на новом узле, выполните <code>cassandra-nodetool.sh</code> с параметром <code>status</code>:

<big>'''[Скачать]'''</big> '''<big>[Скопировать в буфер обмена]</big>'''

<code>sudo $DT_DIR/utils/cassandra-nodetool.sh status</code>

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

<code>Datacenter: datacenter1</code>

<code>===============Status=Up/Down</code>

<code>/ State=Normal/Leaving/Joining/Moving</code>

<code>– Address Load Tokens Owns (effective) Host ID Rack</code>

<code>UN 10.176.41.167 18.82 GB 256 100.0% 3af25127-4f99-4f43-afc3-216d7a2c10f8 rack1</code>

<code>UN 10.176.41.154 19.44 GB 256 100.0% 5a618559-3a73-42ec-83f0-32d28e08beec rack1</code>

Значение нагрузки не должно существенно различаться между узлами, а в состоянии на всех узлах должно отображаться значение UN.

[[Файл:Managednodejoining.webp|альт=Соединение нод Managed]]
----<blockquote>''<big>Хранение транзакций</big>''

*

Отключение узла фактически переводит хранилище транзакций в режим только для чтения, но узел по-прежнему может обрабатывать запросы.</blockquote>
----4. Удаляйте исходные узлы по одному.

Рекомендуется отложить удаление исходного (старого) узла до тех пор, пока не истечет срок хранения нереплицированных данных хранилища транзакций. Хранение этих данных можно настроить, но обычно оно хранится в течение 10 дней.
----<blockquote>Dynatrace не позволит вам удалить несколько узлов одновременно, поэтому перед удалением каждого последующего узла убедитесь, что данные были повторно распределены. Перенаправление данных обычно занимает пару часов в зависимости от объема данных и пропускной способности между узлами. В крайнем случае это может занять пару дней.</blockquote>

Настройка повышенных прав доступа

2023-01-26T11:54:49Z

YaPolkin:

По умолчанию управляемый кластер Dynatrace использует <code>sudo</code> для повышения разрешений для определенных операций обслуживания, и вам не нужно выполнять какие-либо дополнительные действия при запуске установки с целью настройки пользователей, разрешений и служб. Однако, если <code>sudo</code> недоступен в вашей ОС или вам необходимо использовать альтернативную команду для повышения разрешений, вы должны указать их во время установки.

* В интерактивном режиме, когда вас спросят о повышенных разрешениях, передайте префикс команды, включая программу, например <code>pbrun</code>, <code>sesudo</code> и <code>suexec</code>
* В тихом режиме этот параметр можно указать через настраиваемую установку

'''Примечание'''. Во всех примерах команд на этой странице предполагается следующее:

* <code>astromkey</code>(по умолчанию) — это пользователь, который запускает все службы ОС Dynatrace.
* Dynatrace Managed установлен в <code>/opt/astromkey-managed/</code>
* Данные расположены в директории <code>/var/opt/astromkey-managed/</code>

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

== Когда требуются повышенные разрешения ==
Пользователю ОС, запускающему управляемые службы Dynatrace, требуются повышенные разрешения для выполнения следующих задач:

* Запуск сценария установки или перенастройки
* Добавка или удаление ноду кластера
* Запуск, останавка, перезапуск и проверка состояния служб

Полный список команд, требующих повышенных разрешений, находится в файле <code>/opt/dtrun/dtrun.conf</code>. Директория <code>/opt/dtrun</code> и все файлы внутри принадлежат пользователю root по соображениям безопасности.

== Перенастройка команду dtrun sudo ==
Чтобы упростить управление разрешениями ОС, Dynatrace Managed использует один скрипт для запуска всех команд, требующих повышенных разрешений. Сценарий под названием <code>dtrun</code> представляет собой оболочку для <code>sudo</code> или любой другой команды, которую вы должны указать во время установки. Файл <code>dtrun</code> находится в директории <code>/opt/dtrun/dtrun</code>, и все команды, которые исполняются файлом <code>dtrun</code>, находятся в директории <code>/opt/dtrun/dtrun.conf</code>. Исполняться могут только скрипты и команды в директории <code>/opt/dtrun/dtrun.conf</code> can be run.

Если кластеру необходимо выполнить команду от имени пользователя root (например, чтобы добавить iptables, перезапустить компонент или запустить средство обновления), он будет использовать набор <code>SUDO_COMMAND</code> во время установки, чтобы попытаться получить повышенные разрешения. Вы также можете искать проблемы в лог-файле <code>/var/opt/astromkey-managed/log/dtrun.log</code>.

Если вам нужно перенастроить существующую установку для использования альтернативы <code>sudo</code>, вы можете запустить сценарий перенастройки. Например, чтобы изменить команду <code>sudo</code> на <code>pbrun</code>, используйте этот скрипт для повторного запуска программы установки:

<code>sudo /opt/astromkey-managed/installer/reconfigure.sh --sudo-cmd "/usr/bin/pbrun \$CMD"</code>

== Исправление неполадок ==
Неправильно настроенные разрешения могут привести к различным проблемам, например, с Dynatrace Managed или сетью. Если есть проблема с разрешениями, вы увидите такие записи в журнале установки, как:
<code>sudo: pam_open_session: System error
sudo: policy plugin failed session initialization</code>
Также вы увидите проблемы в этих журналах:

* <code>/var/opt/astromkey-managed/log/dtrun.log</code> (логи dtrun)
* <code>/var/opt/astromkey-managed/log/launch-logging.log</code> (логи скриптов запуска служб)

При устранении неполадок с sudo или повышенными разрешениями лучший подход — запустить всю конфигурацию сразу и сравнить. Под пользователем root все приведенные ниже команды должны генерировать вывод:
<code>cat /etc/sudoers | grep -i include
cat /etc/sudoers.d/astromkey

su - astromkey-s /bin/bash -c 'sudo /opt/dtrun/dtrun iptables -L -n'

cat /etc/sudoers | grep astromkey
cat /etc/passwd | grep astromkey
cat /etc/shadow | grep astromkey

chage -l astromkey</code>
Команда <code>chage</code> сообщает вам, истекает ли срок действия пароля (это также может вызвать проблемы с доступом к <code>sudo</code>). Когда вы выполняете дополнительные проверки безопасности, чтобы контролировать, что разрешено выполнять <code>dtrun</code>, вы можете легко узнать, работает ли <code>sudo</code> должным образом, выполнив следующую команду от имени пользователя root:
<code>su - astromkey -s /bin/bash -c 'sudo /opt/dtrun/dtrun service astromkey-server status'</code>
Следующая команда является примером проверки повышения разрешений с помощью альтернативы <code>sudo</code>, <code>pbrun</code>:
<code>su - astromkey -s /bin/bash -c 'pbrun /opt/dtrun/dtrun service astromkey-server status'</code>

Балансировка нагрузки

2023-01-26T11:53:07Z

YaPolkin:

Dynatrace Managed включает NGINX, универсальный высокопроизводительный HTTP-сервер с открытым исходным кодом и обратный прокси-сервер. NGINX, установленный на каждом узле кластера, выполняет балансировку нагрузки и маршрутизацию трафика между узлами. NGINX настроен специально для выполнения следующих задач:

* '''Постоянство сеанса.''' После открытия сеанса веб-интерфейса на данной ноде кластера запросы перенаправляются на эту ноду до тех пор, пока пользователь не закроет сеанс (выйдет из системы).
* '''Проверка работоспособности узлов'''. Если узел недоступен, этот узел помечается как неработоспособный, и трафик перенаправляется только на исправные узлы.
* '''Разрешение DNS''' (необязательно). Записи DNS управляются для кластера; DNS разрешается в IP-адреса всех узлов кластера. Это обеспечивает дополнительную балансировку нагрузки на основе DNS (порядок IP-адресов рандомизирован в разрешении DNS). Автоматическое управление DNS для кластера не является обязательным — вы можете отказаться и использовать вместо этого свой DNS.

NGINX является неотъемлемой частью управляемого развертывания Dynatrace. Если вам нужен дополнительный уровень балансировки нагрузки для создания единой точки доступа, вы можете настроить балансировщик нагрузки перед кластером.

== Рекомендации по установке ==

* '''Сертификация.''' В вашей организации могут быть строгие правила в отношении управления сертификатами TLS и контроля доступа. Например, политика может требовать, чтобы весь входящий трафик проходил через одобренный организацией центральный балансировщик нагрузки или прокси-сервер.
* '''Расширенная отработка отказа'''. В случае сбоя оборудования или сети узла IP-адрес узла может оставаться частью записи домена. Это может привести к тайм-аутам подключения, если в разрешении DNS выбран неработоспособный IP-адрес. Внешний балансировщик нагрузки может автоматически исключать неработоспособный узел, что улучшает взаимодействие с пользователем.
* '''Географически распределенная балансировка нагрузки'''. Для кластеров, развернутых в двух центрах обработки данных (с использованием функции ВысокаяДоступность), мы рекомендуем иметь дополнительный балансировщик нагрузки, который может оптимизировать доступ пользователей и обрабатывать отказоустойчивость между центрами обработки данных. См. [[ВысокаяДоступность для дата-центров]]

== Рекомендации по настройке ==
Конфигурация балансировщика нагрузки зависит от того, как будет использоваться конкретный балансировщик нагрузки. Ниже приведены общие рекомендации.

=== Целевая конфигурация ===
Список целевых узлов должен содержать IP-адреса управляемых узлов Dynatrace, предназначенных для получения веб-трафика, включая пользовательский трафик и вызовы REST API. Обычно список должен содержать все узлы кластера. Этот список необходимо обновлять после присоединения или удаления узла.

В консоли управления кластером вы можете исключить узел из трафика веб-интерфейса. Эта функция влияет на конфигурацию NGINX и автоматически выделяемый домен (<code>xyz.astromkey-managed.com</code>). При использовании внешнего балансировщика нагрузки узлы кластера необходимо исключить из списка целевых узлов; в противном случае они все равно будут получать сетевой трафик. См. Возможности узла кластера.

Трафик должен быть перенаправлен на HTTPS-порт 443 NGINX. Путь/параметры запроса никоим образом не должны изменяться; пользовательские суффиксы пути не поддерживаются.

=== Таймауты ===
Мы рекомендуем установить значение таймаута для целевого ответа не меньше, чем настроено в NGINX по умолчанию (120 секунд).

=== Проверки работоспособности ===
Мы рекомендуем настроить проверки работоспособности для всех целевых узлов. Если вы не настроите проверки работоспособности для всех целевых узлов, балансировщик нагрузки может попытаться перенаправить трафик на узел, который не отслеживается проверкой работоспособности и который может быть недоступен из-за сбоя.

Используйте URL-адрес <code>/rest/health</code> для проверки работоспособности с ожидаемым кодом ответа <code>HTTP 200</code>.

=== Постоянство сеанса ===
Постоянство сеансанастраивается и реализуется кластером Dynatrace Managed. Настройка не требуется.

=== Домен и SSL-сертификаты (необязательно) ===
Конфигурация доменного имени, указывающего на балансировщик нагрузки, и сертификат TLS необязательны. Вы можете отключить опцию автоматической обработки доменов и сертификатов Dynatrace. См. [[Конфигурация DNS для Ключ-АСТРОМ Managed|Конфигурация DNS для Dynatrace Managed]].

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

=== Конфигурация общедоступной конечной точки ===

# В консоли управления кластером (CMC) перейдите в раздел '''Параметры''' и выберите '''Общедоступные конечные точки'''.
# Настройте '''URL-адрес веб-интерфейса Dynatrace''', чтобы он указывал на ваш балансировщик нагрузки.

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

=== Конфигурация конечной точки OneAgent ===

# В консоли управления кластером (CMC) перейдите к '''Статус развертывания''' и выберите '''Узлы кластера'''.
# На странице сведений о каждом узле выберите '''Настроить''' и в разделе '''Настройка конечных точек узла''' укажите '''IP-адрес и порт для трафика OneAgent''', чтобы они указывали на подсистему балансировки нагрузки, а не на узел напрямую.

== Мониторинг реального пользователя/Мобильный/Синтетический трафик ==
Если вы планируете использовать балансировщик нагрузки там, где используется безагентный мониторинг реального пользователя или мобильных приложений, мы настоятельно рекомендуем настроить балансировщик нагрузки либо перед кластерными ActiveGate'ами, либо непосредственно перед кластером. Из-за возможности больших объемов TLS-подключений и скачков запросов, передача завершения TLS на балансировщик нагрузки выгодна, особенно если балансировщик нагрузки имеет аппаратно-ускоренную обработку TLS и/или возможности автоматического масштабирования. Это может защитить кластер от перегрузки и разделить путь доступа между трафиком маяка и трафиком веб-интерфейса/OneAgent.

Если вы планируете использовать балансировщик нагрузки для Мобильного/Синтетического трафика и мониторинга реального пользователя, в дополнение к общим рекомендациям по настройке балансировщика нагрузки необходимо настроить следующий параметр.

=== Конфигурация общедоступной конечной точки ===

# В консоли управления кластером (CMC) перейдите в раздел '''Параметры''' и выберите '''Общедоступные конечные точки'''.
# Настройте '''URL-адрес ActiveGate Кластера''', чтобы он указывал на ваш балансировщик нагрузки. Вы можете сделать это, даже если у вас нет кластерных ActiveGate и/или балансировщик нагрузки указывает прямо на управляемый кластер.

Балансировка нагрузки

2023-01-26T11:52:53Z

YaPolkin:

Dynatrace Managed включает NGINX, универсальный высокопроизводительный HTTP-сервер с открытым исходным кодом и обратный прокси-сервер. NGINX, установленный на каждом узле кластера, выполняет балансировку нагрузки и маршрутизацию трафика между узлами. NGINX настроен специально для выполнения следующих задач:

* '''Постоянство сеанса.''' После открытия сеанса веб-интерфейса на данной ноде кластера запросы перенаправляются на эту ноду до тех пор, пока пользователь не закроет сеанс (выйдет из системы).
* '''Проверка работоспособности узлов'''. Если узел недоступен, этот узел помечается как неработоспособный, и трафик перенаправляется только на исправные узлы.
* '''Разрешение DNS''' (необязательно). Записи DNS управляются для кластера; DNS разрешается в IP-адреса всех узлов кластера. Это обеспечивает дополнительную балансировку нагрузки на основе DNS (порядок IP-адресов рандомизирован в разрешении DNS). Автоматическое управление DNS для кластера не является обязательным — вы можете отказаться и использовать вместо этого свой DNS.

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

== Рекомендации по установке ==

* '''Сертификация.''' В вашей организации могут быть строгие правила в отношении управления сертификатами TLS и контроля доступа. Например, политика может требовать, чтобы весь входящий трафик проходил через одобренный организацией центральный балансировщик нагрузки или прокси-сервер.
* '''Расширенная отработка отказа'''. В случае сбоя оборудования или сети узла IP-адрес узла может оставаться частью записи домена. Это может привести к тайм-аутам подключения, если в разрешении DNS выбран неработоспособный IP-адрес. Внешний балансировщик нагрузки может автоматически исключать неработоспособный узел, что улучшает взаимодействие с пользователем.
* '''Географически распределенная балансировка нагрузки'''. Для кластеров, развернутых в двух центрах обработки данных (с использованием функции ВысокаяДоступность), мы рекомендуем иметь дополнительный балансировщик нагрузки, который может оптимизировать доступ пользователей и обрабатывать отказоустойчивость между центрами обработки данных. См. [[ВысокаяДоступность для дата-центров]]

== Рекомендации по настройке ==
Конфигурация балансировщика нагрузки зависит от того, как будет использоваться конкретный балансировщик нагрузки. Ниже приведены общие рекомендации.

=== Целевая конфигурация ===
Список целевых узлов должен содержать IP-адреса управляемых узлов Dynatrace, предназначенных для получения веб-трафика, включая пользовательский трафик и вызовы REST API. Обычно список должен содержать все узлы кластера. Этот список необходимо обновлять после присоединения или удаления узла.

В консоли управления кластером вы можете исключить узел из трафика веб-интерфейса. Эта функция влияет на конфигурацию NGINX и автоматически выделяемый домен (<code>xyz.astromkey-managed.com</code>). При использовании внешнего балансировщика нагрузки узлы кластера необходимо исключить из списка целевых узлов; в противном случае они все равно будут получать сетевой трафик. См. Возможности узла кластера.

Трафик должен быть перенаправлен на HTTPS-порт 443 NGINX. Путь/параметры запроса никоим образом не должны изменяться; пользовательские суффиксы пути не поддерживаются.

=== Таймауты ===
Мы рекомендуем установить значение таймаута для целевого ответа не меньше, чем настроено в NGINX по умолчанию (120 секунд).

=== Проверки работоспособности ===
Мы рекомендуем настроить проверки работоспособности для всех целевых узлов. Если вы не настроите проверки работоспособности для всех целевых узлов, балансировщик нагрузки может попытаться перенаправить трафик на узел, который не отслеживается проверкой работоспособности и который может быть недоступен из-за сбоя.

Используйте URL-адрес <code>/rest/health</code> для проверки работоспособности с ожидаемым кодом ответа <code>HTTP 200</code>.

=== Постоянство сеанса ===
Постоянство сеансанастраивается и реализуется кластером Dynatrace Managed. Настройка не требуется.

=== Домен и SSL-сертификаты (необязательно) ===
Конфигурация доменного имени, указывающего на балансировщик нагрузки, и сертификат TLS необязательны. Вы можете отключить опцию автоматической обработки доменов и сертификатов Dynatrace. См. [[Конфигурация DNS для Ключ-АСТРОМ Managed|Конфигурация DNS для Dynatrace Managed]].

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

=== Конфигурация общедоступной конечной точки ===

# В консоли управления кластером (CMC) перейдите в раздел '''Параметры''' и выберите '''Общедоступные конечные точки'''.
# Настройте '''URL-адрес веб-интерфейса Dynatrace''', чтобы он указывал на ваш балансировщик нагрузки.

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

=== Конфигурация конечной точки OneAgent ===

# В консоли управления кластером (CMC) перейдите к '''Статус развертывания''' и выберите '''Узлы кластера'''.
# На странице сведений о каждом узле выберите '''Настроить''' и в разделе '''Настройка конечных точек узла''' укажите '''IP-адрес и порт для трафика OneAgent''', чтобы они указывали на подсистему балансировки нагрузки, а не на узел напрямую.

== Мониторинг реального пользователя/Мобильный/Синтетический трафик ==
Если вы планируете использовать балансировщик нагрузки там, где используется безагентный мониторинг реального пользователя или мобильных приложений, мы настоятельно рекомендуем настроить балансировщик нагрузки либо перед кластерными ActiveGate'ами, либо непосредственно перед кластером. Из-за возможности больших объемов TLS-подключений и скачков запросов, передача завершения TLS на балансировщик нагрузки выгодна, особенно если балансировщик нагрузки имеет аппаратно-ускоренную обработку TLS и/или возможности автоматического масштабирования. Это может защитить кластер от перегрузки и разделить путь доступа между трафиком маяка и трафиком веб-интерфейса/OneAgent.

Если вы планируете использовать балансировщик нагрузки для Мобильного/Синтетического трафика и мониторинга реального пользователя, в дополнение к общим рекомендациям по настройке балансировщика нагрузки необходимо настроить следующий параметр.

=== Конфигурация общедоступной конечной точки ===

# В консоли управления кластером (CMC) перейдите в раздел '''Параметры''' и выберите '''Общедоступные конечные точки'''.
# Настройте '''URL-адрес ActiveGate Кластера''', чтобы он указывал на ваш балансировщик нагрузки. Вы можете сделать это, даже если у вас нет кластерных ActiveGate и/или балансировщик нагрузки указывает прямо на управляемый кластер.

Настройка экстренных контактов

2023-01-26T11:50:01Z

YaPolkin:

Чтобы указать экстренные контакты в Dynatrace Managed:

# В Консоли Менеджмента Кластера перейдите в '''Настройки'''> '''Почта'''> '''Уведомления по электронной почте'''.
# На странице '''Уведомления по электронной почте''' в разделе '''Получатели экстренных уведомлений''' введите один или несколько адресов электронной почты, разделенных запятыми. Эти адреса будут получать экстренные уведомления от команды Dynatrace в случае катастрофических состояний кластера или критических уязвимостей, которые необходимо устранить.
# Сохраните изменения.

Уведомления о работе кластера

2023-01-26T11:47:22Z

YaPolkin:

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

* '''Недостаточно места на диске на ноде кластера.''' Запускается, когда раздел диска на узле кластера имеет меньше дискового пространства, чем требуется для данного типа хранилища. В этом случае вам необходимо расширить диск или просмотреть настройки кластера. В противном случае срок хранения данных может уменьшиться.
* '''Недостаточное оборудование на ноде кластера'''. Запускается, когда на узле кластера недостаточно ядер ЦП и оперативной памяти для выполнения рекомендуемых требований. Дополнительные сведения см. в разделе [[Требования Managed к оборудованию|Требования к оборудованию]].
* '''Хранилище метрик превышает поддерживаемый размер (4 ТБ).''' Запускается, когда хранилище метрик для узла кластера слишком велико. В этом случае вам необходимо просмотреть настройки мониторинга или добавить дополнительные узлы в кластер.
* '''Сокращение периода хранения транзакций.''' Запускается, когда срок хранения данных автоматически сокращается для хранения новых данных. В этом случае мы рекомендуем настроить целевое время хранения, просмотреть параметры мониторинга или расширить диск.
* '''Адаптивное снижение нагрузки'''. Запускается, когда узел кластера считается перегруженным и не может справиться с обработкой входящих запросов. В этом случае вам необходимо пересмотреть настройки мониторинга или увеличить количество ядер ЦП и ОЗУ на узле кластера. Дополнительные сведения см. в разделе [[Адаптивное управление и контроль трафика]].

== Настройка параметров уведомлений кластера ==

# Создайте токен кластера,
# (необязательно) Проверьте схему настроек уведомлений
# (необязательно) Проверьте текущие настройки уведомлений
# Создайте объект настроек уведомлений
# Обновите настройки уведомлений
# (необязательно) Удалите объект настроек уведомлений

== Аутентификация ==
Чтобы создать токен кластера с областями параметров '''записи''' и '''чтения:'''

# В меню Dynatrace выберите '''Настройки''' -> '''Токены API'''.
# В разделе '''Токены кластера''' выберите '''Создать токен'''.
# Введите имя для вашего токена и определите области доступа к параметрам '''записи''' и '''чтения''' вашего токена API кластера.
# '''Сохраните''' и '''скопируйте''' токен в безопасное место.

== Настройка уведомлений по электронной почте ==
Чтобы отправить конфигурацию в формате JSON, используйте конечную точку объекта POST с токеном кластера, который имеет соответствующие области доступа:
<code>[
{
"schemaId": "builtin:cluster-events-notification-settings",
"scope": "cluster",
"value": {
"insufficientDiskSpace": {
"sendEmail": true
},
"insufficientHardware": {
"sendEmail": true
},
"insufficientMetricStorage": {
"sendEmail": false
},
"transactionStorageTruncation": {
"sendEmail": false
},
"adaptiveLoadReductionActivated": {
"sendEmail": false
}
}
}
]</code>

== Чтение схемы конфигурации ==
Чтобы узнать формат JSON, необходимый для публикации вашей конфигурации, используйте конечную точку схемы GET с токеном кластера, который имеет соответствующие области доступа. Идентификатор схемы конфигурации (<code>schemaId</code>) — <code>builtin:cluster-events-notification-settings</code>.
<code>{
"AstromKey": "1",
"schemaId": "builtin:cluster-events-notification-settings",
"displayName": "Cluster events notification settings",
"description": "Configuration of emails notifications for cluster events.",
"documentation": "Email notifications are sent to recipients defined in Settings - Emails - Email notifications.",
"version": "0",
"multiObject": false,
"maxObjects": 1,
"allowedScopes": [
"cluster"
],
"enums": {},
"types": {
"SingleEventSettings": {
"version": "0",
"versionInfo": "",
"displayName": "Single event settings",
"summaryPattern": "",
"description": "Settings for a single cluster event",
"documentation": "",
"properties": {
"sendEmail": {
"displayName": "Send email",
"description": "",
"documentation": "",
"type": "boolean",
"nullable": false,
"maxObjects": 1,
"modificationPolicy": "DEFAULT",
"default": true
}
},
"type": "object"
}
},
"properties": {
"insufficientDiskSpace": {
"displayName": "Insufficient disk space on a cluster node",
"description": "Triggered when a disk partition on a cluster node has less disk space than required for a given storage type. In that case, you need to extend your disk or review cluster settings. Otherwise, data retention might be reduced.",
"documentation": "",
"type": {
"$ref": "#/types/SingleEventSettings"
},
"nullable": false,
"maxObjects": 1,
"modificationPolicy": "DEFAULT"
},
"insufficientHardware": {
"displayName": "Insufficient hardware on a cluster node",
"description": "Triggered when a cluster node doesn't have enough CPU cores and RAM to meet recommended requirements.",
"documentation": "",
"type": {
"$ref": "#/types/SingleEventSettings"
},
"nullable": false,
"maxObjects": 1,
"modificationPolicy": "DEFAULT"
},
"insufficientMetricStorage": {
"displayName": "Metrics storage exceeds supported size (4TiB)",
"description": "Triggered when Metrics storage a cluster node is too high. In that case, you need to review your monitoring settings or add additional nodes to the cluster.",
"documentation": "",
"type": {
"$ref": "#/types/SingleEventSettings"
},
"nullable": false,
"maxObjects": 1,
"modificationPolicy": "DEFAULT"
},
"transactionStorageTruncation": {
"displayName": "Transaction storage retention period truncation",
"description": "Triggered when data retention has been automatically reduced to store new data. In that case, it is recommended to adjust target retention time, review monitoring settings or extend a disk.",
"documentation": "",
"type": {
"$ref": "#/types/SingleEventSettings"
},
"nullable": false,
"maxObjects": 1,
"modificationPolicy": "DEFAULT"
},
"adaptiveLoadReductionActivated": {
"displayName": "Adaptive Load Reduction activity",
"description": "Triggered when a cluster node has been considered as overloaded and not able to keep up with processing incoming requests. In that case, you need to review monitoring settings or increase CPU cores and RAM on the cluster node.",
"documentation": "",
"type": {
"$ref": "#/types/SingleEventSettings"
},
"nullable": false,
"maxObjects": 1,
"modificationPolicy": "DEFAULT"
}
}
}</code>

== Чтение текущих настроек ==
Чтобы проверить текущую конфигурацию, используйте конечную точку объектов GET (<code>/api/cluster/v2/settings/objects?schemaIds=builtin:cluster-events-notification-settings&scopes=cluster</code>) с токеном кластера, который имеет соответствующие права доступа.

* Если эти настройки были ранее изменены, список элементов будет содержать один объект. Используйте <code>objectId</code> из списка при последующих обновлениях.
* Если список элементов пуст, используется значение по умолчанию (не отображается в API):

<code>{
"value": {
"insufficientDiskSpace": {
"sendEmail": true
},
"insufficientHardware": {
"sendEmail": true
},
"insufficientMetricStorage": {
"sendEmail": true
},
"transactionStorageTruncation": {
"sendEmail": false
},
"adaptiveLoadReductionActivated": {
"sendEmail": false
}
}
}</code>

== Создание объекта настроек уведомлений ==
Чтобы создать объект параметров уведомлений о событиях кластера, используйте конечную точку объектов POST с токеном кластера, который имеет соответствующие области доступа. Используйте идентификатор вновь созданного объекта (настройки уведомлений о событиях) для последующего обновления настроек уведомлений.
В этом примере, используя <code>POST-вызов</code> к API <code>/api/cluster/v2/settings/objects</code> и схеме <code>builtin:cluster-events-notification-settings</code> вы создаёте объект настроек уведомлений в кластере.
<code>[
{
"schemaId": "builtin:cluster-events-notification-settings",
"scope": "cluster",
"value": {
"insufficientDiskSpace": {
"sendEmail": true
},
"insufficientHardware": {
"sendEmail": true
},
"insufficientMetricStorage": {
"sendEmail": false
},
"transactionStorageTruncation": {
"sendEmail": false
},
"adaptiveLoadReductionActivated": {
"sendEmail": false
}
}
}
]</code>

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

* Вы можете использовать тот же метод <code>POST</code>, который вы использовали для создания объекта настроек (Создать объект настроек уведомлений). Схема не допускает дублирования объектов настроек, поэтому, если вы попытаетесь создать другой объект настроек, вы перезапишете существующий.
* Вы можете изменить существующий объект настроек, выполнив вызов <code>PUT</code> к API <code>/api/cluster/v2/settings/objects/<objectId></code> конечной точки и предоставления <code>objectId</code>, полученного при создании объекта настроек начального уведомления о событии.

Выполните <code>PUT-вызов</code> к API <code>/api/cluster/v2/settings/objects/<objectId></code>
<code>{
"value": {
"insufficientDiskSpace": {
"sendEmail": true
},
"insufficientHardware": {
"sendEmail": true
},
"insufficientMetricStorage": {
"sendEmail": false
},
"transactionStorageTruncation": {
"sendEmail": false
},
"adaptiveLoadReductionActivated": {
"sendEmail": false
}
}
}</code>

== Удалить настройки уведомлений ==
Вы можете удалить существующий объект настроек уведомлений, выполнив <code>DELETE-вызов</code> к API <code>/api/cluster/v2/settings/objects/<objectId></code> конечной точки (с токеном кластера с соответствующими областями доступа) и предоставлением <code>objectId</code>, полученного при создании объекта настроек начального уведомления о событии. После удаления объекта поведение уведомлений возвращается к значению по умолчанию: все уведомления инициируют отправку электронной почты настроенным получателям.

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

2023-01-26T11:46:51Z

YaPolkin:

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

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

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

Правила сложности пароля

2023-01-26T11:46:09Z

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 символов (требование большей длины не обязательно лучше).
# Обязательное использование комбинации прописных и строчных букв, цифр и не буквенно-цифровых символов.
# Обучайте пользователей не использовать их пароли Dynatrace повторно в целях, не связанных с Dynatrace.
# По возможности используйте центральную службу репозитория пользователей вашей организации - LDAP или SSO.

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

2023-01-26T11:44:43Z

YaPolkin:

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

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

Типы входа:

* <code>LOCAL</code> - Пользователи, которые существуют только в базе данных кластера и являются локальными по отношению к кластеру.
* <code>LDAP</code> - пользователи LDAP
* <code>SSO</code> - вход от вашего поставщика удостоверений
* <code>DEVOPSTOKEN</code> - вход через проактивную службу поддержки Mission Control

Чтобы завершить сеанс, выберите [[Файл:Remove-icon.png|альт=Удалить]] и подтвердите действие. Сеанс немедленно завершится, и пользователь выйдет из системы.

Чтобы изменить количество разрешенных одновременных пользовательских сеансов, выберите '''Настроить пользовательские сессии'''. Вы можете установить разные лимиты для обычных пользователей и администраторов. Учетные записи администраторов - это пользователи, которые принадлежат к любой группе с глобальными разрешениями администратора кластера.

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

Используйте REST API для обновления политики автоматического выхода из системы. По умолчанию автоматический выход из системы для пользователей, которые остаются на автоматически обновляемых страницах, отсутствует. См. раздел Обновление конфигурации пользовательских сеансов кластера.

Возможности ноды кластера

2023-01-26T11:43:55Z

YaPolkin:

Для некоторых развертываний может потребоваться, чтобы определенные узлы обслуживали только трафик пользовательского интерфейса, а не обрабатывали данные OneAgent. Или наоборот, когда узлы обрабатывают только данные OneAgent и не обслуживают трафик пользовательского интерфейса. Настроив один или другой из этих параметров, вы можете добиться более высокой стабильности, лучшего поведения кеша и более быстрого времени отклика пользовательского интерфейса.
----<blockquote><big>''Трафик веб-интерфейса''</big>

*

Чтобы повысить производительность балансировки нагрузки DNS, начиная с Dynatrace Managed 1.214, трафик веб-интерфейса по умолчанию отключен при установке 13-го и последующих узлов (или 7-го и последующих узлов в центре обработки данных для Premium HA). Вы можете включить/отключить трафик веб-интерфейса для узла через Cluster REST API (кластерный REST API).

* Примечания к релизу Dynatrace Managed версии 1.214
</blockquote>
----Чтобы включить или отключить трафик OneAgent на узле, вы можете использовать веб-интерфейс, командную строку или вызов API.

== Включение/отключение трафика OneAgent через пользовательский интерфейс консоли управления кластером ==
Чтобы отключить трафик OneAgent (т.е. установить узел кластера в режим ожидания)

# В меню Dynatrace перейдите в раздел '''Статус развертывания'''.
# Разверните ноду кластера, которую вы хотите отключить, и нажмите '''Настроить'''.
# Нажмите кнопку обзора ('''…''') в правом верхнем углу.
# Выберите '''Отключить трафик OneAgent''', чтобы остановить обработку данных мониторинга на узле.

Чтобы включить трафик OneAgent на узле, повторите первые три шага выше, затем выберите '''Включить трафик OneAgent''', чтобы начать обработку данных мониторинга на узле.

== Включение/отключение трафика веб-интерфейса через интерфейс консоли управления кластером ==
Чтобы отключить трафик веб-интерфейса (т.е. установить узел кластера в режим ожидания)

# В меню Dynatrace перейдите в раздел '''Статус развертывания'''.
# Разверните ноду кластера, которую вы хотите отключить, и нажмите '''Настроить'''.
# Нажмите кнопку обзора ('''…''') в правом верхнем углу.
# Выберите '''Отключить трафик веб-интерфейса''', чтобы остановить обработку данных мониторинга на узле.

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

== Включение/отключение трафика OneAgent или веб-интерфейса с помощью вызова 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
|Устанавливает трафик OneAgent для этой ноды. Определите, должен ли этот узел получать трафик OneAgent (<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>

Удалённый доступ к кластеру

2023-01-26T11:40:24Z

YaPolkin:

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

Важно! Для доступа к Консоли Менеджмента Кластера у Вас должны быть права администратора.

Чтобы настроить уровень разрешений в вашем кластере, в Консоли Менеджмента Кластера выберите '''Настройки''' > '''Разрешения на удаленный доступ'''. На этой странице вы можете разрешить команде Dynatrace удаленный доступ к вашему кластеру. Если этот параметр включен и события обнаружены, наша команда может удаленно настроить параметры вашего кластера, чтобы обеспечить оптимальную производительность и стабильность.

Вся связь с Контроллером Задач защищена и осуществляется через HTTPS с проверкой сертификатов, как в браузере. Все изменения конфигурации, управляемые Ключом-Астром, полностью регистрируются аудитом, и каждый удаленный доступ регистрируется как отдельное событие (в меню перейдите в раздел '''События''', чтобы просмотреть список зарегистрированных событий). Контроллер Задач не может получить доступ к сертификатам или учетным данным пользователя и root-доступ к каким-либо серверам.

После включения поддержки удаленного доступа Dynatrace вы можете установить область разрешений удаленного доступа для команды Dynatrace на одну из следующих областей:

* '''Все''' Вся наша команда экспертов может получить доступ к вашему кластеру, чтобы предоставить вам всю мощь поддержки и оптимизировать настройки вашего кластера.
* '''Только чтение для всех''' Вся наша команда экспертов имеет доступ к вашему кластеру, но не может изменять какие-либо настройки кластера. Этот вариант значительно ограничивает уровень поддержки. В этом случае пользователю с удаленным доступом доступна только роль наблюдателя. При необходимости наша команда свяжется с вами, чтобы внести необходимые изменения.
* '''Только одобренные участники''' Только утвержденные члены нашей команды могут получить доступ к вашему кластеру. Администраторы вашего кластера получат уведомление по электронной почте об ожидающих запросах на удаленный доступ. Администратор кластера должен утверждать каждый запрос на предоставление разрешений. Вы можете настроить продолжительность и роль, которую вы предоставляете. Вы также можете заранее предоставить разрешения известным членам команды Dynatrace. Эта область дает вам максимальный контроль над тем, кто может получить доступ к вашему кластеру, но существенно влияет на способность нашей команды предоставлять вам поддержку. Пользователю удаленного доступа можно назначить роль администратора, пользователя или наблюдателя. Подробные сведения о разрешениях, назначаемых каждой роли, см. в следующей таблице:

{| class="wikitable"
!Права
!Администратор
!Пользователь
!Наблюдатель
!Описание
|-
|Окружение
|Да
|Да
|Да
|Разрешает доступ только для чтения к среде. В частности, сотрудники Dynatrace имеют доступ к:

* Пользовательские настройки — профиль пользователя, выполнившего вход, и параметры пользователя, выполнившего вход (например, запланированные отчеты, избранные информационные панели и пункты меню).
* Страницы Dynatrace — страницы установки для OneAgent или ActiveGate.
* Настройки в режиме только для чтения
* Отчеты
* Консоль Менеджмента Кластера в режиме чтения
* Запросить настройку правил сбора данных в режиме чтения
* Только внутренние диагностические данные
* Чтение журнала аудита
* Поддержка доступа к архиву
* Доступ к хранилищу синтетических учетных данных, действия по обновлению/удалению учетных данных, принадлежащих пользователю

Сотрудники Dynatrace не могут изменять настройки или устанавливать OneAgent только с этим разрешением.
|-
|Запись
|Да
|Нет
|Нет
|Позволяет пользователю изменять настройки мониторинга среды.
|-
|Скачивание OneAgent и ActiveGate
|Да
|Нет
|Нет
|Позволяет пользователю загружать OneAgent и ActiveGate из концентратора и устанавливать их на хосты.
|-
|Изменение конфигурации Консоли Менеджмента Кластера
|Да
|Нет
|Нет
|Позволяет пользователю изменять параметры кластера в Консоли Менеджмента Кластера.
|-
|Логи
|Да
|Нет
|Нет
|Позволяет пользователю получить доступ к странице журналов и журналу содержимого ваших приложений. Журналы могут содержать конфиденциальную информацию.
|-
|Настройка захвата конфиденциальных данных
|Да
|Нет
|Нет
|Позволяет пользователю настраивать правила захвата атрибутов запроса. Их можно использовать для захвата таких элементов, как заголовки HTTP или параметры публикации, для хранения, фильтрации и поиска. Также позволяет пользователю вручную запускать дампы памяти.
|-
|Просмотр конфиденциальных данных запроса
|Нет
|Нет
|Нет
|Позволяет пользователю просматривать потенциально личные данные, захваченные Ключом-Астром, включая разрешение на загрузку дампов памяти. Пользователи, у которых нет этого разрешения, видят, что точка данных существует, но личные данные скрыты звездочками (*****). Также позволяет пользователю вручную запускать дампы памяти.
|-
|Включение отладочных флагов OneAgent
|Да
|Да
|Нет
|Позволяет пользователю выполнять диагностические операции только для чтения и устанавливать флаги отладки OneAgent.
|-
|Выполнение диагностических операций
|Да
|Нет
|Нет
|Позволяет пользователю выполнять диагностические операции, такие как перезапуск службы, запуск диагностических сценариев на узлах кластера и доступ к базе данных.
|-
|Воспроизведение данных сеанса с маскированием
|Да
|Да
|Да
|Позволяет пользователю воспроизводить записанные сеансы пользователя с применением правил маскирования воспроизведения во время воспроизведения. Обратите внимание, что данные, замаскированные во время записи, никогда не захватываются и поэтому всегда маскируются при воспроизведении.
|-
|Воспроизведение данных сеанса без маскирования
|Нет
|Нет
|Нет
|Позволяет пользователю воспроизводить записанные сеансы пользователя без применения правил маскирования воспроизведения. Обратите внимание, что любые данные, замаскированные во время записи, всегда замаскированы во время воспроизведения.
|-
|Решение проблемы безопасности
|Нет
|Нет
|Нет
|Позволяет пользователю управлять проблемами, о которых сообщает Безопасность Приложений.
|-
|Просмотр проблем безопасности
|Да
|Нет
|Нет
|Позволяет пользователю просматривать проблемы безопасности.
|}

== API ==
Вы также можете использовать REST API удаленного доступа для настройки параметров и разрешений удаленного доступа. Подробности см. в разделе [[API Кластера v2]].

Конфигурация DNS для Ключ-АСТРОМ Managed

2023-01-26T11:37:59Z

YaPolkin: YaPolkin переименовал страницу Конфигурация DNS для Ключ-АСТРОМ Managed в Конфигурация DNS для Dynatrace Managed

#перенаправление [[Конфигурация DNS для Dynatrace Managed]]

Конфигурация DNS для Dynatrace Managed

2023-01-26T11:37:59Z

YaPolkin: YaPolkin переименовал страницу Конфигурация DNS для Ключ-АСТРОМ Managed в Конфигурация DNS для Dynatrace Managed

Если вам необходимо настроить собственный сертификат SSL (см. раздел [[Установка собственного SSL-сертификата для ноды кластера|Установка собственного сертификата SSL]]), вам также необходимо создать собственное доменное имя для домена кластера. Для этого вам необходимо указать свою общедоступный эндпоинт и изменить локальный DNS.
----<blockquote><big>''Неверная конфигурация может привести к сбою кластера''</big>

*

Неверная конфигурация DNS может привести к несоответствию данных или к отказу кластера. Никакой дополнительной настройки не требуется, кроме шагов, описанных ниже.</blockquote>
----

===== Укажите свою общедоступный эндпоинт =====
В меню Dynatrace перейдите в '''Настройки''' > '''Общедоступные эндпоинты''' и введите адрес, который вы обычно используете для доступа к пользовательскому интерфейсу кластера Dynatrace (ваше собственное доменное имя).

===== Добавьте записи в свой локальный DNS =====
Для каждого управляемого узла Dynatrace добавьте запись с его IP-адресом и вашим доменом. Если вы полагаетесь на сопоставление имен хостов с IP-адресами, добавьте записи типа <code>A</code> в следующем формате:

<code>Host Type IP</code>

Например:

<code>dynatrace.mycompany.com A 10.176.0.1, 10.176.0.2, 10.176.0.3</code>

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

Например:

<code>dynatrace.mycompany.com A 10.176.0.1, 10.176.0.2, 10.176.0.3</code>

<code>n01.dynatrace.mycompany.com A 10.176.0.1</code>

<code>n02.dynatrace.mycompany.com A 10.176.0.2</code>

<code>n03.dynatrace.mycompany.com A 10.176.0.3</code>

Конфигурация DNS для Dynatrace Managed

2023-01-26T11:37:51Z

YaPolkin:

Настройка подключения к SMTP-серверу

2023-01-26T11:37:15Z

YaPolkin:

Используйте эти настройки, чтобы определить, как Dynatrace доставляет пользователям и администраторам уведомления по электронной почте, отчеты и другие сообщения.

1. В меню Dynatrace зайдите в '''Настройки'''.

2. Разверните '''Emails''' и выберите '''сервер''' '''SMTP''', чтобы отобразить страницу настройки '''SMTP-сервера'''.

3. Начните с выбора способа доставки электронной почты.

* '''SMTP-сервер с резервным режимом Mission Control''' (настройка по умолчанию)

<blockquote>Выберите это, чтобы SMTP-сервер доставлял электронную почту, но использовался Mission Control в качестве резервного метода доставки.

** Пока ваш SMTP-сервер доступен, ваша SMTP-конфигурация определяет, как отправляется электронная почта (почтовый сервер, безопасность соединения и т.д.).
** Если ваш SMTP-сервер становится недоступным, Mission Control доставит ваше письмо с отправляющим адресом <code>noreply</code>.
</blockquote>

* '''SMTP-сервер'''

<blockquote>Выберите это, чтобы SMTP-сервер доставлял электронную почту (без резервного метода доставки).

** Ваша конфигурация SMTP определяет, как отправляется ваша электронная почта (почтовый сервер, безопасность соединения и т.д.).
** Если ваш SMTP-сервер станет недоступен, ваше письмо не будет отправлено.
</blockquote>

* '''Mission Control'''

<blockquote>Выберите это, чтобы Mission Control отправлял все электронные письма.

** Все шаги настройки SMTP-сервера, описанные ниже, недоступны, потому что вам не нужно настраивать SMTP-сервер. Dynatrace обо всем позаботится за вас.
** Адрес отправки: <code>noreply</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. Выберите '''Сохранить изменения''', если конфигурация верна.

Настройка прокси

2023-01-26T11:36:05Z

YaPolkin:

Настройка интернет-соединения нужна для:

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

Настройка прокси осуществляется:

* Во время установки Dynatrace Managed
* Через Консоль Менеджмента Кластера (CMC)
* [[Установка/обновление прокси кластера|Через REST API]]

== Используя установщик Dynatrace Managed ==
Вы можете использовать параметры командной строки во время управляемой установки Ключа-Астром. Используйте следующие параметры для настройки прокси-соединения с Контроллером Задач Dynatrace: <code>--network-proxy</code>

Если ваша машина использует сетевой прокси-сервер для подключения к Интернету, введите адрес в следующем формате:

<code>protocol://[логин:пароль@]адрес-сервера:порт</code>. Значение по умолчанию — <code>none</code>.

<code>--network-proxy-cert-file</code>. Если на вашем компьютере используется сетевой HTTPS-прокси с самоподписанным сертификатом, вам необходимо расширить хранилище доверенных сертификатов. За этим параметром должен следовать полный путь к общедоступному файлу сертификата SSL в формате PEM.

== Используя Консоль Менеджмента Кластера (CMC) ==
В Консоли Менеджмента Кластера:

# Перейдите в '''Настройки''' -> '''Прокси''' и настройте прокси для дата-центров.
# Выберите '''Соединение через прокси''' и введите параметры прокси-сервера
#* '''Схема'''
#* '''Адрес прокси''' и '''Порт'''
#* '''Логин''' и '''Пароль''' при невозможности анонимного доступа.

Также вы можете исключить хосты из использования прокси. Это полезно, например, когда вы настроили интеграцию проблем через веб-хуки с программным обеспечением во внутренней сети. Используйте (<code>*</code>) в начале или в конце каждой записи узла, чтобы включить все URL-адреса в пределах определенного домена узла.

== Используя REST API ==
Вы также можете использовать REST API интернет-прокси (REST API CMC) в отдельных кластерах для обычных и премиальных развертываний с высокой доступностью, чтобы настроить конфигурацию интернет-прокси. Для дополнительных сведений см. [[Установка/обновление прокси кластера]].

== Часто задаваемые вопросы ==

==== Можно ли использовать прозрачный прокси? ====
Да, Dynatrace поддерживает настройку прозрачного прокси. Прозрачный прокси-сервер (также известный как перехватывающий прокси-сервер, встроенный прокси-сервер или принудительный прокси-сервер) может направлять и перехватывать связь кластера Dynatrace с Контроллером Задач.

Прозрачный прокси-сервер обычно располагается между управляемым кластером Dynatrace и Контроллером Задач. Используя прозрачный прокси-сервер, вы можете дополнительно проверять все коммуникационные полезные нагрузки.

Ключу-Астром не нужно знать о существовании прокси. Dynatrace Managed необходимо настроить так, чтобы он доверял корневому сертификату, закрытый ключ которого известен прокси-серверу. В таких ситуациях становится возможным прокси-анализ содержимого транзакции SSL/TLS. Прокси-сервер эффективно использует атаку «человек посередине», что разрешено доверием Dynatrace к корневому сертификату, которым владеет прокси-сервер.

==== Как обновить SSL сертификат? ====
Используйте параметры командной строки в скрипте конфигурации Dynatrace Managed:

<code><ПУТЬ_ДО_ВАШЕГО_ПРИЛОЖЕНИЯ>/installer/reconfigure.sh --update-cert --network-proxy-cert-file <proxy_cert_file></code>

Добавление SSL-сертификата в TrustStore кластера Ключ-АСТРОМ Managed

2023-01-26T11:34:58Z

YaPolkin: YaPolkin переименовал страницу Добавление SSL-сертификата в TrustStore кластера Ключ-АСТРОМ Managed в Добавление SSL-сертификата в TrustStore кластера Dynatrace Managed

#перенаправление [[Добавление SSL-сертификата в TrustStore кластера Dynatrace Managed]]

Добавление SSL-сертификата в TrustStore кластера Dynatrace Managed

2023-01-26T11:34:58Z

Могут быть случаи, когда вам нужно вручную добавить сертификат SSL в TrustStores кластера Dynatrace Managed, например, если ваш кластер отказывается принимать сертификат SSL при отправке электронных писем или уведомлений WebHook. Обычно это происходит при использовании самозаверяющего сертификата.

== Как узнать, что ваш кластер не принимает сертификаты ==
Если в кластере возникают проблемы с отправкой уведомлений, поищите [[Требования Managed к оборудованию|файлы в каталоге журнала установки]] узла кластера с шаблоном имени <code>Server.*.*.log</code>.

Если какие-либо файлы с этим шаблоном именования существуют в папке журнала, найдите в этих файлах журнала следующую запись:

<code>sun.security.validator.ValidatorException: PKIX path building failed:</code>

<code>sun.security.provider.certpath.SunCertPathBuilderException</code>

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

== Добавьте пользовательский сертификат в TrustStore ноды кластера ==
Используйте сертификат PEM (<code>.crt</code> , <code>.pem</code> , <code>.cer</code>) и выполните сценарий реконфигурации на каждом узле кластера, используя параметры <code>--update-cert</code> и <code>--network-proxy-cert-file</code>: Используйте команду <code>nohup</code> , чтобы предотвратить прерывание выполнения сценария (например, отключение сеанса) во время важных операций.

<code>nohup <PRODUCT_PATH>/installer/reconfigure.sh --update-cert --network-proxy-cert-file <cert_file>.cer &</code>
----<big>''Параметр прокси''</big>

Параметр <code>--network-proxy-cert-file</code> предназначен для предоставления сертификата прокси для Managed, но его также можно использовать для предоставления сертификата для любого безопасного подключения к кластеру Managed.

Добавление SSL-сертификата в TrustStore кластера Dynatrace Managed

2023-01-26T11:34:41Z

YaPolkin:

Настраиваемые свойства Ключ-АСТРОМ Managed

2023-01-26T11:32:34Z

YaPolkin: YaPolkin переименовал страницу Настраиваемые свойства Ключ-АСТРОМ Managed в Настраиваемые свойства Dynatrace Managed

#перенаправление [[Настраиваемые свойства Dynatrace Managed]]

Настраиваемые свойства Dynatrace Managed

2023-01-26T11:32:34Z

YaPolkin: YaPolkin переименовал страницу Настраиваемые свойства Ключ-АСТРОМ Managed в Настраиваемые свойства Dynatrace Managed

Настраиваемые свойства Dynatrace Managed хранятся в файле <code>/server/conf/config.properties</code> , но не редактируйте их в этом файле. Он перезаписывается во время обновления.
----<blockquote><big>''Важно''</big>

*

Если вы настроите свойства непосредственно в <code>/server/conf/config.properties</code> , '''ваша пользовательская конфигурация не будет сохранена во время обновления.'''</blockquote>
----Вместо редактирования <code>/server/conf/config.properties</code> внесите все свои изменения в файл <code>custom.settings</code> , расположенный в каталоге <code><install_dir>/installer</code> каждого узла кластера. Вы можете создать файл, если он ещё не существует. Во время обновления программа установки считывает <code>custom.settings</code> и соответствующим образом изменяет <code>config.properties</code>.

В файле <code>custom.settings</code> указываются:

* Расположение файла, который нужно изменить
* Раздел для изменения
* Свойство и значение, которое нужно установить

== Пример редактирования custom.settings ==
Предположим, вы внесли две модификации в настройки:

* Установили для свойства <code>connection-timeout</code> значение <code>3000000</code>
* Установили для свойства <code>proxy-off</code> значение <code>true</code>

Чтобы сохранить эти настройки во время обновления:

1. Откройте файл <code>custom.settings</code> для редактирования.

* Расположение файла: каталог <code><install_dir>/installer</code> узла кластера.
* Создайте файл в этом месте, если он ещё не существует.

2. Добавьте одну строку, чтобы указать файл конфигурации, который нужно изменить во время установки.

<code><server/conf/config.properties></code>

Обязательно укажите угловые скобки (<code><</code> и <code>></code>).

3. Добавьте две строки, чтобы указать раздел, имя свойства и значение свойства, которое нужно изменить для <code>connection-timeout</code> , которое находится в разделе <code>[settings]</code>.

<code>[settings]</code>

<code>connection-timeout=3000000</code>

4. Добавьте две строки, чтобы указать раздел, имя свойства и значение свойства, которое нужно изменить для <code>proxy-off</code> , которое находится в разделе <code>[http.client.external]</code>.

<code>[http.client.external]</code>

<code>proxy-off = true</code>

5. Результирующий файл <code>custom.settings</code> для этого примера теперь должен выглядеть следующим образом:

<code><server/conf/config.properties></code>

<code>[settings]</code>

<code>connection-timeout=3000000</code>

<code>[http.client.external]</code>

<code>proxy-off = true</code>

Поскольку этот файл <code>custom.settings</code> размещен на всех узлах кластера в каталоге <code><install_dir>/installer</code> , каждый раз, когда вы обновляете узел, установщик будет устанавливать <code>connection-timeout</code> на <code>3000000</code> , а для <code>proxy-off</code> значение <code>true</code> в <code>config.properties</code> , таким образом сохраняя вашу индивидуальную конфигурацию.
----<blockquote><big>''Применимо к перезапускам службы''</big>

*

Dynatrace Managed также выполняет это действие настраиваемой конфигурации при каждом перезапуске службы Dynatrace.</blockquote>
----

== Раздел: [com.compuware.apm.webserver] ==
{| class="wikitable"
!Свойство
!Значение по умолчанию
!Описание
|-
|port–ssl
|8021
|Порт, на котором Dynatrace Сервер прослушивает трафик от OneAgent.
|-
|ssl–protocols
|TLSv1.2
|Поддерживаемые протоколы SSL. Может быть одним или списком следующих значений: <code>TLSv1</code> , <code>TLSv1.1</code> , <code>TLSv1.2</code>
|-
|excluded–ciphers
|не установлено
|Список дополнительно исключаемых шифров (шифры определяются подстрокой, совпадающей хотя бы с частью имени шифра, например <code>_DHE_</code>)
|}

Настраиваемые свойства Dynatrace Managed

2023-01-26T11:32:24Z

YaPolkin:

Принцип работы Контроллера Задач

2023-01-26T11:27:19Z

YaPolkin:

Dynatrace Managed автоматически решает многие распространенные проблемы обслуживания и поддержки. С Контроллером Задач вы получаете полностью автоматизированные возможности управления, которые обеспечивают безопасность, надежность и актуальность сервера Dynatrace, избавляя вас от хлопот, связанных с обновлением и устранением неполадок.

После того, как вы предоставите необходимые разрешения, наша команда Dynatrace сможет получить удаленный доступ к вашему серверу Dynatrace, чтобы помочь с обновлениями и устранением неполадок, когда вы столкнетесь с проблемами. Вы полностью контролируете настройки конфиденциальности, используя [[Конфиденциальность и обмен данными в развертываниях Managed|настройки конфиденциальности данных, предоставляемые Dynatrace Managed]].

== Как работает Контроллер Задач ==
Для облегчения поддержки ваш сервер Dynatrace передает информацию о состоянии в Контроллер Задач.

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

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

== Какие задачи выполняет Контроллер Задач ==
Контроллер задач обрабатывает следующую информацию:

* '''Данные лицензий''' Данные об использовании лицензий, содержащие подробную информацию о почасовом использовании лицензий. См. [[Экспорт данных о лицензировании]]
* '''Состояние кластера''' Мы собираем базовую статистику развертывания Dynatrace Managed для быстрого оповещения в случае проблем с инфраструктурой и для обеспечения автоматизации конфигурации. Контроллер Задач собирает такую информацию, как количество узлов, состояние служб Dynatrace и использование разделов диска.
* '''События кластера''' Такие события, как запуск/выключение сервера, добавление/удаление узлов и регистрация ActiveGate'ов, отслеживаются автоматически. Наша команда Dynatrace может удаленно анализировать и устранять проблемы или несовместимости с вашим сервером Dynatrace на основе системных событий. Если вам когда-нибудь понадобится связаться с нами, вам не нужно будет собирать необходимые файлы журналов для получения подробной информации о проблеме — Контроллер Задач собирает эти данные для вас автоматически. Чтобы просмотреть список системных событий сервера Dynatrace, которые автоматически регистрируются, в меню вашего окружения выберите '''«События»'''.
* '''Настройки кластера''' Наша команда Dynatrace может удаленно оптимизировать ваши настройки Dynatrace Managed, чтобы обеспечить оптимальную производительность и стабильность.
* '''Обновления''' Обновления управляемого программного обеспечения Dynatrace обязательны и обычно публикуются каждые четыре недели. Вы можете настроить время обновления Dynatrace Managed (ежедневно или еженедельно). Обновления автоматически сообщаются вашим пользователям как минимум за 24 часа. Управляемые обновления Dynatrace выполняются быстро и позволяют беспрепятственно продолжать мониторинг.

== Потерялось соединение со службами Контроллера Задач? ==
Чтобы ваш кластер активно поддерживался, вам необходимо постоянное подключение к Контроллеру Задач Dynatrace Managed. Чтобы получить информацию об отправляемых данных и частоте их отправки, см. [[Конфиденциальность и обмен данными в развертываниях Managed|Конфиденциальность и обмен данными Dynatrace]].

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

Отслеживаемые технологии и использование функций

2023-01-26T11:24:45Z

YaPolkin:

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

'''Примечание:''' Соответствующие журналы доступны на каждом узле кластера в <code><datastore_dir>\log\server\audit.rest.proxy.log</code>. Dynatrace не отправляет имена хостов или какую-либо информацию, которая может поставить под угрозу безопасность вашего кластера.

== ActiveGate'ы ==
Тип ActiveGate, версия сборки, операционная система, поддерживаемые возможности и статусы обновлений

== Использование API ==
Базовая статистика используемых эндпоинтов Dynatrace API, включая количество вызовов и время ответа

== Конфиги приложений ==
Соответствующие конфигурации на уровне приложений, охватывающие аспекты контроля затрат, ключевые действия пользователя и синтетические проверки

== Конфиги дашборда ==
Конфигурации дашборда на уровне дашбордов, включая базовые настройки общего доступа и используемые типы плиток

== Цифровой опыт ==
Данные об информации хранилища сеансов, метриках, касающихся посещений и использования сеансов

== Использование JS-фреймворка ==
Сводная статистика по фреймворкам JavaScript, наблюдаемым при мониторинге

== Запросы ==
Информация о внедрении функции классификации ключевых запросов и статистики атрибутов запросов

== Использование мониторинга журналов ==
Обобщенная статистика использования журналов, например статистика индексов

== Мобайл ==
Версия агента, используемая для мобильного мониторинга, а также метаданные об отслеживаемой версии ОС и данные о сбоях агента

== Контролируемые объекты ==
Базовые метаданные для отслеживаемых процессов, хостов, служб, приложений и других связанных объектов

== Статистика сетевой зоны ==
Базовая статистика сетевой зоны на уровне клиента и кластера с подсчетом агентов и ActiveGate'ов

== Регистрации OneAgent ==
Подключенные OneAgent'ы с версией установщика, операционной системой, информацией о внедрении, информацией о процессах и технологиях хоста, а также показателями памяти хоста

== Плагины (расширения) ==
Активные плагины с типом плагина, версией, размером, статусом, метриками плагина и информацией о взаимоотношениях с хостом

== Обнаружение проблем ==
Проблемы со статусом, уровнем серьезности/воздействия, идентификаторами затронутых объектов, подробностями о проблемных событиях

== Безопасность ==
Метаданные технических проблем безопасности и уязвимостей

== Самоконтроль и встроенная статистика ==
Ежедневная статистика по биллинговым сеансам, MSU мэйнфреймов, действиям синтетического монитора по внутреннему идентификатору объекта и данным о потреблении DDU

== Синтетические мониторы ==
Активные конфигурации синтетического монитора с типом монитора, именем местоположения и идентификатором. Для настраиваемых местоположений название местоположения не отправляется

== Использование тегов ==
Сводная статистика, описывающая количество тегов по типу тега и типу объекта

== Настройки ==

=== Профили оповещений ===
Базовые конфигурации профиля оповещений

=== Разрешения токена API ===
Сводная статистика для токенов API по уровням разрешений

=== Условные процедуры ===
Обзор правил для зон управления и автоматически применяемых тегов

=== Глубокий мониторинг ===
Ранняя версия OneAgent и настройки функций устранения неполадок

=== Конфигурация окружения ===
Информация об использовании настроек предпочтений и расширенных конфигураций среды

=== Флаги функций ===
Настройки для функций клиента, которые установлены не по умолчанию

=== Интеграции ===
Настройки интеграции, включая уведомления о проблемах, Dynatrace API, модули Dynatrace, экспорт пользовательских сеансов и интеграцию с системой отслеживания проблем на релизе

=== События метрик ===
Информация о количестве конфигураций, типах моделей конфигурации, типах фильтров конфигурации

=== Метрики ===
Метаданные метрик среды, настроенные типы данных метрик, метрики использования, статистика использования метрик

=== Окна обслуживания ===
Информация о настроенных окнах мониторинга и их настройках, таких как тип обслуживания, предоставленная длина текста, расписание, фильтры

=== Предпочтения ===
Настройки для обновлений OneAgent и конфиденциальности данных

=== Цели уровня обслуживания (SLO) ===
Обобщенная статистика использования SLO

=== Фильтры плиток ===
Обобщенная статистика фильтра плиток, которая может оптимизировать масштабируемость

=== Виртуализация ===
Обзор настроенных типов виртуализации, таких как AWS, Azure и VMware

Отслеживаемые технологии и использование функций

2023-01-26T11:23:54Z

YaPolkin:

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

'''Примечание:''' Соответствующие журналы доступны на каждом узле кластера в <code><datastore_dir>\log\server\audit.rest.proxy.log</code>. Dynatrace не отправляет имена хостов или какую-либо информацию, которая может поставить под угрозу безопасность вашего кластера.

== ActiveGate'ы ==
Тип ActiveGate, версия сборки, операционная система, поддерживаемые возможности и статусы обновлений

== Использование API ==
Базовая статистика используемых эндпоинтов Dynatrace API, включая количество вызовов и время ответа

== Конфиги приложений ==
Соответствующие конфигурации на уровне приложений, охватывающие аспекты контроля затрат, ключевые действия пользователя и синтетические проверки

== Конфиги дашборда ==
Конфигурации дашборда на уровне дашбордов, включая базовые настройки общего доступа и используемые типы плиток

== Цифровой опыт ==
Данные об информации хранилища сеансов, метриках, касающихся посещений и использования сеансов

== Использование JS-фреймворка ==
Сводная статистика по фреймворкам JavaScript, наблюдаемым при мониторинге

== Запросы ==
Информация о внедрении функции классификации ключевых запросов и статистики атрибутов запросов

== Использование мониторинга журналов ==
Обобщенная статистика использования журналов, например статистика индексов

== Мобайл ==
Версия агента, используемая для мобильного мониторинга, а также метаданные об отслеживаемой версии ОС и данные о сбоях агента

== Контролируемые объекты ==
Базовые метаданные для отслеживаемых процессов, хостов, служб, приложений и других связанных объектов

== Статистика сетевой зоны ==
Базовая статистика сетевой зоны на уровне клиента и кластера с подсчетом агентов и ActiveGate'ов

== Регистрации ЕдиногоАгента ==
Подключенные ЕдиныеАгенты с версией установщика, операционной системой, информацией о внедрении, информацией о процессах и технологиях хоста, а также показателями памяти хоста

== Плагины (расширения) ==
Активные плагины с типом плагина, версией, размером, статусом, метриками плагина и информацией о взаимоотношениях с хостом

== Обнаружение проблем ==
Проблемы со статусом, уровнем серьезности/воздействия, идентификаторами затронутых объектов, подробностями о проблемных событиях

== Безопасность ==
Метаданные технических проблем безопасности и уязвимостей

== Самоконтроль и встроенная статистика ==
Ежедневная статистика по биллинговым сеансам, MSU мэйнфреймов, действиям синтетического монитора по внутреннему идентификатору объекта и данным о потреблении DDU

== Синтетические мониторы ==
Активные конфигурации синтетического монитора с типом монитора, именем местоположения и идентификатором. Для настраиваемых местоположений название местоположения не отправляется

== Использование тегов ==
Сводная статистика, описывающая количество тегов по типу тега и типу объекта

== Настройки ==

=== Профили оповещений ===
Базовые конфигурации профиля оповещений

=== Разрешения токена API ===
Сводная статистика для токенов API по уровням разрешений

=== Условные процедуры ===
Обзор правил для зон управления и автоматически применяемых тегов

=== Глубокий мониторинг ===
Ранняя версия ЕдиногоАгента и настройки функций устранения неполадок

=== Конфигурация окружения ===
Информация об использовании настроек предпочтений и расширенных конфигураций среды

=== Флаги функций ===
Настройки для функций клиента, которые установлены не по умолчанию

=== Интеграции ===
Настройки интеграции, включая уведомления о проблемах, Dynatrace API, модули Dynatrace, экспорт пользовательских сеансов и интеграцию с системой отслеживания проблем на релизе

=== События метрик ===
Информация о количестве конфигураций, типах моделей конфигурации, типах фильтров конфигурации

=== Метрики ===
Метаданные метрик среды, настроенные типы данных метрик, метрики использования, статистика использования метрик

=== Окна обслуживания ===
Информация о настроенных окнах мониторинга и их настройках, таких как тип обслуживания, предоставленная длина текста, расписание, фильтры

=== Предпочтения ===
Настройки для обновлений ЕдиногоАгента и конфиденциальности данных

=== Цели уровня обслуживания (SLO) ===
Обобщенная статистика использования SLO

=== Фильтры плиток ===
Обобщенная статистика фильтра плиток, которая может оптимизировать масштабируемость

=== Виртуализация ===
Обзор настроенных типов виртуализации, таких как AWS, Azure и VMware