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á.
# Registrar em log e monitorar no Amazon EKS
O Amazon Elastic Kubernetes Service (Amazon EKS) se CloudWatch integra aos registros do plano de controle do Kubernetes. O plano de controle é fornecido como um serviço gerenciado pelo Amazon EKS e você pode [ativar o registro sem instalar um CloudWatch agente](https://docs.aws.amazon.com//eks/latest/userguide/control-plane-logs.html). O CloudWatch agente também pode ser implantado para capturar registros de nós e contêineres do Amazon EKS. O [Fluent Bit e o Fluentd](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-logs.html) também são compatíveis para enviar seus registros de contêiner para o Logs. CloudWatch
CloudWatch O Container Insights fornece uma solução abrangente de monitoramento de métricas para o Amazon EKS nos níveis de cluster, nó, pod, tarefa e serviço. O Amazon EKS também oferece suporte a várias opções para captura de métricas com o [Prometheus.](https://prometheus.io/) O plano de controle do Amazon EKS [fornece um endpoint de métricas](https://docs.aws.amazon.com//eks/latest/userguide/prometheus.html) que expõe métricas no formato Prometheus. Você pode implantar o Prometheus em seu cluster Amazon EKS para consumir essas métricas.
Você também pode [configurar o CloudWatch agente para coletar métricas do Prometheus e criar CloudWatch métricas](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html), além de consumir outros endpoints do Prometheus. O [monitoramento do Container Insights para o Prometheus](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus.html) também pode descobrir e capturar automaticamente as métricas do Prometheus de cargas de trabalho e sistemas compatíveis e em contêineres.
Você pode instalar e configurar o CloudWatch agente nos nós do Amazon EKS, de forma semelhante à abordagem usada para o Amazon EC2 com o Distributor and State Manager, para alinhar os nós do Amazon EKS às configurações padrão de registro e monitoramento do sistema.
# Registro para Amazon EKS
O registro do Kubernetes pode ser dividido em registro do plano de controle, registro de nós e registro de aplicativos. O [plano de controle do Kubernetes](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) é um conjunto de componentes que gerenciam clusters do Kubernetes e produzem registros usados para fins de auditoria e diagnóstico. Com o Amazon EKS, você pode [ativar registros para diferentes componentes do plano de controle](https://docs.aws.amazon.com//eks/latest/userguide/control-plane-logs.html) e enviá-los para CloudWatch.
O Kubernetes também executa componentes do sistema, como `kubelet` e `kube-proxy` em cada nó do Kubernetes que executa seus pods. Esses componentes gravam registros em cada nó e você pode configurar o CloudWatch Container Insights para capturar esses registros para cada nó do Amazon EKS.
Os contêineres são agrupados como [pods](https://kubernetes.io/docs/concepts/workloads/pods/) em um cluster Kubernetes e estão programados para serem executados em seus nós do Kubernetes. A maioria dos aplicativos em contêineres grava na saída padrão e no erro padrão, e o mecanismo do contêiner redireciona a saída para um driver de registro. No Kubernetes, os registros do contêiner são encontrados no `/var/log/pods` diretório em um nó. Você pode configurar o CloudWatch Container Insights para capturar esses registros para cada um dos seus pods do Amazon EKS.
## Registro em log do ambiente de gerenciamento do Amazon EKS
Um cluster do Amazon EKS consiste em um plano de controle de locatário único e de alta disponibilidade para seu cluster Kubernetes e os nós do Amazon EKS que executam seus contêineres. Os nós do plano de controle são executados em uma conta gerenciada por AWS. Os nós do plano de controle do cluster Amazon EKS estão integrados CloudWatch e você pode ativar o registro em log para componentes específicos do plano de controle.
Os registros são fornecidos para cada instância do componente do plano de controle do Kubernetes. AWS gerencia a integridade dos nós do seu plano de controle e fornece um [acordo de nível de serviço (SLA) para o endpoint do](https://aws.amazon.com//eks/sla/) Kubernetes.
## Registro de nós e aplicativos do Amazon EKS
Recomendamos que você use o [CloudWatchContainer Insights](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs.html) para capturar registros e métricas para o Amazon EKS. O Container Insights implementa métricas em nível de cluster, nó e pod com o CloudWatch agente, além do Fluent Bit ou Fluentd para captura de registros. CloudWatch O Container Insights também fornece painéis automáticos com visualizações em camadas das métricas capturadas CloudWatch . O Container Insights é implantado como CloudWatch DaemonSet um Fluent Bit DaemonSet que é executado em todos os nós do Amazon EKS. Os nós Fargate não são compatíveis com o Container Insights porque os nós são gerenciados AWS e não oferecem suporte. DaemonSets O registro em Fargate para o Amazon EKS é abordado separadamente neste guia.
A tabela a seguir mostra os CloudWatch grupos de registros e os registros capturados pela [configuração padrão de captura de registros do Fluentd ou do Fluent Bit para o Amazon EKS](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html).
| | |
| --- |--- |
| /aws/containerinsights/Cluster\$1Name/application | Todos os arquivos de log são inseridos/var/log/containers. Esse diretório fornece links simbólicos para todos os registros de contêineres do Kubernetes na estrutura de diretórios. /var/log/pods Isso captura os registros do contêiner do aplicativo gravados em stdout oustderr. Também inclui registros para contêineres do sistema Kubernetesaws-vpc-cni-init, como, e. kube-proxy coreDNS |
| /aws/containerinsights/Cluster\$1Name/host | Registros de /var/log/dmesg/var/log/secure, /var/log/messages e. |
| /aws/containerinsights/Cluster\$1Name/dataplane | Os logs no /var/log/journal para kubelet.service, kubeproxy.service e docker.service. |
Se você não quiser usar o Container Insights com o Fluent Bit ou o Fluentd para registrar, você pode capturar registros de nós e contêineres com o CloudWatch agente instalado nos nós do Amazon EKS. Os nós do Amazon EKS são instâncias do EC2, o que significa que você deve incluí-los em sua abordagem padrão de registro em nível de sistema para o Amazon EC2. Se você instalar o CloudWatch agente usando o Distributor and State Manager, os nós do Amazon EKS também serão incluídos na instalação, configuração e atualização do CloudWatch agente.
A tabela a seguir mostra registros específicos do Kubernetes e que você deve capturar se não estiver usando o Container Insights com o Fluent Bit ou o Fluentd para registro em log.
| | |
| --- |--- |
| /var/log/containers | Esse diretório fornece links simbólicos para todos os registros de contêineres do Kubernetes na estrutura de diretórios. /var/log/pods Isso captura com eficácia os registros do contêiner do aplicativo gravados em stdout oustderr. Isso inclui registros para contêineres do sistema Kubernetesaws-vpc-cni-init, como, e. kube-proxy coreDNS Importante: Isso não é necessário se você estiver usando o Container Insights. |
| var/log/aws-routed-eni/ipamd.log/var/log/aws-routed-eni/plugin.log | Os registros do daemon L-IPAM podem ser encontrados aqui |
Você deve garantir que os nós do Amazon EKS instalem e configurem o CloudWatch agente para enviar registros e métricas apropriados no nível do sistema. No entanto, a AMI otimizada do Amazon EKS não inclui o agente Systems Manager. Usando [modelos de lançamento](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html), você pode automatizar a instalação do agente do Systems Manager e uma CloudWatch configuração padrão que captura registros importantes específicos do Amazon EKS com um script de inicialização implementado por meio da seção de dados do usuário. Os nós do Amazon EKS são implantados usando um grupo Auto Scaling como [um grupo de nós gerenciados ou [como](https://docs.aws.amazon.com//eks/latest/userguide/worker.html) nós](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-groups.html) autogerenciados.
Com grupos de nós gerenciados, você fornece um [modelo de execução](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html) que inclui a seção de dados do usuário para automatizar a instalação e a CloudWatch configuração do agente do Systems Manager. Você pode personalizar e usar o modelo [amazon\$1eks\$1managed\$1node\$1group\$1launch\$1config.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon_eks_managed_node_group_launch_config.yaml) para criar um CloudFormation modelo de execução que instala o agente e o agente do Systems Manager e também adiciona uma configuração de log específica do Amazon EKS ao diretório de configuração. CloudWatch CloudWatch Esse modelo pode ser usado para atualizar seu modelo de lançamento de grupos de nós gerenciados do Amazon EKS com uma abordagem infrastructure-as-code (IaC). Cada atualização do CloudFormation modelo fornece uma nova versão do modelo de lançamento. Em seguida, você pode atualizar o grupo de nós para usar a nova versão do modelo e fazer com que o [processo de ciclo de vida gerenciado](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-update-behavior.html) atualize seus nós sem tempo de inatividade. Certifique-se de que a função e o perfil da instância do IAM aplicados ao seu grupo de nós gerenciados incluam as políticas `AmazonSSMManagedInstanceCore` AWS gerenciadas `CloudWatchAgentServerPolicy` e.
Com os nós autogerenciados, você provisiona e gerencia diretamente o ciclo de vida e a estratégia de atualização dos seus nós do Amazon EKS. [Os nós autogerenciados permitem que você execute nós do Windows em seu cluster Amazon EKS e no [Bottlerocket](https://aws.amazon.com//bottlerocket/), junto com outras opções.](https://docs.aws.amazon.com//eks/latest/userguide/eks-compute.html) Você pode usar CloudFormation para implantar nós autogerenciados em seus clusters do Amazon EKS, o que significa que você pode usar uma abordagem de IaC e mudança gerenciada para seus clusters do Amazon EKS. AWS fornece o CloudFormation modelo [amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml) que você pode usar como está ou personalizar. O modelo provisiona todos os recursos necessários para os nós do Amazon EKS em um cluster (por exemplo, uma função separada do IAM, um grupo de segurança, um grupo do Amazon EC2 Auto Scaling e um modelo de lançamento). O CloudFormation modelo [amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml) é uma versão atualizada que instala o agente e o agente necessários do Systems Manager e também adiciona uma configuração de log específica do Amazon EKS ao CloudWatch diretório de configuração. CloudWatch
## Registro para Amazon EKS no Fargate
Com o Amazon EKS no Fargate, você pode implantar pods sem alocar ou gerenciar seus nós do Kubernetes. Isso elimina a necessidade de capturar registros em nível de sistema para seus nós do Kubernetes. Para capturar os registros de seus pods Fargate, você pode usar o FluentBit para encaminhá-los diretamente para o. CloudWatch Isso permite que você encaminhe automaticamente os registros CloudWatch sem configuração adicional ou um contêiner auxiliar para seus pods do Amazon EKS no Fargate. Para obter mais informações sobre isso, consulte [Fargate logging](https://docs.aws.amazon.com//eks/latest/userguide/fargate-logging.html) na documentação do Amazon EKS e [Fluent Bit for Amazon EKS no blog](https://aws.amazon.com//blogs/containers/fluent-bit-for-amazon-eks-on-aws-fargate-is-here/). AWS Essa solução captura os fluxos `STDOUT` e `STDERR` input/output (E/S) do seu contêiner e os envia CloudWatch por meio do Fluent Bit, com base na configuração do Fluent Bit estabelecida para o cluster Amazon EKS no Fargate.
# Métricas para Amazon EKS e Kubernetes
O Kubernetes fornece uma API de métricas que permite acessar métricas de uso de recursos (por exemplo, uso de CPU e memória para nós e pods), mas a API fornece apenas point-in-time informações e não métricas históricas. [O servidor de [métricas do Kubernetes é](https://github.com/kubernetes-sigs/metrics-server) normalmente usado para implantações do Amazon EKS e do Kubernetes para agregar métricas, fornecer informações históricas de curto prazo sobre métricas e oferecer suporte a recursos como o Horizontal Pod Autoscaler.](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)
O Amazon EKS expõe métricas do plano de controle por meio do servidor de API Kubernetes em [formato Prometheus](https://docs.aws.amazon.com//eks/latest/userguide/prometheus.html) e pode capturar e ingerir essas métricas. CloudWatch CloudWatch e o Container Insights também podem ser configurados para fornecer captura, análise e alarme abrangentes de métricas para seus nós e pods do Amazon EKS.
## Métricas do plano de controle do Kubernetes
O Kubernetes expõe as métricas do plano de controle no formato Prometheus usando o endpoint da API HTTP. `/metrics` Você deve instalar o [Prometheus](https://prometheus.io/) em seu cluster Kubernetes para representar graficamente e visualizar essas métricas com um navegador da web. Você também pode [ingerir as métricas expostas pelo servidor](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html#ContainerInsights-Prometheus-Setup-new-exporters) da API Kubernetes em. CloudWatch
## Métricas de nós e sistemas para Kubernetes
O Kubernetes fornece o pod de [servidor de métricas](https://github.com/kubernetes-sigs/metrics-server) Prometheus que você pode [implantar e executar em seus clusters Kubernetes para estatísticas de CPU e memória](https://docs.aws.amazon.com//eks/latest/userguide/metrics-server.html) em nível de cluster, nó e pod. Essas métricas são usadas com o escalador automático de [pods horizontais e o autoescalador](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) de [pods verticais](https://docs.aws.amazon.com/eks/latest/userguide/vertical-pod-autoscaler.html). CloudWatch também pode fornecer essas métricas.
Você deve instalar o Kubernetes Metrics Server se usar o [Kubernetes Dashboard ou os autoescaladores](https://github.com/kubernetes/dashboard) de pod horizontais e verticais. O Painel do Kubernetes ajuda você a navegar e configurar seu cluster, nós, pods e configurações relacionadas do Kubernetes, além de visualizar as métricas de CPU e memória do Kubernetes Metrics Server.
As métricas fornecidas pelo Kubernetes Metrics Server não podem ser usadas para fins que não sejam de escalonamento automático (por exemplo, monitoramento). As métricas são destinadas à point-in-time análise e não à análise histórica. O Kubernetes Dashboard implanta o `dashboard-metrics-scraper` para armazenar métricas do Kubernetes Metrics Server por um curto período de tempo.
O Container Insights usa uma versão em contêiner do CloudWatch agente que é executada em um Kubernetes DaemonSet para descobrir todos os contêineres em execução em um cluster e fornecer métricas em nível de nó. Ele coleta dados de desempenho em cada camada da pilha de desempenho. Você pode usar o Quick Start em AWS Quick Starts ou configurar o Container Insights separadamente. O Quick Start configura o monitoramento de métricas com o CloudWatch agente e o registro com o Fluent Bit, então você só precisa implantá-lo uma vez para registrar e monitorar.
Como os nós do Amazon EKS são instâncias do EC2, você deve capturar métricas em nível de sistema, além das métricas capturadas pelo Container Insights, usando os padrões que você definiu para o Amazon EC2. Você pode usar a mesma abordagem da [Configurar o State Manager and Distributor para implantação e configuração do CloudWatch agente](install-cloudwatch-systems-manager.md#set-up-systems-manager-distributor) seção deste guia para instalar e configurar o CloudWatch agente para seus clusters do Amazon EKS. Você pode atualizar seu arquivo de CloudWatch configuração específico do Amazon EKS para incluir métricas, bem como sua configuração de log específica do Amazon EKS.
[O CloudWatch agente com suporte do Prometheus pode descobrir e extrair automaticamente as métricas do Prometheus a partir de cargas de trabalho e sistemas compatíveis e em contêineres.](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus.html) Ele os ingere como CloudWatch registros em formato métrico incorporado para análise com o CloudWatch Logs Insights e cria CloudWatch métricas automaticamente.
**Importante**
Você deve [implantar uma versão especializada](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup.html#ContainerInsights-Prometheus-Setup-install-agent) do CloudWatch agente para coletar métricas do Prometheus. Esse é um agente separado do CloudWatch agente implantado para o Container Insights. Você pode usar o aplicativo Java de amostra [prometheus\$1jmx](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/tree/main/examples/eks/prometheus_jmx), que inclui os arquivos de implantação e configuração do agente CloudWatch e a implantação do pod Amazon EKS para demonstrar a descoberta das métricas do Prometheus. Para obter mais informações, consulte [Configurar Java/JMX amostra de carga de trabalho no Amazon EKS e no Kubernetes](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Sample-Workloads-javajmx.html) na documentação. CloudWatch Você também pode configurar o CloudWatch agente para capturar métricas de outros destinos do Prometheus em execução no seu cluster Amazon EKS.
## Métricas da aplicação
Você pode criar suas próprias métricas personalizadas com o [formato métrico CloudWatch incorporado.](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) Para ingerir instruções de formato métrico incorporado, você precisa enviar entradas de formato métrico incorporado para um endpoint de formato métrico incorporado. O CloudWatch agente pode ser configurado como um [contêiner auxiliar em seu pod Amazon EKS](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Generation_CloudWatch_Agent.html). A configuração do CloudWatch agente é armazenada como um Kubernetes ConfigMap e lida pelo contêiner auxiliar do CloudWatch agente para iniciar o endpoint de formato métrico incorporado.
Você também pode configurar seu aplicativo como um alvo do Prometheus e configurar o agente, com CloudWatch o suporte do Prometheus, para descobrir, extrair e ingerir suas métricas. CloudWatch Por exemplo, você pode usar o [exportador JMX de código aberto com seus aplicativos Java para expor](https://github.com/prometheus/jmx_exporter) os JMX Beans para o consumo do Prometheus pelo agente. CloudWatch
Se você não quiser usar o formato de métrica incorporada, você também pode criar e atualizar CloudWatch métricas usando a [AWS API](https://docs.aws.amazon.com//AmazonCloudWatch/latest/APIReference/Welcome.html) ou o [AWS SDK](https://aws.amazon.com/developer/tools/). No entanto, não recomendamos essa abordagem porque ela combina o monitoramento e a lógica do aplicativo.
## Métricas para o Amazon EKS no Fargate
O Fargate provisiona automaticamente os nós do Amazon EKS para executar seus pods do Kubernetes, para que você não precise monitorar e coletar métricas em nível de nó. No entanto, você deve monitorar as métricas dos pods em execução nos nós do Amazon EKS no Fargate. Atualmente, o Container Insights não está disponível para o Amazon EKS no Fargate porque requer os seguintes recursos que não são compatíveis atualmente:
+ DaemonSets não são compatíveis atualmente. O Container Insights é implantado executando o CloudWatch agente como um DaemonSet em cada nó do cluster.
+ HostPath volumes persistentes não são suportados. O contêiner do CloudWatch agente usa volumes persistentes do HostPath como pré-requisito para coletar dados métricos do contêiner.
+ O Fargate impede contêineres privilegiados e o acesso às informações do host.
Você pode usar o [roteador de log integrado do Fargate para](https://docs.aws.amazon.com//eks/latest/userguide/fargate-logging.html) enviar instruções de formato métrico incorporado para. CloudWatch O roteador de log usa o Fluent Bit, que tem um CloudWatch plug-in que pode ser configurado para suportar instruções de formato métrico incorporado.
Você pode recuperar e capturar métricas em nível de pod para seus nós Fargate implantando o servidor Prometheus em seu cluster Amazon EKS para coletar métricas de seus nós Fargate. Como o Prometheus exige armazenamento persistente, você pode implantá-lo no Fargate usando o Amazon Elastic File System (Amazon EFS) para armazenamento persistente. Você também pode implantar o Prometheus em um nó com suporte do Amazon EC2. Para obter mais informações, consulte [Monitoramento do Amazon EKS sobre AWS Fargate o uso do Prometheus e](https://aws.amazon.com//blogs/containers/monitoring-amazon-eks-on-aws-fargate-using-prometheus-and-grafana/) do Grafana no blog. AWS