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á.
# Entendendo os dados de alocação de custos divididos
Você pode usar os relatórios de custo e uso (AWS CUR) para rastrear seus custos de contêineres do Amazon ECS e do Amazon EKS. Usando dados de alocação de custos divididos, você pode alocar seus custos de contêiner em unidades de negócios e equipes individuais, com base em como suas workloads de contêiner consomem recursos compartilhados de computação e memória. Os dados de alocação de custos divididos introduzem dados de custo e uso de novos recursos em nível de contêiner (ou seja, tarefas do ECS e pods do Kubernetes) no CUR. AWS Anteriormente, o AWS CUR só suportava custos no nível da instância do EC2. Os dados de alocação de custos divididos geram custos em nível de contêiner ao analisar o consumo de recursos da instância do EC2 de cada contêiner e geram custos com base no custo amortizado da instância e na porcentagem de recursos de CPU e memória consumidos pelos contêineres executados na instância.
Para instâncias com computação acelerada usadas com o Amazon EKS, os dados de alocação de custos divididos incluem alocação de recursos para processadores especializados junto com CPU e memória. Isso abrange os aceleradores NVIDIA e AMD GPUs, AWS Trainium e AWS Inferentia. O recurso está disponível somente para ambientes Amazon EKS e fornece dados de reserva de recursos em nível de pod para esses recursos com computação acelerada. Isso permite acompanhar e alocar custos para workloads que usam esses processadores especializados, como aplicações de IA/ML e outras tarefas de uso intenso de computação. Para ver uma lista atual de instâncias com computação acelerada, consulte [Computação acelerada.](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
Os dados de alocação de custos divididos introduzem novos registros de uso e novas colunas de métricas de custo para cada ID de recurso em contêiner (ou seja, tarefa do ECS e pod do Kubernetes) no CUR. AWS Para obter mais informações, consulte [Detalhes do item de linha dividida](https://docs.aws.amazon.com/cur/latest/userguide/split-line-item-columns.html).
Ao incluir dados de alocação de custos divididos no AWS CUR, dois novos registros de uso são adicionados para cada tarefa do ECS e pod do Kubernetes por hora para refletir os custos de CPU e memória. Para estimar o número de novos itens de linha em AWS CUR por dia, use a seguinte fórmula:
Para ECS: `(number of tasks * average task lifetime * 2) * 24`
Para EKS: `(number of pods * average pod lifetime * 2) * 24`
Por exemplo, se você tiver 1.000 pods em execução a cada hora em um cluster de 10 instâncias do EC2 e a vida útil do pod for inferior a 1 hora, então:
`(1000 * 1 * 2) * 24 = 48,000 new usage records in AWS CUR`
Em relação a instâncias com computação acelerada no Amazon EKS, três novos registros de uso foram adicionados para cada pod do Kubernetes por hora a fim de exibir os custos do acelerador, da CPU e da memória. Para estimar o número de novos itens de linha em AWS CUR por dia, use a seguinte fórmula:
Em relação ao EKS com computação acelerada: `(number of pods * average pod lifetime * 3) * 24`
Por exemplo, se você tiver mil pods em execução a cada hora em um cluster de dez instâncias do EC2 e o valor de permanência de cada pod for inferior a uma hora, então: `(1000 * 1 * 3) * 24 = 72,000 new usage records in AWS CUR`
**nota**
Para ECS: quando se trata de tags de alocação de AWS custos, você pode usar tags gerenciadas pelo Amazon ECS ou tags adicionadas pelo usuário para seus relatórios de custo e uso. Essas tags se aplicam a todos os novos registros de uso de dados de alocação de custos divididos do ECS. Para obter mais informações, consulte [Como marcar os seus recursos para o faturamento](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html#tag-resources-for-billing).
Para EKS: dados de alocação de custos divididos criam novas tags de alocação de custos para alguns atributos do Kubernetes. Essas tags incluem `aws:eks:cluster-name`, `aws:eks:deployment`, `aws:eks:namespace`, `aws:eks:node`, `aws:eks:workload-name` e `aws:eks:workload-type`.
`aws:eks:cluster-name`, `aws:eks:namespace` e `aws:eks:node` são preenchidos retrospectivamente com os nomes do cluster, namespace e nó.
`aws:eks:workload-type` só será preenchido se houver exatamente um workload gerenciando o pod e for um dos workloads integrados. Os tipos de workload incluem `ReplicaSet`, `StatefulSet`, `Job`, `DaemonSet` ou `ReplicationController` e `aws:eks:workload-name` inclui o nome da workload. Para obter mais informações, consulte [Workloads](https://kubernetes.io/docs/concepts/workloads/) na *documentação do Kubernetes*.
`aws:eks:deployment` só é preenchido para o tipo de workload `ReplicaSet`. É a implantação que cria um `ReplicaSet`.
Essas tags se aplicam a todos os novos registros de uso de dados de alocação de custos divididos do EKS. Essas tags são habilitadas para alocação de custos por padrão. Se você usou e desabilitou a tag `aws:eks:cluster-name` anteriormente, os dados de alocação de custos divididos manterão essa configuração e não habilitarão a tag. Você pode habilitá-la na página do console [Tags de alocação de custos](https://console.aws.amazon.com/billing/home#/tags).
# Habilitar dados de alocação de custos divididos
**nota**
Os dados de alocação de custos divididos não estão disponíveis no Cost Explorer. Eles estão disponíveis nos Relatórios de Custos e Uso (CUR) antigos e no Relatório de Custos e Uso (CUR 2.0) com exportações de dados.
É um pré-requisito aceitar os dados de alocação de custos divididos por meio das preferências de gerenciamento de custos.
**Como optar por dividir os dados de alocação de custos**
1. Abra o console de Gerenciamento de Faturamento e Custos em [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. No painel de navegação, escolha **Preferência de gerenciamento de custos**.
1. Em **Geral**, na seção **Dados de alocação de custos divididos**, escolha entre as seguintes opções:
+ **Amazon Elastic Container Service (Amazon ECS)** para aceitar somente o Amazon ECS.
+ **Amazon Elastic Kubernetes Service (Amazon EKS)** para aceitar somente o Amazon EKS. Para o Amazon EKS, escolha uma das seguintes opções:
+ **Solicitações de recursos**: aloca seu Amazon EC2 somente pelos recursos de CPU e memória do pod do Kubernetes. Isso incentivará as equipes de aplicações a provisionar apenas o que precisam.
+ **Amazon Managed Service for Prometheus**: aloca seus custos do Amazon EC2 pelo que for maior entre solicitações de recursos de CPU e memória do pod do Kubernetes e utilização real. Isso garante que cada equipe de aplicações pague pelo que usa. Para saber mais sobre a configuração do Amazon Managed Service for Prometheus, consulte [Configuração](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-setting-up.html) no *Guia do usuário do Amazon Managed Service for Prometheus*.
Pré-requisito: Você deve habilitar todos os recursos no. AWS Organizations Para obter mais detalhes, consulte [Habilitar todos os atributos na sua organização](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) no *Guia do usuário do Organizations*.
+ **Amazon CloudWatch Container Insights**: isso fornece uma visibilidade de custo mais granular para seus clusters que executam vários contêineres de aplicativos usando instâncias EC2 compartilhadas, permitindo uma melhor alocação de custos para os custos compartilhados de seus clusters EKS.
**nota**
Somente contas regulares e pagadoras têm acesso às AWS Cost Management preferências e podem optar por dividir os dados de alocação de custos. Depois de cadastradas, as contas de membros podem visualizar os dados nos relatórios de custos e uso.
Se você escolher solicitações de recursos, somente os pods configurados com solicitações de memória e CPU serão usados pelos dados de alocação de custos divididos. Os pods que não solicitaram nenhum uso não verão nenhum dado de custo dividido.
Se você escolher o Amazon Managed Service for Prometheus, precisará habilitar todos os recursos em Organizations. AWS Para obter mais informações, consulte [Habilitar todos os atributos na sua organização](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html). Além disso, os dados de alocação de custos divididos criam um novo perfil vinculado a serviços, que permite o acesso a serviços e recursos da AWS usados ou gerenciados por dados de alocação de custos divididos.
Em relação a instâncias com computação acelerada, somente a opção de solicitação de recursos é aceita. Nem o Amazon Managed Service for Prometheus nem o CloudWatch Amazon Container Insights são compatíveis com essas instâncias. Ao usar instâncias com computação acelerada, o sistema usará como padrão a solicitação de recursos a fim de calcular os custos do acelerador de computação, da CPU e da memória, mesmo se outras opções de medição estiverem habilitadas.
Depois de se inscrever, você pode optar por incluir dados de custos e uso de recursos em nível de contêiner em seu relatório durante a primeira etapa da criação do relatório ou, posteriormente, editando os detalhes do relatório.
**Como incluir dados de custo e uso em seu relatório**
1. Abra o console de Gerenciamento de Faturamento e Custos em [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. No painel de navegação, em **Páginas legadas**, escolha **Relatórios de Custos e Uso**.
1. Seja criando um novo relatório ou editando um relatório existente, na página **Especificar detalhes do relatório**, em **Conteúdo do relatório**, selecione **Dividir dados de alocação de custos**.
**nota**
Você também pode usar a API AWS CUR ou a AWS Command Line Interface (CLI) para gerenciar suas preferências de dados de alocação de custos divididos.
Os dados de alocação de custos divididos permitem a visibilidade dos custos de todos os objetos de contêiner do Amazon ECS e do Amazon EKS em toda a sua família de faturamento consolidado (contas pagantes e vinculadas). Depois de ativados, os dados de alocação de custos divididos examinam automaticamente as tarefas e os contêineres. Ele consome os dados de uso da telemetria para suas workloads de contêiner e prepara os dados de custo granulares para o mês atual.
**nota**
Pode levar até 24 horas para que os dados fiquem visíveis no AWS CUR.
Para obter informações sobre como gerenciar o acesso às páginas do console do Gerenciamento de Faturamento e Custos, consulte [Overview of managing access permissions](https://docs.aws.amazon.com/cost-management/latest/userguide/control-access-billing.html).
Para obter informações sobre AWS Cost Management preferências e controle do acesso ao Cost Explorer, consulte [Controlando o acesso ao Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html).
# Exemplo de dados de alocação de custos divididos
O objetivo do exemplo a seguir é mostrar como os dados de alocação de custos divididos são computados calculando o custo de serviços individuais do ECS, tarefas em clusters do Amazon ECS, namespace e pods do Kubernetes em clusters do Amazon EKS. As taxas usadas em todo o exemplo são apenas para fins ilustrativos.
**nota**
O exemplo demonstra o namespace e os pods do Kubernetes em execução nos clusters do Amazon EKS. Em seguida, podemos aplicar o mesmo modelo de custo ao serviço e às tarefas do Amazon ECS executados em um cluster do Amazon ECS.
Você tem o seguinte uso em uma única hora:
+ Cluster compartilhado de instância única (m5.xlarge) com dois namespaces e quatro pods, em execução por uma hora inteira.
+ A configuração da instância é de 4 vCPUs e 16 GB de memória.
+ O custo amortizado da instância é de USD 1/hora.
Os dados de alocação de custos divididos usam pesos unitários relativos para CPU e memória com base em uma proporção de 9:1. Isso é derivado dos preços por vCPU por hora e por GB por hora no [AWS Fargate](https://aws.amazon.com/fargate/pricing/).
## Etapa 1: Calcular o custo unitário da CPU e da memória
`Unit-cost-per-resource = Hourly-instance-cost/((Memory-weight * Memory-available) + (CPU-weight * CPU-available))`
= USD 1/( (1 \$1 16GB) \$1 (9 \$1 4vCPU)) = USD 0,02
`Cost-per-vCPU-hour = CPU-weight * Unit-cost-per-resource`
= 9 \$1 USD 0,02 = USD 0,17
`Cost-per-GB-hour = Memory-weight * Unit-cost-per-resource`
= 1 \$1 USD 0,02 = USD 0,02
****
| Instance | Instance type | vCPU-available | Memory-available | Amortized-cost-per-hour | Cost-per-vCPU-hour | Cost-per-GB-hour |
| --- | --- | --- | --- | --- | --- | --- |
| Instance1 | m5.xlarge | 4 | 16 | \$11 | 0,17 US\$1 | \$10,02 |
## Etapa 2: Calcular a capacidade alocada e a capacidade não utilizada da instância
+ Capacidade alocada: a memória e a vCPU alocadas para o pod do Kubernetes a partir da instância do EC2 principal, definida como a capacidade máxima usada e reservada.
**nota**
Se os dados de uso da memória ou da vCPU não estiverem disponíveis, os dados de reserva serão usados em vez disso. Para obter mais informações, consulte [Relatórios de uso do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/usage-reports.html) ou [Monitoramento de custos do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/cost-monitoring.html).
+ Capacidade não utilizada da instância: a capacidade não utilizada da vCPU e da memória.
`Pod1-Allocated-vCPU = Max (1 vCPU, 0.1 vCPU)` = 1 vCPU
`Pod1-Allocated-memory = Max (4 GB, 3 GB)` = 4 GB
`Instance-Unused-vCPU = Max (CPU-available - SUM(Allocated-vCPU), 0)`= Máx (4-4,9, 0) = 0
`Instance-Unused-memory = Max (Memory-available - SUM(Allocated-memory), 0)`= Máx (16-14, 0) = 2 GB
Neste exemplo, a instância tem CPU acima da assinatura, atribuída a Pod2, que usou mais vCPU do que o reservado.
****
| Pod name | Namespace | Reserved-vCPU | Used-vCPU | Allocated-vCPU | Reserved-memory | Used-memory | Allocated-memory |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | 1 | 0,1 | 1 | 4 | 3 | 4 |
| Pod2 | Namespace2 | 1 | 1.9 | 1.9 | 4 | 6 | 6 |
| Pod3 | Namespace1 | 1 | 0,5 | 1 | 2 | 2 | 2 |
| Pod4 | Namespace2 | 1 | 0,5 | 1 | 2 | 2 | 2 |
| Unused | Unused | | | 0 | | | 2 |
| | | | | 4,9 | | | 16 |
## Etapa 3: Calcular as taxas de uso divididas
+ Taxa de uso dividida: a porcentagem de CPU ou memória usada pelo pod do Kubernetes em comparação com a CPU ou a memória geral disponível na instância do EC2.
+ Proporção não utilizada: a porcentagem de CPU ou memória usada pelo pod do Kubernetes em comparação com a CPU ou memória geral usada na instância do EC2 (ou seja, sem considerar a CPU ou a memória não utilizadas na instância).
`Pod1-vCPU-split-usage-ratio = Allocated-vCPU / Total-vCPU`
= 1 vCPU / 4,9vCPU = 0,204
`Pod1-Memory-split-usage-ratio = Allocated-GB / Total-GB`
= 4 GB/ 16 GB = 0,250
`Pod1-vCPU-unused-ratio = Pod1-vCPU-split-usage-ratio / (Total-CPU-split-usage-ratio – Instance-unused-CPU)`(definido como 0 se Instance-unused-CPU for 0)
= 0 (já que Instance-unused-CPU é 0)
`Pod1-Memory-unused-ratio = Pod1-Memory-split-usage-ratio / (Total-Memory-split-usage-ratio – Instance-unused-memory)`(definido como 0 se Instance-unused-memory for 0)
= 0,250 / (1-0,125) = 0,286
****
| Pod name | Namespace | vCPU-split-usage-ratio | vCPU-unused-ratio | Memory-split-usage-ratio | Memory-unused-ratio |
| --- | --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | 0,204 | 0 | 0,250 | 0,286 |
| Pod2 | Namespace2 | 0,388 | 0 | 0,375 | 0,429 |
| Pod3 | Namespace1 | 0,204 | 0 | 0.125 | 0.143 |
| Pod4 | Namespace2 | 0,204 | 0 | 0.125 | 0.143 |
| Unused | Unused | 0 | | 0.125 | |
| | | 1 | | 1 | |
## Etapa 4: Calcular o custo dividido e os custos não utilizados
+ Custo dividido: a alocação do custo de pagamento por uso do custo da instância do EC2 com base no uso de CPU e memória alocados pelo pod do Kubernetes.
+ Custo da instância não utilizada: o custo dos recursos de CPU ou memória não utilizados na instância.
`Pod1-Split-cost = (Pod1-vCPU-split-usage-ratio * vCPU-available * Cost-per-vCPU-hour) + (Pod1-Memory-split-usage-ratio * Memory-available * Cost-per-GB-hour)`
= (0,204 \$1 4 vCPU \$1 USD 0,17) \$1 (0,25 \$1 16GB \$1 USD 0,02) = USD 0,22
`Pod1-Unused-cost = (Pod1-vCPU-unused-ratio * Instance-vCPU-unused-ratio * vCPU-available * Cost-per-VCPU-hour) + (Pod1-Memory-unused-ratio * Instance-Memory-unused ratio * Memory-available * Cost-per-GB-hour)`
= (0 \$1 0 \$1 4 \$1 USD 0,17) \$1 (0,286 \$1 0,125 \$1 16 \$1 USD 0,02) = USD 0,01
`Pod1-Total-split-cost = Pod1-Split-cost + Pod1-Unused-cost`
= USD 0,23
****
| Pod name | Namespace | Split-cost | Unused-cost | Total-split-cost |
| --- | --- | --- | --- | --- |
| Pod1 | Namespace1 | \$10,22 | \$10,01 | \$10,23 |
| Pod2 | Namespace2 | \$10,38 | \$10,02 | \$10,40 |
| Pod3 | Namespace1 | 0,18 US\$1 | \$10,01 | 0,19 US\$1 |
| Pod4 | Namespace2 | 0,18 US\$1 | \$10,01 | 0,19 US\$1 |
| Unused | Unused | \$10,04 | | |
| | | \$11 | \$10,04 | \$11 |
O custo do serviço é a soma do custo dos pods associados a cada namespace.
Custo total do Namespace1 = USD 0,23 \$1 USD 0,19 = USD 0,42
Custo total do Namespace2 = USD 0,40 \$1 USD 0,19 = USD 0,59
## Amostra AWS CUR
Se seu Savings Plans cobrir todo o uso da instância do EC2 no período de cobrança, os custos amortizados serão calculados usando savingsPlan/SavingsPlanEffectiveCost.
![\[Table showing EC2 instance usage details with Savings Plans and cost breakdown.\]](http://docs.aws.amazon.com/pt_br/cur/latest/userguide/images/savings-plan-entire-usage.png)
Se você tiver um Savings Plans cobrindo o uso parcial da instância do EC2 no período de cobrança e o restante do uso da instância do EC2 for cobrado de acordo com taxas sob demanda, os custos amortizados da instância do EC2 serão calculados usando savingsPlan/SavingsPlanEffectiveCost (para) \$1 (para SavingsPlanCoveredUsage uso sob demanda). lineItem/UnblendedCost
![\[Table showing EC2 instance usage details, costs, and savings plan information.\]](http://docs.aws.amazon.com/pt_br/cur/latest/userguide/images/savings-plan-partial-usage.png)
# Exemplo de dados de alocação de custos divididos para instâncias aceleradas
O objetivo do exemplo a seguir é mostrar como os dados de alocação de custos divididos são computados calculando o custo do namespace e pods do Kubernetes em clusters no Amazon EKS. As taxas usadas em todo o exemplo são apenas para fins ilustrativos.
Você tem o seguinte uso em uma única hora:
+ Instância única do EC2 que executa quatro pods em dois namespaces, e você quer entender os custos de cada namespace.
+ A instância do EC2 é p3.16xlarge com 8 GPUs, 64 vCPUs e 488 GB de RAM.
+ O custo amortizado da instância é de 10 USD/hora.
Os dados de alocação de custos divididos normalizam o custo por recurso com base em uma proporção relativa de GPU: (cpu: memória) de 9:1. Isso implica que uma unidade de GPU custa 9x mais do que uma unidade de CPU e memória. A CPU e a memória recebem então um peso de 9:1. Em relação a uma instância do EC2 não acelerada, o comportamento padrão atual será adotado, que é cpu: o peso da memória é padronizado como 9:1.
## Etapa 1: calcular o custo unitário
Com base nos recursos de CPU e memória na instância do EC2 e usando a proporção mencionada acima, os dados de alocação de custos divididos calculam primeiro o custo unitário por GPU, vCPU-HR e GB-h.
`GPU-Weight =9`
`GPU+Memory-Weight =1`
`CPU-Weight=1*.9=.9`
`Memory-Weight=1*0.1=0.1`
`Hourly-Instance-Cost=$10`
`GPU-Available=8`
`Memory-Available=488`
`CPU-Available=64`
`UnitCostPerResource = Hourly-Instance-Cost/(( GPU-Weight * GPU-Available) + (Memory-Weight * Memory-Available) + (CPU-Weight * CPU-Available)) = $10/((9*8gpu)+ (0.1 * 488GB) + (.9 * 64vcpu)) = $0.056`
`Cost-per-GPU-Hour = GPU-Weight * UnitCostPerResource = 9 * $0.056 = $0.504`
`Cost-per-vcpu-Hour = CPU-Weight * UnitCostPerResource = .9 * $0.056 = $0.05`
`Cost-per-GB-Hour = Memory-Weight * UnitCostPerResource = .1 * $0.056 = $0.00506`
**Tabela 1: Cálculo do custo unitário**
| Instância | Tipo de instância | vCPU disponível | GPU disponível | \$1\$1 | Memória disponível | Custo amortizado por hora | Custo por vCPU por hora | Custo por GPU por hora | Custo por GB por hora |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Instância 1 | p3.16xlarge | 64 | 8 | | 488 | \$110 | 0,05 USD | \$10,50 | 0.005 |
## Etapa 2: calcular a capacidade alocada e não utilizada
Capacidade alocada
A GPU, a vcpu e a memória alocadas ao pod do Kubernetes por meio da instância do EC2 principal, definida como a capacidade máxima (usada e reservada).
Capacidade não utilizada da instância
A capacidade não utilizada da GPU, vcpu e memória
`Pod1-Allocated-GPU = Max (1 GPU, 1 GPU) = 1 GPU`
`Pod1-Allocated-vcpu = Max (16 vcpu, 4 vcpu) = 16 vcpu`
`Pod1-Allocated-Memory = Max (100 GB, 60 GB) = 100 GB`
`Instance-Unused-GPU = Max (GPU-Available - SUM(Allocated-vcpu), 0)`
`= Max (8 – 8, 0) = 0`
`Instance-Unused-vcpu = Max (CPU-Available - SUM(Allocated-vcpu), 0)`
`= Max (16 – 18, 0) = 0`
`Instance-Unused-Memory = Max (Memory-Available - SUM(Allocated-Memory), 0)`
`= Max (488 – 440, 0) = 48 GB`
Neste exemplo, a instância tem excesso de assinatura de CPU, atribuído ao Pod 2, que usou mais GPU e vcpu do que o reservado.
**Tabela 2: Calcular a capacidade alocada e não utilizada**
| Nome do pod | Namespace | vcpu reservada | vcpu usada | vcpu alocada | GPU reservada | GPU usada | GPU alocada | Memória reservada | Memória usada | Memória alocada |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Namespace 1 | 16 | 4 | 16 | 1 | 1 | 1 | 100 | 60 | 100 |
| Pod 2 | Namespace 2 | 16 | 18 | 18 | 2 | 3 | 3 | 100 | 140 | 140 |
| Pod 3 | Namespace 1 | 16 | 4 | 16 | 2 | 1 | 2 | 100 | 60 | 100 |
| Cápsula 4 | Namespace 2 | 16 | 4 | 16 | 2 | 2 | 2 | 100 | 40 | 100 |
| Não utilizado | Não utilizado | 0 | 34 | 0 | 1 | 1 | 0 | 88 | 188 | 48 |
| \$1\$1\$1 | | 64 | 32 | 66 | 8 | 8 | 8 | 488 | 488 | 488 |
## Etapa 3: calcular as proporções de utilização e uso dividido
Proporção de uso dividido
A porcentagem de CPU ou memória usada pelo pod do Kubernetes em comparação à CPU ou à memória geral disponível na instância do EC2.
Proporção não utilizada
A porcentagem de CPU ou memória usada pelo pod do Kubernetes em comparação à CPU ou à memória geral usada na instância do EC2 (ou seja, sem considerar a CPU ou a memória não utilizadas na instância).
A porcentagem de CPU ou memória usada pelo pod do Kubernetes em comparação à CPU ou à memória geral disponível na instância do EC2.
`Pod1-GPU-Utilization-Ratio = Allocated-GPU / Total-GPU`
`= 1 gpu / 8 gpu = 0.125`
`Pod1-vcpu-Utilization-Ratio = Allocated-vcpu / Total-vcpu`
`= 16 vcpu / 66 vcpu = 0.24`
`Pod1-Memory-Utilization-Ratio = Allocated-GB / Total-GB`
`= 100 GB/ 488GB = 0.205`
`Pod1-GPU-Split-Ratio = Pod1-GPU-Utilization-Ratio / (Total-GPU-Utilization-Ratio – Instance-Unused-GPU). Set to 0 if Instance-Unused-GPU = 0`
`= 0 since Instance-Unused-GPU is 0`
`Pod1-vcpu-Split-Ratio = Pod1-CPU-Utilization-Ratio / (Total-CPU-Utilization-Ratio – Instance-Unused-CPU). Set to 0 if Instance-Unused-CPU = 0`
`= 0 since Instance-Unused-CPU is 0`
`Pod1-Memory-Split-Ratio = Pod-Memory-Utilization-Ratio / (Total-Utilization-Ratio – Instance-Unused-Memory). Set to 0 if Instance-Unused-Memory = 0`
`= 0.204/ (1-0.102) = 0.227`
**Tabela 3: Proporão de utilização da computação**
| Nome do pod | Namespace | Utilização da vcpu | Proporção de divisão de vcpu | Utilização da GPU | Proporção de divisão da GPU | Utilização da memória | Proporção de divisão de memória |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Namespace 1 | 0,242 | 0 | 0.125 | 0 | 0,205 | 0.227 |
| Pod 2 | Namespace 2 | 0,277 | 0 | 0,375 | 0 | 0,287 | 0,318 |
| Pod 3 | Namespace 1 | 0,242 | 0 | 0.25 | 0 | 0,205 | 0.227 |
| Cápsula 4 | Namespace 2 | 0,242 | 0 | 0.25 | 0 | 0,205 | 0.227 |
| Não utilizado | Não utilizado | 0 | | | | 0,098 | |
| | | 1 | 0 | 1 | 0 | 1 | 1 |
## Etapa 4: Calcular o custo dividido e os custos não utilizados
Custo dividido
A alocação do custo de pagamento por uso do custo da instância do EC2 com base no uso de CPU e memória alocados pelos pods do Kubernetes.
Custo da instância não utilizada
Custo da instância ou dos recursos de memória não utilizados na instância.
`Pod1-Split-Cost = (Pod1-GPU-Utilization-Ratio * GPU-Available * Cost per GPU-Hour) + (Pod1-vcpu-Utilization-Ratio * vcpu-Available * Cost per vcpu-Hour) + (Pod1-Memory-Utilization-Ratio * Memory-Available * Cost per GB-Hour)`
`= (.125*8gpu*$0.504) + (0.242 * 64 vcpu * $0.05) + (0.204 * 488GB * $0.00506) = 0.504+ 0.774 + 0.503 = $1.85`
`Pod1-Unused-Cost = (GPU-Split-Ratio * Unused-Cost) + (vcpu-Split-Ratio * Unused-Cost) + (Memory-Split-Ratio * Unused-Cost)`
`= (0*0*8*$0.504) + (0 * $0.05) + (0.227 *.102*488GB*$.00506) = $0.06`
`Pod1-Total-Split-Cost = Pod1-Split-Cost + Pod1-Unused-Cost = $1.85 + $0.06 = $1.91`
[Observação: custo não utilizado = proporção de uso não utilizada \$1 Recurso total \$1 custo por hora do recurso]
**Tabela 4 - Resumo dos custos divididos e não utilizados calculados a cada hora para todos os pods em execução no cluster**
| Nome do pod | Namespace | Custo dividido | Custo não utilizado | Custo total |
| --- | --- | --- | --- | --- |
| Pod 1 | Namespace 1 | \$11,85 | US\$1 0,06 | \$11,91 |
| Pod 2 | Namespace 2 | \$13,18 | \$10,09 | \$13,26 |
| Pod 3 | Namespace 1 | \$12,35 | US\$1 0,06 | \$12,41 |
| Cápsula 4 | Namespace 2 | \$12,35 | US\$1 0,06 | \$12,41 |
| Total | | | | \$110 |
# Usar rótulos do Kubernetes para alocação de custos no EKS
Os dados de alocação de custos divididos comportam os rótulos do Kubernetes como tags de alocação de custos divididos para clusters do Amazon EKS. Embora esses rótulos sejam importados automaticamente como rótulos de alocação de custos definidos pelo usuário, eles exigem ativação em nível de conta gerencial. Depois de ativados, você pode usá-los para atribuir custos em nível de pod em seus Relatórios de custo e de uso (CUR) utilizando atributos personalizados, como centro de custos, aplicação, unidade de negócios e ambiente.
Esse recurso ajuda as organizações a acompanhar e alocar custos com precisão em ambientes EKS compartilhados entre equipes, projetos ou departamentos. Usando rótulos do Kubernetes, você pode alocar seus custos do Kubernetes com base em seus requisitos de negócios específicos e no design organizacional.
## Pré-requisitos
Como pré-requisitos para usar rótulos do Kubernetes com dados de alocação de custos divididos:
+ Você precisa ativar os dados de alocação de custos divididos no console AWS Billing and Cost Management. Isso deve ser habilitado em nível de conta gerencial. Para obter detalhes, consulte [Habilitar dados de alocação de custos divididos](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Você precisa de um cluster do EKS para o qual rastrear dados de alocação de custos divididos. Pode ser um cluster existente ou você pode criar um novo. Para acessar mais informações, consulte [Criar um cluster do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) no *Guia do usuário do Amazon EKS*.
+ Você deve ter rótulos atribuídos aos seus pods no cluster do EKS. Para acessar mais informações sobre como criar rótulos no Kubernetes, consulte [Labels and Selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) na *documentação do Kubernetes*.
## Trabalhar com rótulos do Kubernetes no EKS
Os dados de alocação de custos divididos comportam até cinquenta rótulos do Kubernetes por pod, que são classificados em ordem alfabética antes de serem importados como tags de alocação de custos. Todos os rótulos além das cinquenta primeiras são automaticamente descartados. Se precisar adicionar uma nova etiqueta de alocação de custos depois de atingir o limite de cinquenta rótulos, primeiro remova um dos rótulos e garanta que seu novo rótulo esteja entre os primeiros cinquenta quando classificados em ordem alfabética.
**nota**
Alguns serviços AWS gerenciados adicionam rótulos automaticamente aos pods do EKS. Esses rótulos são contabilizados no limite de cinquenta rótulos por pod e aparecerão na sua página de tags de alocação de custos.
Embora os rótulos do Kubernetes não tenham restrições de tamanho, as tags de alocação de custos têm limites de caracteres específicos: 128 caracteres para chaves de tag e 256 caracteres para valores de tag. Os rótulos que excederem esses limites de caracteres serão descartados e não serão apresentados como tags de alocação de custos. É recomendável criar rótulos que sigam esses limites de caracteres para fins de alocação de custos.
Os rótulos importados do Kubernetes aparecem como tags de alocação de custos e devem ser ativados em nível de conta pagante. Para acessar mais informações sobre tags de alocação de custos e ativação, consulte [Usar tags de alocação de custos definidas pelo usuário](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html). Os seguintes limites de tags de alocação de custos se aplicam: cinquenta tags definidas pelo usuário por recurso e 500 tags definidas pelo usuário por conta pagante. As tags geradas pelo sistema não são contabilizadas para esses limites.
**nota**
Depois de criar e aplicar tags definidas pelo usuário aos recursos, pode levar até 24 horas para que as chaves de tag apareçam na página de tags de alocação de custos. Depois de ativar as tags, pode levar mais 24 horas para que elas se tornem ativas.
## Gerenciar rótulos do Kubernetes e tags de alocação de custos
Você pode adicionar, excluir e editar rótulos do Kubernetes no EKS, bem como desativar as tags de alocação de custos associadas. A seguir, descrevemos o comportamento esperado para cada ação.
**Adicionar um novo rótulo**
É possível adicionar um novo rótulo do Kubernetes a um pod. Se o limite de cinquenta etiquetas não for atingido, o novo rótulo será importado e oferecido como uma tag de alocação de custos, que poderá então ser ativada. No entanto, se o limite de cinquenta for atingido, o novo rótulo não será importado, mesmo que esteja na ordem de classificação alfabética dos primeiros cinquenta rótulos. Primeiro, você deve desativar uma tag de alocação de custos existente a fim de importar um novo rótulo.
**Editando um rótulo**
O Kubernetes não permite que você edite uma chave de rótulo. Para alterar uma chave de rótulo, você deve removê-la e adicionar um novo rótulo. No entanto, é possível editar os valores dos rótulos, que serão exibidos em seu próximo CUR.
**Excluindo um rótulo**
Você pode remover um rótulo dos pods do EKS. Observe que a remoção de um rótulo não desativa automaticamente a tag de alocação de custos associada. Os dados de alocação de custos divididos continuarão sendo preenchidos no CUR até que você desative explicitamente a tag de alocação de custos.
**Desativar uma tag de alocação de custos**
É possível desativar qualquer tag de alocação de custos criada com base nos rótulos do Kubernetes. Depois de desativada, os dados não serão mais preenchidos nas respectivas colunas e a coluna será excluída do CUR do próximo mês.
## Práticas recomendadas de gerenciamento de rótulos do Kubernetes para alocação de custos
Os rótulos do Kubernetes oferecem flexibilidade significativa na modelagem compartilhada de alocação de custos. Para maximizar o potencial desse recurso, recomendamos seguir estas práticas recomendadas a fim de otimizar sua abordagem de gerenciamento de custos.
**Noções básicas sobre limites de rótulos**
O label-per-pod limite de 50 é baseado na classificação alfabética. Somente os primeiros cinquenta rótulos em ordem alfabética serão importados para alocação de custos. Para garantir que etiquetas importantes sejam incluídas, planeje cuidadosamente a nomenclatura da etiqueta para garantir que etiquetas importantes apareçam entre as 50 primeiras quando classificadas em ordem alfabética.
**Seguir as restrições de caracteres**
AWS as tags de alocação de custos têm os seguintes limites de caracteres:
+ Teclas de tag: 128 caracteres
+ Valores de tags: 256 caracteres
Embora o Kubernetes permita rótulos mais longos, os rótulos que excederem esses limites não serão importados. Crie seus rótulos respeitando esses limites a fim de garantir um acompanhamento bem-sucedido da alocação de custos.
**Adicionar novos rótulos ao atingir o limite de capacidade**
Quando um pod atingir o limite de cinquenta rótulos e você precisar adicionar um novo rótulo de alocação de custos, siga estas etapas:
1. Analise os rótulos existentes e identifique uma tag de alocação de custos a ser desativada.
1. Desative a tag selecionada.
1. Adicione o novo rótulo de alocação de custos.
1. Verifique se o novo rótulo está dentro dos primeiros cinquenta classificados em ordem alfabética.
**nota**
Lembre-se de que somente os primeiros cinquenta rótulos classificados em ordem alfabética são usados para alocação de custos.
# Uso de dados de alocação de custo dividido com o Amazon Managed Service for Prometheus
A divisão dos dados de custo do Amazon EKS exige que você colete e armazene métricas dos seus clusters, incluindo uso de memória e CPU. O Amazon Managed Service for Prometheus pode ser usado para essa finalidade.
Quando você optar pelos dados de alocação de custos divididos e seu espaço de trabalho do Amazon Managed Service for Prometheus começar a receber as duas métricas necessárias (`container_cpu_usage_seconds_total` e `container_memory_working_set_bytes`), os dados de alocação de custos divididos reconhecerão as métricas e as usarão automaticamente.
**nota**
As duas métricas necessárias (`container_cpu_usage_seconds_total` e `container_memory_working_set_bytes`) estão presentes na configuração padrão de extrator do Prometheus e na configuração padrão fornecida com um coletor gerenciado pela AWS . No entanto, se você personalizar essas configurações, não renomeie, modifique ou remova os seguintes rótulos das métricas `container_cpu_usage_seconds_total` e `container_memory_working_set_bytes`: `name`, `namespace` e `pod`. Se você renomear, modificar ou remover esses rótulos, isso poderá afetar a ingestão de suas métricas.
Você pode usar o Amazon Managed Service for Prometheus para coletar métricas do EKS de uma única conta de uso, em uma única região. O espaço de trabalho do Amazon Managed Service for Prometheus precisa estar nessa conta e nessa região. Você precisa de uma instância do Amazon Managed Service for Prometheus para cada conta de uso e região para a qual deseja monitorar os custos. Você pode coletar métricas para vários clusters no espaço de trabalho do Amazon Managed Service for Prometheus, desde que eles estejam na mesma conta de uso e na mesma região.
As seções a seguir descrevem como enviar as métricas corretas do seu cluster do EKS para o espaço de trabalho do Amazon Managed Service for Prometheus.
## Pré-requisitos
Como pré-requisitos para usar o Amazon Managed Service for Prometheus com dados de alocação de custos divididos:
+ Você precisa ativar os dados de alocação de custos divididos no console AWS Billing and Cost Management. Para obter detalhes, consulte [Habilitar dados de alocação de custos divididos](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html). A aceitação de dados de alocação de custos divididos cria um perfil vinculado ao serviço em cada conta de uso para consultar o Amazon Managed Service for Prometheus quanto às métricas de cluster do Amazon EKS nessa conta. Para obter mais informações, consulte [Perfis vinculados ao serviço para dados de alocação de custos divididos](https://docs.aws.amazon.com/cost-management/latest/userguide/split-cost-allocation-data-SLR.html).
+ Você precisa de um cluster do EKS para o qual rastrear dados de alocação de custos divididos. Pode ser um cluster existente ou você pode criar um novo. Para acessar mais informações, consulte [Criar um cluster do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) no *Guia do usuário do Amazon EKS*.
**nota**
Você precisará do `EKS cluster ARN`, de `security group IDs` e de pelo menos dois `subnet IDs` (em zonas de disponibilidade diferentes) para usar nas etapas posteriores.
(opcional) Defina o modo de autenticação do cluster do EKS como `API` ou `API_AND_CONFIG_MAP`.
+ Você precisa de uma instância do Amazon Managed Service for Prometheus na mesma conta e na mesma região do seu cluster do EKS. Se você ainda não tiver uma, deverá criá-la. Para obter informações sobre como criar uma instância do Amazon Managed Service for Prometheus, consulte [Criar um espaço de trabalho](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) no *Guia do usuário do Amazon Managed Service for Prometheus*.
**nota**
Você precisará do `Amazon Managed Service for Prometheus workspace ARN` para uso em etapas posteriores.
## Encaminhar as métricas do EKS no Amazon Managed Service for Prometheus
Assim que tiver um cluster do EKS e uma instância do Amazon Managed Service for Prometheus, você poderá encaminhar as métricas do cluster para a instância. É possível enviar métricas de duas maneiras.
+ [Opção 1: usar um coletor AWS gerenciado.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#use-managed-collector) Essa é a maneira mais simples de enviar métricas de um cluster do EKS para o Amazon Managed Service for Prometheus. No entanto, ele tem um limite de extração de métricas a cada 30 segundos, no máximo.
+ [Opção 2: criar seu próprio agente do Prometheus.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent) Nesse caso, você tem mais controle sobre a configuração de extração, mas precisa gerenciar o agente depois de criá-lo.
### Opção 1: usar um coletor AWS gerenciado
Usar um coletor AWS gerenciado (um *raspador*) é a maneira mais simples de enviar métricas de um cluster EKS para uma instância do Amazon Managed Service for Prometheus. O procedimento a seguir orienta você na criação de um coletor AWS gerenciado. Para obter mais informações, consulte [Coletores gerenciados pela AWS](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html) no *Guia do usuário do Amazon Managed Service for Prometheus*.
**nota**
AWS coletores gerenciados têm um intervalo mínimo de raspagem de 30 segundos. Se você tiver pods de curta duração, a recomendação é definir o intervalo do raspador para 15 segundos. Para usar um intervalo de 15 segundos com o raspador, use a opção 2 para [criar seu próprio agente do Prometheus](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent).
Há três etapas para criar um coletor AWS gerenciado:
1. Criar uma configuração de raspador.
1. Criar o raspador.
1. Configurar o cluster do EKS para permitir que o raspador acesse as métricas.
*Etapa 1: Criar uma configuração de raspador*
Para criar um raspador, é preciso ter uma configuração de raspador. Você pode usar uma configuração padrão ou criar a sua própria. A seguir estão três maneiras de obter uma configuração de raspador:
+ Obtenha a configuração padrão usando a AWS CLI, chamando:
```
aws amp get-default-scraper-configuration
```
+ Criar sua própria configuração. Para obter mais informações, consulte [Configuração do raspador](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) no *Guia do usuário do Amazon Managed Service for Prometheus*.
+ Copie o exemplo de configuração fornecido nas mesmas instruções de [Configuração do raspador](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) no *Guia do usuário do Amazon Managed Service for Prometheus*.
Você pode editar a configuração do raspador para modificar o intervalo de extração ou filtrar as métricas que são extraídas, por exemplo.
Para filtrar as métricas que são extraídas para incluir apenas as duas necessárias para os dados de alocação de custos divididos, use a seguinte configuração de raspador:
```
global:
scrape_interval: 30s
#external_labels:
#clusterArn:
scrape_configs:
- job_name: kubernetes-nodes-cadvisor
scrape_interval: 30s
scrape_timeout: 10s
scheme: https
authorization:
type: Bearer
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- regex: (.+)
replacement: /api/v1/nodes/$1/proxy/metrics/cadvisor
source_labels:
- __meta_kubernetes_node_name
target_label: __metrics_path__
- replacement: kubernetes.default.svc:443
target_label: __address__
metric_relabel_configs:
- source_labels: [__name__]
regex: 'container_cpu_usage_seconds_total|container_memory_working_set_bytes'
action: keep
```
Depois de ter a configuração do raspador, você deve codificá-lo em base64 para uso na *etapa 2*. A configuração é um arquivo YAML de texto. Para codificar o arquivo, use um site como [https://www.base64encode.org/](https://www.base64encode.org/).
*Etapa 2: Criar o raspador*
Agora que você tem um arquivo de configuração, você precisa criar seu raspador. Crie um raspador usando o seguinte comando da AWS CLI, com base nas variáveis descritas na seção de pré-requisitos. Você deve usar as informações do seu cluster EKS para os ** campos ****, e, ** substituir pela configuração do raspador que você criou na etapa anterior e substituir ** pelo ARN do espaço de trabalho do Amazon Managed Service for Prometheus.
```
aws amp create-scraper \
--source eksConfiguration="{clusterArn=,securityGroupIds=[],subnetIds=[]}" \
--scrape-configuration configurationBlob= \
--destination ampConfiguration={workspaceArn=""}
```
Anote o `scraperId` que é retornado para uso na *etapa 3*.
*Etapa 3: Configurar o cluster do EKS para permitir que o raspador acesse as métricas*
Se o modo de autenticação do seu cluster do EKS estiver definido como `API` ou `API_AND_CONFIG_MAP`, seu raspador terá automaticamente a política de acesso correta no cluster, e os raspadores terão acesso ao seu cluster. Nenhuma configuração adicional é necessária e as métricas devem converger para o Amazon Managed Service for Prometheus.
Se o modo de autenticação do seu cluster EKS não estiver definido como `API` ou`API_AND_CONFIG_MAP`, você precisará configurar manualmente o cluster para permitir que o raspador acesse suas métricas por meio de um ClusterRole e. ClusterRoleBinding Para saber como habilitar essas permissões, consulte [Configurar manualmente um cluster do EKS para acesso do raspador](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup) no *Guia do usuário do Amazon Managed Service for Prometheus*.
Quando o extrator estiver ativo, verifique se as duas métricas (`container_cpu_usage_seconds_total` e `container_memory_working_set_bytes`) estão sendo enviadas ao espaço de trabalho do Amazon Managed Service for Prometheus.
```
awscurl --service="aps" --region="" "https://aps-workspaces..amazonaws.com/workspaces//api/v1/label/__name__/values"
```
Saída:
```
{
"status": "success",
"data": [
"container_cpu_usage_seconds_total",
"container_memory_working_set_bytes",
"scrape_duration_seconds",
"scrape_samples_post_metric_relabeling",
"scrape_samples_scraped",
"scrape_series_added",
"up"
]
}
```
### Opção 2: criar seu próprio agente do Prometheus
Se você não pode usar o coletor AWS gerenciado ou já tem seu próprio servidor Prometheus, pode usar sua própria instância do Prometheus como agente para extrair métricas do seu cluster EKS e enviá-las para o Amazon Managed Service for Prometheus.
Para obter instruções detalhadas sobre como usar sua própria instância do Prometheus como agente, consulte [Usar uma instância do Prometheus como coletor](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-ingest-with-prometheus.html) no *Guia do usuário do Amazon Managed Service for Prometheus*.
Veja a seguir um exemplo de configuração de extração do Prometheus que inclui o intervalo de extração do servidor Prometheus e as métricas de contêiner necessárias para os dados de alocação de custos divididos. Se você tiver pods de curta duração, a recomendação é reduzir o intervalo padrão de extração do servidor Prometheus de 30 segundos para 15 segundos. Observe que isso pode ocasionar um alto uso da memória do servidor Prometheus.
```
global:
scrape_interval: 30s
#external_labels:
#clusterArn:
scrape_configs:
- job_name: kubernetes-nodes-cadvisor
scrape_interval: 30s
scrape_timeout: 10s
scheme: https
authorization:
type: Bearer
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- regex: (.+)
replacement: /api/v1/nodes/$1/proxy/metrics/cadvisor
source_labels:
- __meta_kubernetes_node_name
target_label: __metrics_path__
- replacement: kubernetes.default.svc:443
target_label: __address__
metric_relabel_configs:
- source_labels: [__name__]
regex: 'container_cpu_usage_seconds_total|container_memory_working_set_bytes'
action: keep
```
Se você seguiu [Configurar a ingestão de um novo servidor Prometheus usando o Helm](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-ingest-metrics-new-Prometheus.html) no *Guia do usuário do Amazon Managed Service for Prometheus*, poderá atualizar sua configuração de extração.
**Para atualizar a configuração de extração**
1. Edite `my_prometheus_values_yaml` a partir do guia e inclua o exemplo de configuração de extração no bloco `server`.
1. Execute o comando a seguir usando `prometheus-chart-name` e `prometheus-namespace` a partir do *Guia do usuário do Amazon Managed Service for Prometheus*.
```
helm upgrade prometheus-chart-name prometheus-community/prometheus -n prometheus-namespace -f my_prometheus_values_yaml
```
Para saber mais sobre `scrape_interval` ou como usar um scrape\$1interval não global, consulte a [configuração de extração do Prometheus](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config).
Como alternativa, você pode usar o AWS Distro for OpenTelemetry Collector que tem um receptor Prometheus, um exportador de gravação remota Prometheus e a extensão de autenticação AWS Sigv4 para obter acesso de gravação remota ao Amazon Managed Service for Prometheus.
**nota**
Depois de configurar seu agente Prometheus, AWS diferentemente dos coletores gerenciados, você é responsável por manter o agente atualizado e pronto para coletar métricas.
## Estimar seus custos do Amazon Managed Service for Prometheus
Você pode usar a Calculadora de AWS preços para estimar o custo do uso do Amazon Managed Service for Prometheus para dividir os dados de alocação de custos.
**Para configurar o Amazon Managed Service for Prometheus de acordo com sua estimativa**
1. Abra a calculadora de AWS preços em [https://calculator.aws/\$1/](https://calculator.aws/#/).
1. Selecione **Criar estimativa**.
1. Na página **Adicionar serviço**, insira **Amazon Managed Service for Prometheus** no campo de pesquisa e escolha **Configurar**.
1. No campo **Descrição**, insira uma descrição para sua estimativa.
1. Escolha uma **Region**.
1. Selecione **Calcular o custo usando os detalhes da sua infraestrutura**. Essa opção permite estimar seus custos de ingestão, armazenamento e consulta de exemplo com base na configuração de infraestrutura atual ou proposta.
1. Em **Número de instâncias do EC2**, insira o número total de instâncias do EC2 em todos os seus clusters para toda a sua família de faturamento consolidado (incluindo todas as contas e regiões). Se você usa AWS Fargate, use o número de tarefas do Fargate como proxy para sua contagem de instâncias do EC2.
1. Os dados de alocação de custos divididos exigem duas métricas: `container_cpu_usage_seconds_total` e `container_memory_working_set_bytes`. Em **Métricas do Prometheus por instâncias do EC2**, insira 2.
1. Os dados de alocação de custos divididos sugerem um intervalo de extração de 15 segundos. Em **Intervalo de coleta de métricas (em segundos)**, insira 15. Se você usou um intervalo diferente (por exemplo, 30 segundos), altere-o para o intervalo que você configurou.
1. Os dados de alocação de custos divididos não impõem requisitos específicos para os outros parâmetros, portanto, insira valores apropriados para o restante dos parâmetros de entrada de acordo com os requisitos de sua empresa.
1. Selecione **Salvar e adicionar serviço**.
# Usando dados de alocação de custos divididos com o Amazon CloudWatch Container Insights
A divisão dos dados de custo do Amazon EKS exige que você colete e armazene métricas dos seus clusters, incluindo uso de memória e CPU. O Amazon CloudWatch Container Insights pode ser usado para essa finalidade.
Depois de optar por dividir os dados de alocação de custos e configurar o CloudWatch agente com o complemento de observabilidade EKS em seu cluster EKS, os dados de alocação de custos divididos começam a receber as duas métricas necessárias `pod_memory_working_set` (`(pod_cpu_usage_total`e) no `ContainerInsights` namespace e as usam automaticamente. Para ver o conjunto completo de métricas de contêineres para o EKS, consulte as métricas do [Amazon EKS e do Kubernetes Container Insights no Guia](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) do usuário da *Amazon CloudWatch *.
As seções a seguir descrevem como enviar as métricas corretas do seu cluster do EKS aos dados de alocação de custos divididos.
## Pré-requisitos
Como pré-requisitos para usar o Amazon CloudWatch Container Insights com dados de alocação de custos divididos:
+ Você precisa ativar os dados de alocação de custos divididos no console AWS Billing and Cost Management. Para obter detalhes, consulte [Habilitar dados de alocação de custos divididos](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Você precisa de um cluster do EKS para o qual rastrear dados de alocação de custos divididos. Pode ser um cluster existente ou você pode criar um novo. Para acessar mais informações, consulte [Criar um cluster do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) no *Guia do usuário do Amazon EKS*.
## Configurando o Amazon CloudWatch Container Insights para encaminhar métricas do EKS
Você precisa instalar e configurar o CloudWatch agente para encaminhar as métricas do EKS. Você pode usar o [complemento Amazon CloudWatch Observability EKS ou o gráfico Amazon CloudWatch Observability Helm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) para instalar o CloudWatch agente e o agente Fluent-bit em um cluster EKS. Para obter mais informações sobre como instalar e configurar o CloudWatch agente, consulte [Instalar o complemento Amazon CloudWatch Observability EKS no Guia CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html) *do usuário da Amazon*.
A seguir estão as versões mínimas necessárias para o CloudWatch agente e o complemento EKS:
+ CloudWatch versão do agente: v1.300045.0
+ CloudWatch Versão complementar do Observability EKS: v2.0.1-eksbuild.1
## Estimando seus custos com a Amazon CloudWatch
Ativar o recurso para usar o Amazon CloudWatch Container Insights com dados de alocação de custos divididos adiciona duas novas métricas ao Amazon CloudWatch Container Insights: `pod_cpu_usage_total` e. `pod_memory_working_set` Para obter detalhes sobre essas métricas, consulte as métricas do [Amazon EKS e do Kubernetes Container Insights no Guia](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) do usuário da *Amazon CloudWatch *.
**Como entender os custos associados ao recurso**
1. Abra os CloudWatch preços da Amazon a [https://aws.amazon.com/cloudwatch/preços /.](https://aws.amazon.com/cloudwatch/pricing/)
1. Navegue até a seção **Nível pago**.
1. Escolha a guia **Container Insights**.
1. Para ver um cálculo detalhado dos custos, navegue até a seção **Exemplos de definição de preço** e consulte o **Exemplo 13 - Container Insights para o Amazon EKS e Kubernetes**.