Bagikan melalui

Memantau Azure Kubernetes Service (AKS)

Pemantauan AKS memerlukan beberapa tingkat pengamatan di seluruh metrik platform, metrik Prometheus, log aktivitas, log sumber daya, dan wawasan kontainer. AKS menyediakan kemampuan pemantauan bawaan dan terintegrasi dengan Azure Monitor, Wawasan kontainer, layanan terkelola untuk Prometheus, dan Azure Managed Grafana untuk pemantauan kesehatan dan performa kluster yang komprehensif.

Tips

Anda dapat menggunakan Azure Copilot untuk mengonfigurasi pemantauan pada kluster AKS Anda di portal Microsoft Azure. Untuk informasi selengkapnya, lihat Bekerja dengan kluster AKS secara efisien menggunakan Azure Copilot.

Wawasan

Beberapa layanan di Azure memiliki dasbor pemantauan bawaan di portal Azure yang menyediakan titik awal untuk memantau layanan Anda. Dasbor ini disebut wawasan, dan Anda dapat menemukannya di Insights Hub Azure Monitor di portal Azure.

Data pemantauan AKS: metrik, log, integrasi

AKS menghasilkan jenis data pemantauan yang sama dengan sumber daya Azure lainnya seperti yang dijelaskan dalam Memantau data dari sumber daya Azure. Untuk informasi terperinci tentang metrik dan log yang dibuat oleh AKS, lihat referensi data pemantauan AKS.

Layanan dan fitur Azure lainnya mengumpulkan data lain dan mengaktifkan opsi analisis lain seperti yang ditunjukkan dalam diagram dan tabel berikut.

Diagram data pemantauan yang dikumpulkan dari AKS.

Sumber Deskripsi
Platform metrik Metrik platform dikumpulkan secara otomatis untuk kluster AKS tanpa biaya. Anda dapat menganalisis metrik ini menggunakan penjelajah metrik atau menggunakannya untuk membuat pemberitahuan metrik.
Metrik Prometheus Saat Anda mengaktifkan pengikisan metrik untuk kluster Anda, layanan terkelola untuk Prometheus di Azure Monitor mengumpulkan metrik Prometheus dan menyimpannya di ruang kerja Azure Monitor. Analisis metrik ini menggunakan dasbor bawaan di Azure Managed Grafana dan dengan pemberitahuan Prometheus.
Log aktivitas Log aktivitas Azure Monitor secara otomatis mengumpulkan beberapa data untuk kluster AKS tanpa biaya. File log ini melacak informasi seperti ketika kluster dibuat atau perubahan dilakukan pada konfigurasi kluster. Untuk menganalisis data log aktivitas dengan data log Anda yang lain, kirim data log aktivitas ke ruang kerja Analitik Log.
Log sumber daya Log sarana kontrol untuk AKS diimplementasikan sebagai log sumber daya. Buat pengaturan diagnostik untuk mengirim log ke ruang kerja Analitik Log. Di ruang kerja, Anda dapat menganalisis log menggunakan kueri dan menyiapkan pemberitahuan berdasarkan informasi log.
Wawasan kontainer Wawasan Kontainer mengumpulkan berbagai log dan data performa dari kluster dan menyimpannya baik di ruang kerja Analitik Log maupun di metrik Azure Monitor. Menganalisis data seperti stdout dan stderr aliran menggunakan tampilan dan buku kerja di Wawasan Kontainer atau Analitik Log dan Penjelajah Metrik.
Application Insights Application Insights, fitur Azure Monitor, mengumpulkan log, metrik, dan jejak terdistribusi. Telemetri disimpan di ruang kerja Analitik Log untuk analisis di portal Microsoft Azure. Untuk mengaktifkan Application Insights dengan perubahan kode, lihat Mengaktifkan Azure Monitor OpenTelemetry. Untuk mengaktifkan Application Insights tanpa perubahan kode, lihat AKS Autoinstrumentasi. Untuk informasi selengkapnya tentang instrumentasi, pelajari tentang dasar-dasar pengumpulan data.

Jenis Sumber Daya

Azure menggunakan konsep jenis sumber daya dan ID untuk mengidentifikasi semuanya dalam langganan. Jenis sumber daya juga merupakan bagian dari ID sumber daya untuk setiap sumber daya yang berjalan di Azure. Misalnya, satu jenis sumber daya untuk komputer virtual adalah Microsoft.Compute/virtualMachines. Untuk daftar layanan dan jenis sumber daya terkait, lihat Penyedia sumber daya.

Azure Monitor juga mengatur data pemantauan inti ke dalam metrik dan log berdasarkan jenis sumber daya, juga disebut namespaces. Metrik dan log yang berbeda tersedia untuk berbagai jenis sumber daya. Layanan Anda mungkin dikaitkan dengan lebih dari satu jenis sumber daya.

Untuk informasi selengkapnya tentang jenis sumber daya di AKS, lihat referensi data pemantauan AKS.

Penyimpanan data

Untuk Azure Monitor:

  • Data metrik disimpan dalam database metrik Azure Monitor.
  • Data log disimpan di penyimpanan log Azure Monitor. Log Analytics adalah alat di portal Azure yang dapat mengkueri penyimpanan ini.
  • Log aktivitas Azure adalah penyimpanan terpisah dengan antarmukanya sendiri di portal Azure.

Anda dapat secara opsional merutekan metrik dan data log aktivitas ke penyimpanan log Azure Monitor. Anda kemudian dapat menggunakan Analitik Log untuk mengkueri data dan menghubungkannya dengan data log lainnya.

Banyak layanan dapat menggunakan pengaturan diagnostik untuk mengirim metrik dan data log ke lokasi penyimpanan lain di luar Azure Monitor. Contohnya termasuk Azure Storage, sistem mitra yang dihosting, dan sistem mitra non-Azure, dengan menggunakan Azure Event Hubs.

Untuk informasi terperinci tentang cara Azure Monitor menyimpan data, lihat Platform data Azure Monitor.

Metrik platform Azure Monitor

Azure Monitor menyediakan metrik platform untuk sebagian besar layanan. Metrik ini adalah:

  • Didefinisikan secara individual untuk setiap namespace.
  • Disimpan dalam database metrik rangkaian waktu Azure Monitor.
  • Ringan dan mampu mendukung peringatan hampir real-time.
  • Digunakan untuk melacak performa sumber daya dari waktu ke waktu.

Koleksi: Azure Monitor mengumpulkan metrik platform secara otomatis. Tidak diperlukan konfigurasi.

Perutean: Anda juga dapat merutekan beberapa metrik platform ke Log Azure Monitor / Analitik Log sehingga Anda dapat mengkuerinya dengan data log lainnya. Periksa pengaturan ekspor DS untuk setiap metrik untuk melihat apakah Anda dapat menggunakan pengaturan diagnostik untuk merutekan metrik ke Log Azure Monitor / Analitik Log.

Untuk daftar semua metrik yang mungkin dikumpulkan untuk semua sumber daya di Azure Monitor, lihat Metrik yang didukung di Azure Monitor.

Untuk daftar metrik yang dapat Anda kumpulkan untuk AKS, lihat referensi data pemantauan AKS.

Metrik memainkan peran penting dalam memantau kluster, mengidentifikasi masalah, dan mengoptimalkan performa di kluster AKS. Metrik platform diambil menggunakan server metrik bawaan yang diinstal di namespace kube-system, yang secara berkala mengambil metrik dari semua simpul AKS yang dikelola oleh kubelet. Anda juga harus mengaktifkan layanan terkelola untuk metrik Prometheus untuk mengumpulkan metrik kontainer dan metrik objek Kubernetes, termasuk status penyebaran objek.

Anda dapat melihat daftar layanan terkelola default untuk metrik Prometheus.

Untuk informasi selengkapnya, lihat Mengumpulkan layanan terkelola untuk metrik Prometheus dari kluster AKS.

Metrik yang tidak berbasis Azure Monitor

Layanan ini menyediakan metrik lain yang tidak disertakan dalam database metrik Azure Monitor.

Anda dapat menggunakan layanan Azure berikut dan fitur Azure Monitor untuk memantau kluster AKS Anda. Anda mengaktifkan fitur-fitur ini saat membuat kluster AKS.

Di portal Microsoft Azure, gunakan tab Integrasi , atau gunakan Azure CLI, Terraform, atau Azure Policy. Dalam beberapa kasus, Anda dapat menyiapkan kluster Anda untuk layanan atau fitur pemantauan setelah Anda membuat kluster. Setiap layanan atau fitur mungkin dikenakan biaya, jadi lihat informasi harga untuk setiap komponen sebelum Anda mengaktifkannya.

Layanan atau fitur Deskripsi
Wawasan Kontainer Menggunakan versi terkontainer dari Agen Azure Monitor untuk mengumpulkan log dan peristiwa Kubernetes dari setiap simpul di kluster Anda. Fitur ini mendukung berbagai skenario pemantauan untuk kluster AKS. Anda dapat mengaktifkan pemantauan untuk kluster AKS saat dibuat menggunakan Azure CLI, Azure Policy, portal Microsoft Azure, atau Terraform. Jika Anda tidak mengaktifkan wawasan Kontainer saat membuat kluster, lihat Mengaktifkan wawasan Kontainer untuk kluster AKS untuk opsi lain untuk mengaktifkannya.

Container insights menyimpan sebagian besar datanya di ruang kerja Analitik Log. Anda biasanya menggunakan ruang kerja Analitik Log yang sama dengan log sumber daya untuk kluster Anda. Untuk panduan tentang berapa banyak ruang kerja yang harus Anda gunakan dan tempat menemukannya, lihat Mendesain arsitektur ruang kerja Analitik Log.
Layanan terkelola untuk Prometheus di Azure Monitor Prometheus adalah solusi metrik cloud-native dari Cloud Native Computing Foundation. Ini adalah alat yang paling umum digunakan untuk mengumpulkan dan menganalisis data metrik dari kluster Kubernetes. Layanan terkelola untuk Prometheus di Azure Monitor adalah solusi pemantauan yang kompatibel dengan Prometheus yang dikelola sepenuhnya. Jika Anda tidak mengaktifkan layanan terkelola untuk Prometheus saat membuat kluster, lihat Mengumpulkan metrik Prometheus dari kluster AKS untuk opsi lain untuk mengaktifkannya.

Layanan terkelola untuk Prometheus di Azure Monitor menyimpan datanya di ruang kerja Azure Monitor yang ditautkan ke ruang kerja Grafana. Anda dapat menggunakan Azure Managed Grafana untuk menganalisis data.
Azure Managed Grafana Implementasi Grafana yang dikelola sepenuhnya. Grafana adalah platform visualisasi data sumber terbuka yang umumnya digunakan untuk menyajikan data Prometheus. Beberapa dasbor Grafana yang telah ditentukan tersedia untuk memantau Kubernetes dan pemecahan masalah tumpukan penuh. Jika Anda tidak mengaktifkan Azure Managed Grafana saat membuat kluster, lihat Menautkan ruang kerja Grafana. Anda dapat menautkannya ke ruang kerja Azure Monitor sehingga dapat mengakses metrik Prometheus dari kluster Anda.

Pemantauan metrik sarana kontrol AKS (pratinjau)

Prasyarat dan cakupan: Fitur pratinjau ini tersedia untuk kluster AKS yang menjalankan Kubernetes 1.27 atau yang lebih baru dan mengharuskan layanan terkelola untuk Prometheus diaktifkan pada kluster Anda. Fitur ini saat ini mendukung kumpulan simpul Linux dan Windows tetapi tidak kompatibel dengan Virtual Machine Availability Sets (VMAS).

AKS juga mengekspos metrik dari komponen kontrol plane penting seperti API server, etcd, dan scheduler melalui layanan terkelola untuk Prometheus di Azure Monitor. Saat ini, fitur ini sedang dalam pratinjau. Untuk informasi selengkapnya, lihat Memantau metrik sarana kontrol AKS. Subset metrik sarana kontrol untuk server API dan dll tersedia gratis melalui metrik platform Azure Monitor. Metrik ini dikumpulkan secara default. Anda dapat menggunakan metrik untuk membuat pemberitahuan.

Log sumber daya Azure Monitor

Log sumber daya memberikan wawasan tentang operasi yang dilakukan oleh sumber daya Azure. Log dihasilkan secara otomatis, tetapi Anda harus merutekannya ke log Azure Monitor untuk menyimpan atau mengkuerinya. Log diatur dalam kategori. Namespace tertentu mungkin memiliki beberapa kategori log sumber daya.

Koleksi: Log sumber daya tidak dikumpulkan dan disimpan hingga Anda membuat pengaturan diagnostik dan merutekan log ke satu atau beberapa lokasi. Saat membuat pengaturan diagnostik, Anda menentukan kategori log yang akan dikumpulkan. Ada beberapa cara untuk membuat dan memelihara pengaturan diagnostik, termasuk portal Azure, secara terprogram, dan melalui Azure Policy.

Perutean: Default yang disarankan adalah merutekan log sumber daya ke Log Azure Monitor sehingga Anda dapat mengkuerinya dengan data log lainnya. Lokasi lain seperti Azure Storage, Azure Event Hubs, dan mitra pemantauan Microsoft tertentu juga tersedia. Untuk informasi selengkapnya, lihat Log sumber daya Azure dan Destinasi log sumber daya.

Untuk informasi terperinci tentang mengumpulkan, menyimpan, dan merutekan log sumber daya, lihat Pengaturan diagnostik di Azure Monitor.

Untuk daftar semua kategori log sumber daya yang tersedia di Azure Monitor, lihat Log sumber daya yang didukung di Azure Monitor.

Semua log sumber daya di Azure Monitor memiliki bidang header yang sama, diikuti oleh bidang khusus layanan. Skema umum diuraikan dalam skema log sumber daya Azure Monitor.

Untuk kategori log sumber daya yang tersedia, tabel Analitik Log terkait, dan skema log untuk AKS, lihat referensi data pemantauan AKS.

Log sumber daya sarana kontrol AKS

Prasyarat: Memerlukan ruang kerja Analitik Log dalam langganan yang sama dengan kluster AKS Anda. Log sumber daya dikenakan biaya penyerapan dan retensi di ruang kerja tujuan. Untuk pengoptimalan biaya, gunakan mode khusus sumber daya dan konfigurasikan tingkat log Dasar untuk tabel audit.

Log kontrol untuk kluster AKS diimplementasikan sebagai log sumber daya di Azure Monitor. Log sumber daya tidak dikumpulkan dan disimpan hingga Anda membuat pengaturan diagnostik untuk merutekannya ke setidaknya satu lokasi. Anda biasanya mengirim catatan sumber daya ke workspace Log Analytics, tempat sebagian besar data untuk pengamatan Kontainer disimpan.

Untuk mempelajari cara membuat pengaturan diagnostik menggunakan portal Microsoft Azure, Azure CLI, atau Azure PowerShell, lihat Membuat pengaturan diagnostik. Saat membuat pengaturan diagnostik, Anda menentukan kategori log yang akan dikumpulkan. Kategori untuk AKS tercantum dalam referensi data pemantauan AKS.

Peringatan

Anda mungkin akan menanggung biaya besar ketika mengumpulkan log sumber daya untuk AKS, terutama untuk log kube-audit. Pertimbangkan rekomendasi berikut untuk mengurangi jumlah data yang dikumpulkan:

  • Nonaktifkan kube-audit pengelogan jika tidak diperlukan.
  • Aktifkan koleksi dari kube-audit-admin, yang mengecualikan kejadian audit get dan list.
  • Aktifkan log khusus sumber daya seperti yang dijelaskan dalam artikel ini, dan konfigurasikan tabel AKSAudit sebagai log Dasar.

Untuk rekomendasi pemantauan selengkapnya, lihat Memantau kluster AKS menggunakan layanan Azure dan alat cloud-native. Untuk strategi mengurangi biaya pemantauan Anda, lihat Pengoptimalan biaya dan Azure Monitor.

AKS mendukung mode diagnostik Azure atau mode khusus untuk log sumber daya. Mode diagnostik Azure mengirimkan semua data ke tabel AzureDiagnostics. Mode khusus sumber daya menentukan tabel di ruang kerja Analitik Log tempat data dikirim. Ini juga mengirim data ke AKSAudit, AKSAuditAdmin, dan AKSControlPlane seperti yang ditunjukkan dalam tabel di Log sumber daya.

Kami menyarankan agar Anda menggunakan mode khusus sumber daya untuk AKS karena alasan berikut:

  • Data lebih mudah dikueri karena berada dalam tabel individual yang didedikasikan untuk AKS.
  • Mode khusus sumber daya mendukung konfigurasi sebagai Log dasar untuk penghematan biaya yang signifikan.

Untuk informasi selengkapnya tentang perbedaan antara mode pengumpulan, termasuk cara mengubah pengaturan yang ada, lihat Memilih mode koleksi.

Catatan

Anda dapat mengonfigurasi pengaturan diagnostik menggunakan Azure CLI. Pendekatan ini tidak dijamin berhasil karena tidak memeriksa status provisi kluster. Setelah Anda mengubah pengaturan diagnostik, periksa untuk memastikan bahwa kluster mencerminkan perubahan pengaturan.

az monitor diagnostic-settings create --name AKS-Diagnostics --resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.ContainerService/managedClusters/my-cluster --logs '[{"category": "kube-audit","enabled": true}, {"category": "kube-audit-admin", "enabled": true}, {"category": "kube-apiserver", "enabled": true}, {"category": "kube-controller-manager", "enabled": true}, {"category": "kube-scheduler", "enabled": true}, {"category": "cluster-autoscaler", "enabled": true}, {"category": "cloud-controller-manager", "enabled": true}, {"category": "guard", "enabled": true}, {"category": "csi-azuredisk-controller", "enabled": true}, {"category": "csi-azurefile-controller", "enabled": true}, {"category": "csi-snapshot-controller", "enabled": true}]'  --workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace --export-to-resource-specific true

Kueri log sumber daya AKS dan contohnya

Persyaratan cakupan kueri: Saat Anda memilih Log pada menu kluster AKS, Analitik Log terbuka dengan cakupan kueri yang diatur ke kluster saat ini. Kueri log hanya menyertakan data dari sumber daya tersebut. Untuk menjalankan kueri yang menyertakan data dari kluster lain atau layanan Azure, pilih Log dari menu Azure Monitor .

Jika pengaturan diagnostik untuk kluster Anda menggunakan mode diagnostik Azure, log sumber daya untuk AKS disimpan dalam tabel AzureDiagnostics . Identifikasi log melalui kolom Kategori . Untuk mengetahui deskripsi tiap kategori, lihat log sumber daya AKS.

Deskripsi Pengaturan Kueri log
Hitung log untuk setiap kategori Mode diagnostik Azure AzureDiagnostics
| where ResourceType == "MANAGEDCLUSTERS"
| summarize count() by Category
Semua log server API Mode diagnostik Azure AzureDiagnostics
| where Category == "kube-apiserver"
Semua log kube-audit dalam rentang waktu Mode diagnostik Azure let starttime = datetime("2023-02-23");
let endtime = datetime("2023-02-24");
AzureDiagnostics
| where TimeGenerated between(starttime..endtime)
| where Category == "kube-audit"
| extend event = parse_json(log_s)
| extend HttpMethod = tostring(event.verb)
| extend User = tostring(event.user.username)
| extend Apiserver = pod_s
| extend SourceIP = tostring(event.sourceIPs[0])
| project TimeGenerated, Category, HttpMethod, User, Apiserver, SourceIP, OperationName, event
Semua log audit Mode khusus sumber daya AKSAudit
Semua log audit kecuali peristiwa audit get dan list Mode khusus sumber daya AKSAuditAdmin
Semua log server API Mode khusus sumber daya AKSControlPlane
| where Category == "kube-apiserver"

Untuk mengakses serangkaian kueri bawaan di ruang kerja Analitik Log, lihat antarmuka kueri Analitik Log, dan pilih jenis sumber daya Kubernetes Services . Untuk daftar kueri umum untuk wawasan kontainer, lihat Kueri Wawasan Kontainer.

Kebijakan audit AKS

AKS menggunakan kebijakan audit Kubernetes untuk mengontrol peristiwa apa yang dicatat dan data apa yang dikandungnya. Kebijakan menentukan aturan yang menentukan tingkat audit untuk berbagai jenis permintaan API berdasarkan pengguna, sumber daya, namespace, dan kata kerja. Tingkat audit berikut digunakan:

  • Tidak ada: Peristiwa yang cocok dengan aturan ini tidak dicatat.
  • Metadata: Metadata log permintaan (pengguna yang meminta, tanda waktu, sumber daya, kata kerja) tetapi bukan isi permintaan atau respons.
  • Permintaan: Catat metadata peristiwa dan isi permintaan tetapi bukan isi respons.
  • RequestResponse: Mencatat metadata peristiwa, badan permintaan, dan respons.

Tabel berikut ini meringkas aturan kebijakan audit utama yang diterapkan di AKS:

Tingkat audit Deskripsi Contoh kejadian
Tidak Operasi baca volume tinggi dan berisiko rendah aksServiceoperasi penggunaget/list, kube-proxy mengawasi endpoint/layanan, kubelet get pada node/status node, URL pemeriksaan kesehatan (/healthz*, /version, /swagger*)
Metadata Peristiwa sistem, sumber daya terkait peristiwa (kecuali membuat/memperbarui di default/kube-system), data rahasia, konfigurasi peta, akun layanan, ulasan token Ulasan token, akses rahasia/configmap, CRD besar seperti installations.operator.tigera.io
Permintaan Pembaruan status node dan pod dari kubelet/node, operasi pengumpulan penghapusan, pembaruan CRD untuk rekam jepret volume, operasi baca (get/list/watch) pada grup API inti, perubahan VPA Pembaruan status Kubelet, penghapusan namespace, pembaruan titik pemeriksaan VPA
RequestResponse Pembaruan peta konfigurasi kustom CoreDNS, operasi API Armada, perubahan sumber daya Karpenter, semua operasi tulis lainnya pada grup API inti Perubahan konfigurasi CoreDNS, operasi kluster anggota Armada, perubahan kumpulan simpul Karpenter

Kebijakan audit lengkap yang digunakan di AKS tersedia untuk ditinjau di bagian yang dapat diciutkan berikut.

Lihat kebijakan audit AKS lengkap 
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # audit level 'None' for high volume and low risk events
  - level: None
    users: ["aksService"]
    verbs: ["get", "list"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: ""
        resources: ["endpoints", "services", "services/status"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["kubelet"] # legacy kubelet identity
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  # audit level 'None' for low-risk requests
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  # audit level 'None' for low-risk requests
  - level: None
    users:
      - aksService # the default user/cert used by aks in master node
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: ""
        resources: ["endpoints"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["namespaces", "namespaces/status", "namespaces/finalize"]
  # audit level 'None' for low-risk requests
  - level: None
    users:
      - aksService # the default user/cert used by aks in master node
    verbs: ["get", "list"]
    resources:
      - group: "metrics.k8s.io"
  # Don't log these read-only URLs.
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # monitor metadata for system events which are being logged by eventlogger component
  - level: Metadata
    verbs: ["create", "update", "patch"]
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
    namespaces: ["default", "kube-system"]
  # Monitoring of actions to detect security/performance relevant activities.
  - level: Metadata
    verbs: ["delete", "list"]
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
  # Don't log other events requests.
  - level: None
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
  # node and pod status calls from nodes are high-volume and can be large, don't log responses for expected updates from nodes
  - level: Request
    users: ["client", "kubelet", "system:node-problem-detector", "system:serviceaccount:kube-system:node-problem-detector", "system:serviceaccount:kube-system:aci-connector-linux"]
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["nodes/status", "pods/status"]
    omitStages:
      - "RequestReceived"
  # node and pod status calls from nodes are high-volume and can be large, don't log responses for expected updates from nodes
  - level: Request
    userGroups: ["system:nodes"]
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["nodes/status", "pods/status"]
    omitStages:
      - "RequestReceived"
  # deletecollection calls can be large, don't log responses for expected namespace deletions
  - level: Request
    users: ["system:serviceaccount:kube-system:namespace-controller"]
    verbs: ["deletecollection"]
    omitStages:
      - "RequestReceived"
  # ignore response object that has big size
  - level: Request
    verbs: ["update","patch"]
    resources:
      - group: "apiextensions.k8s.io"
        resources: ["customresourcedefinitions"]
        resourceNames: ["volumesnapshotcontents.snapshot.storage.k8s.io", "volumesnapshots.snapshot.storage.k8s.io"]
    omitStages:
      - "RequestReceived"
  # ignore request and response objects for large CRDs that will be filtered down anyway
  - level: Metadata
    resources:
      - group: "apiextensions.k8s.io"
        resources: ["customresourcedefinitions"]
        resourceNames: ["installations.operator.tigera.io"]
    omitStages:
      - "RequestReceived"
  # overriding the default behavior of coredns might have security threats for Kubernetes DNS in security perspective, set the level as RequestResponse
  - level: RequestResponse
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["configmaps"]
        resourceNames: ["coredns-custom"]
    namespaces: ["kube-system"]
    omitStages:
      - "RequestReceived"
  # Secrets, ConfigMaps, ServiceAccounts, TokenRequest and TokenReviews can contain sensitive & binary data,
  # so only log at the Metadata level.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps", "serviceaccounts", "serviceaccounts/token"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"
  # Capture state of vertical pod autoscalers
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "autoscaling.k8s.io"
        resources: ["verticalpodautoscalers", "verticalpodautoscalercheckpoints"]
    omitStages:
      - "RequestReceived"
  # Capture create and delete of internal fleet resources
  - level: RequestResponse
    verbs: ["create", "delete"]
    resources:
      - group: "cluster.kubernetes-fleet.io"
        resources: ["memberclusters", "internalmemberclusters"]
      - group: "placement.kubernetes-fleet.io"
        resources: ["works"]
      - group: "networking.fleet.azure.com"
        resources: ["internalserviceexports", "internalserviceimports"]
    omitStages:
      - "RequestReceived"
  # Capture CUD of user facing Fleet API
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "placement.kubernetes-fleet.io"
        resources: ["clusterstagedupdateruns", "clusterresourceplacements", "clusterresourceplacementevictions", "clusterresourceplacementdisruptionbudgets", "clusterstagedupdatestrategies", "clusterapprovalrequests", "clusterresourceoverrides", "resourceoverrides"]
      - group: "networking.fleet.azure.com"
        resources: ["serviceexports", "multiclusterservices", "trafficmanagerprofiles", "trafficmanagerbackends"]
    omitStages:
      - "RequestReceived"
  # Capture CUD of user facing Karpenter resources
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "karpenter.azure.com"
        resources: ["aksnodeclasses", "aksnodeclasses/status"]
      - group: "karpenter.sh"
        resources: ["nodepools", "nodepools/status", "nodeclaims", "nodeclaims/status"]
    omitStages:
      - "RequestReceived"
  # Get responses can be large; don't log response
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: ""
      - group: "admissionregistration.k8s.io"
      - group: "apiextensions.k8s.io"
      - group: "apiregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "metrics.k8s.io"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "scheduling.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
    omitStages:
      - "RequestReceived"
  # Default level for known APIs
  - level: RequestResponse
    resources:
      - group: ""
      - group: "admissionregistration.k8s.io"
      - group: "apiextensions.k8s.io"
      - group: "apiregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "metrics.k8s.io"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "scheduling.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
    omitStages:
      - "RequestReceived"
  # Default level for all other requests.
  - level: Metadata
    omitStages:
      - "RequestReceived"

Catatan

Kebijakan audit dikelola oleh AKS dan tidak dapat disesuaikan. Kebijakan ini dirancang untuk menyeimbangkan pengamatan keamanan dengan pengoptimalan performa dan biaya dengan mengurangi volume log untuk operasi frekuensi tinggi dan berisiko rendah.

Log wawasan Kontainer bidang data AKS

Persyaratan prasyarat dan konfigurasi: Wawasan kontainer memerlukan ruang kerja Analitik Log untuk penyimpanan log dan mendukung identitas terkelola dan metode autentikasi warisan. Untuk kluster baru, autentikasi identitas terkelola disarankan. Pengumpulan data dapat disesuaikan menggunakan Aturan Pengumpulan Data (DCR) Azure Monitor untuk mengontrol biaya dan mengurangi volume penyerapan.

Wawasan kontainer mengumpulkan berbagai jenis data telemetri dari kontainer dan kluster AKS untuk membantu Anda memantau, memecahkan masalah, dan mendapatkan wawasan tentang aplikasi kontainer Anda yang berjalan di kluster AKS Anda. Lihat Referensi tabel Azure Monitor untuk daftar tabel dan deskripsi terperinci yang digunakan oleh Container Insights. Semua tabel tersedia untuk kueri log.

Gunakan pengaturan pengoptimalan biaya untuk menyesuaikan dan mengontrol data metrik yang dikumpulkan melalui agen wawasan Kontainer. Fitur ini mendukung pengaturan pengumpulan data untuk pemilihan tabel individual, interval pengumpulan data, dan namespace untuk mengecualikan pengumpulan data melalui Aturan Pengumpulan Data (DCR) Azure Monitor. Pengaturan ini mengontrol volume data yang masuk dan mengurangi biaya pemantauan Container Insights. Anda dapat menyesuaikan wawasan Kontainer yang dikumpulkan di portal Azure menggunakan opsi berikut. Memilih opsi apa pun selain Semua (Default) membuat pengalaman wawasan Kontainer tidak tersedia.

Pengelompokan Tabel Catatan
Semua (Default) Semua tabel wawasan kontainer standar Diperlukan untuk mengaktifkan visualisasi wawasan Kontainer default.
Performance Perf, InsightsMetrics N/A
Catatan dan peristiwa ContainerLog atau ContainerLogV2, KubeEvents, KubePodInventory Disarankan jika Anda mengaktifkan layanan terkelola untuk metrik Prometheus.
Beban Kerja, Penempatan, dan HPAs InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices N/A
Volume-Volume Persisten "InsightsMetrics", "KubePVInventory" N/A

Pengelompokan Log dan peristiwa-peristiwa mengumpulkan log dari tabel ContainerLog atau ContainerLogV2, KubeEvents, dan KubePodInventory, namun bukan metrik. Jalur yang direkomendasikan untuk mengumpulkan metrik adalah mengaktifkan layanan terkelola untuk Prometheus dari kluster AKS Anda dan menggunakan Azure Managed Grafana untuk visualisasi data. Untuk informasi selengkapnya, lihat Kelola ruang kerja di Azure Monitor.

Skema ContainerLogV2

Persyaratan kompatibilitas dan konfigurasi: Skema ContainerLogV2 direkomendasikan untuk penyebaran wawasan Kontainer baru menggunakan autentikasi identitas terkelola melalui templat Azure Resource Manager (ARM), Bicep, Terraform, Azure Policy, atau portal Microsoft Azure. Skema ini kompatibel dengan tingkat log Dasar untuk penghematan biaya dan tidak memengaruhi fungsionalitas analitik atau pemberitahuan. Untuk informasi selengkapnya tentang cara mengaktifkan ContainerLogV2 melalui DCR atau configmap kluster, lihat Mengaktifkan skema ContainerLogV2.

Wawasan kontainer di Azure Monitor menyediakan skema yang direkomendasikan untuk log kontainer, ContainerLogV2. Format ini mencakup bidang berikut untuk kueri umum untuk melihat data yang terkait dengan kluster Kubernetes yang didukung AKS dan Azure Arc:

  • ContainerName
  • PodName
  • PodNamespace

Log aktivitas Azure

Log aktivitas berisi peristiwa tingkat langganan yang melacak operasi untuk setiap sumber daya Azure seperti yang terlihat dari luar sumber daya tersebut; misalnya, membuat sumber daya baru atau memulai komputer virtual.

Pengumpulan: Peristiwa log aktivitas secara otomatis dihasilkan dan dikumpulkan di penyimpanan terpisah untuk dilihat di portal Azure.

Pengarahan: Anda dapat mengirim data log aktivitas ke Azure Monitor Logs sehingga Anda dapat menganalisisnya bersama data log lainnya. Lokasi lain seperti Azure Storage, Azure Event Hubs, dan mitra pemantauan Microsoft tertentu juga tersedia. Untuk informasi selengkapnya tentang cara merutekan log aktivitas, lihat Gambaran Umum Log Aktivitas Azure.

Tinjau log kontainer AKS, kejadian, dan metrik pod secara real time.

Prasyarat dan penyiapan: Fitur data langsung mengharuskan Wawasan Kontainer diaktifkan pada Cluster Anda dan menggunakan akses API Kubernetes langsung. Untuk kluster privat, akses memerlukan komputer di jaringan privat yang sama dengan kluster. Autentikasi mengikuti model RBAC Kubernetes dan memerlukan izin kluster yang sesuai.

Anda dapat melihat log kontainer AKS, events, dan metrik pod menggunakan fitur data langsung dalam Container insights dan memecahkan masalah secara real time dengan akses langsung ke kubectl logs -c, events kubectl get, dan kubectl top pods.

Catatan

AKS menggunakan arsitektur pencatatan log tingkat kluster Kubernetes. Log kontainer terletak di /var/log/containers pada simpul. Untuk mengakses simpul, lihat Menyambungkan ke node kluster AKS.

Untuk mempelajari cara menyiapkan fitur ini, lihat Mengonfigurasi data langsung di Wawasan kontainer. Fitur ini langsung mengakses API Kubernetes. Untuk informasi selengkapnya tentang model autentikasi, lihat API Kubernetes.

Menampilkan log langsung sumber daya AKS

Persyaratan jaringan kluster privat: Untuk mengakses log dari kluster privat, Anda harus menggunakan komputer yang berada di jaringan privat yang sama dengan kluster.

  1. Di portal Microsoft Azure, buka kluster AKS Anda.

  2. Di bawah Sumber daya Kubernetes, pilih Beban Kerja.

  3. Untuk Deployment, Pod, Replica Set, Stateful Set, Job, atau Cron Job, pilih nilai, lalu pilih Live Logs.

  4. Pilih log sumber daya untuk dilihat.

    Contoh berikut menunjukkan log untuk sumber daya pod:

    Cuplikan layar yang memperlihatkan penyebaran log langsung.

Melihat log langsung kontainer menggunakan Wawasan Kontainer

Autentikasi dan streaming data: Setelah autentikasi berhasil, jika data dapat diambil, data mulai mengalir ke tab Log Langsung. Data log muncul dalam aliran yang berkelanjutan. Akses log alternatif tersedia melalui Lihat Log di Log Analitik untuk keperluan analisis historis.

Anda dapat melihat data log real-time saat mesin kontainer menghasilkannya pada tab Kluster, Node, Pengontrol, atau Kontainer .

  1. Di portal Microsoft Azure, buka kluster AKS Anda.

  2. Di Pemantauan, pilih Insight.

  3. Pada tab Kluster, Simpul, Pengontrol, atau Kontainer , pilih nilai.

  4. Pada panel Gambaran Umum untuk sumber daya, pilih Log Langsung.

    Gambar berikut menunjukkan log untuk sumber daya kontainer:

    Cuplikan layar yang memperlihatkan opsi Log Langsung kontainer untuk melihat data.

Tinjau peristiwa langsung kontainer menggunakan Bagian Wawasan Kontainer

Pemancaran dan akses peristiwa: Aliran data peristiwa secara real-time saat mesin container menghasilkannya. Peristiwa termasuk pembuatan pod, penghapusan, operasi penskalaan, dan kondisi kesalahan. Data peristiwa historis dapat diakses melalui Lihat Peristiwa di Analitik Log.

Anda dapat melihat data peristiwa real-time saat mesin kontainer menghasilkannya pada tab Kluster, Node, Pengontrol, atau Kontainer .

  1. Di portal Microsoft Azure, buka kluster AKS Anda.

  2. Di Pemantauan, pilih Insight.

  3. Pilih tab Kluster, Simpul, Pengontrol, atau Kontainer , lalu pilih objek.

  4. Pada panel Gambaran Umum sumber daya, pilih Acara Langsung.

    Setelah autentikasi berhasil, jika data dapat diambil, data mulai mengalir ke tab Acara Langsung . Gambar berikut menunjukkan peristiwa untuk sumber daya kontainer:

    Cuplikan layar yang memperlihatkan opsi Acara Langsung kontainer untuk melihat data.

Melihat metrik realtime pod menggunakan Container Insights

Cakupan dan ketersediaan metrik: Metrik langsung tersedia untuk sumber daya pod pada tab Simpul atau Pengontrol . Metrik termasuk penggunaan CPU, konsumsi memori, I/O jaringan, dan statistik sistem file. Metrik historis dapat diakses melalui Lihat Peristiwa di Analitik Log.

Anda dapat melihat data metrik real-time saat mesin kontainer menghasilkannya pada tab Simpul atau Pengontrol dengan memilih sumber daya pod.

  1. Di portal Microsoft Azure, buka kluster AKS Anda.

  2. Di Pemantauan, pilih Insight.

  3. Pilih tab Simpul atau Pengontrol , lalu pilih objek pod.

  4. Pada panel Gambaran Umum sumber daya, pilih Metrik Langsung.

    Setelah autentikasi berhasil, jika data dapat diambil, data mulai mengalir ke tab Metrik Langsung . Gambar berikut menunjukkan metrik untuk sumber daya pod:

    Cuplikan layar yang memperlihatkan opsi Metrik Langsung pod untuk melihat data.

    Menganalisis data pemantauan

    Ada banyak alat untuk menganalisis data pemantauan.

    Perangkat Azure Monitor

    Azure Monitor mendukung alat dasar berikut:

    • Penjelajah metrik, alat di portal Azure yang memungkinkan Anda melihat dan menganalisis metrik untuk sumber daya Azure. Untuk informasi selengkapnya, lihat Menganalisis metrik dengan penjelajah metrik Azure Monitor.

    • Log Analytics, alat di portal Azure yang memungkinkan Anda mengkueri dan menganalisis data log dengan menggunakan bahasa kueri Kusto (KQL). Untuk informasi selengkapnya, lihat Mulai menggunakan kueri Log di Azure Monitor.

    • Log aktivitas, yang memiliki antarmuka pengguna di portal Azure untuk melihat dan pencarian dasar. Untuk melakukan analisis yang lebih mendalam, Anda harus merutekan data ke log Azure Monitor dan menjalankan kueri yang lebih kompleks di Analitik Log.

    Alat yang memungkinkan visualisasi yang lebih kompleks meliputi:

    • Dasbor yang memungkinkan Anda menggabungkan berbagai jenis data ke dalam satu panel di portal Azure.
    • Buku kerja, laporan yang dapat disesuaikan yang bisa Anda buat di portal Azure. Buku kerja dapat menyertakan kueri teks, metrik, dan log.
    • Grafana, alat platform terbuka yang unggul di dasbor operasional. Anda dapat menggunakan Grafana untuk membuat dasbor yang menyertakan data dari beberapa sumber selain Azure Monitor.
    • Power BI, layanan analitik bisnis yang menyediakan visualisasi interaktif di berbagai sumber data. Anda dapat mengonfigurasi Power BI untuk mengimpor data log secara otomatis dari Azure Monitor untuk memanfaatkan visualisasi ini.

    Alat ekspor Azure Monitor

    Anda bisa mendapatkan data dari Azure Monitor ke alat lain dengan menggunakan metode berikut:

    • Metrik: Gunakan REST API untuk metrik untuk mengekstrak data metrik dari database metrik Azure Monitor. API mendukung ekspresi filter untuk menyempurnakan data yang diambil. Untuk informasi selengkapnya, lihat Referensi REST API Azure Monitor.

    • Log: Gunakan REST API atau pustaka klien terkait.

    • Opsi lain adalah ekspor data ruang kerja.

    Untuk memulai dengan REST API untuk Azure Monitor, lihat Panduan penggunaan REST API pemantauan Azure.

Memantau kluster AKS di portal Microsoft Azure

Tab Pemantauan pada panel Gambaran Umum untuk sumber daya kluster AKS Anda menawarkan cara cepat untuk mulai menampilkan data pemantauan di portal Microsoft Azure. Tab ini mencakup grafik dengan metrik umum untuk kluster yang dipisahkan oleh kumpulan simpul. Anda dapat memilih salah satu grafik ini untuk menganalisis data lebih lanjut di penjelajah metrik.

Tab Pemantauan juga menyertakan tautan ke layanan terkelola Azure untuk Prometheus dan Wawasan Kontainer untuk kluster. Anda dapat mengaktifkan alat ini pada tab Pemantauan . Anda mungkin juga melihat banner di bagian atas panel yang merekomendasikan fitur lain untuk meningkatkan pemantauan untuk kluster Anda.

Tips

Untuk mengakses fitur pemantauan untuk semua kluster AKS di langganan Anda, di beranda portal Microsoft Azure, pilih Azure Monitor.

Kueri Kusto

Anda dapat menganalisis data pemantauan di penyimpanan Log Azure Monitor / Analitik Log dengan menggunakan bahasa kueri Kusto (KQL).

Penting

Saat Anda memilih Logs dari menu layanan di portal, Log Analytics terbuka dengan cakupan kueri yang diatur ke layanan saat ini. Cakupan ini berarti bahwa kueri log hanya akan menyertakan data dari jenis sumber daya tersebut. Jika Anda ingin menjalankan kueri yang menyertakan data dari layanan Azure lainnya, pilih Log dari menu Azure Monitor . Lihat Cakupan kueri log dan rentang waktu di Azure Monitor Log Analytics untuk detail lebih lanjut.

Untuk daftar kueri umum untuk layanan apa pun, lihat antarmuka kueri Analitik Log.

Peringatan

Pemberitahuan Azure Monitor secara proaktif memberi tahu Anda saat kondisi tertentu ditemukan di data pemantauan Anda. Pemberitahuan memungkinkan Anda mengidentifikasi dan mengatasi masalah di sistem Anda sebelum pelanggan Anda memperhatikannya. Untuk informasi selengkapnya, lihat Pemberitahuan Azure Monitor.

Ada banyak sumber pemberitahuan umum untuk sumber daya Azure. Untuk contoh pemberitahuan umum pada sumber daya Azure, lihat Contoh kueri pemberitahuan log. Situs Azure Monitor Baseline Alerts (AMBA) menyediakan metode semi-otomatis untuk menerapkan pemberitahuan, dasbor, dan panduan metrik platform penting. Situs ini berlaku untuk subset layanan Azure yang terus berkembang, termasuk semua layanan yang merupakan bagian dari Zona Pendaratan Azure (ALZ).

Skema peringatan umum menstandarkan penggunaan pemberitahuan Azure Monitor. Untuk informasi selengkapnya, lihat Skema pemberitahuan umum.

Jenis peringatan

Anda dapat memperingatkan metrik atau sumber data log apa pun di platform data Azure Monitor. Ada banyak jenis pemberitahuan yang berbeda tergantung pada layanan yang Anda pantau dan data pemantauan yang Anda kumpulkan. Berbagai jenis pemberitahuan memiliki berbagai manfaat dan kelemahan. Untuk informasi selengkapnya, lihat Memilih jenis pemberitahuan pemantauan yang tepat.

Daftar berikut ini menjelaskan jenis pemberitahuan Azure Monitor yang bisa Anda buat:

  • Peringatan metrik mengevaluasi metrik sumber daya secara berkala. Metrik dapat berupa metrik platform, metrik kustom, log dari Azure Monitor yang dikonversi ke metrik, atau metrik Application Insights. Pemberitahuan metrik juga dapat menerapkan beberapa kondisi dan ambang batas dinamis.
  • Pemberitahuan log memungkinkan pengguna menggunakan kueri Analitik Log untuk mengevaluasi log sumber daya pada frekuensi yang telah ditentukan sebelumnya.
  • Peringatan log aktivitas dipicu saat terjadi peristiwa log aktivitas baru yang sesuai dengan kondisi yang ditentukan. Pemberitahuan Resource Health dan pemberitahuan Service Health adalah pemberitahuan log aktivitas yang melaporkan layanan dan kesehatan sumber daya Anda.

Beberapa layanan Azure juga mendukung pemberitahuan deteksi pintar, pemberitahuan Prometheus, atau aturan pemberitahuan yang direkomendasikan.

Untuk beberapa layanan, Anda dapat memantau dalam skala besar dengan menerapkan aturan pemberitahuan metrik yang sama ke beberapa sumber daya dengan jenis yang sama yang ada di wilayah Azure yang sama. Pemberitahuan individual dikirim untuk setiap sumber daya yang dipantau. Untuk layanan dan cloud Azure yang didukung, lihat Memantau beberapa sumber daya dengan satu aturan alert.

Untuk beberapa layanan Azure, Anda dapat mengaktifkan aturan pemberitahuan yang langsung siap digunakan dan direkomendasikan.

Sistem mengompilasi daftar aturan peringatan yang direkomendasikan berdasarkan:

  • Pengetahuan penyedia sumber daya tentang sinyal dan ambang penting untuk memantau sumber daya.
  • Data yang menunjukkan hal-hal yang biasa diperingatkan oleh pelanggan terkait sumber daya ini.

Catatan

Aturan pemberitahuan yang direkomendasikan tersedia untuk:

  • Mesin virtual
  • Sumber daya Azure Kubernetes Service (AKS)
  • Ruang Kerja Log Analytics

Mengonfigurasi pemberitahuan berbasis metrik Prometheus

Persyaratan unduhan dan konfigurasi: Aturan pemberitahuan tersedia sebagai templat ARM atau file Bicep yang dapat diunduh. Sebelum mengonfigurasi pemberitahuan, pastikan layanan terkelola untuk Prometheus diaktifkan di kluster Anda dan ruang kerja Azure Monitor ditautkan dengan benar ke kluster AKS Anda.

Saat mengaktifkan pengumpulan layanan terkelola untuk metrik Prometheus untuk kluster, Anda dapat mengunduh kumpulan layanan terkelola yang direkomendasikan untuk aturan pemberitahuan Prometheus.

Unduhan mencakup aturan berikut:

Tingkat Peringatan
Tingkat kluster KubeCPUQuotaOvercommit
KubeMemoryQuotaOvercommit
KubeContainerOOMKilledCount
KubeClientErrors
KubePersistentVolumeFillingUp
KubePersistentVolumeInodesFillingUp
KubePersistentVolumeErrors
KubeContainerWaiting
KubeDaemonSetNotScheduled
KubeDaemonSetMisScheduled
KubeQuotaAlmostFull
Tingkat node KubeNodeUnreachable
KubeNodeReadinessFlapping
Tingkat Pod KubePVUsageHigh
KubeDeploymentReplicasMismatch
KubeStatefulSetReplicasMismatch
KubeHpaReplicasMismatch
KubeHpaMaxedOut
KubePodCrashLooping
KubeJobStale
KubePodContainerRestart
KubePodReadyStateLow
KubePodFailedState
KubePodNotReadyByController
KubeStatefulSetGenerationMismatch
KubeJobFailed
KubeContainerAverageCPUHigh
KubeContainerAverageMemoryHigh
KubeletPodStartUpLatencyHigh

Untuk informasi selengkapnya, lihat Membuat alert log dari Container insight dan Membuat kueri log dari Container insight.

Pemberitahuan log dapat mengukur dua jenis informasi untuk membantu Anda memantau berbagai skenario:

  • Jumlah hasil: Menghitung jumlah baris yang dikembalikan oleh kueri. Gunakan informasi ini untuk menangani peristiwa seperti catatan peristiwa Windows, peristiwa syslog, dan pengecualian aplikasi.
  • Perhitungan nilai: Membuat perhitungan berdasarkan kolom numerik. Gunakan informasi ini untuk menyertakan beragam sumber daya. Contohnya adalah persentase CPU.

Sebagian besar kueri log membandingkan nilai DateTime dengan waktu saat ini menggunakan operator now dengan rentang waktu satu jam yang lalu. Untuk mempelajari cara membuat pemberitahuan berbasis log, lihat Buat pemberitahuan log dari Wawasan Kontainer.

Aturan pemberitahuan AKS

Tabel berikut ini mencantumkan beberapa aturan pemberitahuan yang disarankan untuk AKS. Pemberitahuan ini hanyalah contoh. Anda dapat mengatur pemberitahuan untuk metrik, entri log, atau entri log aktivitas apa pun yang tercantum dalam referensi data pemantauan AKS.

Kondisi Deskripsi
Persentase> Penggunaan CPU95 Pemberitahuan saat penggunaan CPU rata-rata di semua simpul melebihi ambang batas.
Persentase Set Kerja Memori>100 Pemberitahuan saat rata-rata set kerja di semua simpul melebihi ambang batas.

Rekomendasi Advisor

Untuk beberapa layanan, jika kondisi penting atau perubahan segera terjadi selama operasi sumber daya, pemberitahuan ditampilkan di halaman Gambaran Umum layanan di portal. Anda dapat menemukan informasi selengkapnya dan perbaikan yang direkomendasikan untuk pemberitahuan di rekomendasi Advisor di bawah Pemantauan di menu sebelah kiri. Selama operasi normal, tidak ada rekomendasi advisor yang ditampilkan.

Untuk informasi selengkapnya tentang Azure Advisor, lihat Gambaran umum Azure Advisor.

Catatan

Jika Anda membuat atau menjalankan aplikasi yang berjalan di layanan Anda, wawasan aplikasi Azure Monitor mungkin menawarkan lebih banyak jenis pemberitahuan.

Pemantauan metrik jaringan simpul AKS

Persyaratan versi dan pengaktifan: Di Kubernetes versi 1.29 dan yang lebih baru, metrik jaringan simpul diaktifkan secara default untuk semua kluster yang mengaktifkan Azure Monitor. Untuk versi Kubernetes sebelumnya, Anda harus mengaktifkan pemantauan jaringan secara manual melalui konfigurasi kluster. Fitur ini mengharuskan Azure Monitor atau Container Insights dikombinasikan dengan kluster Anda.

Metrik jaringan node sangat penting untuk mempertahankan kluster Kubernetes yang sehat dan berkinerja. Dengan mengumpulkan dan menganalisis data tentang lalu lintas jaringan, Anda dapat memperoleh wawasan berharga tentang operasi kluster Anda dan mengidentifikasi potensi masalah sebelum menyebabkan pemadaman atau kehilangan performa.

Metrik jaringan simpul berikut diaktifkan secara default dan diagregasi per simpul. Semua metrik mencakup kluster label dan instans (nama node). Anda dapat dengan mudah melihat metrik ini menggunakan dasbor Grafana Terkelola di bawah Azure Managed Prometheus>Kubernetes>Jaringan>Klaster.

Metrik jaringan simpul AKS berdasarkan jenis sarana data

Semua metrik mencakup label ini:

  • cluster
  • instance (nama node)

Dukungan dan batasan OS: Untuk skenario sarana data Cilium, fitur Container Network Observability menyediakan metrik hanya untuk kumpulan simpul Linux. Saat ini, Windows tidak didukung untuk metrik Container Network Observability. Pastikan kluster Anda memiliki kumpulan simpul Linux untuk ketersediaan metrik Cilium penuh.

Untuk skenario sarana data Cilium, fitur Container Network Observability menyediakan metrik hanya untuk Linux. Saat ini, Windows tidak didukung untuk metrik Container Network Observability.

Cilium memaparkan beberapa metrik yang digunakan Container Network Observability:

Nama metrik Deskripsi Label tambahan Linux Windows
cilium_forward_count_total Jumlah paket yang diteruskan total direction Didukung ✅ Tidak didukung ❌
cilium_forward_bytes_total Jumlah total byte yang diteruskan direction Didukung ✅ Tidak didukung ❌
cilium_drop_count_total Total jumlah paket yang dihilangkan direction, reason Didukung ✅ Tidak didukung ❌
cilium_drop_bytes_total Total jumlah byte yang dihilangkan direction, reason Didukung ✅ Tidak didukung ❌

Menonaktifkan kumpulan metrik jaringan simpul AKS

Anda dapat menonaktifkan pengumpulan metrik jaringan pada simpul tertentu dengan menambahkan label networking.azure.com/node-network-metrics=disabled ke simpul tersebut.

Catatan

Retina memiliki operator: "Exists"effect: NoSchedule toleransi, sehingga melewati NoSchedule taint. Oleh karena itu, label digunakan alih-alih taint untuk mengontrol penjadwalan.

Jika kluster adalah autoprovisioning/autoscaling simpul, Anda perlu mengaktifkan bendera secara manual pada setiap simpul.

Penting

Fitur ini tidak berlaku jika Advanced Container Networking Services (ACNS) diaktifkan pada kluster Anda.

Untuk menonaktifkan kumpulan metrik pada simpul:

kubectl label node <node-name> networking.azure.com/node-network-metrics=disabled

Untuk metrik tingkat pod dan DNS terperinci, lihat Layanan Jaringan Kontainer Tingkat Lanjut.

Konten terkait

  • Last updated on