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