Compartilhar via

Como 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ê recebe cobranças pela ingestão e pela retenção desses dados, é possível reduzir significativamente os custos de monitoramento filtrando os dados desnecessários.

Importante

Este artigo descreve diferentes opções de filtragem que exigem que você modifique o DCR ou o ConfigMap para um cluster monitorado. Consulte Como configurar a coleta de logs no Container Insights para saber como realizar a configuração.

Como filtrar logs de contêiner

Os logs de contêiner stderr e stdout são gerados por contêineres no cluster Kubernetes. Esses logs são armazenados na tabela ContainerLogV2 no workspace do Log Analytics. Por padrão, todos os logs de contêiner são coletados, mas é possível filtrar os logs de namespaces específicos ou desabilitar completamente a coleta de logs de contêiner.

Com a DCR (regra de coleta de dados), é possível habilitar ou desabilitar os logs stdout e stderr e filtrar os 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 é possível definir esses valores individualmente com os outros métodos de configuração de DCR.

Usando o ConfigMap, é possível configurar a coleta dos logs stderr e stdout separadamente para o cluster, a fim de 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 namespaces kube-system 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 logs da plataforma (namespaces do Kubernetes do sistema)

Por padrão, os logs de contêiner do namespace do sistema são excluídos da coleta para minimizar o custo do Log Analytics. Os logs de contêineres do sistema podem ser essenciais 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-public e kube-node-lease.

Habilite os logs de plataforma usando o ConfigMap com a configuração collect_system_pod_logs. Também é preciso verificar se o namespace do sistema não está na configuração exclude_namespaces.

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

[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

Com a filtragem baseada em anotação, é possível 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 precisar filtrar o ruído.

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

[log_collection_settings.filter_using_annotations]
   enabled = true

Também é preciso adicionar as anotações necessárias à especificação do pod da carga de trabalho. A tabela a seguir realça diferentes anotações possíveis de pod.

Anotação Descrição
fluentbit.io/exclude: "true" Exclui fluxos stdout e 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" Excluir fluxos stdout e stderr somente para o contêiner1 no pod
fluentbit.io/exclude_stdout_container1: "true" Excluir somente stdout para o contêiner1 no pod

Observação

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

Confira a seguir um exemplo de anotação fluentbit.io/exclude: "true" em uma especificação de 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

Como 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 configurações a seguir.

[log_collection_settings.env_var]
    enabled = true

Se a coleção de variáveis de ambiente estiver habilitada globalmente, você poderá desabilitá-la para um contêiner específico definindo a variável de ambiente AZMON_COLLECT_ENV como False com uma configuração do Dockerfile ou no arquivo de configuração do pod na seção env:. Se a coleta de variáveis de ambiente estiver desabilitada globalmente, você não poderá habilitá-la 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 nas visualizações e alertas

Se houver pastas de trabalho ou alertas personalizados que usem os dados do Container Insights, a modificação das configurações de coleta de dados poderá prejudicar 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 verificar os alertas que fazem referência a essas 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óximas etapas