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