Partilhar via

Filtrar a coleta de logs no Container insights

  • Artigo

Este artigo descreve as diferentes opções de filtragem disponíveis no Container insights. Os clusters do Kubernetes geram uma grande quantidade de dados que são coletados pelo Container insights. Como você é cobrado pela ingestão e retenção desses dados, pode reduzir significativamente seus custos de monitoramento filtrando os dados de que não precisa.

Importante

Este artigo descreve diferentes opções de filtragem que exigem que você modifique o DCR ou o ConfigMap para um cluster monitorado. Consulte Configurar coleta de logs em Informações de contêiner para obter detalhes sobre como executar essa configuração.

Filtrar logs de contêiner

Os logs de contêiner são logs stderr e stdout gerados por contêineres no cluster do Kubernetes. Esses logs são armazenados na tabela ContainerLogV2 no espaço de trabalho do Log Analytics. Por padrão, todos os logs de contêiner são coletados, mas você pode filtrar logs de namespaces específicos ou desabilitar totalmente a coleta de logs de contêiner.

Usando a regra de coleta de dados (DCR), você pode habilitar ou desabilitar logs stdout e stderr e filtrar namespaces específicos de cada um. As configurações para logs de contêiner e filtragem de namespace estão incluídas nas predefinições de custo configuradas no portal do Azure e você pode definir esses valores individualmente usando os outros métodos de configuração DCR.

Usando o ConfigMap, você pode configurar a coleção e stderr stdout os logs separadamente para o cluster, para que você possa optar por habilitar um e não o outro.

O exemplo a seguir mostra as configurações do ConfigMap para coletar stdout e stderr excluindo os kube-system namespaces e gatekeeper-system .

[log_collection_settings]
    [log_collection_settings.stdout]
        enabled = true
        exclude_namespaces = ["kube-system","gatekeeper-system"]

    [log_collection_settings.stderr]
        enabled = true
        exclude_namespaces = ["kube-system","gatekeeper-system"]

    [log_collection_settings.enrich_container_logs]
        enabled = true

Filtragem de log da plataforma (namespaces do System Kubernetes)

Por padrão, os logs de contêiner do namespace do sistema são excluídos da coleção para minimizar o custo do Log Analytics. Os logs de contêiner de contêineres do sistema podem ser críticos em cenários específicos de solução de problemas. Esse recurso é restrito aos seguintes namespaces do sistema: kube-system, gatekeeper-system, calico-system, azure-arc, kube-publice kube-node-lease.

Habilite os logs da plataforma usando o ConfigMap com a collect_system_pod_logs configuração. Você também deve garantir que o namespace do sistema não esteja na exclude_namespaces configuração.

O exemplo a seguir mostra as configurações do ConfigMap para coletar logs stdout e stderr do coredns contêiner no kube-system namespace.

[log_collection_settings]
    [log_collection_settings.stdout]
        enabled = true
        exclude_namespaces = ["gatekeeper-system"]
        collect_system_pod_logs = ["kube-system:coredns"]

    [log_collection_settings.stderr]
        enabled = true
        exclude_namespaces = ["kube-system","gatekeeper-system"]
        collect_system_pod_logs = ["kube-system:coredns"]

Filtragem baseada em anotação para cargas de trabalho

A filtragem baseada em anotação permite excluir a coleta de logs para determinados pods e contêineres anotando o pod. Isso pode reduzir significativamente o custo de ingestão de logs e permitir que você se concentre em informações relevantes sem peneirar o ruído.

Habilite a filtragem baseada em anotações usando o ConfigMap com as seguintes configurações.

[log_collection_settings.filter_using_annotations]
   enabled = true

Você também deve adicionar as anotações necessárias na especificação do pod da carga de trabalho. A tabela a seguir destaca diferentes anotações de pod possíveis.

Anotação Description
fluentbit.io/exclude: "true" Exclui ambos os fluxos stdout & stderr em todos os contêineres no Pod
fluentbit.io/exclude_stdout: "true" Exclui apenas o fluxo stdout em todos os contêineres no Pod
fluentbit.io/exclude_stderr: "true" Exclui apenas o fluxo stderr em todos os contêineres no Pod
fluentbit.io/exclude_container1: "true" Exclua ambos os fluxos stdout & stderr somente para o container1 no pod
fluentbit.io/exclude_stdout_container1: "true" Excluir apenas stdout apenas para o recipiente1 no pod

Nota

Essas anotações são baseadas em bits fluentes. Se você usar sua própria solução de coleta de logs baseada em bits fluentes com o filtro de plug-in do Kubernetes e a exclusão baseada em anotações, ela deixará de coletar logs do Container Insights e da sua solução.

A seguir está um exemplo de fluentbit.io/exclude: "true" anotação em uma especificação do Pod:

apiVersion: v1 
kind: Pod 
metadata: 
 name: apache-logs 
 labels: 
  app: apache-logs 
 annotations: 
  fluentbit.io/exclude: "true" 
spec: 
 containers: 
 - name: apache 
  image: edsiper/apache_logs

Filtrar variáveis de ambiente

Habilite a coleta de variáveis de ambiente em todos os pods e nós no cluster usando o ConfigMap com as seguintes configurações.

[log_collection_settings.env_var]
    enabled = true

Se a coleção de variáveis de ambiente estiver habilitada globalmente, você poderá desativá-la para um contêiner específico definindo a variável AZMON_COLLECT_ENV de ambiente como False com uma configuração Dockerfile ou no arquivo de configuração para o Pod na env: seção . Se a coleta de variáveis de ambiente estiver desabilitada globalmente, você não poderá habilitar a coleta para um contêiner específico. A única substituição que pode ser aplicada no nível do contêiner é desabilitar a coleta quando ela já estiver habilitada globalmente.

Impacto em visualizações e alertas

Se você tiver alertas personalizados ou pastas de trabalho usando dados de insights de contêiner, modificar suas configurações de coleta de dados pode degradar essas experiências. Se você estiver excluindo namespaces ou reduzindo a frequência de coleta de dados, revise seus alertas, painéis e pastas de trabalho existentes usando esses dados.

Para procurar alertas que façam referência a estas tabelas, execute a seguinte consulta do Azure Resource Graph:

resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "Perf" or properties  contains "InsightsMetrics" or properties  contains "ContainerInventory" or properties  contains "ContainerNodeInventory" or properties  contains "KubeNodeInventory" or properties  contains"KubePodInventory" or properties  contains "KubePVInventory" or properties  contains "KubeServices" or properties  contains "KubeEvents" 
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc

Próximos passos