Partilhar via

Transformações de dados no Container insights

  • Artigo

Este artigo descreve como implementar transformações de dados no Container insights. As transformações no Azure Monitor permitem modificar ou filtrar dados antes que eles sejam ingeridos em seu espaço de trabalho do Log Analytics. Eles permitem que você execute ações como filtrar dados coletados do cluster para economizar custos ou processar dados de entrada para ajudar em suas consultas de dados.

Importante

Os artigos Configure log collection in Container insights e Filtering log collection in Container insights descrevem definições de configuração padrão para configurar e filtrar a coleta de dados para insights de contêiner. Você deve executar qualquer configuração necessária usando esses recursos antes de usar transformações. Use uma transformação para executar filtragem ou outra configuração de dados que você não pode executar com as definições de configuração padrão.

Regra de recolha de dados

As transformações são implementadas em regras de coleta de dados (DCRs) que são usadas para configurar a coleta de dados no Azure Monitor. Configurar a coleta de dados usando DCR descreve o DCR que é criado automaticamente quando você habilita Insights de contêiner em um cluster. Para criar uma transformação, você deve executar uma das seguintes ações:

  • Novo cluster. Use um modelo ARM existente para integrar um cluster AKS ao Container insights. Modifique o DCR nesse modelo com a configuração necessária, incluindo uma transformação semelhante a um dos exemplos abaixo.
  • DCR existente. Depois que um cluster tiver sido integrado ao Container insights e a coleta de dados configurada, edite seu DCR para incluir uma transformação usando qualquer um dos métodos em Editando regras de coleta de dados.

Nota

Atualmente, há uma interface do usuário mínima para editar DCRs, que é necessária para adicionar transformações. Na maioria dos casos, você precisa editar manualmente o DCR. Este artigo descreve a estrutura DCR a implementar. Consulte Criar e editar regras de coleta de dados (DCRs) no Azure Monitor para obter orientação sobre como implementar essa estrutura.

Origens de dados

A seção Fontes de dados do DCR define os diferentes tipos de dados de entrada que o DCR processará. Para Container insights, esta é a extensão Container insights, que inclui um ou mais predefinidos streams começando com o prefixo Microsoft-.

A lista de fluxos de informações de contêiner no DCR depende da predefinição de Custo selecionada para o cluster. Se você coletar todas as tabelas, o DCR usará o Microsoft-ContainerInsights-Group-Default fluxo, que é um fluxo de grupo que inclui todos os fluxos listados em Valores de fluxo. Você deve alterar isso para fluxos individuais se for usar uma transformação. Quaisquer outras configurações predefinidas de custo já usarão fluxos individuais.

O exemplo abaixo mostra o Microsoft-ContainerInsights-Group-Default fluxo. Consulte os DCRs de exemplo para amostras usando fluxos individuais.

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

Fluxos de dados

A seção Fluxos de dados do DCR corresponde aos fluxos com os destinations destinos definidos na seção do DCR. Os nomes de tabela não precisam ser especificados para fluxos conhecidos se os dados estiverem sendo enviados para a tabela padrão. Os fluxos que não exigem uma transformação podem ser agrupados em uma única entrada que inclui apenas o destino do espaço de trabalho. Cada um será enviado para sua tabela padrão.

Crie uma entrada separada para fluxos que exigem uma transformação. Isso deve incluir o destino do espaço de trabalho e a transformKql propriedade. Se você estiver enviando dados para uma tabela alternativa, precisará incluir a outputStream propriedade que especifica o nome da tabela de destino.

O exemplo abaixo mostra a dataFlows seção para um único fluxo com uma transformação. Consulte os DCRs de exemplo para vários fluxos de dados em um único DCR.

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

Exemplos de DCRs

Filtrar dados

O primeiro exemplo filtra os dados do ContainerLogV2 baseado na LogLevel coluna. Somente registros com um LogLevel de error ou critical serão coletados, pois essas são as entradas que você pode usar para alertar e identificar problemas no cluster. Coletar e armazenar outros níveis, como info e debug gerar custos sem valor significativo.

Você pode recuperar esses registros usando a seguinte consulta de log.

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

Esta lógica é mostrada no diagrama a seguir.

Diagrama que mostra a filtragem de logs de contêiner usando uma transformação.

Em uma transformação, o nome source da tabela é usado para representar os dados de entrada. A seguir está a consulta modificada a ser usada na transformação.

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

O exemplo a seguir mostra essa transformação adicionada ao DCR do Container insights. Observe que um fluxo de dados separado é usado para Microsoft-ContainerLogV2 uma vez que este é o único fluxo de entrada ao qual a transformação deve ser aplicada. Um fluxo de dados separado é usado para os outros fluxos.

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

Enviar dados para tabelas diferentes

No exemplo acima, apenas registros com um LogLevel de error ou critical são coletados. Uma estratégia alternativa em vez de não coletar esses registros é salvá-los em uma tabela alternativa configurada para logs básicos.

Para esta estratégia, são necessárias duas transformações. A primeira transformação envia os registros com LogLevel de error ou critical para a tabela padrão. A segunda transformação envia os outros registros para uma tabela personalizada chamada ContainerLogV2_CL. As consultas para cada um são mostradas abaixo usando source para os dados de entrada, conforme descrito no exemplo anterior.

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

Esta lógica é mostrada no diagrama a seguir.

Diagrama que mostra a filtragem de logs de contêiner usando uma transformação que envia alguns dados para a tabela de análise e outros dados para logs básicos.

Importante

Antes de instalar o DCR neste exemplo, você deve criar uma nova tabela com o mesmo esquema do ContainerLogV2. Nomeie-o ContainerLogV2_CL e configure-o para logs básicos.

O exemplo a seguir mostra essa transformação adicionada ao DCR do Container insights. Há dois fluxos de dados para Microsoft-ContainerLogV2 este DCR, um para cada transformação. O primeiro envia para a tabela padrão que você não precisa especificar um nome de tabela. O segundo requer que a outputStream propriedade especifique a tabela de destino.

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

Próximos passos