Mengumpulkan informasi proses debug
Bagian ini menjelaskan cara mengumpulkan log dan konfigurasi untuk proses debug.
Mengambil log dari pod operator
Untuk mengambil log dari pod operator, jalankan perintah berikut:
kubectl logs deployments/fleet-controller-manager -c manager -n alloydb-omni-system > alloydb-omni-system-fleet-controller-manager.out
kubectl logs deployments/local-controller-manager -c manager -n alloydb-omni-system > alloydb-omni-system-local-controller-manager.out
Mengambil log pod database
Untuk mengambil log pod database, jalankan perintah berikut:
DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl logs -c database ${DB_POD} -n DB_CLUSTER_NAMESPACE > ${DB_POD}.log
kubectl logs -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -c database -n DB_CLUSTER_NAMESPACE > dbcluster_DB_CLUSTER_NAME.out
Log berikut adalah contoh pemeriksaan kesehatan database yang berhasil:
I0813 11:01:49.210051 27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.196796 27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.196853 27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.209824 27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.197013 27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.197093 27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.210010 27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.197368 27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.197425 27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.210416 27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
Mengambil postgresql.log
Untuk mengambil postgresql.log, jalankan perintah berikut:
DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl exec -c database -n DB_CLUSTER_NAMESPACE -it ${DB_POD} -- cat /obs/diagnostic/postgresql.log > dbcluster_DB_CLUSTER_NAME_postgresql.log
Mengambil file YAML DBInstance
Untuk mengambil file YAML DBInstance, jalankan perintah berikut:
kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > dbcluster_DB_CLUSTER_NAME.yaml
Mengambil konfigurasi dan log untuk skenario HA
Untuk mengambil konfigurasi dan log khusus untuk skenario ketersediaan tinggi (HA), jalankan perintah berikut:
kubectl get replicationconfig.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > replicationconfig_DB_CLUSTER_NAME.yaml
kubectl get deletestandbyjobs.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > deletestandbyjobs_DB_CLUSTER_NAME.yaml
kubectl get createstandbyjobs.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > createstandbyjobs_DB_CLUSTER_NAME.yaml
kubectl get failovers.alloydbomni.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > failovers_DB_CLUSTER_NAME.yaml
Mengambil status pod dan STS
Untuk mengambil status pod dan StatefulSet (STS), jalankan perintah berikut:
DB_POD=$(kubectl get pod -n DB_CLUSTER_NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod ${DB_POD} -n DB_CLUSTER_NAMESPACE > pod_${DB_POD}.out
kubectl describe statefulset -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE > statefulset_DB_CLUSTER_NAME.out
Mengidentifikasi error
Bagian ini menjelaskan cara mengidentifikasi error.
Mencari status error dan kode error
Untuk mengidentifikasi kode error, periksa file YAML DBCluster di bagian status. Lihat dokumentasi kode error untuk mengetahui informasi selengkapnya.
Untuk mengambil file YAML DBCluster, jalankan perintah berikut:
kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > dbcluster_DB_CLUSTER_NAME.yaml
Cari criticalIncidents. Bagian ini berisi kode error dan pelacakan tumpukan.
Berikut adalah contoh criticalIncidents:
status:
certificateReference:
certificateKey: ca.crt
secretRef:
name: dbs-al-cert-dr-mce
namespace: dr
conditions:
- lastTransitionTime: "2024-10-07T22:46:03Z"
...
criticalIncidents:
- code: DBSE0304
createTime: "2024-10-03T11:50:54Z"
message: 'Healthcheck: Health check invalid result.'
resource:
component: healthcheck
location:
group: alloydbomni.internal.dbadmin.goog
kind: Instance
name: bc0f-dr-mce
namespace: dr
version: v1
stackTrace:
- component: healthcheck
message: 'DBSE0304: Healthcheck: Health check invalid result. rpc error: code
= Code(10304) desc = DBSE0304: Healthcheck: Health check invalid result.
dbdaemon/healthCheck: invalid timestamp read back from the healthcheck table.
Lag is 384837.296269 seconds, wanted 35 seconds'
Anda juga dapat mengambil status dengan mengekstrak kolom tertentu dalam format JSON:
kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath='{.status.criticalIncidents}' | jq
Outputnya mirip dengan hal berikut ini:
[
{
"code": "DBSE0085",
"createTime": "2024-03-14T05:41:37Z",
"message": "Platform: Pod is unschedulable.",
"resource": {
"component": "provisioning",
"location": {
"group": "alloydb.internal.dbadmin.goog",
"kind": "Instance",
"name": "b55f-testdbcluster",
"namespace": "dbs-system",
"version": "v1"
}
},
"stackTrace": [
{
"component": "provisioning",
"message": "DBSE0085: Platform: Pod is unschedulable. 0/16 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/16 nodes are available: 16 No preemption victims found for incoming pod..: Pod is unschedulable"
}
]
}
]
Jika pesan error merujuk ke pod database, periksa instance dan resource pod di namespace yang sama:
kubectl get instances.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > instance_DB_CLUSTER_NAME.yaml
kubectl get pods -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE
Men-debug masalah memori
Bagian ini menjelaskan cara men-debug masalah memori.
Menjalankan dan mengambil heapdump
Hanya aktifkan fitur ini untuk tujuan pemecahan masalah. Jangan lupa untuk menonaktifkannya setelahnya.
Untuk mengambil heapdump, selesaikan langkah-langkah berikut:
- Ubah deployment operator di namespace
alloydb-omni-systemdengan namafleet-controller-managerdanlocal-controller-manager. - Tambahkan argumen berikut ke pod
--pprof-address=:8642atau ke port lain yang tersedia. - Tunggu hingga pod pengontrol dimulai ulang.
Teruskan port sebelumnya. Contoh:
kubectl port-forward FLEET_CONTROLLER_MANAGER_POD_NAME -n alloydb-omni-system 8642:8642Di terminal lain, jalankan
go tool pprof http://localhost:8642/debug/pprof/heap. Ubah port agar cocok dengan port sebelumnya jika Anda tidak menggunakan8642.Hubungkan ke alamat dan jalankan perintah pemecahan masalah. Contoh:
top.Setelah menyelesaikan pemecahan masalah, batalkan langkah 1 dengan menghapus argumen dan menunggu pod dimulai ulang.
Menentukan jumlah resource yang dipantau operator
Untuk memahami resource yang digunakan, jalankan perintah berikut:
kubectl get backuprepositories -A | wc -l
kubectl get failovers -A | wc -l
kubectl get instancebackupplans -A | wc -l
kubectl get instancebackups -A | wc -l
kubectl get instancerestores -A | wc -l
kubectl get instances -A | wc -l
kubectl get instanceswitchovers -A | wc -l
kubectl get lrojobs -A | wc -l
kubectl get replicationconfigs -A | wc -l
kubectl get sidecars -A | wc -l
kubectl get deployments -A | wc -l
kubectl get statefulsets -A | wc -l
kubectl get certificates.cert-manager.io -A | wc -l
kubectl get issuers.cert-manager.io -A | wc -l
kubectl get configmaps -A | wc -l
kubectl get persistentvolumeclaims -A | wc -l
kubectl get persistentvolumes -A | wc -l
kubectl get pods -A | wc -l
kubectl get secrets -A | wc -l
kubectl get services -A | wc -l
kubectl get storageclasses.storage.k8s.io -A | wc -l
Misalnya, jika jumlah secret tinggi, hal ini dapat menyebabkan error Kehabisan Memori (OOM).
kubectl get secrets -A | wc -l
Proses debug HA lanjutan
Bagian ini mereferensikan resource yang merupakan penerapan internal. Resource ini dapat berubah kapan saja dan tidak memiliki komitmen kompatibilitas mundur. Hanya terapkan perbaikan manual untuk masalah pada database non-produksi. Langkah-langkah ini dapat membuat database tidak dapat dipulihkan.
Penyiapan HA AlloyDB Omni memiliki tiga fase:
- Menyiapkan instance utama untuk menerima koneksi dari instance standby.
- Menginisialisasi instance standby dan menghubungkannya ke instance utama.
- Menetapkan setelan utama untuk membuat koneksi sinkron.
Langkah 2 biasanya merupakan langkah yang paling lambat. Bergantung pada ukuran database, proses ini mungkin memerlukan waktu beberapa jam.
Setiap instance yang mereplikasi instance harus memiliki replicationconfig yang terlampir. Contoh:
kubectl get replicationconfigs.alloydbomni.internal.dbadmin.goog -n DB_CLUSTER_NAMESPACE
Contoh output:
NAME PARENT TYPE ROLE READY HEALTHY SYNC_U SYNC_D SLOT_LOG SLOT_REPLAY
cd58-adb--58ea-adb cd58-adb Physical Upstream True True true
ds-58ea-adb 58ea-adb Physical Downstream True True true
Spesifikasi Konfigurasi Replikasi menunjukkan setelan yang diinginkan, sedangkan status mencerminkan status sebenarnya seperti yang dibaca dari database. Jika ada ketidakcocokan antara spesifikasi dan status, pengontrol masih mencoba menerapkan perubahan, atau ada error yang mencegah perubahan diterapkan. Hal ini akan tercermin di kolom status.
Tugas standby
Harus ada dua kumpulan tugas internal yang melacak alur kerja instance standby:
createstandbyjobs.alloydbomni.internal.dbadmin.googdeletestandbyjobs.alloydbomni.internal.dbadmin.goog
Jika penyiapan tampak macet, lihat tugas yang terkait dengan cluster database (DBC). Tugas mungkin memiliki pesan error yang menjelaskan status penyiapan. Tugas akan otomatis dibersihkan beberapa waktu setelah selesai, sehingga Anda mungkin tidak melihat tugas apa pun jika tidak ada tugas yang sedang berlangsung.
kubectl get createstandbyjobs.alloydbomni.internal.dbadmin.goog -n DB_CLUSTER_NAMESPACE
Outputnya mirip dengan hal berikut ini:
apiVersion: alloydbomni.dbadmin.gdc.goog/v1
kind: CreateStandbyJob
metadata:
creationTimestamp: "2024-11-05T03:34:26Z"
finalizers:
- createstandbyjob.dbadmin.goog/finalizer
generation: 1804
labels:
dbs.internal.dbadmin.goog/dbc: foo-ha-alloydb1-clone1
name: foo-ha-alloydb1-clone1--ac00-foo-ha-alloydb1-clone1--6036-foo-ha-alloydb1-clone1-1730777666
namespace: db
resourceVersion: "11819071"
uid: 1f24cedf-b326-422f-9405-c96c8720cd90
spec:
attempt: 3
cleanup: false
currentStep: SetupSynchronous
currentStepTime: "2024-11-05T03:45:31Z"
metadata:
dbc: foo-ha-alloydb1-clone1
primaryInstance: ac00-foo-ha-alloydb1-clone1
retryError: 'etcdserver: leader changed'
standbyInstance: 6036-foo-ha-alloydb1-clone1
requeueTime: "2024-11-05T18:33:03Z"
startTime: "2024-11-05T03:36:56Z"
Verifikasi utama
Hal pertama yang harus diverifikasi adalah instance utama disiapkan dengan benar. Harus ada Profil Replikasi untuk setiap instance standby. Jika isSynchronous bernilai benar pada spesifikasi dan status, penyiapan akan selesai. Jika isSynchronous bernilai salah pada spesifikasi dan status, berarti penyiapan belum mencapai langkah 3. Lihat tugas standby untuk melihat apakah ada tugas yang sedang berjalan, dan apakah tugas tersebut memiliki pesan error.
replication:
profiles:
- isActive: true
isSynchronous: true
name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
password:
name: ha-rep-pw-dbcluster-sample
namespace: default
passwordResourceVersion: "896080"
role: Upstream
type: Physical
username: alloydbreplica
Pastikan anotasi disableHealthcheck bernilai salah. Anotasi ini hanya boleh dinonaktifkan selama failover atau switchover.
apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
annotations:
dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
dbs.internal.dbadmin.goog/disableHealthcheck: "false"
dr-secondary: "false"
forceReconcile: "1730414498"
Kueri
Untuk memverifikasi bahwa resource di pod DB disiapkan dengan benar, login ke database sebagai pengguna administrator alloydbadmin. Kemudian, jalankan kueri berikut:
Slot replikasi
\x on
select * from pg_replication_slots;
-[ RECORD 1 ]-------+---------------------------------------------
slot_name | d85d_dbcluster_sample
plugin |
slot_type | physical
datoid |
database |
temporary | f
active | t
active_pid | 250
xmin | 16318
catalog_xmin |
restart_lsn | 0/CA657F0
confirmed_flush_lsn |
wal_status | reserved
safe_wal_size |
two_phase | f
Status yang baik adalah keberadaan slot replikasi yang memiliki nama yang sama dengan instance standby. Tidak adanya slot replikasi menunjukkan bahwa langkah penyiapan pertama belum berhasil diselesaikan.
Jika active bukan t (benar), berarti instance standby tidak terhubung karena
alasan tertentu (jaringan, instance standby tidak menyelesaikan penyiapan, dll.) dan proses debug kemungkinan
perlu dilanjutkan di sisi instance standby.
Statistik replikasi
\x on
select * from pg_stat_replication;
-[ RECORD 1 ]----+----------------------------------------------------------------
pid | 250
usesysid | 16385
usename | alloydbreplica
application_name | d85d_dbcluster_sample
client_addr | 10.54.79.196
client_hostname | gke-samwise-default-pool-afaf152d-8197.us-central1-a.c.foo
client_port | 24914
backend_start | 2024-10-30 21:44:26.408261+00
backend_xmin |
state | streaming
sent_lsn | 0/CA64DA8
write_lsn | 0/CA64DA8
flush_lsn | 0/CA64DA8
replay_lsn | 0/CA64DA8
write_lag |
flush_lag |
replay_lag |
sync_priority | 2
sync_state | sync
reply_time | 2024-11-04 22:08:04.370838+00
Jika tidak ada, berarti tidak ada koneksi aktif.
sync_state harus sync. Jika bukan sync, berarti langkah terakhir penyiapan tidak selesai. Melihat log / tugas akan memberikan detail selengkapnya.
Verifikasi standby
Instance standby harus memiliki profil replikasi yang cocok dengan profil yang sama dengan instance utama:
replication:
profiles:
- host: 10.54.79.210
isActive: true
isSynchronous: true
name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
passwordResourceVersion: "896080"
port: 5432
role: Downstream
type: Physical
username: alloydbreplica
Jika tidak ada koneksi dari instance standby ke instance utama, ada dua kemungkinan umum:
- Instance standby masih disiapkan.
- Instance standby mengalami error saat menyiapkan atau mencoba terhubung.
Untuk memeriksa apakah opsi 1 terjadi, dapatkan log pod database dan cari pernyataan log yang bernama dbdaemon/setupPhysicalReplicationDownstream. Berikut adalah contoh log penyiapan yang berhasil:
I1104 22:42:42.604871 103 replication.go:107] "dbdaemon/setupPhysicalReplicationDownstream: begin setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:42,605 INFO waiting for postgres to stop
2024-11-04 22:42:43,566 INFO stopped: postgres (exit status 0)
I1104 22:42:43.567590 103 replication.go:131] "dbdaemon/setupPhysicalReplicationDownstream: about to call pg_basebackup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample" cmd=["-h","10.54.79.210","-D","/mnt/disks/pgsql/pg_basebackup_data","-U","alloydbreplica","-v","-P","-p","5432","-w","-c","fast"]
I1104 22:42:44.206403 103 replication.go:139] "dbdaemon/setupPhysicalReplicationDownstream: pg_basebackup finished" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.206440 103 replication.go:141] "dbdaemon/setupPhysicalReplicationDownstream: replacing data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244749 103 replication.go:148] "dbdaemon/setupPhysicalReplicationDownstream: replaced data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244783 103 replication.go:150] "dbdaemon/setupPhysicalReplicationDownstream: Creating config files" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251565 103 replication.go:155] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql config file for log archiving" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251621 103 replication.go:160] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql auto config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251689 103 replication.go:165] "dbdaemon/setupPhysicalReplicationDownstream: Successfully wrote to config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:44,256 INFO spawned: 'postgres' with pid 271
2024-11-04 22:42:45,469 INFO success: postgres entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
I1104 22:42:45.469838 103 replication.go:174] "dbdaemon/setupPhysicalReplicationDownstream: backup replication configuration after changing replication config" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:45.476732 103 replication.go:179] "dbdaemon/setupPhysicalReplicationDownstream: finished standby setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
Jika ada error koneksi, periksa log pod database serta file log di database di /obs/diagnostic/postgresql.log dan lihat error yang terjadi saat mencoba terhubung. Salah satu error umum adalah tidak adanya konektivitas jaringan antara instance standby dan instance utama.
Perbaikan manual
Cara termudah untuk memperbaiki masalah HA adalah menonaktifkan, lalu mengaktifkan kembali HA dengan menetapkan numberOfStandbys ke 0, lalu meresetnya ke angka yang Anda inginkan. Jika instance standby macet dan tidak dapat dinonaktifkan, ikuti langkah-langkah berikut untuk mereset penyiapan HA secara manual agar kosong:
- Hapus instance standby secara manual.
Hubungkan ke database utama. Kueri slot replikasi saat ini dan hapus slot replikasi instance standby yang ingin Anda hapus:
select pg_drop_replication_slot('REPLICATION_SLOT_NAME');Hapus profil replikasi dari instance utama yang ingin Anda hapus.
Jika instance belum direkonsiliasi baru-baru ini, Anda dapat mengedit nilai anotasi forceReconcile. Tetapkan ke nilai numerik apa pun, yang merupakan stempel waktu terakhir kali anotasi tersebut diperbarui. Satu-satunya tujuan anotasi tersebut adalah untuk menyediakan kolom yang dapat kita perbarui untuk memaksa rekonsiliasi baru.
apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
annotations:
dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
dbs.internal.dbadmin.goog/disableHealthcheck: "false"
dr-secondary: "false"
forceReconcile: "1730414498"
Mengumpulkan log audit dan mesin database
Log mesin database dan log audit tersedia sebagai file di dalam pod database (memerlukan akses root):
obs/diagnostic/postgresql.logobs/diagnostic/postgresql.audit
DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl exec -c database -n DB_CLUSTER_NAMESPACE ${DB_POD} -it -- /bin/bash
Saat terhubung ke penampung database:
ls -l /obs/diagnostic/
Contoh output:
drwx--S--- 2 postgres postgres 4096 Aug 13 10:22 archive
-rw------- 1 postgres postgres 256050 Aug 13 13:25 postgresql.internal
-rw------- 1 postgres postgres 1594799 Aug 13 13:25 postgresql.log
Mengumpulkan metrik database dan pod database
Operator AlloyDB Omni menyediakan kumpulan metrik dasar untuk mesin AlloyDB Omni dan pod yang menghostingnya. Metrik tersedia sebagai endpoint Prometheus yang tersedia di port 9187. Untuk mengakses endpoint, Anda harus mengidentifikasi nama pod untuk pod database menggunakan label DBCluster dan memulai penerusan port sebagai berikut:
DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl port-forward -n DB_CLUSTER_NAMESPACE ${DB_POD} 9187:9187
Mengakses metrik pod database
Di terminal lain:
curl http://localhost:9187/metrics | grep HELP
Untuk mengetahui informasi selengkapnya tentang pemantauan, lihat Memantau AlloyDB Omni.
Anda juga dapat mengonfigurasi Prometheus untuk melakukan scraping metrik di cluster Kubernetes. Lihat konfigurasi penemuan layanan Prometheus Kubernetes untuk mengetahui detailnya.