Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Observabilitas
Pengantar
Alat observabilitas membantu Anda mendeteksi, memulihkan, dan menyelidiki beban kerja Anda secara efisien. Biaya data telemetri meningkat secara alami seiring dengan meningkatnya penggunaan EKS. Terkadang, mungkin sulit untuk menyeimbangkan kebutuhan operasional Anda dan mengukur apa yang penting bagi bisnis Anda dan menjaga biaya pengamatan tetap terkendali. Panduan ini berfokus pada strategi pengoptimalan biaya untuk tiga pilar pengamatan: log, metrik, dan jejak. Masing-masing praktik terbaik ini dapat diterapkan secara independen agar sesuai dengan tujuan pengoptimalan organisasi Anda.
Pencatatan log
Logging memainkan peran penting dalam memantau dan memecahkan masalah aplikasi di cluster Anda. Ada beberapa strategi yang dapat digunakan untuk mengoptimalkan biaya logging. Strategi praktik terbaik yang tercantum di bawah ini termasuk memeriksa kebijakan penyimpanan log Anda untuk menerapkan kontrol terperinci tentang berapa lama data log disimpan, mengirim data log ke opsi penyimpanan yang berbeda berdasarkan kepentingan, dan memanfaatkan penyaringan log untuk mempersempit jenis pesan log yang disimpan. Mengelola telemetri log secara efisien dapat menghemat biaya untuk lingkungan Anda.
Pesawat Kontrol EKS
Optimalkan Log Pesawat Kontrol Anda
Bidang kontrol Kubernetes adalah sekumpulan komponen
Misalnya, di klaster non-produksi, aktifkan jenis log tertentu secara selektif, seperti log server api, hanya untuk analisis dan nonaktifkan sesudahnya. Tetapi untuk cluster produksi, di mana Anda mungkin tidak dapat mereproduksi peristiwa, dan menyelesaikan masalah memerlukan lebih banyak informasi log, maka Anda dapat mengaktifkan semua jenis log. Rincian implementasi pengoptimalan biaya bidang kontrol lebih lanjut ada di posting blog
Streaming Log ke S3
Praktik terbaik pengoptimalan biaya lainnya adalah streaming log pesawat kontrol ke S3 melalui langganan CloudWatch Log. Memanfaatkan langganan CloudWatch Log memungkinkan Anda meneruskan log secara selektif ke S3 yang menyediakan penyimpanan jangka panjang yang lebih hemat biaya dibandingkan dengan menyimpan log tanpa batas waktu. CloudWatch Misalnya, untuk kluster produksi, Anda dapat membuat grup log kritis dan memanfaatkan langganan untuk mengalirkan log ini ke S3 setelah 15 hari. Ini akan memastikan Anda memiliki akses cepat ke log untuk analisis tetapi juga menghemat biaya dengan memindahkan log ke penyimpanan yang lebih hemat biaya.
penting
Pada 9/5/2023 log EKS diklasifikasikan sebagai Vded Logs di Amazon Logs. CloudWatch Vending Logs adalah log layanan AWS khusus yang diterbitkan secara native oleh layanan AWS atas nama pelanggan dan tersedia dengan harga diskon volume. Silakan kunjungi halaman CloudWatch harga Amazon
Pesawat Data EKS
Retensi Log
Kebijakan penyimpanan default Amazon CloudWatch adalah menyimpan log tanpa batas waktu dan tidak pernah kedaluwarsa, menimbulkan biaya penyimpanan yang berlaku untuk wilayah AWS Anda. Untuk mengurangi biaya penyimpanan, Anda dapat menyesuaikan kebijakan penyimpanan untuk setiap grup log berdasarkan persyaratan beban kerja Anda.
Dalam lingkungan pengembangan, periode retensi yang panjang mungkin tidak diperlukan. Namun di lingkungan produksi, Anda dapat menetapkan kebijakan retensi yang lebih lama untuk memenuhi persyaratan pemecahan masalah, kepatuhan, dan perencanaan kapasitas. Misalnya, jika Anda menjalankan aplikasi e-commerce selama musim liburan puncak, sistem berada di bawah beban yang lebih berat dan masalah dapat muncul yang mungkin tidak segera terlihat, Anda akan ingin mengatur retensi log yang lebih lama untuk pemecahan masalah terperinci dan analisis posting acara.
Anda dapat mengonfigurasi periode retensi Anda di CloudWatch konsol AWS atau AWS API dengan durasi dari 1 hari hingga 10 tahun berdasarkan setiap grup log. Memiliki periode retensi yang fleksibel dapat menghemat biaya penyimpanan log, sekaligus mempertahankan log penting.
Opsi Penyimpanan Log
Penyimpanan adalah pendorong besar biaya observabilitas oleh karena itu sangat penting untuk mengoptimalkan strategi penyimpanan log Anda. Strategi Anda harus selaras dengan persyaratan beban kerja Anda sambil mempertahankan kinerja dan skalabilitas. Salah satu strategi untuk mengurangi biaya penyimpanan log adalah dengan memanfaatkan bucket AWS S3 dan tingkatan penyimpanannya yang berbeda.
Teruskan log langsung ke S3
Pertimbangkan untuk meneruskan log yang kurang penting, seperti lingkungan pengembangan, langsung ke S3 alih-alih Cloudwatch. Ini dapat berdampak langsung pada biaya penyimpanan log. Salah satu opsi adalah meneruskan log langsung ke S3 menggunakan Fluentbit. Anda menentukan ini di [OUTPUT] bagian, tujuan di mana FluentBit mentransmisikan log kontainer untuk retensi. Tinjau parameter konfigurasi tambahan di sini
[OUTPUT]
Name eks_to_s3
Match application.*
bucket $S3_BUCKET name
region us-east-2
store_dir /var/log/fluentbit
total_file_size 30M
upload_timeout 3m
Teruskan log CloudWatch hanya untuk analisis jangka pendek
Untuk log yang lebih penting, seperti lingkungan produksi di mana Anda mungkin perlu melakukan analisis segera pada data, pertimbangkan untuk meneruskan log ke. CloudWatch Anda menentukan ini di [OUTPUT] bagian, tujuan di mana FluentBit mentransmisikan log kontainer untuk retensi. Tinjau parameter konfigurasi tambahan di sini
[OUTPUT]
Name eks_to_cloudwatch_logs
Match application.*
region us-east-2
log_group_name fluent-bit-cloudwatch
log_stream_prefix from-fluent-bit-
auto_create_group On
Namun, ini tidak akan berdampak instan pada penghematan biaya Anda. Untuk penghematan tambahan, Anda harus mengekspor log ini ke Amazon S3.
Ekspor ke Amazon S3 dari CloudWatch
Untuk menyimpan CloudWatch log Amazon dalam jangka panjang, sebaiknya ekspor CloudWatch log Amazon EKS Anda ke Amazon Simple Storage Service (Amazon S3). Anda dapat meneruskan log ke bucket Amazon S3 dengan membuat tugas ekspor melalui Konsol atau API. Setelah Anda melakukannya, Amazon S3 menghadirkan banyak opsi untuk lebih mengurangi biaya. Anda dapat menentukan aturan Siklus Hidup Amazon S3 Anda sendiri untuk memindahkan log Anda ke kelas penyimpanan yang sesuai dengan kebutuhan Anda, atau memanfaatkan kelas penyimpanan Amazon S3 Intelligent-Tiering
Kurangi Level Log
Berlatih pencatatan selektif untuk aplikasi Anda. Baik aplikasi dan node Anda mengeluarkan log secara default. Untuk log aplikasi Anda, sesuaikan level log agar selaras dengan kekritisan beban kerja dan lingkungan. Misalnya, aplikasi java di bawah ini mengeluarkan INFO log yang merupakan konfigurasi aplikasi default yang khas dan tergantung pada kode dapat menghasilkan volume data log yang tinggi.
import org.apache.log4j.*; public class LogClass { private static org.apache.log4j.Logger log = Logger.getLogger(LogClass.class); public static void main(String[] args) { log.setLevel(Level.INFO); log.debug("This is a DEBUG message, check this out!"); log.info("This is an INFO message, nothing to see here!"); log.warn("This is a WARN message, investigate this!"); log.error("This is an ERROR message, check this out!"); log.fatal("This is a FATAL message, investigate this!"); } }
Dalam lingkungan pengembangan, ubah level log Anda menjadiDEBUG, karena ini dapat membantu Anda men-debug masalah atau menangkap masalah potensial sebelum masuk ke produksi.
log.setLevel(Level.DEBUG);
Dalam lingkungan produksi, pertimbangkan untuk memodifikasi level log Anda ke ERROR atauFATAL. Ini akan menampilkan log hanya ketika aplikasi Anda memiliki kesalahan, mengurangi output log dan membantu Anda fokus pada data penting tentang status aplikasi Anda.
log.setLevel(Level.ERROR);
Anda dapat menyempurnakan berbagai level log komponen Kubernetes. Misalnya, jika Anda menggunakan Bottlerocketkubelet
[settings.kubernetes] log-level = "2" image-gc-high-threshold-percent = "85" image-gc-low-threshold-percent = "80"
Untuk lingkungan pengembangan, Anda dapat mengatur level log lebih besar dari 2 untuk melihat peristiwa tambahan, ini bagus untuk debugging. Untuk lingkungan produksi, Anda dapat mengatur level ke 0 untuk hanya melihat peristiwa penting.
Filter Leverage
Saat menggunakan konfigurasi EKS Fluentbit default untuk mengirim log kontainer ke Cloudwatch, FluentBit menangkap dan mengirim SEMUA log kontainer aplikasi yang diperkaya dengan metadata Kubernetes ke Cloudwatch seperti yang ditunjukkan pada blok konfigurasi di bawah ini. [INPUT]
[INPUT]
Name tail
Tag application.*
Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/kube-proxy*
Path /var/log/containers/*.log
Docker_Mode On
Docker_Mode_Flush 5
Docker_Mode_Parser container_firstline
Parser docker
DB /var/fluent-bit/state/flb_container.db
Mem_Buf_Limit 50MB
Skip_Long_Lines On
Refresh_Interval 10
Rotate_Wait 30
storage.type filesystem
Read_from_Head ${READ_FROM_HEAD}
[INPUT]Bagian di atas menelan semua log kontainer. Ini dapat menghasilkan sejumlah besar data yang mungkin tidak diperlukan. Memfilter data ini dapat mengurangi jumlah data log yang dikirim CloudWatch sehingga mengurangi biaya Anda. Anda dapat menerapkan filter ke log Anda sebelum output ke CloudWatch. Fluentbit mendefinisikan ini di bagian. [FILTER] Misalnya, memfilter metadata Kubernetes agar tidak ditambahkan ke peristiwa log dapat mengurangi volume log Anda.
[FILTER]
Name nest
Match application.*
Operation lift
Nested_under kubernetes
Add_prefix Kube.
[FILTER]
Name modify
Match application.*
Remove Kube.<Metadata_1>
Remove Kube.<Metadata_2>
Remove Kube.<Metadata_3>
[FILTER]
Name nest
Match application.*
Operation nest
Wildcard Kube.*
Nested_under kubernetes
Remove_prefix Kube.
Metrik
Metrik
Pantau apa yang penting dan kumpulkan hanya apa yang Anda butuhkan
Strategi pengurangan biaya pertama adalah mengurangi jumlah metrik yang Anda kumpulkan dan pada gilirannya, mengurangi biaya retensi.
-
Mulailah dengan bekerja mundur dari persyaratan Anda dan/atau pemangku kepentingan Anda untuk menentukan metrik yang paling
penting. Metrik sukses berbeda untuk semua orang! Ketahui seperti apa penampilan yang baik dan ukur untuk itu. -
Pertimbangkan untuk menyelam jauh ke dalam beban kerja yang Anda dukung dan identifikasi Indikator Kinerja Utama (KPIs) alias 'Sinyal Emas'. Ini harus selaras dengan persyaratan bisnis dan pemangku kepentingan. Menghitung SLIs, SLOs, dan SLAs menggunakan Amazon CloudWatch dan Metric Math sangat penting untuk mengelola keandalan layanan. Ikuti praktik terbaik yang diuraikan dalam panduan
ini untuk memantau dan mempertahankan kinerja lingkungan EKS Anda secara efektif. -
Kemudian lanjutkan melalui berbagai lapisan infrastruktur untuk menghubungkan dan menghubungkan
kluster EKS, node, dan metrik infrastruktur tambahan dengan beban kerja Anda. KPIs Simpan metrik bisnis dan metrik operasional Anda dalam sistem di mana Anda dapat menghubungkannya bersama-sama dan menarik kesimpulan berdasarkan dampak yang diamati pada keduanya. -
EKS mengekspos metrik dari bidang kontrol, cluster, pod kube-state-metrics, dan node. Relevansi semua metrik ini tergantung pada kebutuhan Anda, namun kemungkinan Anda tidak memerlukan setiap metrik tunggal di lapisan yang berbeda. Anda dapat menggunakan panduan metrik penting EKS
ini sebagai dasar untuk memantau kesehatan keseluruhan cluster EKS dan beban kerja Anda.
Berikut adalah contoh konfigurasi scrape prometheus di mana kita menggunakan relabel_config untuk menyimpan hanya metrik kubelet dan untuk menghapus semua metrik container. metric_relabel_config
kubernetes_sd_configs: - role: endpoints namespaces: names: - kube-system bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true relabel_configs: - source_labels: [__meta_kubernetes_service_label_k8s_app] regex: kubelet action: keep metric_relabel_configs: - source_labels: [__name__] regex: container_(network_tcp_usage_total|network_udp_usage_total|tasks_state|cpu_load_average_10s) action: drop
Kurangi kardinalitas jika berlaku
Kardinalitas mengacu pada keunikan nilai data dalam kombinasi dengan dimensinya (misalnya label prometheus) untuk kumpulan metrik tertentu. Metrik kardinalitas tinggi memiliki banyak dimensi dan setiap kombinasi metrik dimensi memiliki keunikan yang lebih tinggi. Kardinalitas yang lebih tinggi menghasilkan ukuran data telemetri metrik yang lebih besar dan kebutuhan penyimpanan yang meningkatkan biaya.
Dalam contoh kardinalitas tinggi di bawah ini, kita melihat bahwa Metrik, Latensi, memiliki Dimensi, RequesTid, CustomerID, dan Layanan dan setiap Dimensi memiliki banyak nilai unik. Kardinalitas adalah ukuran kombinasi jumlah nilai yang mungkin per Dimensi. Dalam Prometheus, setiap set dimensi/label unik dianggap sebagai metrik baru, oleh karena itu kardinalitas tinggi berarti lebih banyak metrik.
Di lingkungan EKS dengan banyak metrik dan dimensi/label per metrik (Cluster, Namespace, Service, Pod, Container, dll), kardinalitas cenderung tumbuh. Untuk mengoptimalkan biaya, pertimbangkan kardinalitas metrik yang Anda kumpulkan dengan hati-hati. Misalnya, jika Anda menggabungkan metrik tertentu untuk visualisasi di tingkat cluster, maka Anda dapat menjatuhkan label tambahan yang berada di lapisan bawah seperti label namespace.
Untuk mengidentifikasi metrik kardinalitas tinggi di prometheus, Anda dapat menjalankan kueri PROMQL berikut untuk menentukan target scrape mana yang memiliki jumlah metrik (kardinalitas) tertinggi:
topk_max(5, max_over_time(scrape_samples_scraped[1h]))
dan kueri PROMQL berikut dapat membantu Anda menentukan target scrape mana yang memiliki tingkat churn metrik tertinggi (berapa banyak seri metrik baru yang dibuat dalam gesekan tertentu):
topk_max(5, max_over_time(scrape_series_added[1h]))
Jika Anda menggunakan grafana, Anda dapat menggunakan Mimirtool Grafana Lab untuk menganalisis dasbor grafana dan aturan prometheus Anda untuk mengidentifikasi metrik kardinalitas tinggi yang tidak digunakan. Ikuti panduan inimimirtool analyze prometheus perintah mimirtool analyze dan untuk mengidentifikasi metrik aktif yang tidak direferensikan di dasbor Anda.
Pertimbangkan granularitas metrik
Mengumpulkan metrik pada granularitas yang lebih tinggi seperti setiap detik vs setiap menit dapat berdampak besar pada seberapa banyak telemetri dikumpulkan dan disimpan yang meningkatkan biaya. Tentukan interval pengumpulan gesekan atau metrik yang masuk akal yang menyeimbangkan antara granularitas yang cukup untuk melihat masalah sementara dan cukup rendah agar hemat biaya. Kurangi granularitas untuk metrik yang digunakan untuk perencanaan kapasitas dan analisis jendela waktu yang lebih besar.
penting
interval gesekan prometheus global diatur ke 15 detik. Interval gesekan ini dapat ditingkatkan sehingga terjadi penurunan jumlah data metrik yang dikumpulkan di prometheus.
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: my-collector-amp
...
config: |
extensions:
sigv4auth:
region: "+++<YOUR_AWS_REGION>+++" service: "aps"+++</YOUR_AWS_REGION>+++
receivers:
#
# Scrape configuration for the Prometheus Receiver
# This is the same configuration used when Prometheus is installed using the community Helm chart
#
prometheus:
config:
global: scrape_interval: 15s
scrape_timeout: 10s
Pelacakan
Biaya utama yang terkait dengan penelusuran berasal dari generasi penyimpanan jejak. Dengan penelusuran, tujuannya adalah untuk mengumpulkan data yang cukup untuk mendiagnosis dan memahami aspek kinerja. Namun, karena biaya jejak X-Ray didasarkan pada data yang diteruskan ke X-Ray, menghapus jejak setelah diteruskan tidak akan mengurangi biaya Anda. Mari kita tinjau cara untuk menurunkan biaya penelusuran sambil mempertahankan data agar Anda dapat melakukan analisis yang tepat.
Terapkan aturan Sampling
Tingkat pengambilan sampel X-Ray konservatif secara default. Tentukan aturan pengambilan sampel di mana Anda dapat mengontrol jumlah data yang Anda kumpulkan. Ini akan meningkatkan efisiensi kinerja sekaligus mengurangi biaya. Dengan mengurangi laju pengambilan sampel, Anda dapat mengumpulkan jejak dari permintaan hanya apa yang dibutuhkan beban kerja Anda sambil mempertahankan struktur biaya yang lebih rendah.
Misalnya, Anda memiliki aplikasi java yang ingin Anda debug jejak semua permintaan untuk 1 rute bermasalah.
Konfigurasikan melalui SDK untuk memuat aturan pengambilan sampel dari dokumen JSON
{ "version": 2, "rules": [ { "description": "debug-eks", "host": "*", "http_method": "PUT", "url_path": "/history/*", "fixed_target": 0, "rate": 1, "service_type": "debug-eks" } ], "default": { "fixed_target": 1, "rate": 0.1 } }
Melalui Konsol
Terapkan Tail Sampling dengan AWS Distro for OpenTelemetry (ADOT)
ADOT Tail Sampling memungkinkan Anda untuk mengontrol volume jejak yang tertelan dalam layanan. Namun, Tail Sampling memungkinkan Anda untuk menentukan kebijakan pengambilan sampel setelah semua rentang dalam permintaan selesai, bukan di awal. Ini selanjutnya membatasi jumlah data mentah yang ditransfer CloudWatch, sehingga mengurangi biaya.
Misalnya, jika Anda mengambil sampel 1% lalu lintas ke halaman arahan dan 10% permintaan ke halaman pembayaran, ini mungkin meninggalkan Anda dengan 300 jejak untuk jangka waktu 30 menit. Dengan aturan ADOT Tail Sampling yang menyaring kesalahan tertentu, Anda dapat dibiarkan dengan 200 jejak yang mengurangi jumlah jejak yang disimpan.
processors:
groupbytrace:
wait_duration: 10s
num_traces: 300
tail_sampling:
decision_wait: 1s # This value should be smaller than wait_duration
policies:
- ..... # Applicable policies**
batch/tracesampling:
timeout: 0s # No need to wait more since this will happen in previous processors
send_batch_max_size: 8196 # This will still allow us to limit the size of the batches sent to subsequent exporters
service:
pipelines:
traces/tailsampling:
receivers: [otlp]
processors: [groupbytrace, tail_sampling, batch/tracesampling]
exporters: [awsxray]
Manfaatkan opsi Penyimpanan Amazon S3
Anda harus memanfaatkan bucket AWS S3 dan kelas penyimpanannya yang berbeda untuk menyimpan jejak. Ekspor jejak ke S3 sebelum periode retensi berakhir. Gunakan aturan Siklus Hidup Amazon S3 untuk memindahkan data jejak ke kelas penyimpanan yang memenuhi persyaratan Anda.
Misalnya, jika Anda memiliki jejak yang berusia 90 hari, Amazon S3 Intelligent-Tiering
Sumber Daya Tambahan:
