Поделиться через


Рекомендации по созданию правила сбора данных и управлению ими в Azure Monitor

Правила сбора данных (DCR) устанавливают способы сбора и обработки данных телеметрии, отправляемых в Azure. Некоторые правила сбора данных создаются и контролируются самой службой Azure Monitor, а вы можете создавать дополнительные правила под конкретные требования по сбору данных. В этой статье рассматриваются некоторые рекомендации, которые следует применять при создании собственных контроллеров домена.

При создании DCR существуют некоторые аспекты, которые необходимо учитывать, например:

  • Тип собранных данных, также известный как тип источника данных (производительность, события)
  • Целевой Виртуальные машины, с которым будет связан DCR
  • Назначение собранных данных

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

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

Screenshot of data collection rules to virtual machines relation.

Чтобы уточнить, какой область может быть наблюдаемость, подумайте об этом в качестве предпочтительной логической границы для сбора данных. Например, возможное область может быть набором виртуальных машин под управлением программного обеспечения (например, SQL Server), необходимых для конкретного приложения, или базовых счетчиков операционной системы или событий, используемых ИТ-Администратор. Кроме того, можно создавать аналогичные область, предназначенные для различных сред ("Разработка", "Тестирование", "Рабочая среда") для специализации еще больше.

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

Категория Рекомендация Описание Область влияния
Сбор данных Определение область наблюдаемости Определение наблюдаемости область является ключом к упрощению и успешному управлению DCR и область наблюдаемости организации. Это поможет уточнить, что требуется для сбора данных, и с какой целевой виртуальной машины она должна выполняться. Как упоминалось ранее, наблюдаемость область может быть набором виртуальных машин под управлением программного обеспечения, которое является общим для конкретного приложения, набором общих сведений для ИТ-отдела и т. д. Например, сбор базовых счетчиков производительности операционной системы, таких как загрузка ЦП, доступная память и свободное место на диске, можно рассматривать как область для центрального ИТ-управления. Отсутствие четко определенного область не дает ясности и не позволяет правильно управлять.
Создание контроллеров домена, относящихся к наблюдаемости область Создание отдельных контроллеров домена на основе наблюдаемости область является ключевым для простого обслуживания. Это позволит легко связать контроллеры домена с соответствующими целевыми виртуальными машинами. Зачем создавать единый DCR, который собирает счетчики производительности операционной системы, а также счетчики веб-сервера и счетчики баз данных вместе? Этот подход позволяет не только каждой связанной виртуальной машине передавать, обрабатывать и выполнять конфигурацию, которая находится за пределами область, но и потребует больше усилий при обновлении конфигурации DCR. Думайте об управлении шаблоном, который включает ненужные записи; Эта ситуация меньше идеала и оставляет место для ошибок.
Создание DCR для типа источника данных внутри определенных область наблюдаемости Создание отдельных контроллеров домена для производительности и событий поможет как управлять конфигурацией, так и связью с детализацией на основе целевых компьютеров. Например, создание DCR для сбора событий и счетчиков производительности может привести к неоптимальному подходу. Могут возникнуть ситуации, в которых у заданного компьютера (или набора компьютеров) нет журналов событий или счетчиков производительности, настроенных в DCR. В этой ситуации виртуальные машины будут вынуждены обрабатывать и выполнять конфигурацию, которая не требуется в соответствии с установленным на ней программным обеспечением. Не используя разные контроллеры домена, каждая связанная виртуальная машина будет принудительно передавать, обрабатывать и выполнять конфигурацию, которая может быть неприменимой в соответствии с установленным программным обеспечением. Чрезмерное потребление вычислительных ресурсов и ошибки в конфигурации обработки может привести к тому, что агент Azure Monitor (AMA) не отвечает. Кроме того, сбор ненужных данных увеличит затраты на прием данных.
Назначение данных Создание разных DCR на основе назначения Контроллеры домена имеют возможность одновременной отправки данных в несколько разных назначений, таких как метрики Azure Monitor и журналы Azure Monitor. Наличие DCR, относящихся к назначению, полезно для управления требованиями к данным, суверенными или законодательством. Так как для отправки данных может потребоваться только разрешенные репозитории, созданные в разрешенных регионах, наличие различных контроллеров домена позволяет повысить степень детализации целевого назначения. Не разделяя контроллеры домена на основе назначения данных, могут привести к несоответствию требованиям к обработке данных, конфиденциальности и доступу и может привести к ненужным сбору данных, что приведет к непредвиденным затратам.

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

Следующие шаги