As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Observabilidade
Introdução
As ferramentas de observabilidade ajudam você a detectar, corrigir e investigar com eficiência suas cargas de trabalho. O custo dos dados de telemetria aumenta naturalmente à medida que o uso do EKS aumenta. Às vezes, pode ser difícil equilibrar suas necessidades operacionais e medir o que é importante para sua empresa e manter os custos de observabilidade sob controle. Este guia se concentra em estratégias de otimização de custos para os três pilares da observabilidade: registros, métricas e rastreamentos. Cada uma dessas melhores práticas pode ser aplicada de forma independente para se adequar às metas de otimização da sua organização.
Registro em log
O registro desempenha um papel vital no monitoramento e na solução de problemas dos aplicativos em seu cluster. Há várias estratégias que podem ser empregadas para otimizar os custos de registro. As estratégias de melhores práticas listadas abaixo incluem examinar suas políticas de retenção de registros para implementar controles granulares sobre por quanto tempo os dados de registro são mantidos, enviar dados de registro para diferentes opções de armazenamento com base na importância e utilizar a filtragem de registros para restringir os tipos de mensagens de registro que são armazenadas. O gerenciamento eficiente da telemetria de registros pode levar à economia de custos em seus ambientes.
Plano de controle EKS
Otimize seus registros do plano de controle
O plano de controle do Kubernetes é um conjunto de componentes
Por exemplo, em clusters que não são de produção, habilite seletivamente tipos de log específicos, como os registros do servidor de API, somente para análise e desative-os posteriormente. Mas para clusters de produção, nos quais talvez você não consiga reproduzir eventos e a resolução de problemas exija mais informações de registro, você pode habilitar todos os tipos de registro. Mais detalhes sobre a implementação da otimização de custos do plano de controle estão nesta postagem do blog
Transmita registros para o S3
Outra prática recomendada de otimização de custos é transmitir os registros do plano de controle para o S3 por meio de assinaturas de CloudWatch registros. O aproveitamento das assinaturas de CloudWatch registros permite que você encaminhe seletivamente os registros para o S3, o que fornece um armazenamento de longo prazo mais econômico em comparação com a retenção de registros indefinidamente. CloudWatch Por exemplo, para clusters de produção, você pode criar um grupo crítico de registros e aproveitar as assinaturas para transmitir esses registros para o S3 após 15 dias. Isso garantirá que você tenha acesso rápido aos registros para análise, mas também economizará custos ao mover os registros para um armazenamento mais econômico.
Importante
A partir de 05/09/2023, os registros do EKS são classificados como registros vendidos na Amazon Logs. CloudWatch Os Vended Logs são registros de serviços específicos da AWS publicados nativamente pelos serviços da AWS em nome do cliente e disponíveis com preços de desconto por volume. Visite a página de CloudWatch preços da Amazon
Plano de dados EKS
Retenção de log
A política CloudWatch de retenção padrão da Amazon é manter os registros indefinidamente e nunca expirar, incorrendo em custos de armazenamento aplicáveis à sua região da AWS. Para reduzir os custos de armazenamento, você pode personalizar a política de retenção para cada grupo de registros com base em seus requisitos de carga de trabalho.
Em um ambiente de desenvolvimento, um longo período de retenção pode não ser necessário. Mas em um ambiente de produção, você pode definir uma política de retenção mais longa para atender aos requisitos de solução de problemas, conformidade e planejamento de capacidade. Por exemplo, se você estiver executando um aplicativo de comércio eletrônico durante a alta temporada de festas, o sistema está sob carga mais pesada e podem surgir problemas que podem não ser imediatamente perceptíveis. Convém definir uma retenção de registros mais longa para solução de problemas detalhada e análise pós-evento.
Você pode configurar seus períodos de retenção no CloudWatch console da AWS ou na API da AWS com a duração de 1 dia a 10 anos com base em cada grupo de registros. Ter um período de retenção flexível pode economizar custos de armazenamento de registros e, ao mesmo tempo, manter registros críticos.
Opções de armazenamento de registros
O armazenamento é um grande fator de custos de observabilidade, portanto, é crucial otimizar sua estratégia de armazenamento de registros. Suas estratégias devem se alinhar aos requisitos de suas cargas de trabalho e, ao mesmo tempo, manter o desempenho e a escalabilidade. Uma estratégia para reduzir os custos de armazenamento de registros é aproveitar os buckets do AWS S3 e seus diferentes níveis de armazenamento.
Encaminhe os registros diretamente para o S3
Considere encaminhar registros menos críticos, como ambientes de desenvolvimento, diretamente para o S3 em vez do Cloudwatch. Isso pode ter um impacto imediato nos custos de armazenamento de registros. Uma opção é encaminhar os registros diretamente para o S3 usando o Fluentbit. Você define isso na [OUTPUT] seção, o destino onde FluentBit transmite os registros do contêiner para retenção. Revise os parâmetros de configurações adicionais aqui.
[OUTPUT]
Name eks_to_s3
Match application.*
bucket $S3_BUCKET name
region us-east-2
store_dir /var/log/fluentbit
total_file_size 30M
upload_timeout 3m
Encaminhar registros CloudWatch somente para análise de curto prazo
Para registros mais críticos, como ambientes de produção em que talvez seja necessário realizar análises imediatas dos dados, considere encaminhá-los para CloudWatch. Você define isso na [OUTPUT] seção, o destino onde FluentBit transmite os registros do contêiner para retenção. Revise os parâmetros de configurações adicionais aqui.
[OUTPUT]
Name eks_to_cloudwatch_logs
Match application.*
region us-east-2
log_group_name fluent-bit-cloudwatch
log_stream_prefix from-fluent-bit-
auto_create_group On
No entanto, isso não afetará instantaneamente sua economia de custos. Para economizar ainda mais, você precisará exportar esses registros para o Amazon S3.
Exportar para o Amazon S3 a partir de CloudWatch
Para armazenar CloudWatch registros da Amazon a longo prazo, recomendamos exportar seus CloudWatch registros do Amazon EKS para o Amazon Simple Storage Service (Amazon S3). Você pode encaminhar os registros para o bucket do Amazon S3 criando uma tarefa de exportação por meio do console ou da API. Depois de fazer isso, o Amazon S3 apresenta muitas opções para reduzir ainda mais os custos. Você pode definir suas próprias regras de ciclo de vida do Amazon S3 para mover seus registros para uma classe de armazenamento que atenda às suas necessidades ou aproveitar a classe de armazenamento Amazon S3 Intelligent-Tiering
Reduza os níveis de registro
Pratique o registro seletivo para seu aplicativo. Tanto seus aplicativos quanto os nós geram registros por padrão. Para os registros do seu aplicativo, ajuste os níveis de registro para se alinharem à criticidade da carga de trabalho e do ambiente. Por exemplo, o aplicativo java abaixo está gerando INFO registros, que é a configuração padrão típica do aplicativo e, dependendo do código, pode resultar em um alto volume de dados de log.
import org.apache.log4j.*; public class LogClass { private static org.apache.log4j.Logger log = Logger.getLogger(LogClass.class); public static void main(String[] args) { log.setLevel(Level.INFO); log.debug("This is a DEBUG message, check this out!"); log.info("This is an INFO message, nothing to see here!"); log.warn("This is a WARN message, investigate this!"); log.error("This is an ERROR message, check this out!"); log.fatal("This is a FATAL message, investigate this!"); } }
Em um ambiente de desenvolvimento, altere seu nível de registro paraDEBUG, pois isso pode ajudá-lo a depurar problemas ou detectar possíveis problemas antes que eles entrem em produção.
log.setLevel(Level.DEBUG);
Em um ambiente de produção, considere modificar seu nível de registro para ERROR ouFATAL. Isso produzirá o log somente quando o aplicativo tiver erros, reduzindo a saída do log e ajudando você a se concentrar em dados importantes sobre o status do aplicativo.
log.setLevel(Level.ERROR);
Você pode ajustar vários níveis de registro de componentes do Kubernetes. Por exemplo, se você estiver usando o Bottlerocketkubelet
[settings.kubernetes] log-level = "2" image-gc-high-threshold-percent = "85" image-gc-low-threshold-percent = "80"
Para um ambiente de desenvolvimento, você pode definir o nível de log maior que 2 para visualizar eventos adicionais. Isso é bom para depuração. Para um ambiente de produção, você pode definir o nível como 0 para visualizar somente eventos críticos.
Aproveite os filtros
Ao usar uma configuração padrão do EKS Fluentbit para enviar registros de contêiner para o Cloudwatch, FluentBit captura e envia TODOS os registros de contêineres de aplicativos enriquecidos com metadados do Kubernetes para o Cloudwatch, conforme mostrado no bloco de configuração abaixo. [INPUT]
[INPUT]
Name tail
Tag application.*
Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/kube-proxy*
Path /var/log/containers/*.log
Docker_Mode On
Docker_Mode_Flush 5
Docker_Mode_Parser container_firstline
Parser docker
DB /var/fluent-bit/state/flb_container.db
Mem_Buf_Limit 50MB
Skip_Long_Lines On
Refresh_Interval 10
Rotate_Wait 30
storage.type filesystem
Read_from_Head ${READ_FROM_HEAD}
A [INPUT] seção acima está ingerindo todos os registros do contêiner. Isso pode gerar uma grande quantidade de dados que talvez não sejam necessários. A filtragem desses dados pode reduzir a quantidade de dados de log enviados e CloudWatch , portanto, reduzir seus custos. Você pode aplicar um filtro aos seus registros antes que ele saia para CloudWatch. O Fluentbit define isso na [FILTER] seção. Por exemplo, impedir que os metadados do Kubernetes sejam anexados aos eventos de registro pode reduzir seu volume de registros.
[FILTER]
Name nest
Match application.*
Operation lift
Nested_under kubernetes
Add_prefix Kube.
[FILTER]
Name modify
Match application.*
Remove Kube.<Metadata_1>
Remove Kube.<Metadata_2>
Remove Kube.<Metadata_3>
[FILTER]
Name nest
Match application.*
Operation nest
Wildcard Kube.*
Nested_under kubernetes
Remove_prefix Kube.
Métricas
As métricas
Monitore o que importa e colete somente o que você precisa
A primeira estratégia de redução de custos é reduzir o número de métricas que você está coletando e, por sua vez, reduzir os custos de retenção.
-
Comece analisando seus requisitos e/ou os de suas partes interessadas para determinar as métricas mais importantes
. As métricas de sucesso são diferentes para cada pessoa! Saiba qual é a aparência bonita e meça para isso. -
Considere mergulhar profundamente nas cargas de trabalho que você está suportando e identificar seus principais indicadores de desempenho (KPIs), também conhecidos como “Sinais Dourados”. Eles devem estar alinhados aos requisitos dos negócios e das partes interessadas. Calcular SLIs e SLAs usar a Amazon CloudWatch e o Metric Math são cruciais para gerenciar a confiabilidade do serviço. SLOs Siga as melhores práticas descritas neste guia
para monitorar e manter com eficácia o desempenho do seu ambiente EKS. -
Em seguida, continue percorrendo as diferentes camadas da infraestrutura para conectar e correlacionar
o cluster, o nó e as métricas de infraestrutura adicionais do EKS à sua carga de trabalho KPIs. Armazene suas métricas de negócios e métricas operacionais em um sistema onde você possa correlacioná-las e tirar conclusões com base nos impactos observados em ambas. -
O EKS expõe métricas do plano de controle, cluster kube-state-metrics, pods e nós. A relevância de todas essas métricas depende de suas necessidades, mas é provável que você não precise de todas as métricas nas diferentes camadas. Você pode usar este guia de métricas essenciais do EKS
como base para monitorar a integridade geral de um cluster EKS e suas cargas de trabalho.
Aqui está um exemplo de configuração do prometheus scrape em que estamos usando o relabel_config para manter apenas as métricas do kubelet e eliminar todas as métricas do contêiner. metric_relabel_config
kubernetes_sd_configs: - role: endpoints namespaces: names: - kube-system bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true relabel_configs: - source_labels: [__meta_kubernetes_service_label_k8s_app] regex: kubelet action: keep metric_relabel_configs: - source_labels: [__name__] regex: container_(network_tcp_usage_total|network_udp_usage_total|tasks_state|cpu_load_average_10s) action: drop
Reduza a cardinalidade quando aplicável
Cardinalidade se refere à exclusividade dos valores dos dados em combinação com suas dimensões (por exemplo, rótulos prometheus) para um conjunto de métricas específico. Métricas de alta cardinalidade têm muitas dimensões e cada combinação métrica de dimensão tem maior exclusividade. Uma maior cardinalidade resulta em maior tamanho de dados de telemetria métrica e necessidades de armazenamento, o que aumenta o custo.
No exemplo de alta cardinalidade abaixo, vemos que a métrica, a latência, tem dimensões, requestid, customerID e serviço, e cada dimensão tem muitos valores exclusivos. Cardinalidade é a medida da combinação do número de valores possíveis por Dimensão. No Prometheus, cada conjunto de dimensões/rótulos exclusivos é considerado como uma nova métrica, portanto, alta cardinalidade significa mais métricas.
Em ambientes EKS com muitas métricas e dimensões/rótulos por métrica (cluster, namespace, serviço, pod, contêiner etc.), a cardinalidade tende a crescer. Para otimizar o custo, considere cuidadosamente a cardinalidade das métricas que você está coletando. Por exemplo, se você estiver agregando uma métrica específica para visualização no nível do cluster, poderá eliminar rótulos adicionais que estejam em uma camada inferior, como o rótulo do namespace.
Para identificar métricas de alta cardinalidade no prometheus, você pode executar a seguinte consulta PROMQL para determinar quais alvos de scrape têm o maior número de métricas (cardinalidade):
topk_max(5, max_over_time(scrape_samples_scraped[1h]))
e a consulta PROMQL a seguir pode ajudá-lo a determinar quais alvos de scrape têm as maiores taxas de rotatividade de métricas (quantas novas séries de métricas foram criadas em um determinado scrape):
topk_max(5, max_over_time(scrape_series_added[1h]))
Se você estiver usando o grafana, poderá usar o Mimirtool do Grafana Lab para analisar seus painéis do grafana e as regras do prometheus para identificar métricas de alta cardinalidade não utilizadas. Siga este guiamimirtool analyze prometheus comandos mimirtool analyze e para identificar métricas ativas que não são referenciadas em seus painéis.
Considere a granularidade métrica
Coletar métricas com maior granularidade, como a cada segundo versus cada minuto, pode ter um grande impacto na quantidade de telemetria coletada e armazenada, o que aumenta o custo. Determine intervalos sensatos ou de coleta de métricas que se equilibrem entre granularidade suficiente para detectar problemas transitórios e baixos o suficiente para serem econômicos. Diminua a granularidade das métricas usadas para planejamento de capacidade e análise de maior janela de tempo.
Importante
o intervalo global de raspagem do prometheus é definido como 15s. Esse intervalo de raspagem pode ser aumentado, resultando em uma diminuição na quantidade de dados métricos coletados no prometheus.
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: my-collector-amp
...
config: |
extensions:
sigv4auth:
region: "+++<YOUR_AWS_REGION>+++" service: "aps"+++</YOUR_AWS_REGION>+++
receivers:
#
# Scrape configuration for the Prometheus Receiver
# This is the same configuration used when Prometheus is installed using the community Helm chart
#
prometheus:
config:
global: scrape_interval: 15s
scrape_timeout: 10s
Rastreamento
O principal custo associado ao rastreamento decorre da geração de armazenamento de traços. Com o rastreamento, o objetivo é reunir dados suficientes para diagnosticar e entender os aspectos de desempenho. No entanto, como os custos dos rastreamentos do X-Ray são baseados nos dados encaminhados para o X-Ray, apagar os traços após o encaminhamento não reduzirá seus custos. Vamos analisar formas de reduzir seus custos de rastreamento e, ao mesmo tempo, manter os dados para que você realize a análise adequada.
Aplicar regras de amostragem
A taxa de amostragem do X-Ray é conservadora por padrão. Defina regras de amostragem nas quais você possa controlar a quantidade de dados coletados. Isso melhorará a eficiência do desempenho e reduzirá os custos. Ao diminuir a taxa de amostragem, você pode coletar rastreamentos da solicitação somente do que suas cargas de trabalho precisam, mantendo uma estrutura de custos mais baixa.
Por exemplo, você tem um aplicativo java que deseja depurar os rastreamentos de todas as solicitações de uma rota problemática.
Configure por meio do SDK para carregar regras de amostragem de um documento JSON
{ "version": 2, "rules": [ { "description": "debug-eks", "host": "*", "http_method": "PUT", "url_path": "/history/*", "fixed_target": 0, "rate": 1, "service_type": "debug-eks" } ], "default": { "fixed_target": 1, "rate": 0.1 } }
Por meio do console
Aplique o Tail Sampling com o AWS Distro for OpenTelemetry (ADOT)
O ADOT Tail Sampling permite que você controle o volume de traços ingeridos no serviço. No entanto, o Tail Sampling permite que você defina as políticas de amostragem após a conclusão de todos os períodos da solicitação, em vez de no início. Isso limita ainda mais a quantidade de dados brutos transferidos CloudWatch, reduzindo assim os custos.
Por exemplo, se você estiver coletando amostras de 1% do tráfego para uma página de destino e 10% das solicitações para uma página de pagamento, isso pode deixar 300 rastros por um período de 30 minutos. Com uma regra ADOT Tail Sampling que filtra erros específicos, você pode ficar com 200 traços, o que diminui o número de traços armazenados.
processors:
groupbytrace:
wait_duration: 10s
num_traces: 300
tail_sampling:
decision_wait: 1s # This value should be smaller than wait_duration
policies:
- ..... # Applicable policies**
batch/tracesampling:
timeout: 0s # No need to wait more since this will happen in previous processors
send_batch_max_size: 8196 # This will still allow us to limit the size of the batches sent to subsequent exporters
service:
pipelines:
traces/tailsampling:
receivers: [otlp]
processors: [groupbytrace, tail_sampling, batch/tracesampling]
exporters: [awsxray]
Aproveite as opções de armazenamento do Amazon S3
Você deve aproveitar o bucket AWS S3 e suas diferentes classes de armazenamento para armazenar os rastreamentos. Exporte rastreamentos para o S3 antes que o período de retenção expire. Use as regras de ciclo de vida do Amazon S3 para mover os dados de rastreamento para a classe de armazenamento que atenda aos seus requisitos.
Por exemplo, se você tiver rastros com 90 dias, o Amazon S3 Intelligent-Tiering
Recursos adicionais:
