Transformations de données dans Container Insights

Article
10/22/2024

Cet article explique comment implémenter des transformations de données dans Container Insights. Les transformations dans Azure Monitor vous permettent de modifier ou de filtrer les données avant leur ingestion dans votre espace de travail Log Analytics. Elles vous permettent d'effectuer des actions comme filtrer les données collectées à partir de votre cluster afin de réduire les coûts ou de traiter les données entrantes pour faciliter vos requêtes de données.

Important

Les articles Configurer la collecte de journaux dans Container Insights et Filtrer la collecte de journaux dans Container Insights décrivent les paramètres de configuration standard pour configurer et filtrer la collecte de données pour Container Insights. Vous devez effectuer toute configuration requise à l’aide de ces fonctionnalités avant d’utiliser les transformations. Utilisez une transformation pour effectuer un filtrage ou une autre configuration de données que vous ne pouvez pas effectuer avec les paramètres de configuration standard.

Règle de collecte de données

Les transformations sont implémentées dans les règles de collecte de données (DCR) utilisées pour configurer la collecte de données dans Azure Monitor. Configurer la collecte de données à l’aide de DCR décrit le DCR qui est automatiquement créé lorsque vous activez Container Insights sur un cluster. Pour créer une transformation, vous devez effectuer l’une des actions suivantes :

Nouveau groupe. Utilisez un modèle ARM existant pour intégrer un cluster AKS à Container Insights. Modifiez le DCR dans ce modèle avec la configuration requise, y compris une transformation similaire à l’un des exemples ci-dessous.
DCR existant. Une fois qu'un cluster a été intégré à Container Insights et que la collecte de données a été configurée, modifiez son DCR pour inclure une transformation à l'aide de l'une des méthodes décrites dans Modification des règles de collecte de données.

Remarque

Il existe actuellement une interface utilisateur minimale pour l'édition des DCR, ce qui est nécessaire pour ajouter des transformations. Dans la plupart des cas, vous devez modifier manuellement le DCR. Cet article décrit la structure DCR à mettre en œuvre. Consultez Créer et modifier des règles de collecte de données (DCR) dans Azure Monitor pour obtenir des conseils sur la façon d’implémenter cette structure.

Sources de données

La section Sources de données de la DCR définit les différents types de données entrantes que la DCR traitera. Pour Container Insights, il s'agit de l'extension Container Insights, qui inclut un ou plusieurs streams prédéfinis commençant par le préfixe Microsoft-.

La liste des flux Container Insights dans la DCR dépend de la présélection des coûts que vous avez sélectionnée pour le cluster. Si vous collectez toutes les tables, la DCR utilisera le flux Microsoft-ContainerInsights-Group-Default, qui est un flux de groupe comprenant tous les flux énumérés dans Valeurs de flux. Vous devez passer à des flux individuels si vous souhaitez utiliser une transformation. Tous les autres paramètres de présélection des coûts utilisent déjà des flux individuels.

L'exemple ci-dessous montre le flux Microsoft-ContainerInsights-Group-Default. Consultez les exemples de DCR pour obtenir des exemples utilisant des flux individuels.

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

Flux de données

La section Flux de données de la DCR fait correspondre les flux avec les destinations qui sont définies dans la section destinations de la DCR. Les noms de table n'ont pas besoin d'être spécifiés pour les flux connus si les données sont envoyées à la table par défaut. Les flux qui ne nécessitent pas de transformation peuvent être regroupés dans une entrée unique qui ne comprend que la destination de l'espace de travail. Chacun sera envoyé à sa table par défaut.

Créez une entrée distincte pour les flux qui nécessitent une transformation. Cela doit inclure la destination de l'espace de travail et la propriété transformKql. Si vous envoyez des données à une table alternative, vous devez inclure la propriété outputStream qui spécifie le nom de la table de destination.

L'exemple ci-dessous montre la section dataFlows pour un seul flux avec une transformation. Reportez-vous aux Échantillons de DCR pour plusieurs flux de données dans un seul DCR.

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

Échantillons de DCR

Filtrer les données

Le premier exemple filtre les données du ContainerLogV2 en fonction de la colonne LogLevel. Seuls les enregistrements comportant un symbole LogLevel de error ou critical seront collectés, car ce sont les entrées que vous pouvez utiliser pour alerter et identifier les problèmes dans le cluster. La collecte et le stockage d’autres niveaux tels que info et debug génèrent des coûts sans valeur significative.

Vous pouvez récupérer ces enregistrements à l’aide de la requête de journal suivante.

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

Cette logique est illustrée dans le diagramme suivant.

Dans une transformation, le nom de la table source est utilisé pour représenter les données entrantes. Voici la requête modifiée à utiliser dans la transformation.

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

L'exemple suivant montre cette transformation ajoutée au DCR Container Insights. Notez qu’un flux de données distinct est utilisé pour Microsoft-ContainerLogV2 car il s’agit du seul flux entrant auquel la transformation doit être appliquée. Un flux de données distinct est utilisé pour les autres flux.

{
    "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')"
            }
        ],
    },
}

Envoyer des données à différentes tables

Dans l'exemple ci-dessus, seuls les enregistrements avec un LogLevel de error ou critical sont collectés. Une stratégie alternative au lieu de ne pas collecter ces enregistrements du tout consiste à les enregistrer dans une table alternative configurée pour les journaux de base.

Pour cette stratégie, deux transformations sont nécessaires. La première transformation envoie les enregistrements avec LogLevel de error ou critical vers la table par défaut. La deuxième transformation envoie les autres enregistrements vers une table personnalisée nommée ContainerLogV2_CL. Les requêtes pour chacune d'elles sont présentées ci-dessous en utilisant source pour les données entrantes comme décrit dans l'exemple précédent.

# 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')

Cette logique est illustrée dans le diagramme suivant.

Important

Avant d'installer le DCR dans cet exemple, vous devez créer une table avec le même schéma que ContainerLogV2. Nommez-la ContainerLogV2_CL et configurez-la pour les journaux de base.

L'exemple suivant montre cette transformation ajoutée au DCR Container Insights. Il existe deux flux de données pour Microsoft-ContainerLogV2 dans ce DCR, un pour chaque transformation. Le premier envoie à la table par défaut, vous n'avez pas besoin de spécifier un nom de table. La seconde nécessite que la propriété outputStream spécifie la table de destination.

{
    "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"
            }
        ],
    },
}

Étapes suivantes

En savoir plus sur les transformations et les règles de collecte de données dans Azure Monitor.

Partager via