Правила зон управления

• Классическая версия

Зоны управления включают одно или несколько правил, которые определяют и ограничивают сущности или размерные данные (такие как логи и метрики), к которым можно получить доступ в рамках зоны управления.

При выборе зоны управления в Settings > Preferences > Management zones отображаются все настроенные правила. Вы можете Отключить/Включить отдельные правила.

Подробнее о:

• Как данные логов могут быть приняты и автоматически назначены зонам управления в Зоны управления и принятые данные логов (Logs Classic).
• Как добавить целевой уровень обслуживания в зону управления, чтобы пользователи с доступом к зоне управления могли просматривать статус SLO и бюджет ошибок на странице Service-level objectives.

Типы правил

Зоны управления предлагают определение правил через пользовательский интерфейс для:

• Отслеживаемых сущностей
• Размерных данных (логи и метрики)

Вы можете выбрать тип правила, а затем создать условия правила на основе свойств сущности/данных, операторов и значений, где это применимо.

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

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

Дополнительная информация о Metrics API v2

Используйте мощный селектор метрик из Metrics API v2 для ключей и значений метрик и измерений:

• GET список всех доступных метрик в вашей среде.
• GET детали указанной метрики для проверки ключей измерений.
• GET список точек данных для проверки значений измерений.

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

Текстовые правила используют мощный селектор сущностей для Environment API v2 для определения сущностей. Текстовые правила позволяют определять доступ к сущностям на основе всех типов сущностей, свойств, значений и связей, предоставляемых API отслеживаемых сущностей v2.

Существует несколько преимуществ текстовых правил.

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

На среду мониторинга можно добавить:

• 5 000 зон управления по умолчанию. По любым вопросам обращайтесь к эксперту по продукту Dynatrace через онлайн-чат.
• 300 правил зон управления на основе пользовательского интерфейса для сущностей (150 для Dynatrace версий 1.323 и более ранних).
• 300 правил зон управления на основе пользовательского интерфейса для размерных данных (150 для Dynatrace версий 1.323 и более ранних).
• 300 текстовых правил селектора сущностей для зон управления (150 для Dynatrace версий 1.323 и более ранних).
• 100 000 условий для всех правил зон управления вместе взятых (не применяется к правилам селектора сущностей).
• Любую отдельную сущность можно добавить максимум в 200 зон управления (выполните вызов API GET сущность, чтобы увидеть зоны управления сущности).

Ознакомьтесь с нашей документацией о том, как оптимизировать производительность правил зон управления в масштабе.

Добавление правила на основе пользовательского интерфейса для сущностей

См. Примеры для различных типов и реализаций правил.

1. Выберите/создайте зону управления и затем выберите Add a new rule.
2. Выберите Monitored entity в качестве Rule type. (См. также информацию о правилах для размерных данных и определении правил на основе текста через Entity selector.)
3. Выберите тип сущности, к которому должно применяться правило (Rule applies to), например, Web applications.

4. Каждая сущность может быть определена и ограничена несколькими различными условиями. Выберите Add condition. 5. Выберите Property, Operator и Value условия (где применимо). Например, вы можете указать, что Web application name begins with определенной строкой. Вы можете ввести до 80 символов; подстановочные символы не допускаются; регулярные выражения допускаются в операторах условий contains regex и does not contain regex. 6. Если вы вводите текстовую строку, укажите, является ли она Case sensitive.

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

8. Выберите Add condition для добавления еще одного условия (или Remove condition для удаления условия) по мере необходимости.

• Необходимо определить хотя бы одно условие на правило.
• Условия применяются с использованием логики AND -- все условия должны быть выполнены, чтобы правило применялось к сущности.
• Ограничения на количество условий на правило нет. Однако существует ограничение в 100 000 условий для всех правил вместе на среду.
• Выберите Preview для просмотра сущностей, соответствующих правилу, которые были активны и онлайн в последние 72 часа. Конечно, при фактическом применении зоны управления будут отображены все сущности, соответствующие правилам за указанный временной период. Обратите внимание, что Preview доступен только для правил на основе сущностей.

10. Save changes.

Добавление правила на основе пользовательского интерфейса для размерных данных

См. Примеры для различных типов и реализаций правил.

1. Выберите/создайте зону управления и затем выберите Add a new rule.
2. Выберите Dimensional data для Rule type. (См. также информацию о правилах для сущностей и определении правил на основе текста через Entity selector.)

3. Выберите Type данных, к которым должно применяться правило.

4. Для правила на основе пользовательского интерфейса для встроенной, вычисляемой или принятой метрики выберите METRIC.

5. Для правила на основе пользовательского интерфейса для логов выберите LOG.
6. Каждое правило может быть определено и ограничено несколькими различными условиями. Выберите Add condition.
7. Выберите Type, Key (где применимо), Operator и Value условия. Вы можете ввести до 80 символов в любое текстовое поле; подстановочные символы не допускаются.

Типы условий:

• Для атрибута лога или измерения метрики -- DIMENSION.

  * Для имени файла лога -- LOG_FILE_NAME. Имя файла лога должно соответствовать атрибуту log.source.

  * Для ключа метрики -- METRIC_KEY.

  * Для комбинированного условия лога или метрики -- ANY.

Допустимые операторы: begins with и equals. 6. Выберите Add condition для добавления еще одного условия (или Remove condition для удаления условия) по мере необходимости.

• Необходимо определить хотя бы одно условие на правило.
• Условия применяются с использованием логики AND -- все условия должны быть выполнены, чтобы правило применялось к сущности.
• Ограничения на количество условий на правило нет. Однако существует ограничение в 100 000 условий для всех правил вместе на среду.
• Preview недоступен для правил размерных данных.
• Save changes.

Добавление текстового правила селектора сущностей

1. Выберите/создайте зону управления и затем выберите Add a new rule.
2. В Rule type выберите Entity selector.
3. Для заполнения текстовой строки Entity Selector вам может потребоваться выполнить вызовы API отслеживаемых сущностей v2 для получения типов сущностей, свойств, значений и связей. Обратитесь к документации селектора сущностей для получения подробной информации о построении определения сущности. См. Примеры для различных типов и реализаций правил.

Важные части строки селектора сущностей

• type(<entityType>) определяет тип сущности, к которой применяется правило. Например, тип сущности для хостов -- host, а для групп процессов -- process_group. Тип сущности не чувствителен к регистру. Вы можете указать только одну запись в <entityType>.

  Выполните вызов API GET все типы сущностей для получения списка всех типов сущностей в вашей среде (включая пользовательские сущности) и их свойств.

  Альтернативно вы можете указать несколько отдельных идентификаторов сущностей с критерием entityId. Вы можете выполнить вызов API GET список сущностей для получения списка фактических сущностей в вашей среде и их свойств. * Свойства и значения сущностей фильтруют список сущностей, к которым применяется ваше правило. Например:

  • entityName.startsWith("Book") фильтрует сущности, имя которых начинается с Book.
  • serviceType(WEB_REQUEST_SERVICE) фильтрует сервисы веб-запросов.

  Вы можете выполнить вызов API GET типа сущности для любого типа сущности (например, service), чтобы получить список всех его свойств (например, serviceType). Вы также можете выполнить вызов API GET список сущностей для получения списка фактических сущностей в вашей среде с их значениями свойств (например, WEB_REQUEST_SERVICE). * Связи дополнительно уточняют выбор сущностей, определяя сущность с точки зрения ее связи с другой. Связи бывают двух типов.

  • fromRelationship подразумевает, что направление связи -- от данной сущности (то есть запрашиваемой сущности) к связанной сущности. Когда вы запрашиваете все сервисы, которые вызывает сервис A, это связь «от (сервиса A)» к другим сервисам.
  • toRelationship подразумевает, что направление связи -- от связанной сущности к данной сущности (то есть запрашиваемой сущности). Когда вы запрашиваете все сервисы, которые вызывают сервис A, эта связь -- «к (сервису A)».

  Вы можете выполнить вызов API GET типа сущности для любого типа сущности, чтобы получить список связей от/к сущности и связанных типов сущностей. Вы также можете выполнить вызов API GET список сущностей, чтобы получить список фактических сущностей в вашей среде вместе с их значениями связей (например, тип сущности service может иметь связь calls типа «от» к другому service). 4. Выберите Preview для просмотра сущностей, соответствующих правилу, которые были активны и онлайн в последние 72 часа. (Конечно, при фактическом применении зоны управления будут отображены все сущности, соответствующие правилам за указанный временной период.)

5. Save changes.

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

• Условия применяются с использованием логики AND -- все условия в рамках правила должны быть выполнены, чтобы правило применялось к сущности.
• Правила применяются с использованием логики OR -- любое правило должно применяться, чтобы сущность была включена в зону управления.
• При создании правил для некоторых сущностей вы можете распространить доступ на связанные топологические сущности без создания дополнительного правила. Например, при создании правила для сервисов вы можете включить базовые хосты и группы процессов. См. раздел Добавление правила на основе пользовательского интерфейса выше.

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

В случаях, когда такое распространение недоступно, необходимо явно создать правила для сущностей, которые вы хотите добавить в зону управления. Например, правило зоны управления, применяемое к Host groups, не предоставляет автоматически доступ к хостам в этих группах; необходимо явно добавить правила для Hosts, которые вы хотите включить в зону управления, как показано в Примерах ниже.

Зоны управления всегда неявно распространяются на следующие связанные сущности. Однако это не применяется к правилам на основе селектора сущностей. * При добавлении сущности с использованием тегов в зону управления в рамках создания сущности через API может возникнуть задержка в назначении зоны управления в зависимости от количества и сложности ваших правил тегирования. См. Лучшие практики масштабирования тегирования и правил зон управления для лучших практик ускорения назначения тегов и зон управления в ваших средах мониторинга. * Вы не можете определить правила зон управления, где селектор сущностей одной зоны управления фильтрует по другой зоне управления. Предикаты зон управления, такие как mzID или mzName, не допускаются в строках селектора сущностей. Это означает, например, что вы не можете определить зону управления A как содержащую хосты, принадлежащие зоне управления B. Правила зон управления на основе других зон управления увеличивают количество запусков движка условных решений и могут значительно задержать назначение зон управления. См. также Лучшие практики масштабирования тегирования и правил зон управления для получения дополнительной информации.

В качестве обходного решения используйте одну и ту же строку селектора сущностей в обеих зонах управления. Например:

• Зона управления A имеет правило type(SERVICE),entityName.startsWith("myService"),tag("my:tag").
• Зона управления B должна включать сервисы, которые вызывают сервисы в зоне управления A. Для этого определите правило type(SERVICE),fromRelationships.calls(type(SERVICE),entityName.startsWith("myService"),tag("my:tag")).

Примеры

Пример 1: Правила зоны управления, предоставляющие доступ к хостам определенных групп хостов; пользователи, назначенные зоне, могут фильтровать по доступным группам хостов.

1. Настройте правило для хостов.

2. Выберите Monitored entity в качестве Rule type.

3. Выберите Hosts как сущность, к которой применяется Rule applies to.
4. Добавьте условие.
5. Выберите Host group в качестве Property.
6. Выберите или найдите группу хостов в поле Value.

7. Preview -- просмотрите список соответствующих сущностей.

   7. Save changes.

Добавьте правило таким образом для каждого набора хостов по группе хостов. 2. Настройте правило для групп хостов.

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

1. Выберите Monitored entity в качестве Rule type.
2. Выберите Host groups как сущность, к которой применяется Rule applies to.
3. Добавьте условие.
4. Выберите Host group name в качестве Property.
5. Определите условие для имени группы хостов, например, текстовую строку, содержащуюся в имени группы хостов.

6. Preview -- просмотрите список соответствующих групп хостов.

   7. Save changes.

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

Когда зона управления применена, пользователь может видеть только назначенные хосты и может фильтровать страницу Hosts по Host group. Группы хостов -- это те, которые определены в ваших правилах зоны управления.

Пример 2: Правила зоны управления, предоставляющие доступ ко всем синтетическим мониторам

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

• Мониторы браузера
• HTTP-мониторы
• Сторонние мониторы

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

Чтобы настроить правило для покрытия всех Browser monitors, например:

Укажите, что Browser monitor name exists. Preview -- просмотрите правило, чтобы увидеть соответствующие сущности.

Дополнительно настройте аналогичные правила для HTTP и сторонних мониторов, чтобы покрыть все синтетические мониторы в вашей среде.

Если вы хотите, чтобы ваш пользователь мог создавать или редактировать синтетические мониторы в зоне управления, необходимо предоставить разрешение Manage monitoring settings permission на уровне зоны управления или среды.

Пример 3: Правила зоны управления, предоставляющие доступ к определенным измерениям конкретных принятых метрик

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

1. Выберите сущность Dimensional data типа METRIC.
2. Заполните условие для имени метрики (METRIC_KEY). Вы можете предоставить доступ к конкретной метрике, указав полное имя, или к набору метрик, указав начальную строку (например, business.revenue).

3. Для фильтрации по определенным измерениям метрик необходимо добавить условие для измерения метрики. Выберите DIMENSION и укажите имя измерения (Key) и (Value). Например, чтобы отфильтровать ваши бизнес-метрики для восточного региона США, вы должны указать имя измерения region и значение useast.

4. Save changes.

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

Пример 4: Правила зоны управления, предоставляющие доступ к определенным измерениям конкретных принятых логов

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

1. Выберите Dimensional data в поле Rule type.
2. Выберите LOG в поле Type.

3. Добавьте условие для логов.

4. Выберите DIMENSION для типа условия.

5. Укажите имя атрибута лога в поле Key. Вы можете указать только одно значение атрибута.
6. Добавьте фразу для поиска в поле Value.
7. Вы также можете установить Operator как begins with или equals для введенного Value. Например, чтобы отфильтровать ваши логи по определенному имени развертывания Kubernetes, укажите ключ k8s.deployment.name и begins with automation-server как значение.
8. Save changes.

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

Пример 5: Правило селектора сущностей на основе связей сущностей

Чтобы отфильтровать сервисы, которые напрямую вызывают сервис с именем JourneyService, вы можете выполнить вызов API GET все типы сущностей, чтобы проверить тип сущности и связи для сервисов.

На основе полученной информации вы можете построить правило селектора сущностей для типа сущности service, который имеет связь calls типа «от» к типу сущности service с именем JourneyService:

type(SERVICE),fromRelationship.calls(type(SERVICE),entityName(JourneyService))

Это также может быть записано как type(SERVICE),fromRelationship.calls(type(SERVICE) AND entityName.equals(JourneyService)).

Связанные темы

• API отслеживаемых сущностей
• Environment API v2 - Селектор сущностей
• Metrics API v2
• Metrics API - Селектор метрик
• Зоны управления и принятые данные логов (Logs Classic)
• Лучшие практики масштабирования тегирования и правил зон управления