Масштабирование тегов

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

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

Слишком сложные фильтры правил работают медленнее простых фильтров, а общее количество фильтров правил определяет скорость автоматического присвоения тегов и назначения менеджмент-зон в вашей среде мониторинга. Для справки, для завершения присвоения тегов с небольшим количеством фильтров тегов (скажем, 100) требуется около одной минуты; для завершения присвоения тегов с тысячами сложных фильтров тегов может потребоваться несколько часов.

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

Сохранение небольшого количество правил

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

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

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

Для каждой среды мониторинга можно настроить: Любое количество автоматических тегов. 150 правил автоматических тегов сущностей на основе пользовательского интерфейса. 150 текстовых правил селектора сущностей для автоматических тегов. 100 000 условий для всех правил автоматических тегов вместе взятых (не применяется к правилам селектора сущностей). Максимум 1000 ручных тегов и 1000 автоматических тегов на одну сущность. Кроме того, для каждой среды мониторинга можно настроить: 5000 менеджмент-зон по умолчанию. По любым вопросам обращайтесь к эксперту по продуктам Ключ-АСТРОМ через чат. 150 правил менеджмент-зон на основе пользовательского интерфейса для сущностей. 150 правил менеджмент-зон на основе пользовательского интерфейса для размерных данных. 150 текстовых правил селектора сущностей для менеджмент-зон. 100 000 условий для всех правил менеджмент-зон вместе взятых (не применяется к правилам селектора сущностей). Любая отдельная сущность максимум в 200 менеджмент-зонах (выполните вызов API GET сущности, чтобы увидеть менеджмент-зоны сущности).

Медленные запросы топологии

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

Независимо от того, насколько они полезны, такие топологические запросы «дорогие» и медленные, поскольку каждый фильтр должен пройти топологию, в некоторых случаях через несколько шагов, чтобы назначить тег или извлечь значение для заданной сущности. Топологический обход «дорогой», особенно в крупных средах, где каждый такой фильтр добавляет значительную задержку к общему назначению тегов и менеджмент-зон.

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

По возможности избегайте извлечения значений

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

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

Например, если вы запускаете несколько кластеров Kubernetes, вы можете использовать фильтр извлечения для назначения идентификатора кластера K8S в качестве значения в правиле. Это можно легко заменить одним правилом для каждого из ваших кластеров Kubernetes. Это может быть не так гибко, как правило извлечения, но это намного быстрее.

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

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

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

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

Избегайте регулярных выражений или запросов «содержит»

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

Запросы начинается с или равно гораздо эффективнее запросов содержит или запросов на основе регулярных выражений.

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

Вот пример эффективного иерархического шаблона именования, где иерархия определяется от самого общего к самому частному слева направо.

Схема именования сущностей: <stage>.<app>.<cluster>.<entityname>

Используйте ручные, массовые или теги среды

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

Ручные теги

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

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

API пользовательских тегов

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

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

Используйте эту строку селектора сущностей, чтобы выбрать все службы, имя которых начинается с book:

type(SERVICE),entityName.startsWith("Book")

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

type(CONTAINER_GROUP_INSTANCE),fromRelationship.isCgiOfCluster(type(KUBERNETES_CLUSTER) AND entityName.equals(my-prod-cluster-name))

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

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

Теги среды

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

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

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

Используйте менее затратные атрибуты вместо «дорогих»

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

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

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

• Имя контейнера Docker
• Полное имя образа Docker
• Топологии сервисов
• Программные технологии
• Версия программного обеспечения
• Версия образа Docker
• Имя образа, удаленного Docker
• Метки Kubernetes
• Метки облачных приложений
• Метки пространства имен облачных приложений
• Тип экземпляра виртуальной машины OpenStack
• Публичные IP-адреса GCE
• IP-адреса хоста
• IP-адреса пользовательских устройств
• Ограничение памяти PaaS
• Синтетический тип движка
• Синтетическое название движка
• Группы безопасности EC2
• Фронтенд-порты ELB