Entender os custos de monitoramento para insights de contêiner

Este artigo fornece diretrizes de preços dos insights do contêiner para ajudá-lo a entender como:

• Medir os custos após a habilitação dos insights do contêiner para um ou mais contêineres.
• Controlar a coleta de dados e fazer reduções de custos.

Dica

Para ver estratégias que reduzem os seus custos com o Azure Monitor, confira Otimização de custos e o Azure Monitor.

O modelo de preços do Azure Monitor se baseia principalmente na quantidade de dados ingeridos em gigabytes por dia em seu workspace do Log Analytics. O custo de um workspace do Log Analytics não se baseia somente no volume de dados coletados, mas também depende do plano escolhido e de quanto tempo você escolheu armazenar os dados gerados por seus clusters.

Observação

Consulte Estimar os custos do Azure Monitor para estimar seus custos para insights de contêiner antes de habilitá-lo.

Os tipos de dados a seguir coletados de um cluster de Kubernetes com insights do contêiner influenciam o custo e podem ser personalizados com base no seu uso:

• Perf, Inventory, InsightsMetrics e KubeEvents podem ser controlados por meio das configurações de otimização de custo
• Logs de contêiner stdout e stderr de cada contêiner monitorado em cada namespace do Kubernetes do cluster por meio do agente ConfigMap
• Variáveis de ambiente de contêiner de cada contêiner monitorado no cluster
• Trabalhos/pods de Kubernetes concluídos no cluster que não exigem monitoramento
• Configurar a extração de métricas do Prometheus
• Coleta de log de recursos dos logs do nó principal do Kubernetes em seu cluster do Serviço de Kubernetes do Azure (AKS) para analisar os dados de log gerados pelos componentes principais, como kube-apiserver e kube-controller-manager.

Controlar ingestão para reduzir custos

Considere um cenário em que as diferentes unidades de negócios de sua organização compartilha a infraestrutura Kubernetes e um workspace do Log Analytics. Cada unidade de negócios é separada por um namespace de Kubernetes. Você pode ver quantos dados são ingeridos em cada workspace usando o runbook Uso de Dados. O runbook está disponível na guia Relatórios.

Esta pasta de trabalho ajuda na visualização da origem dos seus dados sem precisar criar sua própria biblioteca de consultas a partir do que compartilhamos em nossa documentação. Nesta pasta de trabalho, você pode exibir gráficos que apresentam dados cobrados, como:

• Total cobrado de dados ingeridos em GB por solução.
• Dados ingeridos cobrados por logs de contêiner (logs de aplicativo).
• Dados ingeridos dos logs de contêiner cobrados por namespace de Kubernetes.
• Dados ingeridos dos logs de contêiner cobrados separados por nome de cluster.
• Dados ingeridos do log de contêiner cobrados por entrada de origem do log.
• Dados ingeridos de diagnóstico cobrados por logs do nó principal de diagnóstico.

Para saber mais sobre como gerenciar direitos e permissões para a pasta de trabalho, analise Controle de acesso.

Como determinar a causa raiz da ingestão de dados

Os dados do Container Insights consistem principalmente em contadores de métrica (Perf, Inventory, InsightsMetrics e métricas personalizadas) e logs (ContainerLog). Com base no uso e no tamanho do cluster, você poderá ter diferentes requisitos e necessidades de monitoramento.

Navegando até a seção Por Tabela da pasta de trabalho Uso de Dados, você poderá ver o detalhamento dos tamanhos da tabelas do Container Insights.

Se a maioria dos dados for proveniente de uma destas tabelas:

• Perf
• InsightsMetrics
• ContainerInventory
• ContainerNodeInventory
• KubeNodeInventory
• KubePodInventory
• KubePVInventory
• KubeServices
• KubeEvents

Você pode ajustar sua ingestão usando as configurações de otimização de custos e/ou migração para o complemento de métricas do Prometheus

Caso contrário, a maioria dos dados pertence à tabela ContainerLog. e você poderá seguir as etapas abaixo para reduzir os custos do ContainerLog.

Como reduzir os custos do ContainerLog

Após terminar a análise para determinar quais fontes estão gerando os dados ou que estão excedendo seus requisitos, você pode reconfigurar a coleta de dados. Para obter mais informações sobre como configurar a coleta de variáveis de ambiente, stdout e stderr, confira Definir configurações de coleta de dados do agente.

Os exemplos a seguir mostram quais alterações você pode aplicar ao cluster mudando o arquivo ConfigMap para ajudar a controlar o custo.

1. Desabilite os logs stdout em todos os namespaces no cluster modificando o código a seguir no arquivo ConfigMap para o serviço do insights do Contêiner do Azure que está efetuando pull das métricas:

   [log_collection_settings]       
      [log_collection_settings.stdout]          
         enabled = false
   

2. Desabilite a coleta de logs stderr do namespace de desenvolvimento. Um exemplo é dev-test. Continue coletando logs stderr de outros namespaces, como prod e default, modificando o seguinte código no arquivo ConfigMap:

   Observação

   A coleção de logs kube-system fica desabilitada por padrão. A configuração padrão é mantida. Adicionar o namespace dev-test à lista de namespaces de exclusão é aplicado à coleção de logs stderr.

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

3. Desabilite a coleção de variáveis de ambiente em todo o cluster mudando o código a seguir no arquivo ConfigMap. Essa modificação se aplica a todos os contêineres em todos os namespaces de Kubernetes.

   [log_collection_settings.env_var]
       enabled = false
   

4. Para limpar os trabalhos concluídos, especifique a política de limpeza no YAML de definição de trabalho. A seguir, um exemplo Definição de trabalho com política de limpeza. Para obter mais detalhes, consulte a Documentação do Kubernetes.

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: pi-with-ttl
   spec:
     ttlSecondsAfterFinished: 100
   

Após aplicar uma ou mais dessas alterações em seus ConfigMaps, aplique-as ao seu cluster com o comando kubectl apply -f <config3. map_yaml_file.yaml>. Por exemplo, execute o comando kubectl apply -f container-azm-ms-agentconfig.yaml para abrir o arquivo no editor padrão para modificá-lo e salvá-lo.

Configurar Logs Básicos

Economize nos custos de ingestão de dados no ContainerLog no seu workspace do Log Analytics que você usa principalmente para depuração, solução de problemas e auditoria como Logs Básicos. Para obter mais informações, incluindo as limitações dos logs básicos, confira Configurar logs básicos no Azure Monitor. ContainerLogV2 é a versão configurada dos logs básicos que o recurso Insights de Container usa. O ContainerLogV2 inclui registros detalhados de log baseados em texto.

Você precisa estar no esquema ContainerLogV2 para configurar os logs básicos. Para obter mais informações, confira Habilitar o esquema ContainerLogV2 (versão prévia).

Extração de métricas do Prometheus

Observação

Esta seção descreve coleção de métricas do Prometheus em seu workspace do Log Analytics. Essas informações não se aplicam se você estiver usando o Prometheus Gerenciado para raspar suas métricas do Prometheus.

Se você coletar métricas do Prometheus em seu workspace do Log Analytics, certifique-se de limitar o número de métricas coletadas do cluster:

• Verifique se a frequência de extração foi definida de forma ideal. O padrão é 60 segundos. É possível aumentar a frequência para 15 segundos,mas você precisa garantir que as métricas que você está extraindo sejam publicadas na mesma frequência. Caso contrário, muitas métricas duplicadas serão extraídas e enviadas ao seu workspace do Log Analytics em intervalos que são adicionados aos custos de ingestão e retenção de dados, mas são de menor valor.
• Os insights do contêiner permitem listas de exclusão e inclusão por nome de métrica. Por exemplo, se você estiver extraindo métricas kubedns em seu cluster, centenas delas poderão ser extraídas por padrão. Mas é provável que você só esteja interessado em um subconjunto das métricas. Confirme se você especificou uma lista de métricas para extrair ou excluir outras, exceto para algumas a fim de salvar no volume de ingestão de dados. É fácil habilitar a extração e não usar muitas dessas métricas, o que somente adicionará encargos à sua fatura do Log Analytics.
• Ao extrair por meio de anotações do pod, certifique-se de filtrar por namespace para assim excluir a extração de métricas de pod de namespaces que você não usa. O namespace dev-test é um exemplo.

Dados coletados dos clusters de Kubernetes

Dados de métrica

As informações de contêiner incluem um conjunto predefinido de métricas e itens de inventário coletados que são gravados como dados de log em seu workspace do Log Analytics. Todas as métricas na tabela a seguir são coletadas a cada minuto.

Type	Métricas
Métricas de nó	cpuUsageNanoCores cpuCapacityNanoCores cpuAllocatableNanoCores memoryRssBytes memoryWorkingSetBytes memoryCapacityBytes memoryAllocatableBytes restartTimeEpoch used (disco) free (disco) used_percent (disco) io_time (E/S de disco) writes (E/S de disco) reads (E/S de disco) write_bytes (E/S de disco) write_time (E/S de disco) iops_in_progress (E/S de disco) read_bytes (E/S de disco) read_time (E/S de disco) err_in (net) err_out (net) bytes_recv (net) bytes_sent (net) Kubelet_docker_operations (kubelet)
Métricas do contêiner.	cpuUsageNanoCores cpuRequestNanoCores cpuLimitNanoCores memoryRssBytes memoryWorkingSetBytes memoryRequestBytes memoryLimitBytes restartTimeEpoch

Inventário de cluster

A lista a seguir são os dados de inventário de cluster coletados por padrão:

• KubePodInventory – 1 por pod por minuto
• KubeNodeInventory – 1 por nó por minuto
• KubeServices – 1 por serviço por minuto
• ContainerInventory – 1 por contêiner por minuto

Próximas etapas

Para ajudá-lo a entender quais seriam os prováveis custos com base nos padrões de uso recentes dos dados coletados com os insights do contêiner, confira Analisar uso no workspace do Log Analytics.