Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memahami data alokasi biaya terpisah
Anda dapat menggunakan Laporan Biaya dan Penggunaan (AWS CUR) untuk melacak biaya penampung Amazon ECS dan Amazon EKS Anda. Dengan menggunakan data alokasi biaya terpisah, Anda dapat mengalokasikan biaya kontainer ke unit dan tim bisnis individual, berdasarkan cara beban kerja kontainer menggunakan sumber daya komputasi dan memori bersama. Data alokasi biaya terpisah memperkenalkan data biaya dan penggunaan untuk sumber daya tingkat kontainer baru (yaitu, tugas ECS dan pod Kubernetes) ke CUR. AWS Sebelumnya, AWS CUR hanya mendukung biaya di tingkat instans EC2. Data alokasi biaya terpisah menghasilkan biaya tingkat kontainer dengan melihat konsumsi sumber daya instans EC2 setiap kontainer, dan menghasilkan biaya berdasarkan biaya amortisasi instance dan persentase CPU dan sumber daya memori yang dikonsumsi oleh kontainer yang berjalan pada instance.
Untuk instans komputasi yang dipercepat yang digunakan dengan Amazon EKS, data alokasi biaya terpisah mencakup alokasi sumber daya untuk prosesor khusus bersama CPU dan memori. Ini mencakup akselerator NVIDIA dan AMD GPUs, AWS Trainium, dan AWS Inferentia. Fitur ini hanya tersedia untuk lingkungan Amazon EKS dan menyediakan data reservasi sumber daya tingkat pod untuk sumber daya komputasi yang dipercepat ini. Hal ini memungkinkan Anda untuk melacak dan mengalokasikan biaya untuk beban kerja yang menggunakan prosesor khusus ini, seperti aplikasi AI/ML dan tugas-tugas komputasi intensif lainnya. Untuk daftar instans komputasi yang dipercepat saat ini, lihat [Komputasi Akselerasi](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing).
Data alokasi biaya terpisah memperkenalkan catatan penggunaan baru dan kolom metrik biaya baru untuk setiap ID sumber daya kontainer (yaitu, tugas ECS dan pod Kubernetes) di CUR. AWS Untuk informasi selengkapnya, lihat [Membagi detail item baris](https://docs.aws.amazon.com/cur/latest/userguide/split-line-item-columns.html).
Saat memasukkan data alokasi biaya terpisah di AWS CUR, dua catatan penggunaan baru ditambahkan untuk setiap tugas ECS dan pod Kubernetes per jam untuk mencerminkan biaya CPU dan memori. Untuk memperkirakan jumlah item baris baru di AWS CUR per hari, gunakan rumus berikut:
Untuk ECS: `(number of tasks * average task lifetime * 2) * 24`
Untuk EKS: `(number of pods * average pod lifetime * 2) * 24`
Misalnya, jika Anda memiliki 1.000 pod yang berjalan setiap jam di sebuah cluster yang terdiri dari 10 instans EC2 dan masa pakai pod kurang dari 1 jam, maka:
`(1000 * 1 * 2) * 24 = 48,000 new usage records in AWS CUR`
Untuk instans komputasi yang dipercepat di Amazon EKS, tiga catatan penggunaan baru ditambahkan untuk setiap pod Kubernetes per jam untuk mencerminkan biaya akselerator, CPU, dan memori. Untuk memperkirakan jumlah item baris baru di AWS CUR per hari, gunakan rumus berikut:
Untuk EKS dengan komputasi yang dipercepat: `(number of pods * average pod lifetime * 3) * 24`
Misalnya, jika Anda memiliki 1.000 pod yang berjalan setiap jam di sebuah cluster yang terdiri dari 10 instans EC2 dan masa pakai untuk setiap pod kurang dari satu jam, maka: `(1000 * 1 * 3) * 24 = 72,000 new usage records in AWS CUR`
**catatan**
Untuk ECS: Dalam hal tag alokasi AWS biaya, Anda dapat menggunakan tag yang dikelola Amazon ECS atau tag yang ditambahkan pengguna untuk Laporan Biaya dan Penggunaan Anda. Tag ini berlaku untuk semua catatan penggunaan data alokasi biaya terpisah ECS baru. Untuk informasi selengkapnya, lihat [Menandai sumber daya ECS Anda untuk](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html#tag-resources-for-billing) penagihan.
Untuk EKS: Data alokasi biaya terpisah membuat tag alokasi biaya baru untuk beberapa atribut Kubernetes. Tag ini termasuk`aws:eks:cluster-name`,`aws:eks:deployment`,`aws:eks:namespace`,`aws:eks:node`,`aws:eks:workload-name`, dan`aws:eks:workload-type`.
`aws:eks:cluster-name`,`aws:eks:namespace`, dan diisi `aws:eks:node` secara retrospektif dengan nama cluster, namespace, dan node.
`aws:eks:workload-type`hanya diisi jika ada tepat satu beban kerja yang mengelola pod, dan merupakan salah satu beban kerja bawaan. Jenis beban kerja meliputi`ReplicaSet`,`StatefulSet`,`Job`,`DaemonSet`, atau`ReplicationController`, dan `aws:eks:workload-name` termasuk nama beban kerja. Untuk informasi selengkapnya, lihat [Beban Kerja di Dokumentasi](https://kubernetes.io/docs/concepts/workloads/) *Kubernetes*.
`aws:eks:deployment`hanya diisi untuk jenis beban kerja. `ReplicaSet` Ini adalah penerapan yang menciptakan. `ReplicaSet`
Tag ini berlaku untuk semua catatan penggunaan data alokasi biaya terpisah EKS baru. Tag ini diaktifkan untuk alokasi biaya secara default. Jika sebelumnya Anda menggunakan dan menonaktifkan `aws:eks:cluster-name` tag, data alokasi biaya terpisah akan menyimpan pengaturan ini dan tidak mengaktifkan tag. Anda dapat mengaktifkannya dari halaman konsol [tag alokasi biaya](https://console.aws.amazon.com/billing/home#/tags).
# Mengaktifkan data alokasi biaya terpisah
**catatan**
Data alokasi biaya terpisah tidak tersedia di Cost Explorer. Ini tersedia dalam Laporan Biaya dan Penggunaan lama (CUR) dan Laporan Biaya dan Penggunaan 2.0 (CUR 2.0) dengan Ekspor Data.
Merupakan prasyarat untuk memilih untuk membagi data alokasi biaya melalui preferensi Manajemen Biaya.
**Untuk memilih untuk membagi data alokasi biaya**
1. Buka Konsol Manajemen Penagihan dan Biaya di [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. Di panel navigasi, pilih **preferensi Manajemen Biaya**.
1. Di bawah **Umum**, di bagian **Data alokasi biaya terpisah**, pilih antara yang berikut ini:
+ **Amazon Elastic Container Service (Amazon ECS**) untuk ikut serta dalam Amazon ECS saja.
+ **Amazon Elastic Kubernetes Service (Amazon EKS) untuk ikut serta di Amazon** EKS saja. Untuk Amazon EKS, pilih antara yang berikut ini:
+ **Permintaan sumber daya**: Ini mengalokasikan Amazon EC2 Anda hanya dengan CPU pod Kubernetes dan sumber daya memori. Ini akan mendorong tim aplikasi untuk hanya menyediakan apa yang mereka butuhkan.
+ **Layanan Terkelola Amazon untuk Prometheus**: Ini mengalokasikan biaya Amazon EC2 Anda dengan lebih tinggi dari permintaan CPU dan sumber daya memori Kubernetes pod dan pemanfaatan aktual yang lebih tinggi. Ini memastikan setiap tim aplikasi membayar untuk apa yang mereka gunakan. Untuk mempelajari selengkapnya tentang menyiapkan Layanan Terkelola Amazon untuk Prometheus, lihat [Menyiapkan](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-setting-up.html) di panduan pengguna *Layanan Terkelola Amazon* untuk Prometheus.
Prasyarat: Anda harus mengaktifkan semua fitur di. AWS Organizations Untuk mempelajari lebih lanjut, lihat [Mengaktifkan semua fitur di organisasi Anda](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) di *panduan pengguna Organizations*.
+ **Amazon CloudWatch Container Insights**: Ini memberikan visibilitas biaya yang lebih terperinci untuk klaster Anda yang menjalankan beberapa wadah aplikasi menggunakan instans EC2 bersama, memungkinkan alokasi biaya yang lebih baik untuk biaya bersama kluster EKS Anda.
**catatan**
Hanya akun reguler dan pembayar yang memiliki akses ke AWS Cost Management preferensi dan dapat memilih untuk membagi data alokasi biaya. Setelah memilih, akun anggota dapat melihat data dalam Laporan Biaya dan Penggunaan.
Jika Anda memilih permintaan sumber daya, hanya pod yang dikonfigurasi dengan memori dan permintaan CPU yang digunakan oleh data alokasi biaya terpisah. Pod yang belum meminta penggunaan apa pun tidak akan melihat data biaya terpisah.
Jika memilih Amazon Managed Service for Prometheus, Anda harus mengaktifkan semua fitur di Organizations. AWS Untuk informasi selengkapnya, lihat [Mengaktifkan semua fitur di organisasi Anda](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html). Selain itu, data alokasi biaya terpisah menciptakan peran terkait layanan baru, yang memungkinkan akses ke AWS layanan dan sumber daya yang digunakan atau dikelola oleh data alokasi biaya terpisah.
Untuk instans komputasi yang dipercepat, hanya opsi permintaan Sumber Daya yang didukung. Baik Amazon Managed Service untuk Prometheus maupun CloudWatch Amazon Container Insights tidak didukung untuk instans ini. Saat menggunakan instans komputasi yang dipercepat, sistem akan default ke permintaan Sumber Daya untuk menghitung biaya akselerator, CPU, dan memori, bahkan jika opsi pengukuran lainnya diaktifkan.
Setelah memilih, Anda dapat memilih untuk memiliki data biaya dan penggunaan untuk sumber daya tingkat kontainer yang disertakan dalam laporan selama langkah pertama pembuatan laporan atau yang lebih baru dengan mengedit detail laporan.
**Untuk memasukkan data biaya dan penggunaan dalam laporan Anda**
1. Buka Konsol Manajemen Penagihan dan Biaya di [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. Di panel navigasi, di bawah **Halaman Legacy**, pilih Laporan **Biaya dan Penggunaan**.
1. Baik membuat laporan baru atau mengedit laporan yang ada, di halaman **Tentukan detail laporan**, di bawah **Laporkan konten**, pilih **Pisahkan data alokasi biaya**.
**catatan**
Anda juga dapat menggunakan AWS CUR API atau AWS Command Line Interface (CLI) untuk mengelola preferensi data alokasi biaya terpisah Anda.
Data alokasi biaya terpisah memungkinkan visibilitas biaya untuk semua objek penampung Amazon ECS dan Amazon EKS di seluruh keluarga penagihan gabungan Anda (akun pembayar dan tertaut). Setelah diaktifkan, data alokasi biaya terpisah secara otomatis memindai tugas dan kontainer. Ini menyerap data penggunaan telemetri untuk beban kerja kontainer Anda dan menyiapkan data biaya granular untuk bulan berjalan.
**catatan**
Diperlukan waktu hingga 24 jam agar data dapat terlihat di AWS CUR.
Untuk informasi tentang mengelola akses ke halaman konsol Billing and Cost Management, [lihat Ringkasan mengelola izin akses](https://docs.aws.amazon.com/cost-management/latest/userguide/control-access-billing.html).
Untuk informasi mengenai AWS Cost Management preferensi dan mengontrol akses ke Cost Explorer, lihat [Mengontrol akses ke Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html).
# Contoh data alokasi biaya terpisah
Tujuan dari contoh berikut ini adalah untuk menunjukkan kepada Anda bagaimana data alokasi biaya split dihitung dengan menghitung biaya layanan Amazon ECS individual, tugas di cluster Amazon ECS, dan namespace Kubernetes dan pod di cluster Amazon EKS. Tarif yang digunakan di seluruh contoh hanya untuk tujuan ilustrasi.
**catatan**
Contoh ini menunjukkan namespace Kubernetes dan pod yang berjalan di klaster Amazon EKS. Kami kemudian dapat menerapkan model biaya yang sama ke layanan Amazon ECS dan tugas yang berjalan di cluster Amazon ECS.
Anda memiliki penggunaan berikut dalam satu jam:
+ Instance tunggal (m5.xlarge) berbagi cluster dengan dua namespace dan empat pod, berjalan selama satu jam penuh.
+ Konfigurasi instans adalah 4 vCPU dan 16 GB memori.
+ Biaya amortisasi dari instans adalah \$11/jam.
Data alokasi biaya terpisah menggunakan bobot unit relatif untuk CPU dan memori berdasarkan rasio 9:1. Ini berasal dari per vCPU per jam dan per GB per jam harga di. [AWS Fargate](https://aws.amazon.com/fargate/pricing/)
## Langkah 1: Hitung biaya unit untuk CPU dan memori
`Unit-cost-per-resource = Hourly-instance-cost/((Memory-weight * Memory-available) + (CPU-weight * CPU-available))`
= \$11/ ((1 \$1 16GB) \$1 (9 \$1 4vCPU)) = \$10,02
`Cost-per-vCPU-hour = CPU-weight * Unit-cost-per-resource`
= 9 \$1 \$10,02 = \$10,17
`Cost-per-GB-hour = Memory-weight * Unit-cost-per-resource`
= 1 \$1 \$10,02 = \$10,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 | \$10,17 | \$10,02 |
## Langkah 2: Hitung kapasitas yang dialokasikan dan misalnya kapasitas yang tidak digunakan
+ Kapasitas yang dialokasikan: Memori dan vCPU yang dialokasikan ke pod Kubernetes dari instans EC2 induk, didefinisikan sebagai kapasitas maksimum yang digunakan dan yang dicadangkan.
**catatan**
Jika data penggunaan memori atau vCPU tidak tersedia, data reservasi akan digunakan sebagai gantinya. Untuk informasi selengkapnya, lihat [laporan penggunaan Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/usage-reports.html), atau [pemantauan biaya Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/cost-monitoring.html).
+ Kapasitas instans yang tidak digunakan: Kapasitas vCPU dan memori yang tidak terpakai.
`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)`= Maks (4 — 4,9, 0) = 0
`Instance-Unused-memory = Max (Memory-available - SUM(Allocated-memory), 0)`= Maks (16 - 14, 0) = 2 GB
Dalam contoh ini, instance memiliki CPU over subscription, dikaitkan dengan Pod2 yang menggunakan lebih banyak vCPU daripada yang dicadangkan.
****
| 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 |
## Langkah 3: Hitung rasio penggunaan terpisah
+ Rasio penggunaan terpisah: Persentase CPU atau memori yang digunakan oleh pod Kubernetes dibandingkan dengan keseluruhan CPU atau memori yang tersedia pada instans EC2.
+ Rasio yang tidak terpakai: Persentase CPU atau memori yang digunakan oleh pod Kubernetes dibandingkan dengan keseluruhan CPU atau memori yang digunakan pada instans EC2 (yaitu, tidak memperhitungkan CPU atau memori yang tidak terpakai pada instance).
`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/ 16GB = 0.250
`Pod1-vCPU-unused-ratio = Pod1-vCPU-split-usage-ratio / (Total-CPU-split-usage-ratio – Instance-unused-CPU)`(diatur ke 0 Instance-unused-CPU jika 0)
= 0 ( Instance-unused-CPUkarena 0)
`Pod1-Memory-unused-ratio = Pod1-Memory-split-usage-ratio / (Total-Memory-split-usage-ratio – Instance-unused-memory)`(diatur ke 0 Instance-unused-memory jika 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 | |
## Langkah 4: Hitung biaya split dan biaya yang tidak terpakai
+ Biaya split: Alokasi biaya bayar per penggunaan dari biaya instans EC2 berdasarkan alokasi CPU dan penggunaan memori oleh pod Kubernetes.
+ Biaya instans yang tidak digunakan: Biaya CPU atau sumber daya memori yang tidak digunakan pada instance.
`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 \$10,17) \$1 (0,25 \$1 16GB \$1 \$10,02) = \$10,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 \$10,17) \$1 (0,286 \$1 0,125 \$1 16 \$1 \$10,02) = \$10,01
`Pod1-Total-split-cost = Pod1-Split-cost + Pod1-Unused-cost`
= \$10,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 | \$10,18 | \$10,01 | \$10,19 |
| Pod4 | Namespace2 | \$10,18 | \$10,01 | \$10,19 |
| Unused | Unused | \$10,04 | | |
| | | \$11 | \$10,04 | \$11 |
Biaya layanan adalah jumlah biaya pod yang terkait dengan setiap namespace.
Total biaya Namespace1 = \$10,23 \$1 \$10,19 = \$10,42
Total biaya Namespace2 = \$10,40 \$1\$10,19 = \$10,59
## Contoh AWS CUR
Jika Anda memiliki Savings Plans yang mencakup seluruh penggunaan instans EC2 dalam periode penagihan, biaya diamortisasi dihitung menggunakan. savingsPlan/SavingsPlanEffectiveCost
![\[Table showing EC2 instance usage details with Savings Plans and cost breakdown.\]](http://docs.aws.amazon.com/id_id/cur/latest/userguide/images/savings-plan-entire-usage.png)
Jika Anda memiliki Savings Plans yang mencakup penggunaan sebagian untuk instans EC2 dalam periode penagihan dan sisa penggunaan instans EC2 ditagih dengan tarif Sesuai Permintaan, biaya amortisasi instans EC2 dihitung menggunakan savingsPlan/SavingsPlanEffectiveCost (untuk) \$1 (untuk penggunaan Sesuai Permintaan). SavingsPlanCoveredUsage lineItem/UnblendedCost
![\[Table showing EC2 instance usage details, costs, and savings plan information.\]](http://docs.aws.amazon.com/id_id/cur/latest/userguide/images/savings-plan-partial-usage.png)
# Contoh data alokasi biaya terpisah untuk instans yang dipercepat
Tujuan dari contoh berikut adalah untuk menunjukkan kepada Anda bagaimana data alokasi biaya split dihitung dengan menghitung biaya namespace Kubernetes dan pod di klaster Amazon EKS. Tarif yang digunakan di seluruh contoh hanya untuk tujuan ilustrasi.
Anda memiliki penggunaan berikut dalam satu jam:
+ Instance EC2 tunggal yang menjalankan empat pod di dua namespace, dan Anda ingin memahami biaya setiap namespace.
+ Instans EC2 adalah p3.16xlarge dengan 8 GPU, 64 vCPU, dan 488 GB RAM.
+ Biaya amortisasi dari instans adalah \$110/jam.
Data alokasi biaya terpisah menormalkan biaya per sumber daya berdasarkan rasio relatif GPU: (cpu: memori) 9:1. Ini menyiratkan bahwa satu unit GPU berharga 9x sebanyak unit CPU dan memori. CPU dan memori kemudian diberi berat 9:1. Untuk instance EC2 yang tidak dipercepat, perilaku default saat ini akan diadopsi yaitu cpu: bobot memori default ke 9:1.
## Langkah 1: Hitung biaya unit
Berdasarkan sumber daya cpu dan memori pada instans EC2 dan menggunakan rasio yang disebutkan di atas, data Alokasi Biaya Split pertama-tama menghitung biaya unit per GPU, VCPU-HR dan GB-HR.
`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`
**Tabel 1: Perhitungan biaya unit**
| Instans | Tipe Instans | vCPU Tersedia | GPU Tersedia | \$1\$1 | Memori Tersedia | Biaya Amortisasi per Jam | Biaya per VCPU-jam | Biaya per GPU-jam | Biaya per GB-jam |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Instans 1 | p3.16xlarge | 64 | 8 | | 488 | \$110 | \$10,05 | \$10,50 | 0,005 |
## Langkah 2: Hitung kapasitas yang dialokasikan dan tidak terpakai
Kapasitas yang Dialokasikan
GPU, vcpu, dan Memori yang dialokasikan ke Pod Kubernetes dari Instance EC2 induk, yang didefinisikan sebagai kapasitas Maksimum (reserved, used)
Contoh Kapasitas yang Tidak Digunakan
Kapasitas GPU, vcpu, dan Memori yang tidak terpakai
`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`
Dalam contoh ini, instance memiliki CPU over subscription, dikaitkan dengan Pod 2 yang menggunakan lebih banyak GPU dan vcpu daripada yang dicadangkan.
**Tabel 2: Hitung Kapasitas yang Dialokasikan dan Tidak Digunakan**
| Nama Pod | Namespace | vcpu Dilindungi | vcpu Digunakan | vcpu Dialokasikan | GPU Dilindungi | GPU digunakan | GPU Dialokasikan | Memori Cadangan | Memori yang Digunakan | Memori Dialokasikan |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Ruang nama 1 | 16 | 4 | 16 | 1 | 1 | 1 | 100 | 60 | 100 |
| Pod 2 | Ruang nama 2 | 16 | 18 | 18 | 2 | 3 | 3 | 100 | 140 | 140 |
| Pod 3 | Ruang nama 1 | 16 | 4 | 16 | 2 | 1 | 2 | 100 | 60 | 100 |
| Pod 4 | Ruang nama 2 | 16 | 4 | 16 | 2 | 2 | 2 | 100 | 40 | 100 |
| Tidak terpakai | Tidak terpakai | 0 | 34 | 0 | 1 | 1 | 0 | 88 | 188 | 48 |
| \$1\$1\$1 | | 64 | 32 | 66 | 8 | 8 | 8 | 488 | 488 | 488 |
## Langkah 3: Hitung rasio penggunaan dan pemanfaatan terpisah
Rasio penggunaan split
Persentase CPU atau memori yang digunakan oleh pod Kubernetes dibandingkan dengan keseluruhan CPU atau memori yang tersedia pada instans EC2.
Rasio yang tidak digunakan
Persentase CPU atau memori yang digunakan oleh pod Kubernetes dibandingkan dengan keseluruhan CPU atau memori yang digunakan pada instans EC2 (yaitu, tidak memperhitungkan CPU atau memori yang tidak terpakai pada instance).
Persentase CPU atau memori yang digunakan oleh Kubernetes Pod dibandingkan dengan keseluruhan CPU atau memori yang tersedia pada Instance 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`
**Tabel 3: Rasio Pemanfaatan Komputasi**
| Nama Pod | Namespace | Pemanfaatan vcpu | Rasio Pemisahan vcpu | Pemanfaatan GPU | Rasio Pemisahan GPU | Pemanfaatan Memori | Rasio Pemisahan Memori |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Pod 1 | Ruang nama 1 | 0,242 | 0 | 0,125 | 0 | 0.205 | 0,227 |
| Pod 2 | Ruang nama 2 | 0,267 | 0 | 0,375 | 0 | 0,287 | 0.318 |
| Pod 3 | Ruang nama 1 | 0,242 | 0 | 0,25 | 0 | 0.205 | 0,227 |
| Pod 4 | Ruang nama 2 | 0,242 | 0 | 0,25 | 0 | 0.205 | 0,227 |
| Tidak terpakai | Tidak terpakai | 0 | | | | 0,098 | |
| | | 1 | 0 | 1 | 0 | 1 | 1 |
## Langkah 4: Hitung biaya split dan biaya yang tidak terpakai
Biaya Split
Alokasi biaya bayar per penggunaan biaya Instans EC2 berdasarkan alokasi CPU dan penggunaan memori oleh Kubernetes Pods
Biaya Instans yang Tidak Digunakan
Biaya CPU atau sumber daya memori yang tidak digunakan pada instance
`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`
[Catatan: Biaya yang tidak digunakan = Rasio util yang tidak digunakan \$1 Total sumber daya \$1 biaya per jam sumber daya]
**Tabel 4 - Ringkasan biaya Split dan Unused yang dihitung setiap jam untuk semua Pod yang berjalan di dalam klaster**
| Nama Pod | Namespace | Biaya Split | Biaya yang tidak terpakai | Total Biaya |
| --- | --- | --- | --- | --- |
| Pod 1 | Ruang nama 1 | \$11,85 | \$10,06 | \$11.91 |
| Pod 2 | Ruang nama 2 | \$13,18 | \$10,09 | \$13,26 |
| Pod 3 | Ruang nama 1 | \$12,35 | \$10,06 | \$12,41 |
| Pod 4 | Ruang nama 2 | \$12,35 | \$10,06 | \$12,41 |
| Total | | | | \$110 |
# Menggunakan label Kubernetes untuk alokasi biaya di EKS
Data alokasi biaya terpisah mendukung label Kubernetes sebagai tag alokasi biaya untuk klaster Amazon EKS. Meskipun label ini secara otomatis diimpor sebagai tag alokasi biaya yang ditentukan pengguna, label tersebut memerlukan aktivasi di tingkat akun manajemen. Setelah diaktifkan, Anda dapat menggunakannya untuk mengatribusikan biaya tingkat pod dalam Laporan Biaya dan Penggunaan (CUR) Anda menggunakan atribut khusus seperti pusat biaya, aplikasi, unit bisnis, dan lingkungan.
Fitur ini membantu organisasi melacak dan mengalokasikan biaya secara akurat di lingkungan EKS bersama di seluruh tim, proyek, atau departemen. Dengan menggunakan label Kubernetes, Anda dapat mengalokasikan biaya Kubernetes berdasarkan kebutuhan bisnis dan desain organisasi spesifik Anda.
## Prasyarat
Sebagai prasyarat untuk menggunakan label Kubernetes dengan data alokasi biaya terpisah:
+ Anda perlu mengaktifkan data alokasi biaya terpisah di konsol AWS Billing and Cost Management. Ini harus diaktifkan di tingkat akun manajemen. Untuk detailnya, lihat [Mengaktifkan data alokasi biaya terpisah](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Anda memerlukan kluster EKS yang ingin Anda lacak data alokasi biaya terpisah. Ini bisa berupa cluster yang sudah ada, atau Anda dapat membuat yang baru. Untuk informasi selengkapnya, lihat [Membuat klaster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) di *Panduan Pengguna Amazon EKS*.
+ Anda harus memiliki label yang ditetapkan ke pod Anda di klaster EKS. *Untuk informasi selengkapnya tentang cara membuat label di Kubernetes, lihat [Label dan Selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) di Dokumentasi Kubernetes.*
## Bekerja dengan label Kubernetes di EKS
Data alokasi biaya terpisah mendukung hingga 50 label Kubernetes per pod, yang diurutkan berdasarkan abjad sebelum diimpor sebagai tag alokasi biaya. Setiap label di luar 50 pertama secara otomatis dibuang. Jika Anda perlu menambahkan tag alokasi biaya baru setelah mencapai batas 50 label, Anda harus terlebih dahulu menghapus label yang ada dan memastikan label baru Anda masuk dalam 50 pertama saat diurutkan menurut abjad.
**catatan**
Beberapa layanan AWS terkelola secara otomatis menambahkan label ke pod EKS. Label ini dihitung terhadap batas 50 label per pod dan akan muncul di halaman tag alokasi biaya Anda.
Meskipun label Kubernetes tidak memiliki batasan ukuran, tag alokasi biaya memiliki batas karakter tertentu: 128 karakter untuk kunci tag dan 256 karakter untuk nilai tag. Label yang melebihi batas karakter ini akan dibuang dan tidak disajikan sebagai tag alokasi biaya. Disarankan untuk membuat label yang mengikuti batas karakter ini untuk tujuan alokasi biaya.
Label Kubernetes yang diimpor muncul sebagai tag alokasi biaya dan harus diaktifkan di tingkat akun pembayar. Untuk informasi selengkapnya tentang tag alokasi biaya dan aktivasi, lihat [Menggunakan tag alokasi biaya yang ditentukan pengguna](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html). Batas tag alokasi biaya berikut berlaku: 50 tag yang ditentukan pengguna per sumber daya dan 500 tag yang ditentukan pengguna per akun pembayar. Tag yang dihasilkan sistem tidak dihitung terhadap batas-batas ini.
**catatan**
Setelah Anda membuat dan menerapkan tag yang ditentukan pengguna ke sumber daya Anda, diperlukan waktu hingga 24 jam agar kunci tag muncul di halaman tag alokasi biaya Anda. Setelah Anda mengaktifkan tag, dibutuhkan waktu 24 jam tambahan agar mereka aktif.
## Mengelola label Kubernetes dan tag alokasi biaya
Anda dapat menambahkan, menghapus, dan mengedit label Kubernetes di EKS, serta menonaktifkan tag alokasi biaya terkait. Berikut ini menjelaskan perilaku yang diharapkan untuk setiap tindakan.
**Menambahkan label baru**
Anda dapat menambahkan label Kubernetes baru ke pod. Jika batas label 50 belum tercapai, label baru akan diimpor dan ditawarkan sebagai tag alokasi biaya, yang kemudian dapat diaktifkan. Namun, jika batas 50 telah tercapai, label baru tidak akan diimpor bahkan jika itu termasuk dalam urutan alfabet dari 50 label pertama. Anda harus terlebih dahulu menonaktifkan tag alokasi biaya yang ada untuk mengimpor label baru.
**Mengedit label**
Kubernetes tidak mengizinkan Anda untuk mengedit kunci label. Untuk mengubah kunci label, Anda harus menghapusnya dan menambahkan label baru. Namun, Anda dapat mengedit nilai label, yang akan tercermin dalam CUR berikutnya.
**Menghapus label**
Anda dapat menghapus label dari pod EKS. Perhatikan bahwa menghapus label tidak secara otomatis menonaktifkan tag alokasi biaya terkait. Data alokasi biaya terpisah akan terus terisi di CUR hingga Anda secara eksplisit menonaktifkan tag alokasi biaya.
**Menonaktifkan tag alokasi biaya**
Anda dapat menonaktifkan tag alokasi biaya apa pun yang dibuat dari label Kubernetes. Setelah dinonaktifkan, data tidak akan lagi terisi di kolom masing-masing, dan kolom akan dihapus dari CUR bulan depan.
## Praktik terbaik untuk mengelola label Kubernetes untuk alokasi biaya
Label Kubernetes memberikan fleksibilitas yang signifikan dalam pemodelan alokasi biaya bersama. Untuk memaksimalkan potensi kemampuan ini, kami sarankan mengikuti praktik terbaik ini untuk mengoptimalkan pendekatan manajemen biaya Anda.
**Memahami batas label**
label-per-pod Batas 50 didasarkan pada penyortiran abjad. Hanya 50 label pertama yang diurutkan menurut abjad yang akan diimpor untuk alokasi biaya. Untuk memastikan label penting disertakan, rencanakan penamaan label Anda dengan hati-hati untuk memastikan label penting muncul dalam 50 pertama saat diurutkan menurut abjad.
**Mengikuti kendala karakter**
AWS tag alokasi biaya memiliki batas karakter berikut:
+ Tombol tag: 128 karakter
+ Nilai tag: 256 karakter
Meskipun Kubernetes mengizinkan label yang lebih panjang, label apa pun yang melebihi batas ini tidak akan diimpor. Rancang label Anda dalam batas-batas ini untuk memastikan pelacakan alokasi biaya yang berhasil.
**Menambahkan label baru saat berkapasitas**
Ketika sebuah pod telah mencapai batas 50 label dan Anda perlu menambahkan label alokasi biaya baru, ikuti langkah-langkah berikut:
1. Tinjau label yang ada dan identifikasi tag alokasi biaya untuk dinonaktifkan.
1. Nonaktifkan tag yang dipilih.
1. Tambahkan label alokasi biaya baru.
1. Pastikan label baru termasuk dalam 50 label pertama yang diurutkan menurut abjad.
**catatan**
Ingatlah bahwa hanya 50 label pertama yang diurutkan menurut abjad yang digunakan untuk alokasi biaya.
# Menggunakan data alokasi biaya terpisah dengan Amazon Managed Service untuk Prometheus
Memisahkan data biaya untuk Amazon EKS mengharuskan Anda mengumpulkan dan menyimpan metrik dari cluster Anda, termasuk memori dan penggunaan CPU. Amazon Managed Service untuk Prometheus dapat digunakan untuk tujuan ini.
Setelah Anda memilih untuk membagi data alokasi biaya dan Layanan Terkelola Amazon untuk ruang kerja Prometheus mulai menerima dua metrik yang diperlukan (`container_cpu_usage_seconds_total`dan`container_memory_working_set_bytes`), data alokasi biaya terpisah mengenali metrik dan menggunakannya secara otomatis.
**catatan**
Dua metrik yang diperlukan (`container_cpu_usage_seconds_total`dan`container_memory_working_set_bytes`) hadir dalam konfigurasi scrape Prometheus default dan konfigurasi default yang disediakan dengan kolektor terkelola. AWS Namun, jika Anda menyesuaikan konfigurasi ini, jangan memberi label ulang, memodifikasi, atau menghapus label berikut dari `container_memory_working_set_bytes` metrik `container_cpu_usage_seconds_total` dan:`name`,, `namespace` dan. `pod` Jika Anda memberi label ulang, memodifikasi, atau menghapus label ini, itu dapat memengaruhi konsumsi metrik Anda.
Anda dapat menggunakan Layanan Terkelola Amazon untuk Prometheus untuk mengumpulkan metrik EKS dari satu akun penggunaan, di satu Wilayah. Layanan Terkelola Amazon untuk ruang kerja Prometheus harus ada di akun dan Wilayah tersebut. Anda memerlukan satu Layanan Terkelola Amazon untuk instans Prometheus untuk setiap akun penggunaan dan Wilayah yang ingin Anda pantau biayanya. Anda dapat mengumpulkan metrik untuk beberapa klaster di Layanan Terkelola Amazon untuk ruang kerja Prometheus, selama mereka berada di akun penggunaan dan Wilayah yang sama.
Bagian berikut menjelaskan cara mengirim metrik yang benar dari kluster EKS Anda ke Amazon Managed Service untuk ruang kerja Prometheus.
## Prasyarat
Sebagai prasyarat untuk menggunakan Amazon Managed Service untuk Prometheus dengan data alokasi biaya terpisah:
+ Anda perlu mengaktifkan data alokasi biaya terpisah di konsol AWS Billing and Cost Management. Untuk detailnya, lihat [Mengaktifkan data alokasi biaya terpisah](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html). Memilih untuk membagi data alokasi biaya akan membuat peran terkait layanan di setiap akun penggunaan untuk menanyakan Layanan Terkelola Amazon untuk Prometheus untuk metrik klaster Amazon EKS di akun tersebut. Untuk informasi selengkapnya, lihat [Peran terkait layanan untuk data alokasi biaya terpisah](https://docs.aws.amazon.com/cost-management/latest/userguide/split-cost-allocation-data-SLR.html).
+ Anda memerlukan kluster EKS yang ingin Anda lacak data alokasi biaya terpisah. Ini bisa berupa cluster yang sudah ada, atau Anda dapat membuat yang baru. Untuk informasi selengkapnya, lihat [Membuat klaster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) di *Panduan Pengguna Amazon EKS*.
**catatan**
Anda akan membutuhkan`EKS cluster ARN`,`security group IDs`, dan setidaknya dua `subnet IDs` (di zona ketersediaan yang berbeda) untuk digunakan dalam langkah selanjutnya.
(opsional) Setel mode otentikasi kluster EKS Anda ke salah satu `API` atau`API_AND_CONFIG_MAP`.
+ Anda memerlukan Layanan Terkelola Amazon untuk instans Prometheus di akun dan Wilayah yang sama dengan kluster EKS Anda. Jika Anda belum memilikinya, Anda dapat membuatnya. Untuk informasi selengkapnya tentang membuat Layanan Terkelola Amazon untuk instance Prometheus, [lihat Membuat ruang kerja](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) di Panduan Pengguna Layanan *Terkelola Amazon* untuk Prometheus.
**catatan**
Anda akan membutuhkan `Amazon Managed Service for Prometheus workspace ARN` untuk digunakan dalam langkah-langkah selanjutnya.
## Meneruskan metrik EKS ke Layanan Terkelola Amazon untuk Prometheus
Setelah Anda memiliki kluster EKS dan Layanan Terkelola Amazon untuk instance Prometheus, Anda dapat meneruskan metrik dari cluster ke instance. Anda dapat mengirim metrik dengan dua cara.
+ [Opsi 1: Gunakan kolektor AWS terkelola.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#use-managed-collector) Ini adalah cara paling sederhana untuk mengirim metrik dari kluster EKS ke Amazon Managed Service untuk Prometheus. Namun, itu memang memiliki batas hanya menggores metrik setiap 30 detik paling banyak.
+ [Opsi 2: Buat agen Prometheus Anda sendiri.](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent) Dalam hal ini, Anda memiliki kontrol lebih besar atas konfigurasi pengikisan, tetapi Anda harus mengelola agen setelah membuatnya.
### Opsi 1: Menggunakan kolektor AWS terkelola
Menggunakan kolektor AWS terkelola (*scraper*) adalah cara paling sederhana untuk mengirim metrik dari kluster EKS ke Layanan Terkelola Amazon untuk instance Prometheus. Prosedur berikut akan membantu Anda membuat kolektor AWS terkelola. Untuk informasi selengkapnya, lihat [pengumpul AWS terkelola](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html) di *Amazon Managed Service for Prometheus* User Guide.
**catatan**
AWS kolektor yang dikelola memiliki interval goresan minimum 30 detik. Jika Anda memiliki pod berumur pendek, rekomendasinya adalah mengatur interval scraper Anda menjadi 15 detik. Untuk menggunakan interval scraper 15 detik, gunakan opsi 2 untuk [membuat agen Prometheus Anda sendiri](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data-resource-amp.html#create-prometheus-agent).
Ada tiga langkah untuk membuat kolektor AWS terkelola:
1. Buat konfigurasi scraper.
1. Buat scraper.
1. Konfigurasikan kluster EKS Anda untuk memungkinkan scraper mengakses metrik.
*Langkah 1: Buat konfigurasi scraper*
Untuk membuat scraper, Anda harus memiliki konfigurasi scraper. Anda dapat menggunakan konfigurasi default, atau membuat sendiri. Berikut ini adalah tiga cara untuk mendapatkan konfigurasi scraper:
+ Dapatkan konfigurasi default menggunakan AWS CLI, dengan memanggil:
```
aws amp get-default-scraper-configuration
```
+ Buat konfigurasi Anda sendiri. Untuk detailnya, lihat petunjuk [konfigurasi Scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) di *Amazon Managed Service for Prometheus* User Guide.
+ Salin konfigurasi sampel yang disediakan dalam instruksi [konfigurasi Scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) yang sama di *Amazon Managed Service for Prometheus* User Guide.
Anda dapat mengedit konfigurasi scraper, untuk memodifikasi interval scrape atau untuk memfilter metrik yang tergores, misalnya.
Untuk memfilter metrik yang dikikis agar hanya menyertakan dua yang diperlukan untuk membagi data alokasi biaya, gunakan konfigurasi scraper berikut:
```
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
```
*Setelah Anda memiliki konfigurasi scraper, Anda harus mengkodekannya base64 untuk digunakan pada langkah 2.* Konfigurasi adalah file teks YAMM. Untuk menyandikan file, gunakan situs web seperti [https://www.base64encode.org/.](https://www.base64encode.org/)
*Langkah 2: Buat scraper*
Sekarang setelah Anda memiliki file konfigurasi, Anda perlu membuat scraper Anda. Buat scraper menggunakan perintah AWS CLI berikut, berdasarkan variabel yang diuraikan di bagian prasyarat. Anda harus menggunakan informasi dari kluster EKS untuk**,**, dan ** bidang, ganti ** dengan konfigurasi scraper yang Anda buat pada langkah sebelumnya, dan ganti ** dengan Layanan Terkelola Amazon untuk ARN ruang kerja Prometheus.
```
aws amp create-scraper \
--source eksConfiguration="{clusterArn=,securityGroupIds=[],subnetIds=[]}" \
--scrape-configuration configurationBlob= \
--destination ampConfiguration={workspaceArn=""}
```
Catat `scraperId` yang dikembalikan untuk digunakan pada *langkah 3*.
*Langkah 3: Konfigurasikan cluster EKS Anda untuk memungkinkan scraper mengakses metrik*
Jika mode otentikasi kluster EKS Anda disetel ke salah satu `API` atau`API_AND_CONFIG_MAP`, maka scraper Anda akan secara otomatis memiliki kebijakan akses dalam cluster yang benar, dan pencakar akan memiliki akses ke cluster Anda. Tidak diperlukan konfigurasi lebih lanjut, dan metrik harus mengalir ke Amazon Managed Service untuk Prometheus.
Jika mode otentikasi kluster EKS Anda tidak disetel ke `API` atau`API_AND_CONFIG_MAP`, Anda perlu mengonfigurasi cluster secara manual untuk memungkinkan scraper mengakses metrik Anda melalui dan. ClusterRole ClusterRoleBinding Untuk mempelajari cara mengaktifkan izin ini, lihat [Mengkonfigurasi kluster EKS secara manual untuk akses scraper di Amazon Managed Service for](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup) *Prometheus* User Guide.
Setelah scraper aktif, verifikasi bahwa kedua metrik (`container_cpu_usage_seconds_total`dan`container_memory_working_set_bytes`) didorong ke Layanan Terkelola Amazon Anda untuk ruang kerja Prometheus.
```
awscurl --service="aps" --region="" "https://aps-workspaces..amazonaws.com/workspaces//api/v1/label/__name__/values"
```
Output:
```
{
"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"
]
}
```
### Opsi 2: Membuat agen Prometheus Anda sendiri
Jika Anda tidak dapat menggunakan kolektor AWS terkelola, atau sudah memiliki server Prometheus sendiri, Anda dapat menggunakan instance Prometheus Anda sendiri sebagai agen untuk mengikis metrik dari kluster EKS Anda dan mengirimkannya ke Amazon Managed Service untuk Prometheus.
*Untuk petunjuk terperinci tentang cara menggunakan instans Prometheus Anda sendiri sebagai agen, lihat [Menggunakan instance Prometheus sebagai kolektor di Amazon Managed Service for Prometheus User Guide](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-ingest-with-prometheus.html).*
Berikut ini adalah contoh konfigurasi scrape Prometheus yang mencakup interval pengikisan server Prometheus dan metrik wadah yang diperlukan untuk membagi data alokasi biaya. Jika Anda memiliki pod yang berumur pendek, rekomendasinya adalah menurunkan interval pengikisan server Prometheus default dari 30 detik menjadi 15 detik. Perhatikan bahwa ini dapat mengakibatkan penggunaan memori server Prometheus yang tinggi.
```
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
```
Jika Anda mengikuti [Mengatur konsumsi dari server Prometheus baru menggunakan Helm di dalam Amazon *Managed Service for Prometheus*](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-ingest-metrics-new-Prometheus.html) User Guide, maka Anda dapat memperbarui konfigurasi scrape Anda.
**Untuk memperbarui konfigurasi scrape Anda**
1. Edit `my_prometheus_values_yaml` dari panduan dan sertakan konfigurasi scrape sampel di blok. `server`
1. Jalankan perintah berikut, menggunakan `prometheus-chart-name` dan `prometheus-namespace` dari *Amazon Managed Service for Prometheus User Guide*.
```
helm upgrade prometheus-chart-name prometheus-community/prometheus -n prometheus-namespace -f my_prometheus_values_yaml
```
[Untuk mempelajari lebih lanjut tentang `scrape_interval` atau cara menggunakan scrape\$1interval non-global, lihat konfigurasi scrape Prometheus.](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)
Atau, Anda dapat menggunakan AWS Distro untuk OpenTelemetry kolektor yang memiliki Penerima Prometheus, Eksportir Tulis Jarak Jauh Prometheus, dan AWS Ekstensi Otentikasi Sigv4 untuk mencapai akses tulis jarak jauh ke Amazon Managed Service untuk Prometheus.
**catatan**
Setelah Anda mengatur agen Prometheus Anda, AWS tidak seperti kolektor terkelola, Anda bertanggung jawab untuk menjaga agen tetap up to date dan berjalan untuk mengumpulkan metrik.
## Memperkirakan Layanan Terkelola Amazon Anda untuk biaya Prometheus
Anda dapat menggunakan Kalkulator AWS Harga untuk memperkirakan biaya penggunaan Amazon Managed Service untuk Prometheus untuk data alokasi biaya terpisah.
**Untuk mengonfigurasi Amazon Managed Service untuk Prometheus untuk perkiraan Anda**
1. Kalkulator AWS Harga Terbuka di [https://calculator.aws/\$1/](https://calculator.aws/#/).
1. Pilih **Buat estimasi**.
1. **Pada halaman **Tambah layanan**, masukkan **Amazon Managed Service untuk Prometheus** di kolom pencarian, lalu pilih Configure.**
1. Di bidang **Deskripsi**, masukkan deskripsi untuk perkiraan Anda.
1. Pilih **Wilayah**.
1. Pilih **Hitung biaya menggunakan detail infrastruktur Anda**. Opsi ini memungkinkan Anda memperkirakan biaya konsumsi, penyimpanan, dan kueri sampel berdasarkan penyiapan infrastruktur Anda saat ini atau yang diusulkan.
1. Untuk **Jumlah instans EC2**, masukkan jumlah instans EC2 di semua klaster untuk seluruh keluarga penagihan gabungan Anda (termasuk semua akun dan Wilayah). Jika Anda menggunakan AWS Fargate, gunakan jumlah tugas Fargate sebagai proxy untuk jumlah instans EC2 Anda.
1. Data alokasi biaya terpisah membutuhkan dua metrik: `container_cpu_usage_seconds_total` dan. `container_memory_working_set_bytes` Untuk **metrik Prometheus per instans EC2**, masukkan 2.
1. Data alokasi biaya terpisah menunjukkan interval gesekan 15 detik. Untuk **interval pengumpulan Metrik (dalam detik)**, masukkan 15. Jika Anda menggunakan interval yang berbeda (misalnya, 30 detik), ubah ini ke interval yang Anda atur.
1. Data alokasi biaya terpisah tidak memaksakan persyaratan khusus apa pun untuk parameter lain, jadi masukkan nilai yang sesuai untuk parameter input lainnya sesuai kebutuhan bisnis Anda.
1. Pilih **Simpan dan tambahkan layanan**.
# Menggunakan data alokasi biaya terpisah dengan Amazon CloudWatch Container Insights
Memisahkan data biaya untuk Amazon EKS mengharuskan Anda mengumpulkan dan menyimpan metrik dari cluster Anda, termasuk memori dan penggunaan CPU. Amazon CloudWatch Container Insights dapat digunakan untuk tujuan ini.
Setelah Anda memilih untuk membagi data alokasi biaya dan menyiapkan CloudWatch agen dengan add-on observabilitas EKS di cluster EKS Anda, data alokasi biaya terpisah mulai menerima dua metrik yang diperlukan `(pod_cpu_usage_total` dan`pod_memory_working_set`) di namespace dan menggunakannya secara otomatis. `ContainerInsights` *Untuk melihat set lengkap metrik container untuk EKS, lihat metrik [Amazon EKS dan Kubernetes Container Insights di Panduan](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) Pengguna Amazon. CloudWatch *
Bagian berikut menjelaskan cara mengirim metrik yang benar dari kluster EKS Anda untuk membagi data alokasi biaya.
## Prasyarat
Sebagai prasyarat untuk menggunakan Amazon CloudWatch Container Insights dengan data alokasi biaya terpisah:
+ Anda perlu mengaktifkan data alokasi biaya terpisah di konsol AWS Billing and Cost Management. Untuk detailnya, lihat [Mengaktifkan data alokasi biaya terpisah](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html).
+ Anda memerlukan kluster EKS yang ingin Anda lacak data alokasi biaya terpisah. Ini bisa berupa cluster yang sudah ada, atau Anda dapat membuat yang baru. Untuk informasi selengkapnya, lihat [Membuat klaster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) di *Panduan Pengguna Amazon EKS*.
## Menyiapkan Amazon CloudWatch Container Insights untuk meneruskan metrik EKS
Anda perlu mengatur dan mengonfigurasi CloudWatch agen untuk meneruskan metrik EKS. Anda dapat menggunakan [add-on Amazon CloudWatch Observability EKS atau bagan Helm CloudWatch Observability Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) untuk menginstal CloudWatch agen dan agen Fluent-bit pada cluster EKS. Untuk informasi selengkapnya tentang cara menginstal dan menyiapkan CloudWatch agen, lihat [Menginstal add-on Amazon CloudWatch Observability EKS di CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html) *Panduan Pengguna Amazon*.
Berikut ini adalah versi minimum yang diperlukan untuk CloudWatch agen dan add-on EKS:
+ CloudWatch versi agen: v1.300045.0
+ CloudWatch Versi pengaya Observability EKS: v2.0.1-eksbuild.1
## Memperkirakan biaya Amazon CloudWatch Anda
Mengaktifkan fitur untuk menggunakan Amazon CloudWatch Container Insights dengan data alokasi biaya terpisah menambahkan dua metrik baru ke CloudWatch Amazon Container Insights: dan. `pod_cpu_usage_total` `pod_memory_working_set` *Untuk detail tentang metrik ini, lihat metrik [Amazon EKS dan Kubernetes Container Insights di Panduan Pengguna](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) Amazon. CloudWatch *
**Untuk memahami biaya yang terkait dengan fitur**
1. Buka CloudWatch Harga Amazon dengan [https://aws.amazon.com/cloudwatch/harga/.](https://aws.amazon.com/cloudwatch/pricing/)
1. Arahkan ke bagian **Tingkat berbayar**.
1. Pilih tab **Wawasan Kontainer**.
1. Untuk perhitungan biaya secara terperinci, buka bagian **Contoh Harga, dan lihat Contoh** **13 - Wawasan Kontainer untuk Amazon EKS dan Kubernetes**.