Преобразования данных в аналитике контейнеров

Статья
10/15/2024

В этой статье описывается, как реализовать преобразования данных в аналитике контейнеров. Преобразования в Azure Monitor позволяют изменять или фильтровать данные перед приемом в рабочей области Log Analytics. Они позволяют выполнять такие действия, как фильтрация данных, собранных из кластера, для экономии затрат или обработки входящих данных для помощи в запросах данных.

Внимание

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

Правило сбора данных

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

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

Примечание.

В настоящее время существует минимальный пользовательский интерфейс для редактирования контроллеров домена, необходимых для добавления преобразований. В большинстве случаев необходимо вручную изменить DCR. В этой статье описывается структура DCR для реализации. Инструкции по реализации этой структуры см. в статье "Создание и изменение правил сбора данных (DCR) в Azure Monitor .

Источники данных

Раздел источников данных DCR определяет различные типы входящих данных, которые будет обрабатывать DCR . Для аналитики контейнеров это расширение аналитики контейнеров, которое включает в себя одно или несколько предопределенных streams начиная с префикса Microsoft-.

Список потоков аналитики контейнеров в DCR зависит от предустановки затрат, выбранной для кластера. При сборе всех таблиц DCR будет использовать Microsoft-ContainerInsights-Group-Default поток, который является групповым потоком, который включает все потоки, перечисленные в значениях stream. Если вы собираетесь использовать преобразование, это необходимо изменить на отдельные потоки. Любые другие параметры предустановки затрат уже будут использовать отдельные потоки.

В приведенном Microsoft-ContainerInsights-Group-Default ниже примере показан поток. Примеры контроллеров домена см. в примерах с помощью отдельных потоков.

"dataSources": {
    "extensions": [
        {
            "streams": [
                "Microsoft-ContainerInsights-Group-Default"
            ],
            "name": "ContainerInsightsExtension",
            "extensionName": "ContainerInsights",
            "extensionSettings": { 
                "dataCollectionSettings": {
                    "interval": "1m",
                    "namespaceFilteringMode": "Off",
                    "namespaces": null,
                    "enableContainerLogV2": true
                }
            }
        }
    ]
}

Потоки данных

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

Создайте отдельную запись для потоков, требующих преобразования. Это должно включать назначение рабочей области и transformKql свойство. Если данные отправляются в альтернативную таблицу, необходимо включить outputStream свойство, указывающее имя целевой таблицы.

В приведенном ниже примере показано dataFlows раздел для одного потока с преобразованием. Ознакомьтесь с примерами контроллеров домена для нескольких потоков данных в одном DCR.

"dataFlows": [
    {
        "streams": [
            "Microsoft-ContainerLogV2"
        ],
        "destinations": [
            "ciworkspace"
        ],
        "transformKql": "source | where PodNamespace == 'kube-system'"
    }
]

Примеры контроллеров домена

Фильтрация данных

Первый пример отфильтровывает данные из ContainerLogV2 столбца LogLevel . Только записи с или LogLevel error critical будут собираться, так как это записи, которые можно использовать для оповещения и выявления проблем в кластере. Сбор и хранение других уровней, таких как info и debug создание затрат без значительного значения.

Эти записи можно получить с помощью следующего запроса журнала.

ContainerLogV2 | where LogLevel in ('error', 'critical')

Эта логика показана на следующей схеме.

В преобразовании имя source таблицы используется для представления входящих данных. Ниже приведен измененный запрос для использования в преобразовании.

source | where LogLevel in ('error', 'critical')

В следующем примере показано, как это преобразование добавлено в DCR аналитики контейнеров. Обратите внимание, что для этого используется Microsoft-ContainerLogV2 отдельный поток данных, так как это единственный входящий поток, к которому следует применить преобразование. Для других потоков используется отдельный поток данных.

{
    "properties": {
        "location": "eastus2",
        "kind": "Linux",
        "dataSources": {
            "syslog": [],
            "extensions": [
                {
                    "streams": [
                        "Microsoft-ContainerLogV2",
                        "Microsoft-KubeEvents",
                        "Microsoft-KubePodInventory"
                    ],
                    "extensionName": "ContainerInsights",
                    "extensionSettings": {
                        "dataCollectionSettings": {
                            "interval": "1m",
                            "namespaceFilteringMode": "Off",
                            "enableContainerLogV2": true
                        }
                    },
                    "name": "ContainerInsightsExtension"
                }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
                    "workspaceId": "00000000-0000-0000-0000-000000000000",
                    "name": "ciworkspace"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Microsoft-KubeEvents",
                    "Microsoft-KubePodInventory"
                ],
                "destinations": [
                    "ciworkspace"
                ],
            },
            {
                "streams": [
                    "Microsoft-ContainerLogV2"
                ],
                "destinations": [
                    "ciworkspace"
                ],
                "transformKql": "source | where LogLevel in ('error', 'critical')"
            }
        ],
    },
}

Отправка данных в разные таблицы

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

Для этой стратегии необходимы два преобразования. Первое преобразование отправляет записи с LogLevel error таблицей по умолчанию или critical в нее. Второе преобразование отправляет другие записи в пользовательскую таблицу с именем ContainerLogV2_CL. Запросы для каждого из них показаны ниже, используя source входящие данные, как описано в предыдущем примере.

# Return error and critical logs
source | where LogLevel in ('error', 'critical')

# Return logs that aren't error or critical
source | where LogLevel !in ('error', 'critical')

Эта логика показана на следующей схеме.

Внимание

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

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

{
    "properties": {
        "location": "eastus2",
        "kind": "Linux",
        "dataSources": {
            "syslog": [],
            "extensions": [
                {
                    "streams": [
                        "Microsoft-ContainerLogV2",
                        "Microsoft-KubeEvents",
                        "Microsoft-KubePodInventory"
                    ],
                    "extensionName": "ContainerInsights",
                    "extensionSettings": {
                        "dataCollectionSettings": {
                            "interval": "1m",
                            "namespaceFilteringMode": "Off",
                            "enableContainerLogV2": true
                        }
                    },
                    "name": "ContainerInsightsExtension"
                }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
                    "workspaceId": "00000000-0000-0000-0000-000000000000",
                    "name": "ciworkspace"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Microsoft-KubeEvents",
                    "Microsoft-KubePodInventory"
                ],
                "destinations": [
                    "ciworkspace"
                ],
            },
            {
                "streams": [
                    "Microsoft-ContainerLogV2"
                ],
                "destinations": [
                    "ciworkspace"
                ],
                "transformKql": "source | where LogLevel in ('error', 'critical')"
            },
            {
                "streams": [
                    "Microsoft-ContainerLogV2"
                ],
                "destinations": [
                    "ciworkspace"
                ],
                "transformKql": "source | where LogLevel !in ('error','critical')",
                "outputStream": "Custom-ContainerLogV2_CL"
            }
        ],
    },
}

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

Дополнительные сведения о преобразованиях и правилах сбора данных см. в Azure Monitor.

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