Pemecahan masalah kemampuan observasi

Dokumen ini menjelaskan cara mengidentifikasi kegagalan deployment dan insiden operasional yang mungkin Anda alami di perangkat air-gapped Google Distributed Cloud (GDC) dan berisi deskripsi semua pemberitahuan yang ditampilkan dalam sistem untuk membantu Anda memecahkan masalah umum dengan komponen logging dan pemantauan.

Mengidentifikasi komponen Observability

Platform Observability men-deploy komponennya ke namespace obs-system di cluster infrastruktur organisasi.

Instance Grafana Infrastructure Operator (IO) menyediakan akses ke metrik tingkat organisasi untuk memantau komponen infrastruktur seperti pemakaian CPU dan konsumsi penyimpanan. Layanan ini juga memberikan akses ke log operasional dan audit. Selain itu, alat ini memberikan akses ke pemberitahuan, log, dan metrik dari komponen yang dapat dioperasikan GDC.

Stack pemantauan dan logging GDC menggunakan solusi open source sebagai bagian dari platform Observability. Komponen ini mengumpulkan log dan metrik dari pod Kubernetes, mesin bare metal, switch jaringan, penyimpanan, dan layanan terkelola.

Tabel berikut berisi deskripsi semua komponen yang mengintegrasikan platform Observability:

Komponen Deskripsi
Prometheus Prometheus adalah database deret waktu untuk mengumpulkan dan menyimpan metrik serta mengevaluasi pemberitahuan. Prometheus menyimpan metrik di instance Cortex dari cluster infrastruktur organisasi untuk penyimpanan jangka panjang. Prometheus menambahkan label sebagai key-value pair dan mengumpulkan metrik dari node Kubernetes, pod, mesin bare metal, switch jaringan, dan peralatan penyimpanan.
Alertmanager Alertmanager adalah sistem pengelola yang ditentukan pengguna yang mengirimkan pemberitahuan saat log atau metrik menunjukkan bahwa komponen sistem gagal atau tidak beroperasi secara normal. Aplikasi ini mengelola perutean, penonaktifan, dan penggabungan pemberitahuan Prometheus.
Loki Loki adalah database deret waktu yang menyimpan dan menggabungkan log dari berbagai sumber. Layanan ini mengindeks log untuk pembuatan kueri yang efisien.
Grafana Grafana menyediakan antarmuka pengguna (UI) untuk melihat metrik yang dikumpulkan Prometheus dan membuat kueri log audit dan operasional dari instance Loki yang sesuai. UI memungkinkan Anda memvisualisasikan dasbor metrik dan pemberitahuan.
Fluent Bit Fluent Bit adalah prosesor yang menarik log dari berbagai komponen atau lokasi dan mengirimkannya ke Loki. Agen ini berjalan di setiap node dari semua cluster.

Mengidentifikasi kegagalan deployment

Jika deployment Anda berjalan dan responsif, komponen akan berjalan dalam status READY.

Lakukan langkah-langkah berikut untuk mengidentifikasi kegagalan deployment:

  1. Konfirmasi status komponen saat ini:

    kubectl get -n obs-system TYPE/COMPONENT

    Ganti kode berikut:

    • TYPE: jenis komponen
    • COMPONENT: nama komponen

    Anda akan mendapatkan output yang mirip dengan berikut ini:

    NAME       READY  AGE
COMPONENT  1/1    23h

    Jika komponen dalam kondisi baik, kolom READY pada output akan menampilkan N/N sebagai nilai. Jika kolom READY tidak menampilkan nilai, hal ini tidak selalu menunjukkan kegagalan. Layanan mungkin membutuhkan lebih banyak waktu untuk diproses.

  2. Periksa pod di setiap komponen:

    kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'

    Ganti COMPONENT dengan nama komponen.

    Anda akan mendapatkan output yang mirip dengan berikut ini:

    NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h

    Pastikan kolom READY menampilkan N/N sebagai nilai, kolom STATUS menampilkan nilai Running, dan jumlah RESTARTS tidak melebihi nilai 2.

    Jumlah mulai ulang yang tinggi menunjukkan gejala berikut:

    • Pod gagal dan Kubernetes akan memulainya ulang.
    • Kolom STATUS menampilkan nilai CrashLoopBackoff.

    Untuk mengatasi status gagal, lihat log pod.

    Jika pod dalam status PENDING, status ini menunjukkan satu atau beberapa gejala berikut:

    • Pod sedang menunggu akses jaringan untuk mendownload penampung yang diperlukan.
    • Masalah konfigurasi mencegah pod dimulai. Misalnya, nilai Secret yang diperlukan pod tidak ada.
    • Cluster Kubernetes Anda telah kehabisan resource untuk menjadwalkan pod, yang terjadi jika banyak aplikasi berjalan di cluster.

  3. Menentukan penyebab status PENDING:

    kubectl describe -n obs-system pod/POD_NAME

    Ganti POD_NAME dengan nama pod yang menampilkan status PENDING.

    Output menampilkan detail selengkapnya tentang pod.

  4. Buka bagian Events dari output untuk melihat tabel yang mencantumkan peristiwa terbaru pod dan ringkasan penyebab status Events.PENDING

    Output berikut menunjukkan contoh bagian Events untuk objek StatefulSet Grafana:

    Events:
  Type    Reason            Age                From                    Message
  ----    ------            ----               ----                    -------
  Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful

    Jika tidak ada peristiwa di pod atau resource lain dalam waktu yang lama, Anda akan menerima output berikut:

      Events:         <none>

Pastikan stack logging Observability sedang berjalan

Lakukan langkah-langkah berikut untuk memverifikasi bahwa stack logging sedang berjalan:

  1. Pastikan semua instance atau pod Loki telah disisipkan sidecar Istio. Pastikan semua pod Fluent Bit yang bernama anthos-audit-logs-forwarder-SUFFIX dan anthos-log-forwarder-SUFFIX telah disisipkan sidecar Istio.

  2. Pastikan semua instance Loki berjalan tanpa error di cluster infrastruktur org.

  3. Periksa status objek anthos-audit-logs-forwarder dan anthos-log-forwarder DaemonSet untuk memverifikasi bahwa semua instance berjalan di semua node tanpa error.

  4. Pastikan Anda mendapatkan log operasional dari container kube-apiserver-SUFFIX dan log audit dari server Kubernetes API selama lima menit terakhir di semua cluster. Untuk melakukannya, jalankan kueri berikut di instance Grafana:

    • Log operasional: sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
    • Log audit: sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)

    Anda harus mendapatkan nilai non-nol untuk semua node bidang kontrol di cluster infrastruktur org.

Memeriksa apakah stack pemantauan Observability sedang berjalan

Lakukan langkah-langkah berikut untuk memverifikasi bahwa stack pemantauan sedang berjalan:

  1. Periksa apakah instance Grafana berjalan di cluster infrastruktur org. Pod grafana-0 harus berjalan tanpa error di namespace berikut:

    • obs-system
    • infra-obs-obs-system
    • platform-obs-obs-system

  2. Pastikan semua komponen pemantauan berada di Istio Service Mesh. Ikuti langkah-langkah di bagian Mengidentifikasi kegagalan deployment. Setiap pod berikut harus menunjukkan bahwa semua container siap di kolom READY. Misalnya, nilai 3/3 berarti tiga dari tiga penampung sudah siap. Selain itu, pod harus memiliki penampung istio-proxy. Jika pod tidak memenuhi kondisi ini, mulai ulang pod:

    Nama pod Jumlah container yang siap
    cortex- 2/2
    cortex-etcd-0 2/2
    cortex-proxy-server- 2/2
    cortex-tenant- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server- 2/2
    meta-prometheus-0 4/4
    cortex-alertmanager- 2/2
    cortex-compactor- 2/2
    cortex-distributor- 2/2
    cortex-etcd-0 2/2
    cortex-ingester- 2/2
    cortex-querier- 2/2
    cortex-query-frontend- 2/2
    cortex-query-scheduler- 2/2
    cortex-ruler- 2/2
    cortex-store-gateway- 2/2
    cortex-tenant- 2/2
    grafana-proxy-server- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server-* 2/2
    meta-prometheus-0 4/4

  3. Pastikan Cortex berjalan tanpa error.

Mengambil log Observability

Tabel berikut berisi perintah yang harus Anda jalankan untuk mengambil log setiap komponen yang di-deploy oleh platform Observability.

Komponen Perintah pengambilan log
grafana kubectl logs -n obs-system statefulset/grafana
anthos-prometheus-k8s kubectl logs -n obs-system statefulset/anthos-prometheus-k8s
alertmanager kubectl logs -n obs-system statefulset/alertmanager
ops-logs-loki-io kubectl logs -n obs-system statefulset/ops-logs-loki-io
ops-logs-loki-io-read kubectl logs -n obs-system statefulset/ops-logs-loki-io-read
ops-logs-loki-all kubectl logs -n obs-system statefulset/ops-logs-loki-all
ops-logs-loki-all-read kubectl logs -n obs-system statefulset/ops-logs-loki-all-read
audit-logs-loki-io kubectl logs -n obs-system statefulset/audit-logs-loki-io
audit-logs-loki-io-read kubectl logs -n obs-system statefulset/audit-logs-loki-io-read
audit-logs-loki-pa kubectl logs -n obs-system statefulset/audit-logs-loki-pa
audit-logs-loki-pa-read kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read
audit-logs-loki-all kubectl logs -n obs-system statefulset/audit-logs-loki-all
audit-logs-loki-all-read kubectl logs -n obs-system statefulset/audit-logs-loki-all-read
anthos-log-forwarder kubectl logs -n obs-system daemonset/anthos-log-forwarder
anthos-audit-logs-forwarder kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder
oplogs-forwarder kubectl logs -n obs-system daemonset/oplogs-forwarder
logmon-operator kubectl logs -n obs-system deployment/logmon-operator

Untuk melihat log instance komponen sebelumnya, tambahkan flag -p di akhir setiap perintah. Dengan menambahkan tanda -p, Anda dapat meninjau log instance sebelumnya yang gagal, bukan instance yang sedang berjalan saat ini.

Melihat konfigurasi

Stack Observability menggunakan resource kustom Kubernetes API untuk mengonfigurasi pipeline pemantauan dan logging.

Resource kustom LoggingPipeline di-deploy di cluster infrastruktur org dan mengonfigurasi instance Loki.

Perintah berikut menunjukkan tindakan yang tersedia yang dapat Anda lakukan pada pipeline logging:

  • Lihat konfigurasi deployment pipeline logging Anda saat ini:

    kubectl get loggingpipeline -n obs-system default -o yaml

  • Ubah konfigurasi deployment pipeline logging Anda:

    kubectl edit loggingpipeline -n obs-system default

GDC menggunakan operator logging dan pemantauan bernama logmon-operator untuk mengelola deployment komponen Observability seperti Prometheus dan Fluent Bit. API ke komponen logmon-operator adalah definisi resource kustom logmon. Definisi resource kustom logmon menginstruksikan logmon-operator tentang cara mengonfigurasi Observability untuk deployment Anda. Definisi resource kustom ini mencakup properti volume untuk menyimpan metrik, aturan pemberitahuan untuk Alertmanager, konfigurasi Prometheus untuk mengumpulkan metrik, dan konfigurasi Grafana untuk dasbor.

Perintah berikut menunjukkan tindakan yang tersedia yang dapat Anda lakukan pada definisi resource kustom logmon:

  • Melihat konfigurasi saat ini untuk deployment Observability Anda:

    kubectl get logmon -n obs-system logmon-default -o yaml

  • Ubah konfigurasi deployment Observability Anda:

    kubectl edit logmon -n obs-system logmon-default

Output dari menjalankan salah satu perintah dapat mereferensikan beberapa objek ConfigMap Kubernetes untuk konfigurasi lebih lanjut. Misalnya, Anda dapat mengonfigurasi aturan Alertmanager dalam objek ConfigMap terpisah, yang direferensikan dalam definisi resource kustom logmon berdasarkan nama. Anda dapat mengubah dan melihat konfigurasi Alertmanager melalui definisi resource kustom logmon bernama gpc-alertmanager-config.

Untuk melihat konfigurasi Alertmanager, jalankan:

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

Masalah umum

Bagian ini berisi masalah umum yang mungkin Anda hadapi saat men-deploy platform Observability.

Anda tidak dapat mengakses Grafana

Secara default, Grafana tidak diekspos ke mesin di luar cluster Kubernetes Anda. Untuk mengakses antarmuka Grafana dari luar cluster infrastruktur org untuk sementara, Anda dapat meneruskan port Service ke localhost. Untuk meneruskan port Service, jalankan:

kubectl port-forward -n gpc-system service/grafana 33000\:3000

Di browser web Anda, buka http://localhost:33000 untuk melihat dasbor Grafana untuk deployment Anda. Untuk mengakhiri proses, tekan tombol Control+C.

Grafana berjalan lambat

Grafana berjalan lambat menunjukkan hal berikut:

  • Kueri ke Prometheus atau Loki menampilkan data yang berlebihan.
  • Kueri menampilkan lebih banyak data daripada yang wajar untuk ditampilkan dalam satu grafik.

Untuk mengatasi kecepatan lambat dalam Grafana, periksa kueri di dasbor Grafana kustom Anda. Jika kueri menampilkan lebih banyak data daripada yang wajar untuk ditampilkan pada satu grafik, pertimbangkan untuk mengurangi jumlah data yang ditampilkan guna meningkatkan performa dasbor.

Dasbor Grafana tidak menampilkan metrik atau log

Grafana yang tidak menampilkan metrik atau log dapat disebabkan oleh alasan berikut:

  • Sumber data Grafana tidak disetel dengan benar.
  • Sistem mengalami masalah konektivitas ke sumber data pemantauan atau logging.
  • Sistem tidak mengumpulkan metrik atau log.

Untuk melihat log dan metrik, ikuti langkah-langkah berikut:

  1. Di antarmuka pengguna Grafana, klik Dashboard settings.
  2. Pilih Sumber Data.
  3. Di halaman Sumber Data, pastikan Anda melihat sumber berikut:
Nama Organisasi URL
Audit Logs All http://audit-logs-loki-io-read.obs-system.svc:3100
Operational Logs Root http://ops-logs-loki-io-read.obs-system.svc:3100
Operational Logs Org http://ops-logs-loki-all-read.obs-system.svc:3100
prometheus http://anthos-prometheus-k8s.obs-system.svc:9090

Tidak adanya sumber data ini menunjukkan bahwa stack Observability gagal mengonfigurasi Grafana dengan benar.

Jika Anda telah mengonfigurasi sumber data dengan benar, tetapi tidak ada data yang ditampilkan, hal ini mungkin menunjukkan masalah pada objek Service yang mengumpulkan metrik atau log untuk dimasukkan ke Prometheus atau Loki.

Saat mengumpulkan metrik, Prometheus mengikuti model pull untuk membuat kueri objek Service Anda secara berkala untuk mengumpulkan metrik dan menyimpan nilai yang ditemukan. Agar Prometheus dapat menemukan objek Service untuk pengumpulan metrik, hal berikut harus benar:

  • Semua pod untuk objek Service dianotasi dengan 'monitoring.gke.io/scrape: "true"'.

  • Format metrik Prometheus mengekspos metrik pod melalui HTTP. Secara default, Prometheus mencari metrik ini di endpoint http://POD_NAME:80/metrics. Jika perlu, Anda dapat mengganti port, endpoint, dan skema melalui anotasi.

Fluent Bit mengumpulkan log dan ditujukan untuk berjalan di setiap node cluster Kubernetes Anda. Fluent Bit mengirim log ke Loki untuk penyimpanan jangka panjang.

Jika tidak ada log di Grafana, coba solusi berikut:

  • Periksa log instance Loki untuk memastikan instance berjalan tanpa error.

  • Jika instance Loki berjalan dengan benar, tetapi log tidak muncul, periksa log di Fluent Bit untuk memastikan layanan berfungsi seperti yang diharapkan. Untuk meninjau cara menarik log, lihat Mengambil log Observability.

Alertmanager tidak membuka pemberitahuan

Jika Alertmanager gagal membuka pemberitahuan, lakukan langkah-langkah berikut:

  1. Di objek configMap dalam namespace gpc-system, pastikan label logmon: system_metrics ada.
  2. Pastikan bagian data configMap menyertakan kunci bernama alertmanager.yml. Nilai untuk kunci alertmanager.yml harus berupa aturan pemberitahuan yang ada dalam file konfigurasi Alertmanager yang valid.

  3. Pastikan definisi resource kustom logmon bernama logmon-default di namespace gpc-system berisi referensi ke objek configMap. Definisi resource kustom logmon-default harus berisi nama objek configMap seperti yang ditunjukkan dalam contoh berikut:

    apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config

    Nilai alerts-config dalam contoh adalah nama objek configMap Anda.

Alertmanager tidak mengirimkan pemberitahuan ke saluran notifikasi yang dikonfigurasi

Error konfigurasi dapat mencegah Anda menerima notifikasi di software eksternal yang Anda konfigurasi sebagai saluran notifikasi, seperti Slack, meskipun Alertmanager menghasilkan pemberitahuan di instance Grafana.

Untuk menerima pemberitahuan di software eksternal Anda, ikuti langkah-langkah berikut:

  1. Pastikan nilai dalam file konfigurasi Alertmanager Anda diformat dengan benar. Saat memicu pemberitahuan, Alertmanager akan mengkueri webhook pada software eksternal.

  2. Pastikan URL webhook yang terhubung ke software eksternal sudah benar. Jika URL sudah benar, pastikan software dikonfigurasi untuk menerima webhook. Anda mungkin perlu membuat kunci API untuk mengakses API layanan eksternal, atau kunci API Anda saat ini mungkin sudah tidak berlaku, dan Anda perlu memperbaruinya.

  3. Jika layanan eksternal berada di luar deployment appliance GDC yang terisolasi dari internet, pastikan cluster infrastruktur organisasi Anda telah mengonfigurasi aturan traffic keluarnya. Konfigurasi ini memungkinkan Alertmanager mengirim permintaan ke layanan di luar jaringan Kubernetes internal. Jika aturan keluar tidak diverifikasi, Alertmanager tidak akan dapat menemukan software eksternal.

Anda tidak dapat melihat metrik dari workload yang tercakup dalam project

Ikuti langkah-langkah berikut untuk menerapkan solusi sementara dan mendapatkan metrik dari beban kerja Anda:

  1. Pastikan resource kustom MonitoringTarget memiliki status Ready.
  2. Untuk meng-scrape workload, Anda harus mendeklarasikan semua informasi target yang ditentukan ke MonitoringTarget dalam spesifikasi pod workload. Misalnya, jika Anda menyatakan bahwa metrik tersedia di port 8080, pod workload harus menyatakan kepada Kubernetes bahwa port 8080 terbuka. Jika tidak, Prometheus akan mengabaikan workload.
  3. Prometheus menjalankan beberapa shard, yang berarti tidak semua pod Prometheus diharapkan untuk meng-scrape pod Anda. Anda dapat mengidentifikasi nomor bagian dalam nama setiap pod Prometheus. Sebagai contoh, primary-prometheus-shard0-replica0-0 adalah bagian dari shard 0. Periksa pod yang ingin Anda ambil dari setiap shard Prometheus:
    1. Teruskan port pod primary-prometheus-shardSHARD_NUMBER-replica0-0 Prometheus di namespace obs-system untuk mendapatkan akses ke UI Prometheus. Ganti SHARD_NUMBER di nama pod dengan angka yang bertambah setiap kali Anda memeriksa shard baru.
    2. Buka UI Prometheus di browser web Anda dan ikuti langkah-langkah berikut:
      1. Klik Status > Target.
      2. Pastikan pod yang ingin Anda ambil datanya ada dalam daftar. Jika tidak, periksa shard berikutnya. Jika tidak ada lagi shard yang perlu diperiksa, validasi ulang bahwa Prometheus memiliki informasi yang cukup untuk menemukannya.
    3. Verifikasi bahwa pod primary-prometheus-shardSHARD_NUMBER-replica0-0 Prometheus mencatat error di namespace obs-system.
  4. Verifikasi bahwa log pod cortex-tenant menampilkan error di namespace obs-system.

Dasbor tidak dibuat

Ikuti langkah-langkah berikut untuk menerapkan solusi dan mencari tahu alasan dasbor tidak dibuat:

  1. Tinjau status resource kustom Dashboard untuk mencari error. Resource kustom harus memiliki status Ready.
  2. Pastikan Anda memeriksa instance Grafana yang benar. Misalnya, jika Anda men-deploy dasbor di namespace project bernama my-namespace, dasbor harus berada di instance Grafana di endpoint https://GDCH_URL/my-namespace/grafana.
  3. Periksa log fleet-admin-controller di namespace gpc-system. Cari kesalahan terkait dasbor dengan menelusuri nama dasbor di log. Jika Anda menemukan error, file JSON dalam objek configMap Anda memiliki format yang salah, dan Anda harus memperbaikinya.
  4. Periksa log Grafana di namespace PROJECT_NAME-obs-system untuk mencari error. Dasbor membuat kueri Grafana REST API, jadi Grafana harus berfungsi agar dasbor dapat dibuat.

Pemberitahuan Anda tidak terbuka

Lakukan langkah-langkah berikut untuk menerapkan solusi dan mencari tahu alasan pemberitahuan tidak terbuka:

  1. Pastikan Cortex dan Loki berada dalam mode bucket storage. Aturan tidak akan berfungsi kecuali jika backend didukung oleh penyimpanan bucket.
  2. Verifikasi bahwa status resource kustom MonitoringRule dan LoggingRule adalah Ready.
  3. Periksa kondisi pemberitahuan berikut:
    • Ekspresi PromQL dan LogQL: Bandingkan semua fungsi yang Anda gunakan dengan dokumentasi Membuat aturan pemberitahuan untuk memastikan aturan Anda dikonfigurasi sesuai keinginan Anda. Pastikan ekspresi menampilkan nilai true atau false.
    • Durasi: Bidang for resource kustom menentukan berapa lama suatu kondisi harus terpenuhi. Kolom interval menentukan seberapa sering kondisi dievaluasi. Periksa nilai kolom ini satu sama lain dan pastikan kondisi Anda logis.
  4. Periksa UI Grafana untuk melihat apakah notifikasi terbuka menggunakan halaman Alerts.
  5. Jika Grafana menunjukkan bahwa pemberitahuan terbuka, periksa saluran notifikasi Anda dan pastikan Alertmanager dapat menghubungi saluran tersebut untuk menghasilkan pemberitahuan.

Log yang diharapkan tidak tersedia

Lakukan langkah-langkah berikut jika Anda tidak melihat log operasional dari komponen Anda:

  1. Periksa apakah komponen Anda berjalan dan menghasilkan log.
  2. Periksa apakah log komponen Anda harus dikumpulkan sebagai fungsi bawaan. Jika tidak, pastikan Anda telah men-deploy resource kustom LoggingTarget dengan spesifikasi yang valid dan dengan status Ready.

Lakukan langkah-langkah berikut jika Anda tidak melihat log audit dari komponen Anda:

  1. Jika komponen Anda menulis log ke file, pastikan file tersebut benar-benar ada di sistem file node pada jalur /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log.
  2. Pastikan pod anthos-audit-logs-forwarder-SUFFIX di node yang sama tidak memiliki error.
  3. Jika komponen Anda menggunakan endpoint syslog untuk menerima log, pastikan Anda telah men-deploy resource kustom AuditLoggingTarget dengan spesifikasi yang valid dan dengan status Ready.

Mengidentifikasi aturan pemberitahuan yang telah ditetapkan

Bagian ini berisi informasi tentang aturan pemberitahuan standar yang ada di komponen Observability untuk memberi tahu Anda tentang kegagalan sistem.

Aturan pemberitahuan yang telah ditetapkan di Loki

Tabel berikut menyediakan aturan pemberitahuan yang telah diinstal sebelumnya di Loki untuk kegagalan logging audit:

Aturan pemberitahuan yang sudah diinstal di Loki untuk kegagalan pencatatan log audit
Nama Jenis Deskripsi
FluentBitAuditLoggingWriteFailure Kritis Fluent Bit gagal meneruskan log audit dalam lima menit terakhir.
LokiAuditLoggingWriteFailure Kritis Loki gagal menulis log audit ke penyimpanan backend.

Jika satu atau beberapa pemberitahuan ini ditampilkan, sistem telah kehilangan setidaknya satu catatan audit.

Aturan pemberitahuan yang telah ditentukan sebelumnya di Prometheus

Tabel berikut menyediakan aturan pemberitahuan yang telah diinstal sebelumnya di Prometheus untuk komponen Kubernetes:

Aturan pemberitahuan yang sudah diinstal di Prometheus
Nama Jenis Deskripsi
KubeAPIDown Kritis Kube API telah menghilang dari penemuan target Prometheus selama 15 menit.
KubeClientErrors Peringatan Rasio error dari klien server Kubernetes API telah lebih besar dari 0,01 selama 15 menit.
KubeClientErrors Kritis Rasio error dari klien server Kubernetes API telah lebih besar dari 0,1 selama 15 menit.
KubePodCrashLooping Peringatan Pod telah berada dalam status error berulang selama lebih dari 15 menit.
KubePodNotReady Peringatan Pod telah dalam status belum siap selama lebih dari 15 menit.
KubePersistentVolumeFillingUp Kritis Byte gratis objek PersistentVolume yang diklaim kurang dari 0,03.
KubePersistentVolumeFillingUp Peringatan Byte kosong dari objek PersistentVolume yang diklaim kurang dari 0,15.
KubePersistentVolumeErrors Kritis Volume persisten telah berada dalam fase Failed atau Pending selama lima menit.
KubeNodeNotReady Peringatan Node belum siap selama lebih dari 15 menit.
KubeNodeCPUUsageHigh Kritis Penggunaan CPU node lebih besar dari 80%.
KubeNodeMemoryUsageHigh Kritis Penggunaan memori node lebih besar dari 80%.
NodeFilesystemSpaceFillingUp Peringatan Penggunaan sistem file node lebih dari 60%.
NodeFilesystemSpaceFillingUp Kritis Penggunaan sistem file node lebih dari 85%.
CertManagerCertExpirySoon Peringatan Masa berlaku sertifikat akan berakhir dalam 21 hari.
CertManagerCertNotReady Kritis Sertifikat tidak siap melayani traffic setelah 10 menit.
CertManagerHittingRateLimits Kritis Anda mencapai batas kecepatan saat membuat atau memperpanjang sertifikat selama lima menit.
DeploymentNotReady Kritis Deployment di cluster infrastruktur org telah berada dalam status tidak siap selama lebih dari 15 menit.
StatefulSetNotReady Kritis Objek StatefulSet di cluster infrastruktur org telah berada dalam status tidak siap (non-ready) selama lebih dari 15 menit.
AuditLogsForwarderDown Kritis DaemonSet anthos-audit-logs-forwarder tidak berfungsi selama lebih dari 15 menit.
AuditLogsLokiDown Kritis audit-logs-loki StatefulSet telah dalam status tidak siap selama lebih dari 15 menit.