Compartilhar via

Transformação de dados em insights de contêiner

  • Artigo

Este artigo descreve como implementar transformações de dados em insights de contêiner. As transformações no Azure Monitor permite modificar ou filtrar dados antes de serem ingeridos no workspace do Log Analytics. Elas permitem que você execute ações como filtrar dados coletados do cluster para reduzir custos ou processar dados de entrar para ajudar nas consultas de dados.

Importante

Os artigos Configurar a coleção de logs em Insights de contêiner e Filtrar a coleção de registros em Insights de contêiner, descrevem as configurações padrão para configurar e filtrar a coleta de dados para Insights de contêiner. Execute qualquer configuração necessária usando esses recursos antes de usar as transformações. Use uma transformação para executar a filtragem ou outra configuração de dados que não é possível executar com as configurações padrão.

Regra de coleta de dados

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

  • Novo cluster. Use um modelo do Resource Manager existente para integrar um cluster do AKS aos insights de contêiner. Modifique a 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 aos Insights de contêiner e a coleta de dados configurada, edite a DCR para incluir uma transformação usando qualquer um dos métodos na Edição de regras de coleta de dados.

Observação

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

Fontes de dados

A seção Fontes de dados do DCR define os diferentes tipos de dados de entrada que o DCR irá processar. Para os Insights de contêiner, esta é a extensão dos Insights de contêiner, que inclui uma ou mais streams predefinidas, começando com o prefixo Microsoft-.

A lista de fluxos de insights de contêiner na DCR depende da Predefinição de custo selecionada para o cluster. Se você coletar todas as tabelas, a DCR usará o fluxo Microsoft-ContainerInsights-Group-Default, que é um fluxo de grupo que inclui todos os fluxos listados em Valores de fluxo. Você deve alterar isso para fluxos individuais se quiser usar uma transformação. Qualquer outra configuração predefinida de custo já estará usando fluxos individuais.

O exemplo abaixo mostra o fluxo Microsoft-ContainerInsights-Group-Default. Consulte os DCRs de exemplo para obter exemplos 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 a streams com destinos que estão definidos na seção destinations do DCR. Os nomes de tabela não precisarão 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 workspace. 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 propriedade transformKql. Caso esteja enviando dados para uma tabela alternativa, precisará incluir a propriedade outputStream que especifica o nome da tabela de destino.

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

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

DCRs de exemplo

Filtrar dados

O primeiro exemplo filtra os dados com base em ContainerLogV2 na coluna LogLevel. Somente registros com um LogLevel de error ou critical serão coletados, pois essas são as entradas que é possível usar para alertar e identificar problemas no cluster. Coletar e armazenar outros níveis, como info e debug geram custo sem valor significativo.

É possível recuperar esses registros usando a consulta de log a seguir.

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

Esta lógica é mostrado 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 à DCR de Insights de contêiner. Observe que um fluxo de dados separado é usado para Microsoft-ContainerLogV2, pois esse é 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, somente 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 essa estratégia, duas transformações são necessárias. 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 é mostrado 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 a DCR neste exemplo, você deverá criar uma nova tabela com o mesmo esquema que ContainerLogV2. Nomeie-o ContainerLogV2_CL e configure-o para logs básicos.

O exemplo a seguir mostra essa transformação adicionada à DCR de Insights de contêiner. Há dois fluxos de dados para Microsoft-ContainerLogV2 nesta DCR, um para cada transformação. O primeiro envia para a tabela padrão que você não precisa para especificar um nome de tabela. O segundo requer a propriedade outputStream para especificar 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óximas etapas